Skip to main content
Version: v3

Migrate from v2 to v3

Migrate an existing odo component from v2 to v3

If you have created an odo component using odo v2, this section will help you move it to use odo v3.

Step 1

cd into the component directory, and delete the component from the Kubernetes cluster:

odo delete

Step 2

Download and install odo v3.

Step 3

Run odo dev to start developing your application using odo v3.

Step 4

Run odo list to see a list of components that are running on the cluster and what version of odo they are running.

Where are odo push and odo watch commands?

odo push and odo watch have been replaced in v3 by a single command - odo dev.

In v2, if you wanted to automatically sync the code on developer system with the application running on a Kubernetes cluster, you had to perform two steps - first odo push to start the application on the cluster, and second odo watch to automatically sync the code. In v3, odo dev performs both actions with a single command.

odo dev is not just a replacement for these two commands. It's also different in behaviour in that, it's a long-running process that's going to block the terminal. Hitting Ctrl+c will stop the process and cleanup the component from the cluster. In v2, you had to use odo delete/odo component delete to delete inner loop resources of the component from the cluster.

What happened to Ingress/Route?

If you have used odo v2, you must have used Ingress (on Kubernetes) or Route (on OpenShift) to access the application that was pushed to the cluster using odo push. odo v3 no longer creates an Ingress or a Route. Instead, it uses port-forwarding.

When running odo dev, odo forwards a port on the development system to the port on the container cluster allowing you remote access to your deployed application. It also prints the information when the application has started on the cluster:

$ odo dev
...
...
- Forwarding from 127.0.0.1:40001 -> 8080

This indicates that the port 40001 on the development system has been forwarded to port 8080 of the application represented by the current odo component.

NOTE

odo no longer supports creation of Ingress / Route out of the box. The odo url set of commands no longer exist in v3.

Changes to the way component debugging works

In odo v2, odo push --debug was used to run a component in debug mode. To setup port forwarding to the component's debug port, you had to run odo debug port-forward.

In odo v3, you need to specify the debug port in the devfile.yaml as an endpoint, and run odo dev --debug to start the component in debug mode. For example, a container component in the devfile should look like below, where port 3000 is the application port and 5858 is the debug port:

- name: runtime
container:
image: registry.access.redhat.com/ubi8/nodejs-12:1-36
memoryLimit: 1024Mi
endpoints:
- name: "3000-tcp"
targetPort: 3000
- name: debug
exposure: none
targetPort: 5858

Changes to default configurations

Ephemeral storage

By default, odo v2 used ephemeral storage for the components created using it. However, this has changed in odo v3, and it now uses the underlying storage (Persistent Volumes) configured for use by the users. If you would like to continue using ephemeral storage for odo components, you could change the configuration by doing:

odo preference set Ephemeral true

Commands added, modified or removed in v3

The following table contains a list of odo commands that have either been modified or removed. In case of a modification, the modified command is mentioned in the v3 column. Please refer below legend beforehand:

  • 👷 currently not implemented, but might get implemented in future
  • ❌ not implemented, no plans for implementation
v2v3
app delete
app describe
app list
catalog describe service
catalog describe componentregistry --details
catalog list service👷odo list services
catalog list componentregistry
catalog search service
catalog search componentregistry --filter
config set
config unset
config view
debug info❌ (not needed as debug mode is start with odo dev --debug command that blocks terminal, the application can be running in inner-loop mode only if odo dev is running in terminal)
debug port-forward❌ (port forwarding is automatic when users execute odo dev --debug as long as the endpoint is defined in the devfile)
env set
env uset
env view
preference setpreference set
preference unsetpreference unset
preference viewpreference view
project createcreate namespace
project deletedelete namespace
project get
project listlist namespace
project setset namespace
registry addpreference add registry
registry deletepreference remove registry
registry listpreference view
registry updateno command for update. If needed, it can be done using preference remove registry and preference add registry
service create/delete/describe/list
storage create/delete/list
test👷(will be implemented after v3-GA) #6070
url create/delete/list❌ (odo dev automatically sets port forwarding between container and localhost. If users for some reason require Ingress or Route for inner-loop development they will have to explicitly define them in the devfile as kubernetes components)
build-imagesbuild-images
deploydeploy
loginlogin
logoutlogout
create / component createinit
delete / component deletedelete component
describe / component describedescribe component
exec / component exec
link / component linkadd binding
listlog / component log
logspush / component push
status / component status
unlink / component unlinkremove binding
watch / component watchdev
describe binding
list binding
analyze