https://odo.dev/blog odo Blog 2025-10-23T00:00:00.000Z https://github.com/jpmonette/feed odo Blog https://odo.dev/img/favicon.ico <![CDATA[๐Ÿ“ฃ odo is deprecated ๐Ÿ“ฃ]]> https://odo.dev/blog/odo-deprecation-announcement 2025-10-23T00:00:00.000Z ๐Ÿ“ฃ The odo project is officially deprecated, effective today (Oct 23, 2025)! ๐Ÿ“ฃ

You can find more information and dates in "The odo CLI is deprecated: What developers need to know".

]]> The odo Team <![CDATA[odo v3.16.1 Released]]> https://odo.dev/blog/odo-v3.16.1 2024-06-25T00:00:00.000Z odo v3.16.1 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Note that there is no v3.16.0 release due to an issue with the build pipelines.

What's Changedโ€‹

New Contributorsโ€‹

Full Changelog: https://github.com/redhat-developer/odo/compare/v3.15.0...v3.16.1

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Armel Soro https://github.com/rm3l <![CDATA[How to write custom devfile for your project]]> https://odo.dev/blog/how-to-write-custom-devfile-for-your-project 2023-10-10T00:00:00.000Z Developers often need to customize their development environments to work with a specific project. In many cases, this involves configuring a stack of tools and libraries to work together seamlessly. Fortunately, a Devfile is a single configuration file that can set up an entire development environment with dependencies and services.

By default, the Devfile Registry provides a set of pre-defined Stacks that developers can use to set up development environments quickly. These stacks provide a solid foundation to build upon and can save developers a tremendous amount of time.

However, the predefined stacks may not always suit your needs. In this blog post, we'll explore how to write your own Devfile from scratch to fit your project's needs better. This is also a great opportunity to look more closely at the Devfile structure and how it works.

We'll write a Devfile for a Backstage project as an example.

Backstage recommends using NodeJS 18 and requires Yarn. At the time of writing, no Devfile in Devfile Registry is using NodeJS 18 or Yarn. If you are in a situation like this, writing Devfile on your own makes more sense instead of starting with Devfile from the registry that has nothing in common with what you need.

First, we will need Backstage source code. If you have an existing Backstage project, you can use that, or you can follow Backstage Getting Started Guide (TL;DR: if you already have NodeJS installed, run npx @backstage/create-app@latest)

Now we can start creating a new devfile.yaml.

Structure of a Devfileโ€‹

Create a new file called devfile.yaml in the Backstage root directory and open it in your favorite IDE or editor. We will start with a basic structure of the Devfile and some metadata.

schemaVersion: 2.2.0
metadata:
  name: my-backstage

commands:

components:

Two most important sections in Devfile are commands and components.

Componentsโ€‹

components section is a list of components that our development environment is composed of. There are different types of components available in Devfile.

  • container - this is probably the most common component type. Most Devfiles will have at least one container component. This allows us to define containers in which the exec commands should be executed, or it can be used to define containers that run additional services that our application requires.
  • kubernetes - this component allows us to create any Kubernetes resource. Kubernetes resource can be either directly in-lined in the Devfile or referenced by URI.
  • image - this component can be used to build images from Dockerfile. It can be combined with the container component. The image component creates a container image, which can later be used in container definition.
  • volume - this component is used with container components and allows us to create volumes. Volumes can be used to ensure persistence across container restarts, or to share data between containers. In Kubernetes world Devfile volume is usually translated into PersistentVolumeClaim.

Let's start with adding our first component of a type container. In this example, it will be the only component we will use.

schemaVersion: 2.2.0
metadata:
  name: my-backstage

commands:

components:
  - name: nodejs
    container:
      image: registry.access.redhat.com/ubi9/nodejs-18:latest
      sourceMapping: /projects
      command: ['tail', '-f', '/dev/null']
      memoryLimit: 2Gi
      endpoints:
        - name: frontend
          targetPort: 3000
          exposure: public
        - name: backend
          targetPort: 7007
          exposure: public

Here is an explanation of what each line does.

  • image: registry.access.redhat.com/ubi9/nodejs-18:latest - defines an image that will be used to create a container. Here we are using Red Hat's NodeJS image.
  • sourceMapping: /projects - defines where in the container the source code of our application will be. odo dev process makes sure that the local source code is pushed to this location in the container.
  • command: ['tail', '-f', '/dev/null'] - this will be the main command in the container. In this example the command does nothing; it is there to override the default image command to make sure that the container stays running and we execute our commands inside it.
  • memoryLimit: 2Gi - ensure that we have enough memory to build and run our application
  • endpoints - define what ports should be exposed and how. For example, the next block defines that port 3000 should be exposed as public. Public means that the port can be accessible from outside of the cluster.
       - name: frontend
           targetPort: 3000
           exposure: public

Commandsโ€‹

commands section defines actions that can be performed. There are three types of commands exec, apply, and composite.

  • exec - this just executes the command defined in commandLine inside the container. The container needs to be defined in components section.
  • apply - most commonly coupled with kubernetes component. It creates or, in other words, applies the component referenced in this command.
  • composite - this command can be used to execute multiple existing commands sequentially or in parallel.

Let's add commands to our Devfile.

schemaVersion: 2.2.0
metadata:
  name: my-backstage

commands:
  - id: yarn-install
    exec:
      commandLine: npx yarn install
      component: nodejs
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: build
        isDefault: true
    
  - id: run-dev
    exec:
      commandLine: npx yarn run dev
      component: nodejs
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: run
        isDefault: true

components:
  - name: nodejs
    container:
      image: registry.access.redhat.com/ubi9/nodejs-18:latest
      sourceMapping: /projects
      command: ['tail', '-f', '/dev/null']
      memoryLimit: 2Gi
      endpoints:
        - name: frontend
          targetPort: 3000
          exposure: public
        - name: backend
          targetPort: 7007
          exposure: public

We have added two commands yarn-install and run-dev. Let's use the first one to explain what each line means.

  • commandLine: npx yarn install - this defines that the command npx yarn install should be executed when Devfile command yarn-install is executed.
  • component: nodejs - this defines in which container component the command defined in commandLine should be executed.
  • workingDir: ${PROJECT_SOURCE} - defines in what working directory the command will be executed. Here we are using ${PROJECT_SOURCE} variable. This variable will always point to the root directory with the source code. This will be the same path as we used in sourceMapping in the container component
  • group: - defines to what group this command belongs to. There are build, run, debug, test, deploy.
          kind: build
          isDefault: true
    The previous block defines that this command belongs to build group and is the default command. Each group can have only one default command. When you run odo dev, odo automatically executes the default command in build group first, followed by the default command in run group.

Ideally, this would be all we need, and you could use this Devfile with odo.

Fixing issuesโ€‹

If you try to use Devfile as we have it, you will see an error. The first problem is that the NodeJS image doesn't have yarn installed.

Install yarn into the containerโ€‹

To add yarn, we will leverage Devfile feature called events. Events allow us to define commands that should be executed on predefined events. There are 3 events that you can use.

  • preStart - executed before the main container is started.
  • postStart - executed after the main container is started.
  • preStop - executed before the main container is stopped.

In our case we will use postStart event and execute npm install -g yarn.

schemaVersion: 2.2.0
metadata:
  name: my-backstage

commands:
  - id: install-yarn
    exec:
      commandLine: npm install -g yarn
      workingDir: ${PROJECT_SOURCE}
      component: nodejs
  - id: yarn-install
    exec:
      commandLine: npx yarn install
      component: nodejs
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: build
        isDefault: true
    
  - id: run-start
    exec:
      commandLine: npx yarn run dev
      component: nodejs
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: run
        isDefault: true
    
components:
  - name: nodejs
    container:
      image: registry.access.redhat.com/ubi9/nodejs-18:latest
      sourceMapping: /projects
      command: ['tail', '-f', '/dev/null']
      memoryLimit: 2Gi
      endpoints:
        - name: frontend
          targetPort: 3000
          exposure: public
        - name: backend
          targetPort: 7007
          exposure: public
events:
  postStart:
    - install-yarn

Even after installing yarn you won't be able to use this Devfile with odo and Backstage source code.

No space left on deviceโ€‹

You will get NOSPC: no space left on device error.

This is due to the #6836 issue in odo. At the time of writing this, odo creates a 2GB volume for the source code. For Backstage and it's node_modules this is not enough. Luckily, there is a simple workaround that we can do in Devfile.

We can create extra volume just for /projects/node_modules. This will put node_modules into a separate volume for the source code.

Full Devfile should look like this

schemaVersion: 2.2.0
metadata:
  name: my-backstage

commands:
  - id: install-yarn
    exec:
      commandLine: npm install -g yarn
      workingDir: ${PROJECT_SOURCE}
      component: nodejs

  - id: yarn-install
    exec:
      commandLine: npx yarn install
      component: nodejs
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: build
        isDefault: true
    
  - id: run-start
    exec:
      commandLine: npx yarn run dev
      component: nodejs
      workingDir: ${PROJECT_SOURCE}
      group:
        kind: run
        isDefault: true
    
components:
  - name: nodejs
    container:
      image: registry.access.redhat.com/ubi9/nodejs-18:latest
      sourceMapping: /projects
      command: ['tail', '-f', '/dev/null']
      memoryLimit: 2Gi
      # workaround for https://github.com/redhat-developer/odo/issues/6836
      volumeMounts:
        - name: node-modules
          path: /projects/node_modules
      endpoints:
        - name: frontend
          targetPort: 3000
          exposure: public
        - name: backend
          targetPort: 7007
          exposure: public
  - name: node-modules
    volume:
      size: 3Gi 

events:
  postStart:
    - install-yarn

Now we have completed our devfile.yaml for Backstage. To use it with Backstage we will need more than just running odo dev. We must provide additional flags to ensure that Backstage's frontend and backend can communicate. From the Devfile you can see that there are two ports. 3000 for frontend and 7007 for backend. In default configuration frontend expects that the backend is reachable on localhost:7007. With odo, we can use --port-forward flag to ensure that our local port 7007 is redirected to the backend, for the consistency we will also redirect our local port 3000 to the frontend. 

odo dev --port-forward 3000:3000 --port-forward 7007:7007

You should now be able to access Backstage on 127.0.0.1:3000.

]]> Tomas Kral https://github.com/kadel <![CDATA[odo v3.15.0 Released]]> https://odo.dev/blog/odo-v3.15.0 2023-09-26T00:00:00.000Z odo v3.15.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release:

Featuresโ€‹

odo init: Filter Devfile stacks by architecturesโ€‹

When running odo init either interactively or non-interactively, the supported architectures declared in the Devfile are now handled.

odo UI: create volumes, autoBuild/deployByDefault support, volumes, resources editionโ€‹

The creation of volumes and volume mounts has been added, as well as the support of the autoBuild/deployByDefault parameters for Images and Resources.

The edition of Volumes, Resources, Images, Containers and Commands has been implemented.

[Dev UI] Deleting single item from multi-value fieldsโ€‹

This adds the ability in the odo dev UI to delete single items from multi-value fields:

  • container endpoints
  • volume mounts
  • multi-text fields, like Container Command and Args, or Image Build Args
  • multi-key-value fields, like Container Env Vars, Deployment Annotations and Service Annotations
  • multi-commands fields, in use in Composite Commands

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Release of v3.15.0

v3.15.0 (2023-09-26)โ€‹

Full Changelog

Features/Enhancements:

  • Ignore devstate when existing process name is not odo + delete devstate files with odo delete component #7090 (feloy)
  • [UI] Allow single item deletion from multi-value fields #7084 (rm3l)
  • Display icon in metadata #7078 (feloy)
  • [ui] Edit container #7077 (feloy)
  • [ui] Update commands #7073 (feloy)
  • [ui] Edit images #7068 (feloy)
  • Warning if version of Devfile is different from 2.2.0 #7065 (feloy)
  • [UI] Make sure form validation displays non-valid fields as red in all forms #7064 (rm3l)
  • [ui] Edit resources #7062 (feloy)
  • [ui] Edit volumes #7061 (feloy)
  • [ui] Set AutoBuild and DeployByDefault #7051 (feloy)
  • [ui] Complete container creation #7035 (feloy)

Bugs:

  • Make warning messages more visible #7097 (rm3l)
  • Make sure a Deploy command is present in the Devfile before auto-applying components #7093 (rm3l)
  • Fix API Server panic when volume component has no ephemeral field set #7080 (rm3l)
  • Make sure to run parallel commands part of a composite command in parallel #7075 (rm3l)
  • [ui] Fix Resource URI button not checked #7070 (feloy)
  • Fix invalid link to installation page from all release blog posts #7069 (rm3l)
  • Add a Devfile dependency for commands #7063 (feloy)
  • Fix API Server port detection issue by making sure the same local address is used for listening and checking if the port is available #7041 (rm3l)

Documentation:

Testing/CI:

  • Fix potential namespace name collision issue with odo create/delete/list/set namespace/project tests #7050 (rm3l)
  • Use multiarch image for postgresql instance #7049 (feloy)

Cleanup/Refactor:

  • Replace github.com/ghodss/yaml with sigs.k8s.io/yaml #7005 (Juneezee)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> feloy https://github.com/feloy <![CDATA[odo v3.14.0 Released]]> https://odo.dev/blog/odo-v3.14.0 2023-08-22T00:00:00.000Z odo v3.14.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Featuresโ€‹

odo dev Web UI out of the experimental modeโ€‹

The odo web User Interface, which was previously available experimentally, is now out of the experimental mode. This means that it will be exposed and available out of the box whenever a Dev Session is started with odo dev, regardless of the experimental mode status.

This web UI currently aims at providing a simplified way to:

  1. understand the Devfile and how odo interprets it.
  2. edit the Devfile and tailor it to your project needs.

It is still a work in progress; so we are looking for feedback to improve it.

To use it, just start odo dev (regardless of the target platform) and navigate to the URL displayed in the output (or retrievable via the odo describe component command).

Example Output
$ odo dev --platform podman                                                                                                                                                                    
[...]                                                                                                                                                                                        
                                                                                                                                                                                               
โ†ช Running on podman in Dev mode
 โœ“  Web console accessible at http://localhost:20000/                                                                                                                                          
 โœ“  API Server started at http://localhost:20000/api/v1                                                                                                                                        
 โœ“  API documentation accessible at http://localhost:20000/swagger-ui/
 โœ“  Deploying pod [13s]                                                                                                                                                                        
 โœ“  Syncing files into the container [2s]                                                                                                                                                      
 โœ“  Executing post-start command in container (command: 0-install-yarn) [1s]
 โœ“  Building your application in container (command: doc-install-deps) [25s]
 โ€ข  Executing the application (command: doc-start)  ...
 โœ“  Waiting for the application to be ready [1s]
 -  Forwarding from 127.0.0.1:20001 -> 3000

โ†ช Dev mode
 Status:
 Watching for changes in the current directory /home/user/project

Web console accessible at http://localhost:20000/

Keyboard Commands:
[Ctrl+c] - Exit and delete resources from podman
     [p] - Manually apply local changes to the application on podman

Support for Volumes in the odo Web UIโ€‹

It is now possible to create Volumes in the odo Web UI and also to specify volume mounts from the Containers tab:

Add Volume

Add Volume Mount

--filter in odo registry now supports a list of termsโ€‹

When running odo registry --filter, you can now pass a list of terms to filter the results. --filter is now a comma-separated list of terms for filtering, and search is done using a logical AND against the name or description or supported architectures of the Devfile Stacks.

Example Output
$ odo registry --filter s390x,java
                                                          
 NAME                          REGISTRY                DESCRIPTION                                  ARCHITECTURES          VERSIONS     
 java-maven                    DefaultDevfileRegistry  Java application based on Maven 3.6 and ...                         1.2.0        
 java-openliberty              DefaultDevfileRegistry  Java application based on Java 11 and Ma...  amd64, ppc64le, s390x  0.9.0        
 java-openliberty-gradle       DefaultDevfileRegistry  Java application based on Java 11, Gradl...  amd64, ppc64le, s390x  0.4.0        
 java-quarkus                  DefaultDevfileRegistry  Java application using Quarkus and OpenJ...                         1.3.0        
 java-springboot               DefaultDevfileRegistry  Spring Boot using Java                                              1.2.0, 2.0.0 
 java-vertx                    DefaultDevfileRegistry  Java application using Vert.x and OpenJD...                         1.2.0        
 java-websphereliberty         DefaultDevfileRegistry  Java application based Java 11 and Maven...  amd64, ppc64le, s390x  0.9.0        
 java-websphereliberty-gradle  DefaultDevfileRegistry  Java application based on Java 11 and Gr...  amd64, ppc64le, s390x  0.4.0        
 java-wildfly                  DefaultDevfileRegistry  JakartaEE  application using WildFly                                1.1.0, 2.0.0 
 java-wildfly-bootable-jar     DefaultDevfileRegistry  Java application using WildFly in bootab...                         1.1.0

Filtering devfile stacks based on the architecture field in metadata when running odo initโ€‹

When running odo init either interactively or non-interactively, the supported architectures declared in the Devfile are now handled.

In the interactive mode, odo init now allows you to pick the architectures you want or displays it from the Devfile suggested for your project.

Example Output
$ odo init
[...]
Interactive mode enabled, please answer the following questions:
 โœ“  Determining a Devfile for the current directory [603ms]
 โš   Could not determine a Devfile based on the files in the current directory: No valid devfile found for project in /tmp/test2
? Select architectures to filter by:  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
> [x]  amd64
  [ ]  arm64
  [ ]  ppc64le
  [ ]  s390x
[...]

In the non-interactive mode, odo init allows you to specify the architectures using a repeatable --architecture option.

Example Output
$ odo init --name my-app --devfile nodejs \
    --architecture amd64 \
    --architecture s390x 

[...]

Your new component 'my-app' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Full Changelog

Features/Enhancements:

  • Move UI out of experimental mode #7012 (feloy)
  • [ui] Create/Delete volumes #7029 (feloy)
  • Set Save button on top, enable it only when devfile changed #7015 (feloy)
  • odo init filters devfile stacks by supported architectures #7004 (feloy)
  • Do not display API logs by default #7008 (feloy)

Bugs:

Documentation:

  • Update README main title and display preview video #7037 (rm3l)
  • Update home page preview video with support of Podman #7023 (rm3l)
  • Update Quickstart Guides with Podman support #7016 (rm3l)
  • Document how to change the dev container image pull policy #7014 (rm3l)
  • Use image selector feature in "Deploying application" guides #7013 (rm3l)

Merged pull requests:

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Armel Soro https://github.com/rm3l <![CDATA[odo v3.13.0 Released]]> https://odo.dev/blog/odo-v3.13.0 2023-07-24T00:00:00.000Z odo v3.13.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://www.youtube.com/playlist?list=PLGMB2PY4SNOr967FHII4sye2ucBdCuD1b

Featuresโ€‹

odo describe component displaying information about the running API Serverโ€‹

The command odo describe component now displays the information to access the API server started by odo dev. When this command is executed in Experimental mode, it also displays the information to access the odo graphical user interface.

odo dev --logs displaying logs during a Dev sessionโ€‹

Previously it was necessary to execute an odo logs command in parallel to a Dev session started with odo dev, to be able to get the logs of the running component.

You can now ask with odo dev --logs to display the logs of the component in the output of the odo dev command.

API documentationโ€‹

The documentation of the odo API served during a Dev session is accessible from the Dev session itself.

odo Graphical User Interfaceโ€‹

The PoC available at https://devfile.odo.dev has been integrated into odo. When running odo dev in experimental mode, you can access this inteface to view and edit the Devfile used for the Dev session.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Release of v3.13.0

v3.13.0 (2023-07-24)โ€‹

Full Changelog

Features/Enhancements:

  • Move from github.com/feloy/devfile-builder #6937 (feloy)
  • Alert user when Devfile is synced #6996 (feloy)
  • Serve SwaggerUI #6989 (feloy)
  • Remove API Server from experimental mode, set UI Server as experimental #6985 (feloy)
  • Add UI telemetry #6981 (feloy)
  • Propagate local Devfile changes to the UI #6970 (rm3l)
  • Display information about the running API Server and web UI in odo describe component output #6964 (rm3l)
  • Support Architectures in odo registry #6959 (rm3l)
  • odo dev --logs #6957 (feloy)
  • Serve UI from api server #6954 (feloy)
  • Add new --run-port flag to odo init to set ports non-interactively #6953 (rm3l)
  • Implement odo api-server command #6952 (feloy)
  • Add /devfile PUT and GET endpoints #6950 (feloy)
  • Display list of commands from the local devfile in odo describe component output #6944 (rm3l)
  • Implement devfile state in odo api #6941 (feloy)
  • Watch for new pods when logs --follow #6914 (feloy)

Bugs:

  • Fix potential port conflict issue with the API server tests by using a random server port if --random-ports is set #6995 (rm3l)
  • Add Preference dependency to api-server command #6974 (feloy)
  • [UX] Fix default value of ImageRegistry in odo preference view output #6951 (valaparthvi)
  • Fix oc to odo project translation #6949 (valaparthvi)
  • Fix CI Devfile Registry URL used in OCP interop tests #6946 (rm3l)
  • Document and return JSON data for API errors #6938 (feloy)

Documentation:

Testing/CI:

Cleanup/Refactor:

  • Generate static UI files from within a container #6972 (rm3l)
  • Update go.mod with new location of the Alizer library #6962 (rm3l)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> feloy https://github.com/feloy <![CDATA[odo v3.12.0 Released]]> https://odo.dev/blog/odo-v3.12.0 2023-06-27T00:00:00.000Z odo v3.12.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check these playlists for an overview of the most notable changes in this release:

Featuresโ€‹

Nightly binariesโ€‹

To make it easier to try out new features of odo, you no longer need to wait until a new version is released. We now publish nightly builds of odo with any changes that have been merged into the main branch at that time.

caution

Bear in mind that such builds are provided as is and might be highly unstable.

Find out more on the installation page for instructions on how to download and install nightly builds.

Full control over the application lifecycle with odo dev --no-commands and odo runโ€‹

Prior to v3.12.0, odo dev would implicitly run the build and run/debug commands automatically, and users had no control over the commands execution. To give users more control over the lifecycle of their applications, we wanted to make it possible to not only start a Dev Session without any assumptions on the commands, but also to run any command manually at any time.

The new --no-commands option allows to start a Dev Session without implicitly running the build and run/debug commands, and the new odo run command allows to run any command from the Devfile against an already-running Dev session.

To make the most out of this workflow, users can:

  1. start a Dev session without executing any commands, with odo dev --no-commands
  2. at any time, and in a separate terminal, run any commands defined in the Devfile, with odo run

To make it easier to discover all the commands that are defined in the Devfile, we will be changing the output of odo describe component, to display the list of commands from the Devfile. This will be available in the upcoming v3.13.0, but you can already give it a try by downloading a nightly build.

Syncing .git directory is now possible when running odo devโ€‹

odo dev now has a new --sync-git-dir option, allowing to synchronize the .git folder (which might be huge) into the Dev container. By default, the .git folder is not synchronized, but this option can be helpful for applications that rely on the Git history.

JSON output for odo version and Podman version if availableโ€‹

odo version now displays the version of Podman if available, which should allow users to determine if they can use odo against Podman or not. Note that we have a timeout of 1s for Podman to return a response, otherwise it will be considered unavailable. But this value is configurable via the PODMAN_CMD_INIT_TIMEOUT environment variable.

We are also adding JSON support for the output of odo version. Find out more on the JSON Output documentation.

[Experimental] API Server to control a running odo dev sessionโ€‹

To make it easier to interact with Dev Sessions, we are introducing an experimental feature of starting an API Server based off of this OpenAPI specification. The rationale behind this is to simplify interactions with running Dev Sessions, while paving the way to building awesome things on top of this API server.

At the moment, we have endpoints for:

  • controlling the odo dev instance (getting details about it, or even stop it)
  • getting details about the running component and its Devfile
  • sending requests for re-pushing, exactly as if the p key was pressed in the terminal running odo dev

See the demo below for more details:

Note that this is currently an opt-in feature. To try it out, please enable the experimental mode and run odo dev with the --api-server flag, e.g.:

ODO_EXPERIMENTAL_MODE=t odo dev --api-server
Example output
$ ODO_EXPERIMENTAL_MODE=t odo dev --api-server

============================================================================
โš  Experimental mode enabled. Use at your own risk.
More details on https://odo.dev/docs/user-guides/advanced/experimental-mode
============================================================================

  __
 /  \__     Developing using the "odo-dev" Devfile
 \__/  \    Namespace: demo-api-server
 /  \__/    odo version: v3.12.0
 \__/

โ†ช Running on the cluster in Dev mode
I0703 17:46:42.977459  609287 starterserver.go:58] API Server started at localhost:20000/api/v1
 โ€ข  Waiting for Kubernetes resources  ...
 โš   Pod is Pending
 โœ“  Pod is Running
 โœ“  Syncing files into the container [2s]
 โœ“  Executing post-start command in container (command: 0-install-yarn) [2s]
 โœ“  Building your application in container (command: doc-install-deps) [22s]
 โ€ข  Executing the application (command: doc-start)  ...
 โœ“  Waiting for the application to be ready [1s]
 -  Forwarding from 127.0.0.1:20001 -> 3000

โ†ช Dev mode
 Status:
 Watching for changes in the current directory /home/asoro/work/projects/odo/docs/website

 Keyboard Commands:
[Ctrl+c] - Exit and delete resources from the cluster
     [p] - Manually apply local changes to the application on the cluster

From there, you can see from the output of odo dev where the API Server is exposed (hint: API Server started at localhost:20000/api/v1).

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Full Changelog

Features/Enhancements:

Bugs:

  • List namespace right after namespace has been created #6922 (valaparthvi)
  • Do not necessarily error out if odo dev is stopped via Ctrl+C #6917 (rm3l)
  • Do not return an error in odo analyze if current directory contains an invalid Devfile #6905 (rm3l)
  • Make sure the "Syncing files into the container" spinner is displayed on Podman #6863 (rm3l)
  • Bump Alizer to fix potential panic when analyzing large projects #6926 (rm3l)

Documentation:

Testing/CI:

  • Fix potential issue in odo version nightly tests if user does not have permission to get the OpenShift version #6933 (rm3l)
  • Send tests results to Sheet #6873 (feloy)
  • Skip tests if all changes in docs #6870 (feloy)
  • Temporarily downgrade Podman on GitHub to fix CI failures for Podman tests #6928 (rm3l)
  • Skip IBM Cloud tests for changes that do not affect odo behavior #6924 (valaparthvi)
  • Stop test as soon as expectation is verified #6891 (feloy)
  • Set FsGroup for spring boot test #6931 (feloy)
  • Fix service binding skip on Windows #6929 (feloy)
  • Disable service binding related integration tests #6920 (feloy)
  • Improve website PR preview workflow #6907 (rm3l)
  • Replace odo delete component integration with unit tests #6904 (feloy)
  • Refactor StartDevMode to return a single object instead of multiple args #6886 (valaparthvi)
  • Unit tests/inject test clientset #6874 (feloy)
  • [Dogfooding] Create website deploy previews for PRs using odo deploy #6871 (rm3l)

Merged pull requests:

  • Bump version to 3.12.0 #6935 (rm3l)
  • Build nightly binaries of odo and make them available (via IBM Cloud Object Storage) #6875 (rm3l)
  • Mark issues and pull requests as stale #6872 (ritudes)
  • Website: Bump webpack from 5.81.0 to 5.85.0 in /docs/website #6868 (dependabot[bot])
  • Go: Bump github.com/segmentio/backo-go from 1.0.1-0.20200129164019-23eae7c10bd3 to 1.0.1 #6851 (dependabot[bot])
  • Fix GitHub labels in release changelog generator script and PR template #6916 (rm3l)

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Armel Soro https://github.com/rm3l <![CDATA[odo v3.11.0 Released]]> https://odo.dev/blog/odo-v3.11.0 2023-05-30T00:00:00.000Z odo v3.11.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check these playlists for an overview of the most notable changes in this release:

Featuresโ€‹

Devfile changes handled by odo dev on Podmanโ€‹

When a user is running odo against Podman, the changes to the Devfile are detected and applied, So the user can continuously iterate on the project without having to restart odo dev manually.

Allow passing extra flags to Podman/Dockerโ€‹

odo is now able to pass extra flags to Podman or Docker backends, used for building images or starting a Dev session (Podman only).

The main use case behind this is to allow users of odo to build images targeting a platform running a different architecture, e.g., users on arm64 architecture (like Mac M1) building images for a Kubernetes cluster that does not support arm64.

See Passing extra flags to Podman or Docker for more details.

Handling imageName in Image Component as a selectorโ€‹

odo can now push images from Image Components to a given registry and use that for all matching Kubernetes/OpenShift components manifests, without having to hardcode that information into the Devfile, so that developers can keep their devfile portable.

See How odo handles image names for more details.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Release of v3.11.0

v3.11.0 (2023-05-30)โ€‹

Full Changelog

Features/Enhancements:

  • Track preference options usage #6843 (rm3l)
  • Reuse same volumes when devfile is modified, on podman #6810 (feloy)
  • Delete previous pod and creates new ond when modifying devfile on podman #6802 (feloy)
  • Allow using imageName as a selector #6768 (rm3l)

Bugs:

  • Make sure event is recorded whenever telemetry preference is changed #6842 (rm3l)
  • Do not error out in port detection if any of the /proc/net/{tc,ud}p{,6} files are missing in the dev container #6831 (rm3l)
  • Add a timeout when initializing the Podman client (broken Podman should not affect odo dev on cluster) #6808 (rm3l)
  • Updating the oudated release script #6801 (ritudes)
  • Fix: odo init overwrites personalized configuration when downloading starter project #6800 (valaparthvi)
  • Fix HotReloadCapable Build command #6696 (feloy)

Tests

  • Fix should print warning about default namespace when running odo dev test when Dev Session does not start correctly #6848 (rm3l)
  • Fix issues with describe/list binding tests #6839 (valaparthvi)
  • Fix flaky odo dev test on Podman by randomizing component names #6833 (rm3l)
  • Only run cluster tests on nightly tests, not nocluster tests #6825 (feloy)
  • Do not run 'odo-infra-stage-test' Workflow on PRs if not needed #6823 (rm3l)
  • Move parent devfiles in specific directories #6818 (feloy)
  • Wait after killing odo during integration test #6816 (feloy)
  • fix failing nightly tests #6814 (feloy)
  • Check latest version from index instead of using hardcoded value #6789 (feloy)

Documentation:

Cleanup/Refactor:

  • Use a single handler for executing all commands #6826 (feloy)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> feloy https://github.com/feloy <![CDATA[Using Helm with odo]]> https://odo.dev/blog/using-helm-with-odo 2023-05-05T00:00:00.000Z This blog will show how odo can now be used with tools such as Helm, Kustomize, etc. for the outerloop development cycle.

note

This blog is an extension of an earlier blog which focuses on the innerloop development cycle.

By the end of this blog, we will have deployed a CRUD REST mongodb application on a minikube cluster.

Prerequisites:โ€‹

  1. odo v3.8.0+
  2. Minikube cluster
  3. Ingress enabled on the minikube cluster

1. Fetch the projectโ€‹

git clone https://github.com/valaparthvi/restapi-mongodb-odo.git &&  cd restapi-mongodb-odo

2. Create namespaceโ€‹

Create a namespace called restapi-mongodb:

odo create namespace restapi-mongodb
Sample output:
$ odo create namespace
 โœ“  Namespace "restapi-mongodb" is ready for use
 โœ“  New namespace created and now using namespace: restapi-mongodb

3. Initialize the componentโ€‹

Download the devfile to initialize an odo component with odo init.

odo init --devfile go --name places
Sample output:
$ odo init --devfile go --name places
  __
 /  \__     Initializing a new component
 \__/  \
 /  \__/    odo version: v3.9.0
 \__/

 โœ“  Downloading devfile "go" [3s]

Your new component 'places' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.

4. Modify the Devfileโ€‹

We will be using odo deploy for deploying our application, and for this we need to modify the Devfile by adding required commands and components.

Add the commandsโ€‹

Let us begin by first adding a deploy command under the commands section.

# This is the main "composite" command that will run all below commands
- id: deploy
  composite:
    commands:
      - k8s-serviceaccount-for-helm
      - k8s-role-for-helm
      - k8s-rolebinding-for-helm
      - deploy-db
      - build-image
      - k8s-deployment
      - k8s-service
      - k8s-url
    group:
      isDefault: true
      kind: deploy

deploy command is a composition of various other commands in the order in which we want them to be executed. For e.g. before deploying the database with helm, we need to ensure a service account with the required permissions (made possible by role and rolebinding) has been created; and so we run k8s-serviceaccount-for-helm, k8s-role-for-helm and k8s-rolebinding-for-helm before running deploy-db command.

Let us now add the individual commands.

We will first define the deploy-db command that is used to deploy the helm chart.

To use an external tool such as helm or kustomize, we need to ensure 2 things:

  1. use an exec command; learn more here.
  2. the container component referenced by this command uses an image that contains the required binary.
- id: deploy-db
  exec:
    commandLine: helm repo add bitnami https://charts.bitnami.com/bitnami && helm repo update && helm upgrade --install mongodb bitnami/mongodb
    component: deploy-db

We will now add the remaining commands.

- id: k8s-serviceaccount-for-helm
  apply:
    component: outerloop-serviceaccount
- id: k8s-role-for-helm
  apply:
    component: outerloop-role
- id: k8s-rolebinding-for-helm
  apply:
    component: outerloop-rolebinding
- id: build-image
  apply:
    component: outerloop-build
- id: k8s-deployment
  apply:
    component: outerloop-deployment
- id: k8s-service
  apply:
    component: outerloop-service
- id: k8s-url
  apply:
      component: outerloop-url

Add the componentsโ€‹

Every command above references a component, and so we now add components under the components section.

We will first add the component referenced by deploy-db command.

- name: deploy-db
  container:
    image: quay.io/tkral/devbox-demo-devbox
  attributes:
    pod-overrides:
      spec:
        serviceAccountName: my-go-app

The image used by this container component contains the Helm binary that we can use to deploy the helm chart.

The component is using a pod-overrides attribute that will override the service account used by the pod to deploy the helm chart to use the service account (my-go-app) we define in this Devfile. If we do not do this, the pod will use the default service account that does not have the required permissions.

We will now add the remaining components.

- name: outerloop-serviceaccount
  kubernetes:
    inlined: |
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: {{RESOURCE_NAME}}
- name: outerloop-role
  kubernetes:
    inlined: |
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: {{RESOURCE_NAME}}
      rules:
      - apiGroups:
        - '*'
        resources:
        - '*'
        verbs:
        - '*'
- name: outerloop-rolebinding
  kubernetes:
    inlined: |
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: {{RESOURCE_NAME}}
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: {{RESOURCE_NAME}}
      subjects:
      - kind: ServiceAccount
        name: {{RESOURCE_NAME}}
# This will build the container image before deployment
- name: outerloop-build
  image:
    dockerfile:
      buildContext: ${PROJECT_SOURCE}
      rootRequired: false
      uri: ./Dockerfile
    imageName: "{{CONTAINER_IMAGE}}"
# This will create a Deployment in order to run your container image across the cluster.
# Note that we expose the env vars necessary to connect application with the mongodb service.
- name: outerloop-deployment
  kubernetes:
    inlined: |
      kind: Deployment
      apiVersion: apps/v1
      metadata:
        name: {{RESOURCE_NAME}}
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: {{RESOURCE_NAME}}
        template:
          metadata:
            labels:
              app: {{RESOURCE_NAME}}
          spec:
            containers:
              - name: {{RESOURCE_NAME}}
                image: {{CONTAINER_IMAGE}}
                ports:
                  - name: http
                    containerPort: {{CONTAINER_PORT}}
                    protocol: TCP
                env:
                - name: username
                  value: {{USERNAME}}
                - name: host
                  value: {{HOST}}
                - name: password
                  valueFrom:
                    secretKeyRef:
                      name: mongodb
                      key: mongodb-root-password
                resources:
                  limits:
                    memory: "1024Mi"
                    cpu: "500m"
# This will create a Service so your Deployment is accessible.
# Depending on your cluster, you may modify this code so it's a
# NodePort, ClusterIP or a LoadBalancer service.
- name: outerloop-service
  kubernetes:
    inlined: |
      apiVersion: v1
      kind: Service
      metadata:
        name: {{RESOURCE_NAME}}
      spec:
        ports:
        - name: "{{CONTAINER_PORT}}"
          port: {{CONTAINER_PORT}}
          protocol: TCP
          targetPort: {{CONTAINER_PORT}}
        selector:
          app: {{RESOURCE_NAME}}
        type: NodePort
- name: outerloop-url
  kubernetes:
    inlined: |
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: {{RESOURCE_NAME}}
      spec:
        rules:
          - host: "{{DOMAIN_NAME}}"
            http:
              paths:
              - path: "/"
                pathType: Prefix
                backend:
                  service:
                    name: {{RESOURCE_NAME}}
                    port:
                      number: {{CONTAINER_PORT}}

Add the variablesโ€‹

Next, we add a variables section to the Devfile, so that we can make use of the same variables at multiple locations within the Devfile.

# Add the following variables code anywhere in devfile.yaml
# This MUST be a container registry you are able to access
variables:
  CONTAINER_IMAGE: quay.io/MYUSERNAME/go-odo-example
  RESOURCE_NAME: my-go-app
  CONTAINER_PORT: "8080"
  DOMAIN_NAME: go.example.com
  USERNAME: root
  HOST: mongodb
note

Ensure that you replace MYUSERNAME in CONTAINER_IMAGE with your own username; or use a container registry that you have the write permissions to.

If you are using quay.io registry, you might have to change the repository permissions to Public to continue, otherwise you might see failures related to pulling the image.

Modify schemaVersionโ€‹

One last thing is to change the schemaVersion of the Devfile since deploy commands are only supported in schema 2.2.0+.

# Deploy "kind" ID's use schema 2.2.0+
schemaVersion: 2.2.0
Your final Devfile will look like the following:
commands:
- exec:
    commandLine: go build main.go
    component: runtime
    env:
      - name: GOPATH
        value: ${PROJECT_SOURCE}/.go
      - name: GOCACHE
        value: ${PROJECT_SOURCE}/.cache
    group:
      isDefault: true
      kind: build
    workingDir: ${PROJECT_SOURCE}
  id: build
- exec:
    commandLine: ./main
    component: runtime
    group:
      isDefault: true
      kind: run
    workingDir: ${PROJECT_SOURCE}
  id: run
- id: deploy-db
  exec:
    commandLine: helm repo add bitnami https://charts.bitnami.com/bitnami && helm repo update && helm upgrade --install mongodb bitnami/mongodb
    component: deploy-db
- id: k8s-serviceaccount-for-helm
  apply:
    component: outerloop-serviceaccount
- id: k8s-role-for-helm
  apply:
    component: outerloop-role
- id: k8s-rolebinding-for-helm
  apply:
    component: outerloop-rolebinding

# This is the main "composite" command that will run all below commands
- id: deploy
  composite:
    commands:
      - k8s-serviceaccount-for-helm
      - k8s-role-for-helm
      - k8s-rolebinding-for-helm
      - deploy-db
      - build-image
      - k8s-deployment
      - k8s-service
      - k8s-url
    group:
      isDefault: true
      kind: deploy
# Below are the commands and their respective components that they are "linked" to deploy
- id: build-image
  apply:
    component: outerloop-build
- id: k8s-deployment
  apply:
    component: outerloop-deployment
- id: k8s-service
  apply:
    component: outerloop-service
- id: k8s-url
  apply:
    component: outerloop-url
components:
- container:
    args:
      - tail
      - -f
      - /dev/null
    endpoints:
      - name: http-go
        targetPort: 8080
    image: registry.access.redhat.com/ubi9/go-toolset:latest
    memoryLimit: 1024Mi
    mountSources: true
  name: runtime
- name: deploy-db
  container:
    image: quay.io/tkral/devbox-demo-devbox
  attributes:
    pod-overrides:
      spec:
        serviceAccountName: my-go-app
- name: outerloop-serviceaccount
  kubernetes:
    inlined: |
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: {{RESOURCE_NAME}}
- name: outerloop-role
  kubernetes:
    inlined: |
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: {{RESOURCE_NAME}}
      rules:
      - apiGroups:
        - '*'
        resources:
        - '*'
        verbs:
        - '*'
- name: outerloop-rolebinding
  kubernetes:
    inlined: |
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: {{RESOURCE_NAME}}
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: {{RESOURCE_NAME}}
      subjects:
      - kind: ServiceAccount
        name: {{RESOURCE_NAME}}
# This will build the container image before deployment
- name: outerloop-build
  image:
    dockerfile:
      buildContext: ${PROJECT_SOURCE}
      rootRequired: false
      uri: ./Dockerfile
    imageName: "{{CONTAINER_IMAGE}}"
# This will create a Deployment in order to run your container image across
# the cluster.
- name: outerloop-deployment
  kubernetes:
    inlined: |
      kind: Deployment
      apiVersion: apps/v1
      metadata:
        name: {{RESOURCE_NAME}}
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: {{RESOURCE_NAME}}
        template:
          metadata:
            labels:
              app: {{RESOURCE_NAME}}
          spec:
            containers:
              - name: {{RESOURCE_NAME}}
                image: {{CONTAINER_IMAGE}}
                ports:
                  - name: http
                    containerPort: {{CONTAINER_PORT}}
                    protocol: TCP
                env:
                - name: username
                  value: {{USERNAME}}
                - name: host
                  value: {{HOST}}
                - name: password
                  valueFrom:
                    secretKeyRef:
                      name: mongodb
                      key: mongodb-root-password
                resources:
                  limits:
                    memory: "1024Mi"
                    cpu: "500m"
# This will create a Service so your Deployment is accessible.
# Depending on your cluster, you may modify this code so it's a
# NodePort, ClusterIP or a LoadBalancer service.
- name: outerloop-service
  kubernetes:
    inlined: |
      apiVersion: v1
      kind: Service
      metadata:
        name: {{RESOURCE_NAME}}
      spec:
        ports:
        - name: "{{CONTAINER_PORT}}"
          port: {{CONTAINER_PORT}}
          protocol: TCP
          targetPort: {{CONTAINER_PORT}}
        selector:
          app: {{RESOURCE_NAME}}
        type: NodePort
- name: outerloop-url
  kubernetes:
    inlined: |
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: {{RESOURCE_NAME}}
      spec:
        rules:
          - host: "{{DOMAIN_NAME}}"
            http:
              paths:
              - path: "/"
                pathType: Prefix
                backend:
                  service:
                    name: {{RESOURCE_NAME}}
                    port:
                      number: {{CONTAINER_PORT}}
metadata:
  description:
    Go is an open source programming language that makes it easy to build
    simple, reliable, and efficient software.
  displayName: Go Runtime
  icon: https://raw.githubusercontent.com/devfile-samples/devfile-stack-icons/main/golang.svg
  language: Go
  name: places
  projectType: Go
  provider: Red Hat
  tags:
    - Go
  version: 1.0.2
# Deploy "kind" ID's use schema 2.2.0+
schemaVersion: 2.2.0
starterProjects:
  - description: A Go project with a simple HTTP server
    git:
      checkoutFrom:
        revision: main
      remotes:
        origin: https://github.com/devfile-samples/devfile-stack-go.git
    name: go-starter
# Add the following variables code anywhere in devfile.yaml
# This MUST be a container registry you are able to access
variables:
  CONTAINER_IMAGE: quay.io/MYUSERNAME/go-odo-example
  RESOURCE_NAME: my-go-app
  CONTAINER_PORT: "8080"
  DOMAIN_NAME: go.example.com
  USERNAME: root
  HOST: mongodb

5. Deployโ€‹

Now that the Devfile is ready, we can simply run odo deploy.

odo deploy --var CONTAINER_IMAGE=quay.io/<username>/go-odo-example
Sample output
$ odo deploy --var CONTAINER_IMAGE=quay.io/pvala18/go-odo-example
 __
 /  \__     Running the application in Deploy mode using my-go-app Devfile
 \__/  \    Namespace: restapi-mongodb
 /  \__/    odo version: v3.9.0
 \__/

โ†ช Deploying Kubernetes Component: my-go-app
 โœ“  Creating resource ServiceAccount/my-go-app 

โ†ช Deploying Kubernetes Component: my-go-app
 โœ“  Creating resource Role/my-go-app 

โ†ช Deploying Kubernetes Component: my-go-app
 โœ“  Creating resource RoleBinding/my-go-app 

โ†ช Executing command:
 โœ“  Executing command in container (command: deploy-db) [18s]

โ†ช Building & Pushing Image: quay.io/pvala18/go-odo-example
 โ€ข  Building image locally
[1/2] STEP 1/5: FROM quay.io/redhat-developer/servicebinding-operator:builder-golang-1.16 AS builder  
[1/2] STEP 2/5: USER root   
--> Using cache 6caf9a75a7e8a27da9ebbddc7a4c7451033e53e588796c65e5a7683049927992
--> 6caf9a75a7e
[1/2] STEP 3/5: WORKDIR /workspace
--> Using cache 979b426e92aba26a7ec4c66b698516b35b164ea34c3c77f8b3ee52999009958a
--> 979b426e92a
[1/2] STEP 4/5: COPY / /workspace/
--> 28e87dd1e60
[1/2] STEP 5/5: RUN go build
go: downloading github.com/sirupsen/logrus v1.8.1
go: downloading github.com/spf13/viper v1.11.0   
go: downloading github.com/gorilla/mux v1.8.0    
go: downloading go.mongodb.org/mongo-driver v1.9.0       
go: downloading golang.org/x/sys v0.0.0-20220412211240-33da011f77ad             
go: downloading github.com/mitchellh/mapstructure v1.4.3 
go: downloading github.com/fsnotify/fsnotify v1.5.1      
go: downloading github.com/spf13/afero v1.8.2    
go: downloading github.com/spf13/cast v1.4.1     
go: downloading github.com/spf13/jwalterweatherman v1.1.0
go: downloading github.com/spf13/pflag v1.0.5 
go: downloading github.com/spf13/afero v1.8.2
go: downloading github.com/spf13/cast v1.4.1     
go: downloading github.com/spf13/jwalterweatherman v1.1.0
go: downloading github.com/spf13/pflag v1.0.5    
go: downloading golang.org/x/text v0.3.7         
go: downloading github.com/subosito/gotenv v1.2.0
go: downloading github.com/hashicorp/hcl v1.0.0
go: downloading gopkg.in/ini.v1 v1.66.4
go: downloading github.com/magiconair/properties v1.8.6
go: downloading github.com/pelletier/go-toml v1.9.4
go: downloading gopkg.in/yaml.v2 v2.4.0
go: downloading github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d
go: downloading github.com/pkg/errors v0.9.1
go: downloading github.com/go-stack/stack v1.8.0
go: downloading github.com/golang/snappy v0.0.3
go: downloading github.com/klauspost/compress v1.13.6
go: downloading golang.org/x/crypto v0.0.0-20220411220226-7b82a4e95df4
go: downloading golang.org/x/sync v0.0.0-20210220032951-036812b2e83c 
go: downloading github.com/xdg-go/scram v1.0.2
go: downloading github.com/xdg-go/stringprep v1.0.2
go: downloading github.com/xdg-go/pbkdf2 v1.0.0
--> b596b2ffc4c
[2/2] STEP 1/6: FROM registry.access.redhat.com/ubi8-minimal
[2/2] STEP 2/6: WORKDIR /
--> Using cache 2f7a0096cef8c90c20c8091c6f1cea4660f100593c848ae2f2cd0b2283ca7f11
--> 2f7a0096cef
[2/2] STEP 3/6: COPY --from=builder /workspace/go-rest-mongodb .
--> Using cache 91eeb6e34d81e8ddbc5ef8f4b8ff3243400812e52a54a555a85343fad8a4caf9
--> 91eeb6e34d8
[2/2] STEP 4/6: COPY --from=builder /workspace/config.yml .
--> Using cache dab23c83ba939565242774abf7cac92849935a0d99c33609a0e7a16b32f34aeb
--> dab23c83ba9
[2/2] STEP 5/6: USER 65532:65532
--> Using cache 2faf2c79c0f92dfaac4cb88084beecbfa1df555512da42ec4e10db4208518cc6
--> 2faf2c79c0f
[2/2] STEP 6/6: ENTRYPOINT ["/go-rest-mongodb"]
--> Using cache 2271a27b9d4642a2af86ee5836797fc5161f49346b2251b7a6a0cc80c2d3089c
[2/2] COMMIT quay.io/pvala18/go-odo-example
--> 2271a27b9d4
Successfully tagged quay.io/pvala18/go-odo-example:latest
2271a27b9d4642a2af86ee5836797fc5161f49346b2251b7a6a0cc80c2d3089c
 โœ“  Building image locally [23s]
 โ€ข  Pushing image to container registry  ...
Getting image source signatures
Copying blob 876fba3c71a7 skipped: already exists  
Copying blob 55ea6d5a354e skipped: already exists  
Copying blob a283f9ae821e skipped: already exists  
Copying config 2271a27b9d done  
Writing manifest to image destination
Storing signatures
 โœ“  Pushing image to container registry [10s]

โ†ช Deploying Kubernetes Component: my-go-app
 โœ“  Creating resource Deployment/my-go-app 

โ†ช Deploying Kubernetes Component: my-go-app
 โœ“  Creating resource Service/my-go-app 

โ†ช Deploying Kubernetes Component: my-go-app
 โœ“  Creating resource Route/my-go-app 

Your Devfile has been successfully deployed

6. Accessing the applicationโ€‹

Run odo describe component to obtain access information.

odo describe component
Sample output
$ odo describe component
Name: places
Display Name: Go Runtime
Project Type: Go
Language: Go
Version: 1.0.2
Description: Go (version 1.18.x) is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Tags: Go

Running in: Deploy

Running on:
 โ€ข  cluster: Deploy

Supported odo features:
 โ€ข  Dev: true
 โ€ข  Deploy: true
 โ€ข  Debug: false

Container components:
 โ€ข  runtime
    Source Mapping: /projects
 โ€ข  deploy-db
    Source Mapping: /projects

Kubernetes components:
 โ€ข  outerloop-serviceaccount
 โ€ข  outerloop-role
 โ€ข  outerloop-rolebinding
 โ€ข  outerloop-deployment
 โ€ข  outerloop-service
 โ€ข  outerloop-url

Kubernetes Ingresses:
 โ€ข  my-go-app: go.example.com/

Since we are using Ingress, we first need to check if an IP address has been set.

$ kubectl get ingress my-go-app
NAME        CLASS   HOSTS            ADDRESS          PORTS   AGE
my-go-app   nginx   go.example.com   192.168.59.124   80      7m4s

Once the IP address appears, you can now access the application at the following URL:

curl --resolve "go.example.com:80:192.168.59.124" -i http://go.example.com/api/places
Sample output
$ curl --resolve "go.example.com:80:192.168.59.124" -i http://go.example.com/api/places
HTTP/1.1 200 OK
Date: Thu, 27 Apr 2023 06:16:09 GMT
Content-Type: application/json
Content-Length: 4
Connection: keep-alive

null

This will return a null response since the database is currently empty, but it also means that we have successfully connected to our database application.

note

You can add the following line to the /etc/hosts file of your computer to simply access the application at http://go.example.com. Learn more about using ingress to access an application.

192.168.59.124  go.example.com

Add some data to the database:

curl --resolve "go.example.com:80:192.168.59.124" -i http://go.example.com/api/places -sSL -XPOST -d '{"title": "Agra", "description": "Land of Tajmahal"}'
Sample Output
$ curl --resolve "go.example.com:80:192.168.59.124" -i http://go.example.com/api/places -sSL -XPOST -d '{"title": "Agra", "description": "Land of Tajmahal"}'
HTTP/1.1 201 Created
Date: Thu, 27 Apr 2023 10:43:04 GMT
Content-Type: application/json
Content-Length: 86
Connection: keep-alive

{"id":"62c2a0659fa147e382a4db31","title":"Agra","description":"Land of Tajmahal"}

Fetch the list of places again:

$ curl --resolve "go.example.com:80:192.168.59.124" -i http://go.example.com/api/places
HTTP/1.1 201 Created
Date: Thu, 27 Apr 2023 10:41:09 GMT
Content-Type: application/json
Content-Length: 81
Connection: keep-alive

{"id":"62c2a0659fa147e382a4db31","title":"Agra","description":"Land of Tajmahal"}

List of available API endpointsโ€‹

  • GET /api/places - List all places
  • POST /api/places - Add a new place
  • PUT /api/places - Update a place
  • GET /api/places/<id> - Fetch place with id <id>
  • DELETE /api/places/<id> - Delete place with id <id>
]]> Parthvi Vala https://github.com/valaparthvi <![CDATA[odo v3.10.0 Released]]> https://odo.dev/blog/odo-v3.10.0 2023-05-04T00:00:00.000Z odo v3.10.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check these playlists for an overview of the most notable changes in this release:

Featuresโ€‹

--port-forward to define custom port mapping and --address to define a custom address for port forwarding during odo devโ€‹

To enhance the port forwarding feature provided by odo dev, you can now use custom port mapping with flag --port-forward and a custom address for ports to listen by passing --address flag. Read more about custom port mapping and custom address on odo dev command reference doc.

Custom Port Mapping for port forwarding:

Custom Address for port forwarding:

Automatically mounting volumes, configmaps, and secretsโ€‹

You can now automatically mount existing persistent volumes, configmaps and secrets to your odo dev deployment by applying an appropriate label to them.

metadata:
  labels:
    devfile.io/auto-mount: "true"

Read more about it in Automounting Volumes.

Support variable substitution for odo build-imagesโ€‹

odo build-images now supports the Devfile variable substitution in a similar way as odo dev and odo deploy.

Read more about it in the odo build-images command reference doc.

odo dev can run simultaneously on podman and clusterโ€‹

Bugsโ€‹

Allow to cancel odo dev execution at any phaseโ€‹

In the previous versions, odo dev could not be cancelled until the build phase was complete. This has now been fixed to allow cancelling odo dev at any phase.

odo dev handles failing build commands in a better way.โ€‹

Build command is ideally the first command that is run after the necessary resources are created in the odo dev workflow. Read How odo works for a better understanding of this.

In the previous versions, odo dev would run the build command in an infinite loop until it succeeded, which was unnecessary. In v3.10.0 however, odo dev stops after 1 unsuccessful attempt, and waits for the user to make changes to the project, providing with a slightly better user experience.

PodSecurity Admission: Display duplicate warnings only onceโ€‹

Warnings related to PodSecurity Admission are now printed only once.

Wait until expected ports are opened before starting port-forwardingโ€‹

odo dev now waits until the application ports are listening before printing the port forwarding information.

Documentationโ€‹

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Release of v3.10.0

v3.10.0 (2023-05-04)โ€‹

Full Changelog

Documentation:

v3.10.0 (2023-05-02)โ€‹

Full Changelog

Features/Enhancements:

  • Support variable substitution with --var and --var-file in odo build-images #6776 (rm3l)
  • Use custom address for port forwarding #6766 (valaparthvi)
  • Add annotation for setting access mode on automounted configmap/secret files #6750 (feloy)
  • Use devstats.PID.json as devstate #6713 (feloy)
  • Allow users to define custom port-mappings for port forwarding [Kubernetes] #6704 (valaparthvi)
  • Wait until expected ports are opened in the container before starting port-forwarding #6701 (rm3l)
  • Automount volumes #6698 (feloy)

Bugs:

  • Test flaky devfile modification test #6769 (valaparthvi)
  • Fix flaky tests using custom port mapping when running specs in parallel #6763 (rm3l)
  • Simplify devfile Kubernetes adapter #6762 (feloy)
  • Set 'mountSources' to 'true' in some example SpringBoot multi-container Devfiles #6761 (rm3l)
  • Check files to sync with gitignore library #6760 (feloy)
  • Allow to cancel execution of odo dev at any phase (e.g. if build command is taking long) #6736 (rm3l)
  • Fix e2e test failures and doc test failures due to updated devfile registry #6735 (valaparthvi)
  • Fix: PodSecurity Admission: Display duplicate warnings only once #6733 (valaparthvi)
  • For custom port mapping, handle case where ranged random port matches a custom local port #6727 (valaparthvi)

Documentation:

Cleanup/Refactor:

  • Wait when Build command fails #6771 (feloy)
  • Follow-up to comments on #6654 (support for autoBuild and deployByDefault) #6720 (rm3l)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> valaparthvi https://github.com/valaparthvi <![CDATA[odo v3.9.0 Released]]> https://odo.dev/blog/odo-v3.9.0 2023-04-05T00:00:00.000Z odo v3.9.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check the following Playlists for an overview of the most notable changes in this release:

Deprecation noticeโ€‹

odo registry --details without --devfileโ€‹

We are deprecating the usage of odo registry --details without --devfile. Using odo registry --details without --devfile still works, but might take very long to return information.

--details allows to get more details about a specific Devfile stack, and was not intended to be used without specifying --devfile.

The correct usage of odo registry --details is by specifying the additional --devfile flag.

See the command reference page for more details and examples.

Featuresโ€‹

Pod Security Admission supportโ€‹

Kubernetes v1.25 introduced Pod Security Standards defining different isolation levels for Pods, along with a Pod Security admission controller to enforce those standards. Namespaces can be labeled to enforce the Pod Security Standards, meaning that a Pod can be rejected if it is not compliant with the security restrictions defined.

See Pod Security Admission for more details.

When used against a Kubernetes or OpenShift cluster, odo is now able to automatically detect if the current namespace has such restrictions enforced; and if so, it can dynamically adjust the specifications of the Pods it creates such that they are approved by the Pod Security admission controller. This applies to resources created automatically by the following odo commands:

info

Bear in mind that you can always customize those resources through pod-overrides and container-overrides attributes in the Devfile. See Extending Kubernetes resources.

Support for autoBuild and deployByDefault Devfile fieldsโ€‹

To clarify which Devfile components should get created/applied automatically, the Devfile specification introduced two new fields:

odo now supports those fields, following the rules depicted in our Devfile reference page.

Component name added to odo analyzeโ€‹

odo analyze now includes a new name field in its output, representing the name of the application if was detected automatically or the current directory name.

See the command reference page for more details.

Example:

[
    {
        "devfile": "dotnet50",
        "ports": [
            3000
        ],
        "devfileRegistry": "DefaultDevfileRegistry",
-       "devfileVersion": "1.0.3"
+       "devfileVersion": "1.0.3",
+       "name": "my-dotnet-backend"
    }
]

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Full Changelog

Features/Enhancementsโ€‹

  • Patch Pods to pass pod security admission #6602 (feloy)
  • Pod Security Admission support for odo deploy #6679 (feloy)
  • Speedup odo registry --details #6678 (feloy)
  • Support autoBuild and deployByDefault on Image and Kubernetes/OpenShift components #6654 (rm3l)
  • Add name detection to odo analyze #6682 (valaparthvi)
  • odo dev/odo deploy should display a warning about default namespace on cluster #6688 (valaparthvi)

Bugsโ€‹

  • odo analyze reporting wrong Devfile (nodejs instead of python) #6707 (kadel)
  • Fix problem when odo deploy processes do not terminate #6716 (feloy)
  • Fix issue preventing app from being restarted if /proc/[pid]/task/[tid]/children is missing in container (case of Minikube with VirtualBox or KVM drivers) #6690 (rm3l)
  • Fix: odo init does not ask for starter project if the Devfile stack contains extra files #6684 (valaparthvi)
  • Fix UX issue when exec command fails to run as part of a deploy command #6673 (rm3l)
  • Fix issue with conflicting ports when starting multiple Dev sessions on Podman #6660 (rm3l)
  • Fix error handling when trying to delete remote resources not present in Devfile #6659 (rm3l)
  • Downloading a starter project with odo init should no longer replace the contents of the current directory #6633 (valaparthvi)

Documentationโ€‹

Merged pull requestsโ€‹

  • Bump version to 3.9.0 #6717 (rm3l)
  • Update the PR template #6712 (valaparthvi)
  • Exit a test early if a session has exited while waiting for an output to contain a substring #6711 (valaparthvi)
  • Fix nodejs-react versions on generated doc #6710 (feloy)
  • Add DEVFILE_REGISTRY env var for periodic tests #6709 (feloy)
  • Website: Bump @svgr/webpack from 6.5.1 to 7.0.0 in /docs/website #6708 (dependabot[bot])
  • Update alizer #6707 (kadel)
  • Get DEVFILE_REGISTRY value for tests, to use local Registry #6705 (feloy)
  • Website: Bump @docusaurus/* from 2.3.1 to 2.4.0 in /docs/website #6685 (dependabot[bot])
  • Go: Bump golang.org/x/sync from 0.0.0-20220722155255-886fb9371eb4 to 0.1.0 #6665 (dependabot[bot])
  • Website: Bump @tsconfig/docusaurus from 1.0.6 to 1.0.7 in /docs/website #6664 (dependabot[bot])
  • Go: Bump github.com/operator-framework/api from 0.14.1-0.20220413143725-33310d6154f3 to 0.17.3 #6656 (dependabot[bot])
  • Website: Bump webpack from 5.75.0 to 5.76.1 in /docs/website #6655 (dependabot[bot])
  • Update alizer dependency #6650 (kadel)
  • Fix potential issue with odo describe component integration tests when Podman is installed #6642 (rm3l)

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Armel Soro https://github.com/rm3l <![CDATA[Deploying and using an in-cluster Devfile registry]]> https://odo.dev/blog/deploying-and-using-in-cluster-devfile-registry 2023-03-22T00:00:00.000Z in-cluster Devfile registries with odo

Starting with v3.8.0, odo can detect Devfile registries declared into the current cluster and use them preferably.

In this article, we'll explore how we can deploy our own Devfile Registry into a Kubernetes or OpenShift cluster and how we can use it automatically with odo.

Prerequisitesโ€‹

  • odo 3.8.0 or later
  • A Kubernetes cluster with an Ingress Controller (like ingress-nginx or Traefik) or an OpenShift cluster
  • A user in the cluster with permission to install Custom Resource Definitions (CRDs). Or ask a cluster administrator to install those resources
  • kubectl or oc CLIs
  • Helm CLI, version 3 or higher

Deploying a Devfile Registry in the clusterโ€‹

In this section, we'll leverage Helm to install a Devfile Registry.

The Devfile Registry Chart currently deploys an Ingress resource on Kubernetes, hence the requirement of having an Ingress Controller and a reachable Ingress domain. On OpenShift, it will deploy a Route, which will provide an automatic public HTTP URL for accessing the registry.

  1. Clone the registry-support repository containing the Helm Chart we will deploy:
git clone --depth=1 https://github.com/devfile/registry-support
  1. Install the Helm Chart into the current cluster.

An Ingress Controller should have been installed with a domain for Ingress resources.

helm install my-devfile-registry \
    ./registry-support/deploy/chart/devfile-registry \
    --set global.ingress.domain=<domain> \
    --set global.ingress.class=<ingress-class>
Example output:
$ helm install my-devfile-registry \
    ./registry-support/deploy/chart/devfile-registry \
    --set global.ingress.domain=$(minikube ip).nip.io \
    --set global.ingress.class=nginx

NAME: my-devfile-registry
LAST DEPLOYED: Fri Mar 24 15:50:18 2023
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Determining the Devfile Registry URLโ€‹

On Kubernetes, the Helm Chart installed above will create an Ingress reachable via a DNS domain named as follows: devfile-registry-<namespace>.<ingressDomain>.

You can get the actual Host by getting the Ingress Resource, via the following command:

kubectl get ingress <registryName>
Example output:
$ kubectl get ingress my-devfile-registry \
    -o custom-columns='URL:.spec.rules[*].host' \
    --no-headers

devfile-registry-default.172.20.0.2.nip.io

In this example, the Devfile Registry is now reachable at http://devfile-registry-default.172.20.0.2.nip.io

Try it out by opening your browser at the Registry URL returned above, but please note that it might take some time (around 1 to 2 minutes) before the Registry is accessible, depending on how long it takes for the resources to be ready in the cluster.

in-cluster Devfile Registry preview

Installing the Devfile Registry Operator Custom Resource Definitionsโ€‹

Devfile Registries declared in a DevfileRegistriesList or ClusterDevfileRegistriesList custom resource are automatically included in the list of registries that odo can use. To be able to create such resources, we need to install their definitions as Custom Resource Definitions (CRDs) in the cluster. You can do so by applying the Kustomize project available here, using the command below:

kubectl apply -k https://github.com/devfile/registry-operator/config/crd
Example output:
$ kubectl apply -k https://github.com/devfile/registry-operator/config/crd

customresourcedefinition.apiextensions.k8s.io/clusterdevfileregistrieslists.registry.devfile.io created
customresourcedefinition.apiextensions.k8s.io/devfileregistries.registry.devfile.io created
customresourcedefinition.apiextensions.k8s.io/devfileregistrieslists.registry.devfile.io created

Declaring the Devfile Registryโ€‹

Now that the Custom Resource Definitions are installed, we are ready to declare the Devfile Registry we deployed by listing it as part of a DevfileRegistriesList or ClusterDevfileRegistriesList Custom Resource.

A DevfileRegistriesList resource is scoped at the namespace level, while ClusterDevfileRegistriesList is a cluster-wide resource.

We will go on with creating a DevfileRegistriesList resource in the current namespace, but it is also possible to create a ClusterDevfileRegistriesList instead if we have the appropriate permissions in the cluster.

Make sure you replace <devfileRegistryUrl> in the url field with the Devfile Registry Host (and protocol) we got from the previous sections.

caution

Due to #6635, odo cannot be forced to work with HTTPS registries exposed over insecure or self-signed certificates. So we will need to communicate with the Registry over HTTP for now.

cat <<EOF | kubectl apply -f -               
apiVersion: registry.devfile.io/v1alpha1
kind: DevfileRegistriesList
metadata:
  name: ns-devfile-registries
spec:
  devfileRegistries:
    - name: my-devfile-registry
      url: <devfileRegistryUrl>
EOF
Example output:
$ cat <<EOF | kubectl apply -f -               
apiVersion: registry.devfile.io/v1alpha1
kind: DevfileRegistriesList
metadata:
  name: ns-devfile-registries
spec:
  devfileRegistries:
    - name: my-devfile-registry
      url: 'http://devfile-registry-default.172.20.0.2.nip.io'
EOF

devfileregistrieslist.registry.devfile.io/ns-devfile-registries created
note

There can be only one ClusterDevfileRegistriesList resource per cluster and only one DevfileRegistriesList resource per namespace.

Also, the registry URLs listed in those resources need to be valid and reachable URLs at the time they are created into the cluster.

These rules will be enforced if you have the Devfile Registry Operator installed in the cluster.

Using the in-cluster registry with odoโ€‹

With the DevfileRegistriesList resource installed, odo will start using the registries listed there first. You can check this by running odo preference view.

Example output:
$ odo preference view

Preference parameters:
[...]

Devfile registries:
 NAME                    URL                                                SECURE 
 my-devfile-registry     http://devfile-registry-default.172.20.0.2.nip.io  Yes
 DefaultDevfileRegistry  https://registry.devfile.io                        No

As a rule of thumb, odo will combine Devfile registries from the cluster and those listed in the local settings, and use them in the following priority order:

  1. registries from the current namespace (declared in the DevfileRegistriesList resource)
  2. cluster-wide registries (declared in the ClusterDevfileRegistriesList resource)
  3. all other registries configured in the local configuration file

More details in this guide.

This behavior applies to all odo commands interacting with registries, such as:

For example, we can list Stacks coming from our in-cluster Devfile Registry, with the odo registry command.

Example output:
$ odo registry --devfile-registry my-devfile-registry

 NAME                          REGISTRY             DESCRIPTION                                  VERSIONS     
 dotnet50                      my-devfile-registry  Stack with .NET 5.0                          1.0.3        
 dotnet60                      my-devfile-registry  Stack with .NET 6.0                          1.0.2        
 dotnetcore31                  my-devfile-registry  Stack with .NET Core 3.1                     1.0.3        
 go                            my-devfile-registry  Go is an open source programming languag...  1.0.2, 2.0.0 
 java-maven                    my-devfile-registry  Upstream Maven and OpenJDK 11                1.2.0        
 java-openliberty              my-devfile-registry  Java application Maven-built stack using...  0.9.0        
 java-openliberty-gradle       my-devfile-registry  Java application Gradle-built stack usin...  0.4.0        
 java-quarkus                  my-devfile-registry  Quarkus with Java                            1.3.0        
 java-springboot               my-devfile-registry  Spring Boot using Java                       1.2.0, 2.0.0 
 java-vertx                    my-devfile-registry  Upstream Vert.x using Java                   1.2.0        
 java-websphereliberty         my-devfile-registry  Java application Maven-built stack using...  0.9.0        
 java-websphereliberty-gradle  my-devfile-registry  Java application Gradle-built stack usin...  0.4.0        
 java-wildfly                  my-devfile-registry  Upstream WildFly                             1.1.0        
 java-wildfly-bootable-jar     my-devfile-registry  Java stack with WildFly in bootable Jar ...  1.1.0        
 nodejs                        my-devfile-registry  Stack with Node.js 16                        2.1.1        
 nodejs-angular                my-devfile-registry  Angular is a development platform, built...  2.0.2        
 nodejs-nextjs                 my-devfile-registry  Next.js gives you the best developer exp...  1.0.3        
 nodejs-nuxtjs                 my-devfile-registry  Nuxt is the backbone of your Vue.js proj...  1.0.3        
 nodejs-react                  my-devfile-registry  React is a free and open-source front-en...  2.0.2        
 nodejs-svelte                 my-devfile-registry  Svelte is a radical new approach to buil...  1.0.3        
 nodejs-vue                    my-devfile-registry  Vue is a JavaScript framework for buildi...  1.0.2        
 php-laravel                   my-devfile-registry  Laravel is an open-source PHP framework,...  1.0.1        
 python                        my-devfile-registry  Python is an interpreted, object-oriente...  2.1.0, 3.0.0 
 python-django                 my-devfile-registry  Django is a high-level Python web framew...  2.1.0

Wrapping Upโ€‹

In this article, we have walked through deploying a Devfile Registry into our cluster, and have seen how odo can automatically use registries that are declared in the cluster.

With a Devfile Registry deployed in the cluster, declaring it in a namespace-scoped DevfileRegistriesList or cluster-wide ClusterDevfileRegistriesList resource will make odo automatically discover it and try to use it preferably. This can be useful for example in an air-gapped environment.

This shows how odo can automatically adapt to the environment of the cluster it is used against.

As usual, any feedback on this feature is appreciated.

]]> Armel Soro https://github.com/rm3l <![CDATA[odo v3.8.0 Released]]> https://odo.dev/blog/odo-v3.8.0 2023-03-08T00:00:00.000Z odo v3.8.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: odo v3.8.0 (Sprint 232)

odo on Podman out of Experimental modeโ€‹

Starting with odo v3.8.0, you can use the Podman platform for your development, without the need to enter the experimental mode of odo.

The following commands are supporting the Podman platform:

  • odo dev --platform podman
  • odo logs --platform podman
  • odo list component
  • odo describe component
  • odo delete component

Detecting in-cluster Devfile registriesโ€‹

odo traditionally gets the list of Devfile Registries to work with from a preference file saved on the user's machine. Starting with v3.8.0, odo will also fetch a list of Devfile registries defined into the cluster.

Support Exec command for Deployโ€‹

odo can now execute any command when running the deploy command.

Detailed Changelogโ€‹

Full Changelog

Features/Enhancementsโ€‹

  • Make port-forwarding work on Podman with apps listening on the loopback interface, via a new --forward-localhost flag #6629 (rm3l)
  • Remove podman from experimental mode #6628 (feloy)
  • Automatically use in-cluster Devfile registries if any #6622 (rm3l)
  • On Podman, detect if application is listening on the loopback interface, and either error out or not depending on --ignore-localhost #6620 (rm3l)
  • Bump Go to 1.19 #6586 (rm3l)
  • Describe non-odo component #6615 (feloy)
  • Support exec command #6579 (valaparthvi)

Bugsโ€‹

  • Skip DevfileRegistriesList-related tests on non Kubernetes clusters #6640 (rm3l)
  • Ignore errors that might happen when getting Devfile Registries from the cluster #6639 (rm3l)
  • Allow : character in devfile registry URI #6624 (feloy)
  • fix links to devfile 2.2.0 spec #6616 (kadel)
  • Use Node image compatible with Z and P environments #6626 (HarshithaMS005)

Documentationโ€‹

  • Document air-gapped env #6627 (feloy)
  • Add preview video of odo on the website home page #6605 (rm3l)
  • blog: odo with .NET and PostgreSQL on OpenShift #6500 (kadel)

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> feloy https://github.com/feloy <![CDATA[odo with .NET and PostgreSQL on OpenShift]]> https://odo.dev/blog/odo-dotnet-postgresql-openshift 2023-02-17T00:00:00.000Z In this tutorial, I will show you how you can leverage odo to develop a .NET application communicating with the PostgreSQL database on OpenShift.

Prerequisitesโ€‹

  • odo 3.6.0 or later
  • oc (OpenShift Client) (Optional, but recommended. Alternatively, you can use OpenShift Web Console to create PostgreSQL instance)
  • Access to OpenShift cluster
tip

If you don't have access to the OpenShift cluster, you can use OpenShift Sandbox to get access to the OpenShift cluster for FREE.

This is what I used for this tutorial.

  • Log in to the cluster using odo
    • Log in to the OpenShift Web Console, click on your username in the top right corner and select "Copy login command" Copy login command
    • You might get prompted to log in again. After that, you should be able to display the token.
    • Copy oc login --token=..... command that you see to your terminal, replace oc with odo, and execute the command. (If you have oc installed, you can leave the command as it is. odo and oc store the login information at the same place)

Getting the application source codeโ€‹

We will use .NET Core Sample App for OpenShift

  1. Clone the repository

    git clone https://github.com/redhat-developer/s2i-dotnetcore-persistent-ex
    example output
    โ–ถ git clone https://github.com/redhat-developer/s2i-dotnetcore-persistent-ex
    Cloning into 's2i-dotnetcore-persistent-ex'...
    remote: Enumerating objects: 87, done.
    remote: Counting objects: 100% (28/28), done.
    remote: Compressing objects: 100% (16/16), done.
    remote: Total 87 (delta 20), reused 12 (delta 12), pack-reused 59
    Receiving objects: 100% (87/87), 27.93 KiB | 6.98 MiB/s, done.
    Resolving deltas: 100% (44/44), done.

  2. Change the directory with the application source code

    cd s2i-dotnetcore-persistent-ex/app
    example output
    โ–ถ cd s2i-dotnetcore-persistent-ex/app

    โ–ถ ls
    Data  Migrations  Pages  Program.cs  RazorPagesContacts.csproj  Startup.cs

  1. Switch to the dotnet-6.0 branch

    git checkout dotnet-6.0
    example output
    โ–ถ git checkout dotnet-6.0
    branch 'dotnet-6.0' set up to track 'origin/dotnet-6.0'.
    Switched to a new branch 'dotnet-6.0'
    caution

    For now, we have to use .NET 6.0 as there is no Devfile stack .NET 7.0 in the official Devfile registry yet.

Use odo to develop a .NET application on the OpenShift clusterโ€‹

In this part, we will start our .NET application inside the container on the OpenShift cluster. Because the app will be built and run inside the container, we don't need to install any .NET tools on our local system. All we need is the odo CLI and an OpenShift cluster.

Get the Devfile stack for .NET 6.0โ€‹

info

The Devfile stack is a definition of the containerized development environment. It defines the container image, the environment variables, and the commands that need to be executed to build, run, and optionally also test, debug and deploy the application.

You can learn more about Devfiles at devfile.io.

Run odo init commandโ€‹

odo init
example output
  โ–ถ odo init
    __
  /  \__     Initializing a new component
  \__/  \    Files: Source code detected, a Devfile will be determined based upon source code autodetection
  /  \__/    odo version: v3.6.0
  \__/

  Interactive mode enabled, please answer the following questions:
  Based on the files in the current directory odo detected
  Language: .NET
  Project type: dotnet
  The devfile "dotnet50:1.0.3" from the registry "DefaultDevfileRegistry" will be downloaded.
  ? Is this correct? No
  ? Select language: .NET
  ? Select project type: .NET 6.0
  โœ“  Downloading devfile "dotnet60" from registry "DefaultDevfileRegistry" [1s]

  โ†ช Container Configuration "dotnet":
    OPEN PORTS:
      - 8080
    ENVIRONMENT VARIABLES:
      - CONFIGURATION = Debug
      - STARTUP_PROJECT = app.csproj
      - ASPNETCORE_ENVIRONMENT = Development
      - ASPNETCORE_URLS = http://*:8080

  ? Select container for which you want to change configuration? NONE - configuration is correct
  ? Enter component name: myapp

  You can automate this command by executing:
    odo init --name myapp --devfile dotnet60 --devfile-registry DefaultDevfileRegistry

  Your new component 'myapp' is ready in the current directory.
  To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
  Changes will be directly reflected on the cluster.

odo init command will guide you through selecting the correct Devfile stack and some basic configuration. For purposes of this tutorial, you can just accept the default values.

caution

Please pay attention to the version of the dotnet Devfile that odo suggests. odo might not be able to detect the .NET version that our application is using correctly. If that happens, you need to tell odo that it is not correct and select the correct version manually.

Edit devfileโ€‹

We need to modify devfile.yaml that got downloaded by odo init command to ensure that our application starts correctly. The default .NET Devfile in the registry assumes that we have app.csproj, but our application uses RazorPagesContacts.csproj.

Open devfile.yaml that is in your project directory in your text editor or IDE. Find lines that define the STARTUP_PROJECT environment variable.

- name: STARTUP_PROJECT
  value: app.csproj

Replace the app.csproj value with RazorPagesContacts.csproj

- name: STARTUP_PROJECT
  value: RazorPagesContacts.csproj
Complete devfile.yaml after the changes.
commands:
- exec:
    commandLine: kill $(pidof dotnet); dotnet build -c $CONFIGURATION $STARTUP_PROJECT
      /p:UseSharedCompilation=false
    component: dotnet
    group:
      isDefault: true
      kind: build
    workingDir: ${PROJECT_SOURCE}
  id: build
- exec:
    commandLine: dotnet run -c $CONFIGURATION --no-build --project $STARTUP_PROJECT
      --no-launch-profile
    component: dotnet
    group:
      isDefault: true
      kind: run
    workingDir: ${PROJECT_SOURCE}
  id: run
components:
- container:
    args:
    - tail
    - -f
    - /dev/null
    endpoints:
    - name: http-dotnet60
      targetPort: 8080
    env:
    - name: CONFIGURATION
      value: Debug
    - name: STARTUP_PROJECT
      value: RazorPagesContacts.csproj
    - name: ASPNETCORE_ENVIRONMENT
      value: Development
    - name: ASPNETCORE_URLS
      value: http://*:8080
    image: registry.access.redhat.com/ubi8/dotnet-60:6.0
    mountSources: true
  name: dotnet
metadata:
  description: Stack with .NET 6.0
  displayName: .NET 6.0
  icon: https://github.com/dotnet/brand/raw/main/logo/dotnet-logo.png
  language: .NET
  name: myapp
  projectType: dotnet
  tags:
  - .NET
  version: 1.0.2
schemaVersion: 2.1.0
starterProjects:
- git:
    checkoutFrom:
      remote: origin
      revision: dotnet-6.0
    remotes:
      origin: https://github.com/redhat-developer/s2i-dotnetcore-ex
  name: dotnet60-example
  subDir: app

Start the application on the clusterโ€‹

We have our application source code and the devfile.yaml that describes the environment in which the application should be executed. We can now start the application on the cluster. Just run odo dev in the project directory.

odo dev
example output
โ–ถ odo dev
  __
/  \__     Developing using the "myapp" Devfile
\__/  \    Namespace: tkral-dev
/  \__/    odo version: v3.6.0
\__/

โ†ช Deploying to the cluster in developer mode
โ€ข  Waiting for Kubernetes resources  ...
โœ“  Pod is Running
โœ“  Syncing files into the container [2s]
โœ“  Building your application in container on cluster (command: build) [11s]
โ€ข  Executing the application (command: run)  ...
-  Forwarding from 127.0.0.1:20001 -> 8080


โ†ช Dev mode
Status:
Watching for changes in the current directory /Users/tkral/Code/s2i-dotnetcore-persistent-ex/app

Keyboard Commands:
[Ctrl+c] - Exit and delete resources from the cluster
    [p] - Manually apply local changes to the application on the cluster

odo dev performs the following actions:

  1. Starts the containers on the cluster based on the information from the devfile.yaml.
  2. Copies all the source code from your local machine to the container.
  3. Executes build and run commands as defined in the devfile.yaml.
  4. When the application is successfully running in the container, odo sets the port forwarding between your local machine and the container to ensure we can easily access our application on the local port. In this case, it is port 20001.

Now you can access the application on http://localhost:20001.

App running with In Memory DB

You can see that our application is now using the in-memory database. We will start the PostgreSQL database and connect our application in the following steps.

You can leave odo dev running in the terminal and open a new terminal window to continue with the next steps. Make sure that you run all odo commands in the root folder of our .NET application (where you have devfile.yaml and RazorPagesContacts files).

Use the PostgreSQL databaseโ€‹

Start a new PostgreSQL instance on the OpenShift clusterโ€‹

To start a new PostgreSQL instance on the OpenShift cluster, we can use the postgresql-ephemeral template that is available in the OpenShift cluster.

If you have oc CLI installed, you can use the following command to start a new PostgreSQL instance:

oc new-app postgresql-ephemeral
example output
โ–ถ oc new-app postgresql-ephemeral
--> Deploying template "openshift/postgresql-ephemeral" to project tkral-dev

    PostgreSQL (Ephemeral)
    ---------
    PostgreSQL database service, without persistent storage. For more information about using this template, including OpenShift considerations, see https://github.com/sclorg/postgresql-container/.

    WARNING: Any data stored will be lost upon pod destruction. Only use this template for testing

    The following service(s) have been created in your project: postgresql.

            Username: user2GR
            Password: 6UrRpvC8ups70ffr
      Database Name: sampledb
      Connection URL: postgresql://postgresql:5432/

    For more information about using this template, including OpenShift considerations, see https://github.com/sclorg/postgresql-container/.

    * With parameters:
        * Memory Limit=512Mi
        * Namespace=openshift
        * Database Service Name=postgresql
        * PostgreSQL Connection Username=user2GR # generated
        * PostgreSQL Connection Password=6UrRpvC8ups70ffr # generated
        * PostgreSQL Database Name=sampledb
        * Version of PostgreSQL Image=10-el8

--> Creating resources ...
    secret "postgresql" created
    service "postgresql" created
    deploymentconfig.apps.openshift.io "postgresql" created
--> Success
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
    'oc expose service/postgresql'
    Run 'oc status' to view your app.

If you don't have oc CLI installed, you can use the OpenShift web console to start a new PostgreSQL instance.

Starting new PostgreSQL instance using OpenShift Web Console
  1. Log in to OpenShift Web Console.
  2. Switch to the Developer view and make sure that you are using correct project.ODC step 1
  3. Click on the +Add button in the main menu and select Database option from the Developer Catalog section.ODC step 2
  4. In the Database section select PostgreSQL option. Make sure to select the one using Templates.ODC step 3
  5. Click on the Instantiate Template button.ODC step 4
  6. For our use we can use the default values. Just click on the Create button.ODC step 5
Now you have a new PostgreSQL instance running on the OpenShift cluster and we can connect our application to it.

Connect the application to the PostgreSQLโ€‹

We must ensure that our .NET application can connect to the PostgreSQL instance. The application already expects the connection information to be available as environment variables. We will use the postgresql Secret that was created by the postgresql-ephemeral template.

We will use one of the newest odo and Devfile features - container-overrides. Using this feature, we can modify the container that the Devfile creates.

Open devfile.yaml in the application directory and add the following section to the dotnet container:

attributes:
  container-overrides: {envFrom: [secretRef: {name: "postgresql"}]}

While you have devfile.yaml open, you also need to add a new environment variable called database-service. This variable will tell our application to use the PostgreSQL database instead of the in-memory database. Add the following lines in to the env section of the dotnet container:

- name: database-service
  value: postgresql
This is how the devfile.yaml should look like.
commands:
- exec:
    commandLine: kill $(pidof dotnet); dotnet build -c $CONFIGURATION $STARTUP_PROJECT
      /p:UseSharedCompilation=false
    component: dotnet
    group:
      isDefault: true
      kind: build
    workingDir: ${PROJECT_SOURCE}
  id: build
- exec:
    commandLine: dotnet run -c $CONFIGURATION --no-build --project $STARTUP_PROJECT
      --no-launch-profile
    component: dotnet
    group:
      isDefault: true
      kind: run
    workingDir: ${PROJECT_SOURCE}
  id: run
components:
- container:
    args:
    - tail
    - -f
    - /dev/null
    endpoints:
    - name: http-dotnet60
      targetPort: 8080
    env:
    - name: CONFIGURATION
      value: Debug
    - name: STARTUP_PROJECT
      value: RazorPagesContacts.csproj
    - name: ASPNETCORE_ENVIRONMENT
      value: Development
    - name: ASPNETCORE_URLS
      value: http://*:8080
    - name: database-service
      value: postgresql
    image: registry.access.redhat.com/ubi8/dotnet-60:6.0
    mountSources: true
  name: dotnet
  attributes:
    container-overrides: {envFrom: [secretRef: {name: "postgresql"}]}
metadata:
  description: Stack with .NET 6.0
  displayName: .NET 6.0
  icon: https://github.com/dotnet/brand/raw/main/logo/dotnet-logo.png
  language: .NET
  name: myapp
  projectType: dotnet
  tags:
  - .NET
  version: 1.0.2
schemaVersion: 2.1.0
starterProjects:
- git:
    checkoutFrom:
      remote: origin
      revision: dotnet-6.0
    remotes:
      origin: https://github.com/redhat-developer/s2i-dotnetcore-ex
  name: dotnet60-example
  subDir: app

As you modify the devfile.yaml, you can check the terminal window where you have odo dev running. You should see that odo is automatically handling the changes and reloading the application.

Now, refresh the local URL http://localhost:20001. You should see that our application is using the PostgreSQL database. App running with PostgreSQL DB

]]> Tomas Kral https://github.com/kadel <![CDATA[odo v3.7.0 Released]]> https://odo.dev/blog/odo-v3.7.0 2023-02-15T00:00:00.000Z odo v3.7.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: odo v3.7.0 (Sprint 231)

Featuresโ€‹

odo logs on Podmanโ€‹

To continue improving the feature parity between Kubernetes and Podman, odo logs is now supported on the latter.

Similarly to how odo dev requires specifying the target platform (using the --platform flag), odo logs also requires specifying the platform to display the logs of a component running on Podman, like so:

ODO_EXPERIMENTAL_MODE=t odo logs --platform podman

As a reminder, Podman support in odo is still experimental and requires you to opt in if you want to try it out.

More details on forwarded ports in the output of odo describe componentโ€‹

odo describe component now additionally includes the following helpful information about forwarded ports:

  • the endpoint name, as defined in the Devfile
  • the endpoint exposure, as defined in the Devfile
  • whether the port is a debug endpoint or not. Note that this is based upon a naming convention: the endpoint name in the Devfile should be debug or be prefixed with debug- to be considered as a debug endpoint.
Example output:
Normal outputJSON output
$ odo describe component

[...]

Forwarded ports:
 โ€ข  127.0.0.1:20001 -> cont:3000
    Name: http-node
 โ€ข  127.0.0.1:20002 -> cont:5858
    Name: debug
    Exposure: none
    Debug: true
 โ€ข  127.0.0.1:20003 -> cont2:5005
    Name: debug-2
    Exposure: internal
    Debug: true

[...]
$ odo describe component -o json
{
  [...]
  "devForwardedPorts": [
    {
      "containerName": "cont",
      "portName": "http-node",
      "isDebug": false,
      "localAddress": "127.0.0.1",
      "localPort": 20001,
      "containerPort": 3000
    },
    {
      "containerName": "cont",
      "portName": "debug",
      "isDebug": true,
      "exposure": "none"
      "localAddress": "127.0.0.1",
      "localPort": 20002,
      "containerPort": 5858
    },
    {
      "containerName": "cont2",
      "portName": "debug-2",
      "isDebug": true,
      "exposure": "internal"
      "localAddress": "127.0.0.1",
      "localPort": 20003,
      "containerPort": 5005
    }
  ],
  [...]
}

Support for OpenShift Devfile componentsโ€‹

odo now supports OpenShift components that are defined in a Devfile.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Full Changelog

Features/Enhancements:

  • Support for image component on podman #6577 (valaparthvi)
  • Support dev.odo.push.path:* attributes on Podman #6576 (rm3l)
  • Implement odo logs on podman #6550 (feloy)
  • Add support for OpenShift Devfile components #6548 (rm3l)
  • Set platform and platformVersion in telemetry #6540 (feloy)
  • Show information about forwarded debug ports in odo describe component #6537 (rm3l)

Bugs:

  • Fix UX inconsistency when handling commands bound to events #6574 (rm3l)
  • odo logs: Do not panic when no access to cluster/podman #6561 (feloy)
  • Correct container-attributes data in release blog #6560 (valaparthvi)
  • Log error when podman client cannot be initialized #6538 (valaparthvi)
  • Display error message when odo dev fails on podman and clean resources #6522 (valaparthvi)

Documentation:

  • Fix the port value (20001) in the quickstart guides #6570 (rm3l)
  • Verification file for Google Search console [feloy] #6566 (feloy)
  • Dogfood odo for working on the website #6564 (rm3l)
  • Set the date for the v3 GA blog post #6563 (rm3l)
  • Add blog post demonstrating how odo can be used with Podman #6562 (rm3l)
  • docs: --HEAD flag for homebrew no longer needed #6554 (kadel)
  • Release PR for v3.6.0 #6529 (github-actions[bot])

Cleanup/Refactor:

  • test: use t.TempDir to create temporary test directory #6533 (Juneezee)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Armel Soro https://github.com/rm3l <![CDATA[Local container development with Podman and odo]]> https://odo.dev/blog/local-container-development-with-podman-and-odo 2023-01-30T00:00:00.000Z odo and Podman

So far, odo has been mainly focusing on container development on Kubernetes and OpenShift clusters.

In this post, we will showcase the experimental support we have recently added for Podman. We will see how odo can leverage Podman for local development in containers with no requirement whatsoever on any cluster โ€” making it easier to iterate on the application locally and transition to Kubernetes or OpenShift later on.

Prerequisitesโ€‹

Working locally with Podmanโ€‹

Let's revisit one of our quickstart guides, say the Golang one, to make it work with Podman.

Step 0. Creating the initial source code (optional)โ€‹

We will create the example source code by using some popular frameworks.

Before we begin, we will create a new directory and cd into it.

mkdir quickstart-demo && cd quickstart-demo

This is optional and you may use an existing project instead (make sure you cd into the project directory before running any odo commands) or a starter project from odo init.

For Go, we will create our own application using the standard library:

  1. Create the following main.go file:
package main

import (
  "fmt"
  "log"
  "net/http"
)

func main() {
  const addr = "0.0.0.0:8080"
  http.HandleFunc("/", HelloServer)
  log.Println("Up and running on", addr)
  http.ListenAndServe(addr, nil)
}

func HelloServer(w http.ResponseWriter, r *http.Request) {
  log.Println("New request:", *r)
  fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:])
}
  1. Initialize a go.mod file:
go mod init my.example.go.project
Example
$ go mod init my.example.go.project
go: creating new go.mod: module my.example.go.project
go: to add module requirements and sums:
    go mod tidy

Your source code has now been generated and created in the directory.

Step 1. Initializing your application (odo init)โ€‹

Now we'll initialize the application by creating a devfile.yaml to be deployed.

odo handles this automatically with the odo init command by auto-detecting the source code and downloading the appropriate Devfile.

Note: If you skipped Step 0, select a "starter project" when running odo init.

Let's run odo init and select Go:

odo init
Sample Output
$ odo init
  __
 /  \__     Initializing a new component
 \__/  \    Files: Source code detected, a Devfile will be determined based upon source code autodetection
 /  \__/    odo version: v3.6.0
 \__/

Interactive mode enabled, please answer the following questions:
Based on the files in the current directory odo detected
Language: Go
Project type: Go
The devfile "go:1.0.2" from the registry "Staging" will be downloaded.
? Is this correct? Yes
 โœ“  Downloading devfile "go:1.0.2" from registry "Staging" [1s]

โ†ช Container Configuration "runtime":
  OPEN PORTS:
    - 8080
  ENVIRONMENT VARIABLES:

? Select container for which you want to change configuration? NONE - configuration is correct
? Enter component name: quickstart-demo

You can automate this command by executing:
   odo init --name quickstart-demo --devfile go --devfile-registry Staging --devfile-version 1.0.2

Your new component 'quickstart-demo' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.
note

If you skipped Step 0 and selected "starter project", your output will be slightly different.

Step 2. Enabling the experimental modeโ€‹

Because the support for Podman is still experimental at the time of writing, we first need to explicitly opt-in.

Enabling the experimental mode can be done by setting the ODO_EXPERIMENTAL_MODE environment variable to true in the terminal session, like so:

export ODO_EXPERIMENTAL_MODE=true

Step 3. Iterating on your application locally on containers (odo dev)โ€‹

Now that we've generated our code as well as our Devfile, let's start iterating on our application locally by starting a Development session with odo dev, but targeting our local Podman.

odo dev on Podman will use the same inner loop development as for the cluster mode, allowing you to code, build, run and test the application in a continuous workflow.

Once you run odo dev --platform=podman, you can freely edit the application code in your favorite IDE and watch as odo rebuilds and redeploys it.

Let's run odo dev --platform=podman to start development on your Go application:

odo dev --platform=podman
Sample Output
$ odo dev --platform=podman
============================================================================
โš  Experimental mode enabled. Use at your own risk.
More details on https://odo.dev/docs/user-guides/advanced/experimental-mode
============================================================================

  __
 /  \__     Developing using the "quickstart-demo" Devfile
 \__/  \    Platform: podman
 /  \__/    odo version: v3.6.0
 \__/

โ†ช Running on podman in Dev mode
 โœ“  Deploying pod [5s]
 โœ“  Building your application in container (command: build) [693ms]
 โ€ข  Executing the application (command: run)  ...
 -  Forwarding from 127.0.0.1:20001 -> 8080

โ†ช Dev mode
 Status:
 Watching for changes in the current directory /tmp/test-go-podman/quickstart-demo

 Keyboard Commands:
[Ctrl+c] - Exit and delete resources from podman
     [p] - Manually apply local changes to the application on podman

You can now access the application at 127.0.0.1:20001 in your local browser and start your development loop. odo will watch for changes and push the code for real-time updates.

Example
$ curl http://127.0.0.1:20001/world

Hello, world!

We can optionally open the Podman Desktop application to take a look at the resources odo has created for our application on Podman:

Wrapping Upโ€‹

odo is now able to work with Podman to accelerate local development in containers, without requiring you to have access to any Kubernetes cluster.

Note that our support for Podman is still experimental, but we are working on improving the feature parity (as much as possible) with the cluster mode.

As such, any feedback is highly appreciated.

]]> Armel Soro https://github.com/rm3l <![CDATA[odo v3.6.0 Released]]> https://odo.dev/blog/odo-v3.6.0 2023-01-24T00:00:00.000Z odo v3.6.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: odo v3.6.0 (Sprint 230)

Featuresโ€‹

Extend pod and container specification with Devfile attributes pod-overrides and container-overridesโ€‹

It is now possible to extend a pod and its container specification by using pod-overrides and container-overrides Devfile attributes.

This feature allows you to modify pod specifications such as Service Account, Scheduler Name, Security Context, etc and container specifications such as Security Context, and Resources. However, it restricts from modifying pod specifications such as Init Containers, Containers, and Volumes; and container specifications such as Volume Mounts, Image, Ports, Name, Env, Args, and Commands.

pod-overrides can be specified at both the Component and Devfile attributes levels while container-overrides can only be specified at the Component level. If an attribute is defined at both levels, a strategic merge patch will be used to merge them both.

Example -

attributes:
  pod-overrides:
    spec:
      serviceAccountName: my-new-service-account
  container-overrides:
    spec:
      securityContext:
        runAsUser: 1001
        runAsGroup: 1001

odo delete component now has a new --running-in flagโ€‹

--running-in flag can be used with odo delete component to specify the mode in which resources should be deleted. There are 2 modes to choose from "dev", and "deploy". By default, the commands deletes all the resources regardless of the mode.

To delete resources running in 'Dev' mode, i.e. resources created by odo dev use --running-in=dev.

To delete resources running in 'Deploy' mode, i.e. resources created by odo deploy use --running-in=deploy.

odo can now be used inside DevSpacesโ€‹

Port forwarding done by odo dev now uses port numbers starting from 20001 instead of 40001. This change was made to make it possible to run odo inside DevSpaces.

caution

This is a possible breaking change. For more information or any questions, see the issue #6483.

odo describe component displays remote source code location for every containersโ€‹

odo describe component now shows where the source code is located on your container. It uses the devfile container spec mountSources and sourceMapping to determine the location of a mounted source code.

odo dev on podman now logs errors when the command fails to runโ€‹

odo dev when running on podman now logs error when the command fails to run. In the previous versions of odo this was possible with cluster only.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Release of v3.6.0

v3.6.0 (2023-01-24)โ€‹

Full Changelog

Features/Enhancements:

  • Set experimental mode in telemetry #6520 (feloy)
  • Change port range used for port-forwarding endpoints to start at 20001 #6519 (feloy)
  • Update devfile/library to support pod-overrides and container-overrides attributes and add integration test for it #6512 (valaparthvi)
  • Port-forward Debug endpoints only when running odo dev with --debug #6505 (rm3l)
  • odo describe component: display remote source code location for each container component #6497 (valaparthvi)
  • Implement odo delete component --running-in #6485 (rm3l)
  • [podman] show logs when command fails #6481 (feloy)
  • Display a warning that "odo dev" on Podman needs to be restarted if the Devfile is changed #6477 (rm3l)
  • Ignore and show warning when handling Kubernetes components on Podman #6471 (valaparthvi)
  • Refactor Advanced guide doc to use framework specific output #6444 (valaparthvi)
  • Refactor Quickstart guide doc to use framework specific output #6443 (valaparthvi)

Bugs:

Documentation:

Testing/CI:

  • Make doc tests pass #6516 (feloy)
  • Add more tests for odo dev on Podman (3) #6515 (feloy)
  • Make sure to use random component names when copying sample Devfiles in integration tests #6504 (rm3l)
  • Isolate Podman tests in namespaces #6499 (rm3l)
  • Add more tests for odo dev on Podman (1) #6496 (feloy)
  • Adding Github Actions for podman testing #6385 (anandrkskd)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> valaparthvi https://github.com/valaparthvi <![CDATA[odo v3.5.0 Released]]> https://odo.dev/blog/odo-v3.5.0 2023-01-04T00:00:00.000Z odo v3.5.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: odo v3.5.0 (Sprint 229)

Featuresโ€‹

odo delete component deletes component running on podmanโ€‹

When you run odo dev on podman platform, pressing Ctrl+c will delete the resources from podman. If odo dev does not delete the resources as expected (because it failed unexpectedly, it has been killed with the KILL(9) signal, etc), you can use odo delete component to delete the resources.

Note that you need to run delete command in the experimental mode for this feature.

odo describe component describes component running on podmanโ€‹

You can now get the description of a component running on podman with the command odo describe component.

Note that you need to run the describe command in the experimental mode for this feature.

Allow fetching a specific Devfile Stack versionโ€‹

Version 3.4.0 of odo introduced the support of versioned Devfile stacks, with the ability to list available versions of Devfile stacks. Starting with version 3.5.0, you can initialize a new project with a specific version of a Devfile stack. Previously, the default version was used.

Enable ImageStream resolvingโ€‹

If you are developing on an OpenShift cluster, odo dev can now use images from ImageStreams defined in your cluster, without any configuration.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Release of v3.5.0

v3.5.0 (2023-01-04)โ€‹

Full Changelog

Features/Enhancements:

  • Rename generic run-on flag into platform #6445 (feloy)
  • odo delete component on podman with --name #6437 (feloy)
  • Make odo describe component show information about components running on Podman #6431 (rm3l)
  • Allow fetching specific devfile stack version #6429 (valaparthvi)
  • odo delete component deletes components running on podman #6418 (feloy)
  • Enable use of ImageStreams on OpenShift #6406 (feloy)

Bugs:

  • Fix typo in odo remove binding #6449 (valaparthvi)
  • Add missing example to init command reference doc #6436 (valaparthvi)
  • Fix preference not taken into account for odo version #6415 (feloy)
  • Fallback to interactive mode if there is no match from Alizer when initializing a component #6410 (rm3l)

Documentation:

Testing/CI:

  • Add more tests for Podman + write Component abstraction for integration tests #6427 (feloy)

Cleanup/Refactor:

  • Display a generic Experimental mode warning message when this mode is enabled #6426 (rm3l)

Merged pull requests:

* This Changelog was automatically generated by github_changelog_generator

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Philippe Martin https://github.com/feloy <![CDATA[odo v3.4.0 Released]]> https://odo.dev/blog/odo-v3.4.0 2022-12-13T00:00:00.000Z odo v3.4.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://youtube.com/playlist?list=PLGMB2PY4SNOoGy0Pq38ds0q9I98IJv76M

Potentially breaking changesโ€‹

Output of odo list services -o jsonโ€‹

The group field has been removed from the JSON output of odo list services and is now superseded by a new apiVersion field (containing information about both the group and version).

The service field has also been updated to include information about the version.

See #6347 for more details.

Example:

 {
   "bindableServices": [
     {
       "name": "cluster-sample",
       "namespace": "cmd-describe-list-binding-test549cmw",
       "kind": "Cluster",
-      "group": "postgresql.k8s.enterprisedb.io",
-      "service": "cluster-sample/Cluster.postgresql.k8s.enterprisedb.io"
+      "apiVersion": "postgresql.k8s.enterprisedb.io/v1",
+      "service": "cluster-sample/Cluster.postgresql.k8s.enterprisedb.io/v1"
     }
   ]
 }

Featuresโ€‹

Using odo with Podmanโ€‹

Based on your valuable feedback, we have worked on improving the experience of using odo with Podman. Note that this is still experimental and requires you to opt in if you want to try it out.

  • In #6329, we have added labels to resources created by odo on Podman, so we can easily identify and use them. This adds the same labels depicted in How odo works.
  • With #6366, odo list component is now able to list components running on Podman.
  • With #6328, odo dev now supports volumes and volume mounts defined in a Devfile. Volume components allow sharing files among container components.
  • With #6348, odo dev is now able to react to changes in local source files by re-synchronizing changed files and restarting the application running on Podman.
  • With #6377, odo dev no longer hard-codes the exposed host port. Instead, it is able to pick any freely available local port, in a range starting from 40001.

See the demo below for an overview of these changes:

Support for multi-document YAML resource for Devfile Kubernetes componentsโ€‹

odo now supports running Devfile components that are represented by a multi-document YAML.

Automatic application port detectionโ€‹

When running odo init interactively, we now try to automatically detect as much as possible the ports used in the current application source code. When information about the ports is available, we customize the initial Devfile accordingly.

Listing Devfile Stack versionsโ€‹

odo registry (and its JSON counterpart) now displays the Devfile stack versions.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Features/Enhancements:

  • Add support for parsing multiple k8s definition in a single Devfile K8s component #6372 (valaparthvi)
  • Support Alizer-based automatic port detection with odo init interactive mode #6365 (rm3l)
  • Show Devfile Stack versions in "odo registry" output #6397 (rm3l)
  • Pass caller to registry telemetry #6382 (feloy)
  • Set labels for component on podman #6329 (feloy)
  • odo dev on podman: Add support for devfile volume #6328 (feloy)
  • Get next free port when forwarding ports on podman #6377 (feloy)
  • odo list component shows components running on podman #6366 (feloy)
  • Sync files on Podman #6348 (feloy)

Bugs:

  • Display a warning when connection to cluster fails #6384 (feloy)
  • Improve confirmation message for namespace/project deletion #6383 (rm3l)
  • Delay the display of warnings related to experimental features #6375 (feloy)
  • Fix: Panic when running odo list namespaces without an active Kubernetes context #6367 (valaparthvi)
  • Replace group by apiVersion in odo list services output #6358 (feloy)
  • Fix completion error when command is empty #6354 (feloy)
  • Run Devfile personalization in interactive mode from empty directory #6351 (anandrkskd)
  • Downloading wrong starter project when using odo init #6346 (anandrkskd)

Documentation:

  • Show IDE plugin usage on Home page and in installation docs #6380 (rm3l)
  • Make remaining Quickstart docs consistent #6324 (SD-13)
  • Add complete devfiles to advanced guides #6388 (valaparthvi)
  • Update build version and release blog post for v3.3.0 #6359 (valaparthvi)

Testing/CI:

  • Test with OpenShift cluster non authenticated #6395 (feloy)
  • Flake odo add binding in interactive doest show namespace recently created #6391 (anandrkskd)
  • replacing timeout with time interval #6369 (anandrkskd)
  • updating bindable kind instance #6363 (anandrkskd)
  • Integration tests: Declare devfile volumes as ephemeral #6356 (feloy)
  • Disable flaky test on Windows #6341 (feloy)
  • Integration tests for odo dev running on podman #6332 (feloy)
  • E2e scenario 3 #6073 (anandrkskd)
  • update env name for ODO_ROBOT_KEY #6393 (anandrkskd)
  • Fix flaky behavior with "list namespaces/projects -o json" integration tests #6355 (rm3l)
  • fix: add exit code check for no-cluster tests #6345 (anandrkskd)
  • Fix potential unit tests failures caused by envconfig relying on the system environment #6344 (rm3l)

Cleanup/Refactor:

  • Do not call LogErrorAndExit but return err in GenericRun #6352 (feloy)
  • Use go-cmp instead of reflect.DeepEqual to compare unit test results #6343 (rm3l)
  • Lower log level for kclient.GetAllResourcesFromSelector #6360 (feloy)

Merged pull requests:

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Armel Soro https://github.com/rm3l <![CDATA[odo v3.3.0 Released]]> https://odo.dev/blog/odo-v330 2022-11-29T00:00:00.000Z odo v3.3.0 is now out!

To install odo, follow the installation guide.

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://www.youtube.com/playlist?list=PLGMB2PY4SNOr5pjbPTdcWsIrOezCPXWdX

Featuresโ€‹

Experimental Mode (#6150)โ€‹

There is now an Experimental Mode in odo that can be enabled by exporting ODO_EXPERIMENTAL_MODE=true to your environment. All the new features will be generally available under this mode, giving you an opportunity to try them out sooner.

odo dev using Podman (#6151)โ€‹

You can now useodo dev to run your application on Podman. odo leverages the benefit of Podman to work seamlessly with Kubernetes YAML and replicate them to containers locally. This is an experimental feature and can be used with --run-on flag.

odo list namespaces is now available in JSON format (#6257)โ€‹

odo describe component can now list Routes/Ingresses (#5990)โ€‹

Applications deployed in the Deploy mode often include resources such as Routes (on OpenShift) and Ingresses (on Kubernetes) to allow access to an application. odo describe component can now list these resources.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Features/Enhancements:

  • Add support for an experimental mode #6300 (rm3l)
  • Adds ability to list namespaces in JSON format #6295 (dharmit)
  • Centralize environment configuration #6293 (feloy)
  • display equivalent odo init command for odo init interactive #6265 (anandrkskd)
  • Implement odo delete component --files to delete files generated by odo #6255 (rm3l)
  • List Routes/Ingresses created by odo deploy in odo describe component #6244 (valaparthvi)
  • Podman dev #6183 (feloy)
  • Update odo to use go 1.18 #6166 (dharmit)

Bugs:

  • Disable loading a single branch when getting git starter project #6290 (feloy)
  • fix to prioritize newly added registry #6289 (anandrkskd)
  • fix login failure on interop tests with error: x509 #6288 (anandrkskd)
  • Sanitize value for 'app.openshift.io/runtime' label #6284 (rm3l)
  • If command has only one command assume that it is default #6281 (kadel)
  • resolve inconsistent order of registries in preference view #6266 (anandrkskd)
  • Fix rpminspect specname inspection failure #6241 (rm3l)
  • odo dev deletes remote resources not present in the Devfile #6189 (valaparthvi)

Documentation:

Testing/CI:

Cleanup/Refactor:

  • Remove localconfig LocalConfigProvider abstraction #6285 (feloy)
  • Make functions for executing run command reusable #6277 (feloy)
  • Make 'pkg/logs' platform-agnostic #6251 (rm3l)

Merged pull requests:

Contributing to odoโ€‹

If odo interests you, and you would like to contribute to it, we welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Parthvi Vala https://github.com/valaparthvi <![CDATA[odo v3.0.0 GA Released ๐ŸŽ‰]]> https://odo.dev/blog/odo-v3-release 2022-10-19T00:00:00.000Z odo v3 is now GA! ๐ŸŽ‰

Are you an application developer wanting to work closely with a production-like environment? Pressured on time due to the steep learning curve involved in cluster development?

odo is here to answer your problems!

Over the past couple of months, the odo team has been developing better experiences on working with applications and container clusters.

So, what's new?โ€‹

odo v3 comes with a new set of commands that replaces the old one but essentially does the same thing, in a faster and more efficient way.

odo initโ€‹

odo init allows you to generate example code or fetch an appropriate Devfile for your existing project.

  __
 /  \__     Initializing a new component
 \__/  \    Files: Source code detected, a Devfile will be determined based upon source code autodetection
 /  \__/    odo version: v3.0.0
 \__/

Interactive mode enabled, please answer the following questions:
Based on the files in the current directory odo detected
Language: javascript
Project type: nodejs
The devfile "nodejs" from the registry "StagingRegistry" will be downloaded.
? Is this correct? Yes
 โœ“  Downloading devfile "nodejs" from registry "StagingRegistry" [3s]

โ†ช Container Configuration "runtime":
  OPEN PORTS:
    - 3000
  ENVIRONMENT VARIABLES:

? Select container for which you want to change configuration? NONE - configuration is correct
? Enter component name: my-node-app

Your new component 'my-node-app' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.

How is it different from the odo create command of v2?

Detect the appropriate Devfileโ€‹

odo init will automatically analyze your directory and based on the project type, suggest an appropriate Devfile for use.

Personalize the Devfile configurationโ€‹

odo init also provides a better interactive way to configure your Devfile according to your project requirement. With this feature, you can modify the environment variables exported to and ports exposed by your application on the cluster.

odo devโ€‹

odo dev allows you to build, run, debug and test your application on the cluster in a continuous workflow.

$ odo dev
  __
 /  \__     Developing using the "my-node-app" Devfile
 \__/  \    Namespace: default
 /  \__/    odo version: v3.0.0
 \__/

โ†ช Deploying to the cluster in developer mode
 โ€ข  Waiting for Kubernetes resources  ...
 โš   Pod is Pending
 โœ“  Pod is Running
 โœ“  Syncing files into the container [172ms]
 โœ“  Building your application in container on cluster (command: install) [11s]
 โ€ข  Executing the application (command: run)  ...
 -  Forwarding from 127.0.0.1:40001 -> 3000


โ†ช Dev mode
 Status:
 Watching for changes in the current directory /tmp/pd

 Keyboard Commands:
[Ctrl+c] - Exit and delete resources from the cluster
     [p] - Manually apply local changes to the application on the cluster

How is it different from the odo push command of v2?

odo v3 combines the odo push and odo watch commands from v2 into a single odo dev command.

Additionally the command provides:

Continuous workflowโ€‹

odo dev is a non-terminating command that runs until the user hits Ctrl+c. It continuously watches the directory for any new changes (including the changes occurring in the Devfile) and automatically syncs them with the application running on the cluster.

Manual trigger to apply local changes on the clusterโ€‹

By default, odo dev automatically detects any new change in the directory, and syncs it with the application running on the cluster, but it is possible to do this trigger manually by running the command with a --no-watch flag and pressing p to trigger the sync.

Better watch systemโ€‹

odo dev continuously monitors the resources created to run the application on the cluster and ensures that the application stays running.

Resource cleanupโ€‹

Before exiting, odo dev will cleanup any resources that it created while running the application on the cluster.

Port forwarding to access the applicationโ€‹

odo dev uses port-forwarding instead of Routes and Ingresses for accessing the application.

Read this section to learn more: What happened to Ingress/Route?

odo add bindingโ€‹

odo add binding allows the application to connect to an Operator Backed service.

$ odo add binding
? Do you want to list services from: current namespace
? Select service instance you want to bind to: cluster-sample (Cluster.postgresql.k8s.enterprisedb.io)
? Enter the Binding's name: my-node-app-cluster-sample
? How do you want to bind the service? Bind As Files
? Select naming strategy for binding names: DEFAULT
 โœ“  Successfully added the binding to the devfile.
Run `odo dev` to create it on the cluster.
You can automate this command by executing:
  odo add binding --service cluster-sample.Cluster.postgresql.k8s.enterprisedb.io --name my-node-app-cluster-sample

How is it different from the odo link command of v2?

Interactive modeโ€‹

odo add binding provides an interactive mode that lists bindable services across all the namespaces, and a way to personalize related configuration, making the experience better.

Ability to connect to a service in any namespaceโ€‹

odo add binding allows the application to connect to any bindable service in any namespace, it does not necessarily have to be in the same namespace as the application.

Run from anywhereโ€‹

odo add binding can be run from anywhere and does not require access to a Devfile in order to work. With this method, you can either: directly create the Service Binding on the cluster, write the YAML to a file, or simply display it.

Work without a running applicationโ€‹

As opposed to v2, odo add binding no longer requires the application to be running on the cluster, making it even faster.

Only supports Bindable Operatorsโ€‹

odo link could link an application to another application and any Operator Backed service. As of now, v3 only supports connecting to services that are backed by Operators considered bindable by the Service Binding Operator.

Requires the Service Binding Operatorโ€‹

odo add binding requires that the Service Binding Operator is installed on the cluster before it is run. The command relies on the Operator to provide it with a list of Bindable services.

odo deployโ€‹

odo deploy allows you to run the outerloop of your development cycle, essentially in a production-like environment.

Once you are satisfied with your application development locally, and are now ready to show your application to the world, you can use odo deploy to move to the next stage.

$ odo deploy
  __
 /  \__     Deploying the application using "my-node-app" Devfile
 \__/  \    Namespace: my-node-app
 /  \__/    odo version: v3.0.0
 \__/

โ†ช Building & Pushing Container: quay.io/pvala18/myimage
 โ€ข  Building image locally  ...
STEP 1/7: FROM quay.io/phmartin/node:17
STEP 2/7: WORKDIR /usr/src/app
--> Using cache b18c8d9f4c739a91e5430f235b7beaac913250bec8bfcae531a8e93c750cea87
--> b18c8d9f4c7
STEP 3/7: COPY package*.json ./
--> Using cache cd151181cd9b2c69fc938eb89f3f71d0327d27ffba53c54247a105733cb36217
--> cd151181cd9
STEP 4/7: RUN npm install
--> Using cache 72b79a4f76ab0f9665653a974f5c667b1cb964c89c58e71aa4817b1055b1c473
--> 72b79a4f76a
STEP 5/7: COPY . .
--> 5c81f92690e
STEP 6/7: EXPOSE 8080
--> 9892b562a8a
STEP 7/7: CMD [ "node", "server.js" ]
COMMIT quay.io/pvala18/myimage
--> 7578e3e3667
Successfully tagged quay.io/pvala18/myimage:latest
7578e3e36676418853c579063dd190c9d736114ca414e28c8646880b446a1618
 โœ“  Building image locally [2s]
 โ€ข  Pushing image to container registry  ...
Getting image source signatures
Copying blob 0b3c02b5d746 skipped: already exists
Copying blob 62a747bf1719 skipped: already exists
Copying blob 650b52851ab5 done
Copying blob 013fc0144002 skipped: already exists
Copying blob aef6a4d33347 skipped: already exists
Copying config 7578e3e366 done
Writing manifest to image destination
Storing signatures
 โœ“  Pushing image to container registry [22s]

โ†ช Deploying Kubernetes Component: my-component
 โœ“  Creating kind Deployment 

Your Devfile has been successfully deployed

odo dev vs odo deployโ€‹

You might find yourself wondering how odo dev is different from odo deploy and when should you use the either one, you can read this article to get an answer to that question.

odo registryโ€‹

odo registry lists all the Devfiles provided by the Devfile registries added to your development environment.

$ odo registry
 NAME                          REGISTRY         DESCRIPTION                                 
 dotnet50                      StagingRegistry  Stack with .NET 5.0                         
 dotnet60                      StagingRegistry  Stack with .NET 6.0                         
 dotnetcore31                  StagingRegistry  Stack with .NET Core 3.1                    
 go                            StagingRegistry  Go is an open source programming languag... 
 java-maven                    StagingRegistry  Upstream Maven and OpenJDK 11               
 java-openliberty              StagingRegistry  Java application Maven-built stack using... 
 java-openliberty-gradle       StagingRegistry  Java application Gradle-built stack usin... 
 java-quarkus                  StagingRegistry  Quarkus with Java                           
 java-springboot               StagingRegistry  Spring Bootยฎ using Java                     
 java-vertx                    StagingRegistry  Upstream Vert.x using Java                  
 java-websphereliberty         StagingRegistry  Java application Maven-built stack using... 
 java-websphereliberty-gradle  StagingRegistry  Java application Gradle-built stack usin... 
 java-wildfly                  StagingRegistry  Upstream WildFly                            
 java-wildfly-bootable-jar     StagingRegistry  Java stack with WildFly in bootable Jar ... 
 nodejs                        StagingRegistry  Stack with Node.js 16                       
 nodejs-angular                StagingRegistry  Angular is a development platform, built... 
 nodejs-nextjs                 StagingRegistry  Next.js gives you the best developer exp... 
 nodejs-nuxtjs                 StagingRegistry  Nuxt is the backbone of your Vue.js proj... 
 nodejs-react                  StagingRegistry  React is a free and open-source front-en... 
 nodejs-svelte                 StagingRegistry  Svelte is a radical new approach to buil... 
 nodejs-vue                    StagingRegistry  Vue is a JavaScript framework for buildi... 
 php-laravel                   StagingRegistry  Laravel is an open-source PHP framework,... 
 python                        StagingRegistry  Flask is a web framework, itโ€™s a Pytho...   
 python-django                 StagingRegistry  Django is a high-level Python web framew...

How is it different from odo registry command of v2?

odo registry of v2 was useful in creating/deleting/updating/listing the Devfile registries, however in v3, this command can now be used to list the Devfiles.

note

In odo v3, you can use odo preference <add/remove> registry to create/delete/update the Devfile registries, and odo preference view to list them.

Additionally, it also provides,

Filtering the Devfilesโ€‹

odo registry can filter the list of Devfiles based on a keyword (--filter), a Devfile registry (--devfile-registry), or the Devfile name (--devfile).

Detailed information about the Devfilesโ€‹

odo registry can provide a detailed information about all the Devfiles by running it with --details flag.

odo listโ€‹

odo list lists all the resources created by odo including components, and bindings.

$ odo list
 โœ“  Listing resources from the namespace "my-percona-server-mongodb-operator" [302ms]
 NAME              PROJECT TYPE  RUNNING IN  MANAGED
 my-node-app         nodejs        Deploy      odo (v3.0.0)
 my-go-app         go            Dev         odo (v3.0.0-rc1)
 mongodb-instance  Unknown       None        percona-server-mongodb-operator 

Bindings:
 NAME                        APPLICATION                 SERVICES                                                   RUNNING IN 
 my-go-app-mongodb-instance  my-go-app-app (Deployment)  mongodb-instance (PerconaServerMongoDB.psmdb.percona.com)  Dev

How is it different from odo list of v2?

Better informationโ€‹

odo list gives a better experience by providing information about your application such as: the mode it is running in, the tool (versioned) managing it, and the project type.

It further provides subcommands such as odo list components, and odo list bindings to list respective resources.

Ability to list Bindingsโ€‹

odo list provides a way to list the bindings created on the cluster by odo.

Migrating from v2 to v3โ€‹

The changes from v2 to v3 have been huge, but that does not have to mean big changes for you. We have documented the migration process to ease things for you.

The migration doc also documents the commands that have been added, modified or removed from v3.

Installation Guideโ€‹

To install odo v3.0.0, refer to our installation guide.

Full Changelogโ€‹

You can find the full changelog from v2.5.1 to v3.0.0 in our GitHub release page.

Contributing to odoโ€‹

If odo interests you and you would like to contribute to it, we whole heartedly welcome you!

You can contribute to odo in a lot of different ways!

Take it for a spin ๐Ÿš˜ and report back bugs๐Ÿž that you encountered, or features๐ŸŒŸ that you would like to see.

Help us with the documentation๐Ÿ“œ, or tell us how you used odo ๐Ÿ–.

Review the PRs๐Ÿ‘€, or help us fix a failing test ๐Ÿšฉ.

Work on the TODOs๐Ÿ“, or help us cleanup the code๐Ÿšฎ.

Or, simply tune in๐Ÿ“ป to our contributor calls and learn more about odo.

odo is your playground!

Read the developer reference guide on contributing to odo to know more.

]]> Parthvi Vala https://github.com/valaparthvi <![CDATA[odo v3.0.0-rc2 Released]]> https://odo.dev/blog/odo-v3-rc2-release 2022-09-22T00:00:00.000Z 3.0.0-rc2 of odo has been released!

To install odo, follow our installation guide at odo.dev

Note about Release Candidateโ€‹

With rc2, we are feature complete. Our GA release will include:

  • Onboarding updates, including updates to the Quickstart guide
  • Video tutorial

Notable Changesโ€‹

Check this YouTube playlist for an overview of the most notable changes in this release.

Featuresโ€‹

odo dev manually sync files upon pressing "p" (#6089)โ€‹

odo dev can now sync files when user presses the key "p".

odo list services lists bindable servicesโ€‹

odo version shows the cluster informationโ€‹

Detailed changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page.

Features/Enhancements:

  • Adds support for odo list services #6118 (dharmit)
  • Add runtime label based on metadata:language/projectType #6112 (feloy)
  • JSON output for preference view #6105 (feloy)
  • Manual sync of files pressing p #6089 (feloy)

Bugs:

  • Try to reload config when disconnected from the cluster #6130 (feloy)
  • Port-forward all endpoints regardless of exposure #6119 (rm3l)
  • Fix broken links to installation guide #6117 (valaparthvi)
  • Do not display message when using no-watch flag #6116 (feloy)
  • Show Kubernetes cluster version in odo version #6109 (valaparthvi)
  • No error/help display for JSON output #6106 (feloy)
  • Display "Interactive mode enabled" only when running odo init interactively #6100 (rm3l)
  • Use map for runningIn instead of array in JSON output #6094 (feloy)
  • [flaky test] Move DetectName to method in alizer package #6093 (feloy)
  • Fix interactive tests on Windows #6091 (feloy)
  • (odo init): Add input validation for component name #6088 (valaparthvi)
  • Fix: (odo list) Empty parenthesis for odo version if component is not on the cluster #6078 (valaparthvi)

Documentation:

  • Fix typo in README #6133 (rm3l)
  • Fix broken links to devfile.io #6128 (rm3l)
  • docs: move deploying to advanced usage #6124 (kadel)
  • upgrade to docusaurus 2.1 and fix version mismatch #6123 (kadel)
  • Adds tabs for podman/docker docs and OS differences #6115 (cdrage)
  • Update README.md with logo & updated text #6104 (cdrage)
  • Fix default value for Ephemeral in documentation #6102 (rm3l)
  • Guide for migrating from v2 to v3 #6095 (dharmit)
  • Reorganizes installation document #6086 (cdrage)
  • Remove cluster setup #6081 (cdrage)
  • Blog post for v3.0.0-rc1 release #6074 (feloy)
  • Reorganize and separate language / framework tutorials. #6071 (cdrage)

Testing/CI:

Merged pull requests:

]]> Dharmit Shah https://github.com/dharmit <![CDATA[odo v3.0.0-rc1 Released]]> https://odo.dev/blog/odo-v3-rc1-release 2022-09-01T00:00:00.000Z 3.0.0-rc1 of odo has been released!

To install odo, follow our installation guide at odo.dev

Note about Release Candidateโ€‹

With rc1, we are feature complete with the following exceptions:

  • odo list services (#5996)
  • ability to turn off auto restart and trigger sync manually in odo dev (#5634)

Our GA release will include:

  • Onboarding updates, including updates to the Quickstart guide
  • Video tutorial

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://www.youtube.com/watch?v=OM8WjhGhdmw&list=PLGMB2PY4SNOpvdCgJjgp-91Z3wh9eyatV

Featuresโ€‹

odo dev and odo deploy now always work on current Kubernetes namespace (#6025)โ€‹

odo dev and odo deploy are now always working on the current Kubernetes namespace, and are no longer saving the namespace on which they are working in a local file.

odo list: show the component manager version (#6028)โ€‹

odo list now outputs the version of the manager used to deploy a component, as described in the app.kubernetes.io/managed-by-version label of the component's deployment.

odo list displaying components and bindings (#6043)โ€‹

odo list combines the output of odo list component and odo list binding, for human-readable and JSON output.

odo no longer requires the optional 'metadata.name' field in Devfile (#6015)โ€‹

If the metadata.name field is present in the Devfile, it is used as name of the deployed component. If not present, odo tries to detect the name automatically based on the project configuration. If this is not possible, the directory name is used instead.

odo using alizer name detection with odo init (#5989)โ€‹

odo init detects the project name via pom.xml (java), package.json (node.js), etc using alizer. If the detection fails, defaults to using the directory name.

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page

Features/Enhancements:

  • Implement "odo list" #6043 (feloy)
  • odo list: add odo version used to create a component to the output #6028 (valaparthvi)
  • Do not get project from env.yaml file #6025 (feloy)
  • Make odo work if optional metadata.name field is missing in Devfile #6015 (rm3l)
  • Autodetect project name via Alizer #5989 (cdrage)
  • odo dev: Add support for non-exec commands part of a composite run or debug command #5923 (valaparthvi)

Bugs:

Documentation:

Testing/CI:

Merged pull requests:

  • Bump to version 3.0.0-rc1 #6064 (feloy)
  • Update script to support alpha/beta/rc versions #6063 (feloy)
  • update to OpenShift 4.11 #6060 (kadel)
  • Troubleshoot IBM Cloud Windows tests failing #6038 (feloy)
  • test: use T.Setenv to set env vars in tests #6037 (Juneezee)
  • Revert "Add blog post for v3.0.0-beta3 and update installation docs" #6030 (cdrage)
]]> Philippe Martin https://github.com/feloy <![CDATA[odo v3.0.0-beta3 Released]]> https://odo.dev/blog/odo-v3-beta3-release 2022-08-18T00:00:00.000Z 3.0.0-beta3 of odo has been released!

To install odo, follow our installation guide at odo.dev

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://www.youtube.com/watch?v=oLBDQZYkPUU&list=PLGMB2PY4SNOoDKAk8qQ8nhva3ff1fgZgr

Featuresโ€‹

odo dev: react to changes as soon as possible (#5933)โ€‹

odo dev can now detect changes as soon as they occur. It works in a controller like mechanism, where it keeps a watch on certain resources, events and files, and constantly notifies user about the state of their application.

Allow binding to services from other namespaces (#5936)โ€‹

odo now allows binding to services from all the namespaces so that users can share services that are shared between multiple applications or developers.

Allow using remote Dockerfiles (HTTP(S) only) for building images (#5976)โ€‹

User can now use remote Dockerfiles to build container images for their outer loop development cycle.

Performance improvements to odo logs (#5942, #5973, #5961)โ€‹

We have attempted at improving the performance of odo logs this release with a delta of approximately 1s.

odo.devโ€‹

  • add documentation for env variables used by odo (#5686)

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page

Features/Enhancements:

  • Allow using remote Dockerfiles (HTTP(S) only) for building images #5976 (rm3l)
  • Allow binding to services from other namespaces #5936 (rm3l)
  • odo dev: react to changes as soon as possible #5933 (feloy)

Bugs:

Documentation:

  • Use oceanicNext dark theme for website #6005 (valaparthvi)
  • Adds link to inner loop to the Quickstart guide #6003 (dharmit)
  • update quickstart #5992 (kadel)
  • Remove $ symbol from some commands #5979 (cdrage)
  • Add blog post for v3.0.0-beta2 release and update installation doc #5966 (rm3l)
  • Add blog post for v3.0.0-beta1 release #5956 (rm3l)
  • add documentation for env variables used by odo #5686 (kadel)

Testing/CI:

Merged pull requests:

]]> Parthvi Vala https://github.com/valaparthvi <![CDATA[odo v3.0.0-beta2 Released]]> https://odo.dev/blog/odo-v3-beta2-release 2022-07-21T00:00:00.000Z 3.0.0-beta2 of odo has been released!

To install odo, follow our installation guide at odo.dev

Notable Changesโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://www.youtube.com/playlist?list=PLGMB2PY4SNOoxZNN5Ye1mHC4kndPx3p6h

Featuresโ€‹

odo completion support (#5856, #5921)โ€‹

Executing alternative 'build' and 'run' commands with 'odo dev' (#5878, #5891)โ€‹

Setting naming strategy when running 'odo add binding' (#5912)โ€‹

odo dev: handle port forwarding after pod restart (#5885)โ€‹

odo dev is now able to automatically handle port forwarding (and regenerate them if needed) after a pod restarts, e.g., following a change in the Devfile that modifies the container component configuration while the dev session is running.

Bug fixesโ€‹

  • Error for odo add binding is misleading when no supported operator is installed (#5887)

odo.devโ€‹

  • Blog post on how to connect to a service without using the Service Binding Operator (link)

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page

Features/Enhancements:

  • Allow setting namingStrategy when using odo add binding #5912 (rm3l)
  • odo dev: handle port forwarding after pod restart #5885 (feloy)

Documentation:

Testing/CI:

Merged pull requests:

]]> Armel Soro https://github.com/rm3l <![CDATA[odo v3.0.0-beta1 Released]]> https://odo.dev/blog/odo-v3-beta1-release 2022-07-01T00:00:00.000Z 3.0.0-beta1 of odo has been released!

Notable Changesโ€‹

Featuresโ€‹

Check this Playlist for an overview of the most notable changes in this release: https://www.youtube.com/watch?v=yTUk_rx3aP8&list=PLGMB2PY4SNOrBQabcLZ_M5rN8l5u0B_cw

Ability to show (and stream) logs of running component, with odo logs and odo logs โ€“follow (#5622, #5715)โ€‹

Substituting variables into the Devfile from the CLI when running odo dev or odo deploy (#5489)โ€‹

Support for composite run and debug Devfile commands when running odo dev (#5054)โ€‹

Ability to list existing Service Bindings and interactively generate Service Binding from a directory with no Devfile (#5635, #5772)โ€‹

โ€œBind as filesโ€ UI update when running odo add binding (#5770)โ€‹

Ability to unbind ServiceBindings from the Devfile, with odo remove binding (#5693)โ€‹

Bug fixesโ€‹

  • Better support for command and args fields in Devfile container components: odo no longer overrides the container command with Supervisord (#5648)
  • Devfile Volume components shown when personalizing Devfile configuration via odo init (#5779)

odo.devโ€‹

  • Main site switched to 3.0.0 documentation
  • Blog post about binding an external service with odo v3 (link)
  • Homebrew installation details (#5801)

Detailed Changelogโ€‹

As with every release, you can find the full list of changes and bug fixes on the GitHub release page

Features/Enhancementsโ€‹

Bugsโ€‹

Documentationโ€‹

Testing/CIโ€‹

Other merged pull requestsโ€‹

]]> Armel Soro https://github.com/rm3l <![CDATA[Binding to a database service without the Service Binding Operator]]> https://odo.dev/blog/binding-database-service-without-sbo 2022-06-30T00:00:00.000Z How to bind your application to a database service without the Service Binding Operator.

There are a few ways of binding your application to a database service with the help of odo. The recommended way is with the help of Service Binding Operator(SBO), but it is also possible to bind without it, and this blog will show you how.

Architectureโ€‹

We have a simple CRUD application built in Go that can create/list/update/delete a place. This application requires connecting to a MongoDB database in order to function correctly, which will be deployed as a microservice on the cluster.

Prerequisites:โ€‹

This blog assumes:

(Optional) Setting up the namespaceโ€‹

  1. We will create a new namespace to deploy our application in, with the help of odo.
odo create namespace restapi-mongodb

Setting up the MongoDB microserviceโ€‹

We are going to use the Bitnami's helm charts for creating our MongoDB database.

  1. Add the Bitnami's Helm charts repository and make your Helm client up to date with it:
helm repo add bitnami https://charts.bitnami.com/bitnami && helm repo update
  1. Declare the necessary environment variables:
MY_MONGODB_ROOT_USERNAME=root
MY_MONGODB_ROOT_PASSWORD=my-super-secret-root-password
MY_MONGODB_USERNAME=my-app-username
MY_MONGODB_PASSWORD=my-app-super-secret-password
MY_MONGODB_DATABASE=my-app

Make sure MY_MONGODB_ROOT_USERNAME, and MY_MONGODB_ROOT_PASSWORD are declared/exported in any new terminal session from where you might run an odo command for this application.

  1. Create the MongoDB service.
helm install mongodb bitnami/mongodb \
  --set auth.rootPassword=$MY_MONGODB_ROOT_PASSWORD \
  --set auth.username=$MY_MONGODB_USERNAME \
  --set auth.password=$MY_MONGODB_PASSWORD \
  --set auth.database=$MY_MONGODB_DATABASE
Expected output:
$ helm install mongodb bitnami/mongodb \
  --set auth.rootPassword=$MY_MONGODB_ROOT_PASSWORD \
  --set auth.username=$MY_MONGODB_USERNAME \
  --set auth.password=$MY_MONGODB_PASSWORD \
  --set auth.database=$MY_MONGODB_DATABASE
NAME: mongodb
LAST DEPLOYED: Tue Jul  5 15:53:40 2022
NAMESPACE: restapi-mongodb
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: mongodb
CHART VERSION: 12.1.24
APP VERSION: 5.0.9

** Please be patient while the chart is being deployed **

MongoDB&reg; can be accessed on the following DNS name(s) and ports from within your cluster:

    mongodb.restapi-mongodb.svc.cluster.local

To get the root password run:

    export MONGODB_ROOT_PASSWORD=$(kubectl get secret --namespace restapi-mongodb mongodb -o jsonpath="{.data.mongodb-root-password}" | base64 -d)

To get the password for "my-app-username" run:

    export MONGODB_PASSWORD=$(kubectl get secret --namespace restapi-mongodb mongodb -o jsonpath="{.data.mongodb-passwords}" | base64 -d | awk -F'
,' '{print $1}')

To connect to your database, create a MongoDB&reg; client container:

    kubectl run --namespace restapi-mongodb mongodb-client --rm --tty -i --restart='Never' --env="MONGODB_ROOT_PASSWORD=$MONGODB_ROOT_PASSWORD" --
image docker.io/bitnami/mongodb:5.0.9-debian-11-r1 --command -- bash

Then, run the following command:
    mongosh admin --host "mongodb" --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD

To connect to your database from outside the cluster execute the following commands:

    kubectl port-forward --namespace restapi-mongodb svc/mongodb 27017:27017 &
    mongosh --host 127.0.0.1 --authenticationDatabase admin -p $MONGODB_ROOT_PASSWORD

Notice the resources(sevice, deployment, and secrets) that are deployed.

Wait for the pods to come up, this might take a few minutes:

$ kubectl get pods
NAME                       READY   STATUS    RESTARTS   AGE
mongodb-85fff797f6-fnwvl   1/1     Running   0          63s

Setting up the applicationโ€‹

  1. Clone the repository, and cd into it.
git clone https://github.com/valaparthvi/restapi-mongodb-odo.git && cd restapi-mongodb-odo

Download the devfile.yamlโ€‹

  1. Run odo init to fetch the necessary devfile.
odo init --devfile go --name places
Expected output:
  __
 /  \__     Initializing new component
 \__/  \    Files: Source code detected, a Devfile will be determined based upon source code autodetection
 /  \__/    odo version: v3.0.0-beta1
 \__/

Interactive mode enabled, please answer the following questions:
 โœ“  Downloading devfile "go" [4s]

Your new component 'places' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.
If you run odo dev to deploy the application at this point, you will notice that the 'run' command has failed with some logs, this is expected, because like we mentioned before, our Go application is dependent on the MongoDB service and will not function unless it is connected to it.
$ odo dev
  __
 /  \__     Developing using the restapi Devfile
 \__/  \    Namespace: restapi-mongodb
 /  \__/    odo version: v3.0.0-alpha3
 \__/

โ†ช Deploying to the cluster in developer mode
 โœ“  Waiting for Kubernetes resources [52s]
 โœ“  Syncing files into the container [844ms]
 โœ“  Building your application in container on cluster (command: build) [5s]
 โ€ข  Executing the application (command: run)  ...
 โœ—  Executing the application (command: run) [188ms]
 โš   Devfile command "run" exited with an error status in 20 second(s)
 โš   Last 100 lines of log:
go: downloading github.com/sirupsen/logrus v1.8.1
...
...
2022/07/06 10:52:10 No binding username found
 - Forwarding from 127.0.0.1:40001 -> 8080

Your application is now running on the cluster

Watching for changes in the current directory /home/pvala/restapi-mongodb-odo
Press Ctrl+c to exit `odo dev` and delete resources from the cluster

Adding the connection information to devfile.yamlโ€‹

There are a few changes that we will need to make to our devfile:

6.1 Change the schemaVersion of devfile to 2.2.0.

schemaVersion: 2.2.0

Please note that this change is only necessary because we are using devfile variable substitution.

6.2 Add a variables field in the devfile.

variables:
  PASSWORD: password
  USERNAME: user
  HOST: host

6.3 Edit the 'runtime' container component in devfile to add information such as username, password, and host required to connect to the MongoDB service.

components:
- container:
    ...
    ...
    env:
    - name: username
      value: "{{USERNAME}}"
    - name: password
      value: "{{PASSWORD}}"
    - name: host
      value: "{{HOST}}"
  name: runtime

The values for username, password, and host will be passed to devfile.yaml with the --var flag when we run the odo dev command.

Your final devfile.yaml should look something like this:
commands:
- exec:
    commandLine: GOCACHE=${PROJECT_SOURCE}/.cache go build main.go
    component: runtime
    group:
      isDefault: true
      kind: build
    hotReloadCapable: false
    workingDir: ${PROJECT_SOURCE}
  id: build
- exec:
    commandLine: ./main
    component: runtime
    group:
      isDefault: true
      kind: run
    hotReloadCapable: false
    workingDir: ${PROJECT_SOURCE}
  id: run
components:
- container:
    dedicatedPod: false
    endpoints:
    - name: http
      targetPort: 8080
    image: golang:latest
    memoryLimit: 1024Mi
    mountSources: true
    env:
    - name: username
      value: "{{USERNAME}}"
    - name: password
      value: "{{PASSWORD}}"
    - name: host
      value: "{{HOST}}"
  name: runtime
variables:
  PASSWORD: password
  USERNAME: user
  HOST: host
metadata:
  description: Stack with the latest Go version
  displayName: Go Runtime
  icon: https://raw.githubusercontent.com/devfile-samples/devfile-stack-icons/main/golang.svg
  language: go
  name: restapi
  projectType: go
  tags:
  - Go
  version: 1.0.0
schemaVersion: 2.2.0
starterProjects:
- git:
    checkoutFrom:
      revision: main
    remotes:
      origin: https://github.com/devfile-samples/devfile-stack-go.git
  name: go-starter

Deploy the applicationโ€‹

  1. Run odo dev to deploy the application on the cluster.
odo dev \
  --var PASSWORD=$MY_MONGODB_ROOT_PASSWORD \
  --var USERNAME=$MY_MONGODB_ROOT_USERNAME \
  --var HOST="mongodb"

The value for host is name of the service that belongs to our database application, in this case it is a service resource called "mongodb", you might have noticed it when we deployed the helm chart.

Expected output:
$ odo dev --var PASSWORD=$MY_MONGODB_ROOT_PASSWORD --var USERNAME=$MY_MONGODB_ROOT_USERNAME --var HOST="mongodb"
  __
 /  \__     Developing using the restapi Devfile
 \__/  \    Namespace: restapi-mongodb
 /  \__/    odo version: v3.0.0-alpha3
 \__/

โ†ช Deploying to the cluster in developer mode
 โœ“  Waiting for Kubernetes resources [52s]
 โœ“  Syncing files into the container [844ms]
 โœ“  Building your application in container on cluster (command: build) [5s]
 โ€ข  Executing the application (command: run)  ...

Your application is now running on the cluster

 - Forwarding from 127.0.0.1:40001 -> 8080

Watching for changes in the current directory /home/pvala/restapi-mongodb-odo
Press Ctrl+c to exit `odo dev` and delete resources from the cluster

Accessing the applicationโ€‹

  1. Run the following curl command to test the application:
curl 127.0.0.1:40001/api/places

This will return a null response since the database is currently empty, but it also means that we have successfully connected to our database application.

  1. Add some data to the database:
curl -sSL -XPOST -d '{"title": "Agra", "description": "Land of Tajmahal"}' 127.0.0.1:40001/api/places
  1. Fetch the list of places again:
$ curl 127.0.0.1:40001/api/places

{"id":"62c2a0659fa147e382a4db31","title":"Agra","description":"Land of Tajmahal"}

List of available API endpointsโ€‹

  • GET /api/places - List all places
  • POST /api/places - Add a new place
  • PUT /api/places - Update a place
  • GET /api/places/<id> - Fetch place with id <id>
  • DELETE /api/places/<id> - Delete place with id <id>

Conclusionโ€‹

To conclude this blog, it is possible to connect your application with another microservice without the Service Binding Operator if you have the correct connection information. Using the Service Binding Operator with a Bindable Operator makes it easy for you to not care about finding the connection information and ease the binding.

]]> Parthvi Vala https://github.com/valaparthvi <![CDATA[Binding an external service with odo v3]]> https://odo.dev/blog/binding-external-service-with-odo-v3 2022-06-14T00:00:00.000Z How to bind an external service using odo v3

When developers are working on a micro-service that needs to access a database or another service, they may want to provide to their application the address and the necessary credentials to access this service as simply as possible.

In this article, we are going to talk about binding the service to the application.

Using the Service Binding Operator and creating some Kubernetes resources for each service you want to bind to, you can make the life easier for developers.

Creating a Service resource to redirect to the external serviceโ€‹

To expose an external service from inside a Kubernetes cluster, you can create a Headless Service, and manually create the Endpoints to access this external service.

Here is an example, to connect to an external Redis service on IP 192.168.1.10 and port 6379:

kind: Service
apiVersion: v1
metadata:
  name: redis
  namespace: external-services
spec:
  type: ClusterIP
  ports:
  - port: 6379
    targetPort: 6379

---

kind: Endpoints
apiVersion: v1
metadata:
  name: redis
  namespace: external-services
subsets:
- addresses:
  - ip: 192.168.1.10
  ports:
  - port: 6379

Note that we have created these resources in a external-services namespace, which is a dedicated namespace to store external services information, accessible by all developers.

You can find more information about creating Service resources to access external services here or here.

Storing the credentials into a Secret resourceโ€‹

The Redis instance is protected by a password, and you may want to store this password into a Secret resource, so it can be used by applications.

The developers may want to mount this Secret into their application's Pod, but Secrets are mountable only from Pods in the same namespace, and you would like to share these credentials with all the developers of the team, without creating several instances of this Secret (one in each developer's namespace), but only one in the external-services namespace.

Here is, as an example, the secret to store the Redis password.

kind: Secret
apiVersion: v1
metadata:
  name: redis-credentials
  namespace: external-services
stringData:
  password: MyEasyPassword

Adding SBO Annotations to the Service resourceโ€‹

To be able to mount the values of this secret from any namespace, you can use the Service Binding Operator (SBO for short), so each developer can define a ServiceBinding resource between the service and its application, and get the values of the secret (and other values) mounted into its application's Pod.

You can find information about the Service Binding Operator here.

A ServiceBinding defines a binding between an Application and a Service. The credentials injected into the application can be defined in different ways:

  • if the service is an Operator-backed service running on the cluster, the details of the injected credentials can be set as annotations of the CRD associated with the Operator-backed service,
  • in any case, the details of the injected credentials can be set in the resource itself (not the CRD).
  • in any case, the details of the injected credentials can be set in the ServiceBinding resource itself.

In this article, we are not using an Operator-backed service, but an external service referenced by a Service resource. As the Service resource is a native Kubernetes resource, we cannot add annotations to its CRD, so we will add annotations to the Service resource itself.

You can modify the definition of the Service, by adding the following annotations:

kind: Service
apiVersion: v1
metadata:
  name: redis
  annotations:
    service.binding/host: path={.metadata.name}.{.metadata.namespace}.svc.cluster.local
    service.binding: path={.metadata.name}-credentials,objectType=Secret
spec:
  type: ClusterIP
  ports:
  - port: 6379
    targetPort: 6379

In this snippet, the first annotation

service.binding/host: path={.metadata.name}.{.metadata.namespace}.svc.cluster.local

indicates to the SBO to inject a host variable into the application, with a value computed based on the metadata.name and metadata.namespace of the Service resource. In this example, the value redis.external-services.svc.cluster.local will be given to the host variable.

The second annotation

service.binding: path={.metadata.name}-credentials,objectType=Secret

indicates to the SBO to inject the values defined in the Secret, whose name is the name of the Service resource followed by -credentials (redis-credentials in our example), into the application. In this example, the variable password with a value MyEasyPassword will be injected into the application's Pod.

Adding a ServiceBinding to the Devfileโ€‹

To define a ServiceBinding, we need information (group, version, kind, name, and namespace) about the Application and the Service.

In our example, the service is a Kubernetes Service (group "", version "v1" and kind "Service") named redis in the external-services namespace.

The application will be the Deployment resource (group "apps", version "v1", kind "Deployment") created by odo when you run odo dev. By convention, the Deployment name will be the name of the Devfile (in the .metadata.name field) followed by -app (my-nodejs-app-app in our example). You don't have to specify the namespace, as the Deployment will be in the same namespace as the ServiceBinding.

The option bindAsFiles indicates to the SBO to create files into the Pod's container, each file having the name of a credential, and containing the value of the credential.

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  name: binding-to-redis
spec:
  application:
    group: apps
    version: v1
    kind: Deployment
    name: my-nodejs-app-app
  services:
  - group: ""
    version: v1
    kind: Service
    name: redis
    namespace: external-services
  bindAsFiles: true

You can create a file kubernetes/redis.yaml in your directory containing this snippet, and add a Kubernetes component into your Devfile referring to this YAML file:

metadata:
  name: my-nodejs-app
[...]
components:
[...]
- name: binding-to-redis
  kubernetes:
    uri: kubernetes/redis.yaml

By adding this Kubernetes component to your Devfile, when you run odo dev, the ServiceBinding resource defined in the kubernetes/redis.yaml file will be created into the cluster, and the Service Binding Operator will inject into the application's Pod the host and password necessary to connect to the Redis external service.

Using the variables into the application's codeโ€‹

The Devfile is now ready, and the developer can start accessing the external service from the code.

The first step to know how the credentials are exposed into the application's container is to start the odo dev command and to execute the odo describe binding command.

Running odo dev, you can see that the ServiceBinding resource is deployed to the cluster.

$ odo dev
[...]
โ†ช Deploying to the cluster in developer mode
 โœ“  Creating kind ServiceBinding [60ms]
 โœ“  Waiting for Kubernetes resources [10s]
 โœ“  Syncing files into the container [740ms]
 โœ“  Building your application in container on cluster [4s]
 โœ“  Executing the application [1s]
[...]

From another terminal, running odo describe binding will show you the status of the ServiceBinding:

$ odo describe binding
ServiceBinding used by the current component:

Service Binding Name: binding-to-redis
Services:
 โ€ข  redis (Service.)
Bind as files: true
Detect binding resources: false
Available binding information:
 โ€ข  ${SERVICE_BINDING_ROOT}/binding-to-redis/host
 โ€ข  ${SERVICE_BINDING_ROOT}/binding-to-redis/password

This output shows that two files host and password are present in the application's container, at the mentioned paths.

You can leverage a servicebinding library to help you access these files. A complete list of libraries is available on the page Service Bindings for Application Developers.

Troubleshootingโ€‹

If the output of odo describe binding shows an unknown status:

Available binding information: unknown
  • first check if odo dev is still running. odo is not able to know the bound credentials if the ServiceBinding resource is not deployed by odo dev.
  • if odo dev is running, you can check that the ServiceBinding resource is deployed to the cluster, and if its status is ApplicationsBound, with the command:
    kubectl get servicebindings.binding.operators.coreos.com
  • if the status of the ServiceBinding resource displayed in the list is not ApplicationsBound, you can get an error message with the command:
    kubectl describe servicebindings.binding.operators.coreos.com <service-binding-name>
]]> Philippe Martin https://github.com/feloy <![CDATA[odo v3-alpha1 Released]]> https://odo.dev/blog/odo-v3-alpha1-release 2022-05-02T00:00:00.000Z v3-alpha1 of odo has been released!

odo is a tool that aims to simplify the life of developers working on cloud-native applications.

Thanks to the emergence of the Devfile open standard, which has been accepted as a CNCF Sandbox project (January 2022), odo v3 is now entirely based on this open standard.

The goal of the Devfile standard is to define the structure of applications and how developers can work on them.

A single Devfile defines the smallest building block of an application, that a developer can: build, run, test, debug and deploy. In a cloud-native environment, we generally talk about a micro-service.

Firstly, the Devfile describes the container that is needed to be deployed on a cluster during the development phases, along with the commands to execute on this container to build, run, test and debug the program, assuming the sources have been synchronized into the container.

Secondly, the Devfile provides the instructions to build the container image ready for production, along with the Kubernetes resources to deploy to the cluster.

An example of a Devfileโ€‹

To illustrate, here is a simple yet complete Devfile, usable for a Node.js micro-service:

schemaVersion: 2.2.0
metadata:
  description: Stack with NodeJS 12
  displayName: NodeJS Runtime
  language: nodejs
  name: my-nodejs-app
  projectType: nodejs
variables:
  CONTAINER_IMAGE: quay.io/phmartin/myimage
components:
- name: runtime
  container:
    endpoints:
    - name: http-3000
      targetPort: 3000
    - name: debug-5858
      targetPort: 5858
    image: registry.access.redhat.com/ubi8/nodejs-14:latest
    memoryLimit: 1024Mi
    mountSources: true
    sourceMapping: /project
- name: outerloop-build
  image:
    dockerfile:
      buildContext: ${PROJECT_ROOT}
      rootRequired: false
      uri: ./Dockerfile
    imageName: "{{CONTAINER_IMAGE}}"
- name: outerloop-deployment
  kubernetes:
    inlined: |
      kind: Deployment
      apiVersion: apps/v1
      metadata:
        name: my-node
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: node-app
        template:
          metadata:
            labels:
              app: node-app
          spec:
            containers:
              - name: my-node
                image: {{CONTAINER_IMAGE}}
                ports:
                  - name: http
                    containerPort: 3001
                    protocol: TCP
                resources:
                  limits:
                    memory: "1024Mi"
                    cpu: "500m"
- name: outerloop-service
  kubernetes:
    inlined: |
      apiVersion: v1
      kind: Service
      metadata:
        name: svc
      spec:
        ports:
        - name: "3000"
          port: 3000
          protocol: TCP
          targetPort: 3000
        selector:
          app: node-app
        type: ClusterIP
commands:
- id: install
  exec:
    commandLine: npm install
    component: runtime
    group:
      isDefault: true
      kind: build
    workingDir: /project
- id: run
  exec:
    commandLine: npm start
    component: runtime
    group:
      isDefault: true
      kind: run
    workingDir: /project
- id: debug
  exec:
    commandLine: npm run debug
    component: runtime
    group:
      isDefault: true
      kind: debug
    workingDir: /project
- id: test
  exec:
    commandLine: npm test
    component: runtime
    group:
      isDefault: true
      kind: test
    workingDir: /project
- id: deploy
  composite:
    commands:
    - build-image
    - k8s-deployment
    - k8s-service
    group:
      isDefault: true
      kind: deploy
- id: build-image
  apply:
    component: outerloop-build
- id: k8s-deployment
  apply:
    component: outerloop-deployment
- id: k8s-service
  apply:
    component: outerloop-service
starterProjects:
- name: nodejs-starter
  git:
    remotes:
      origin: https://github.com/odo-devfiles/nodejs-ex.git

The runtime component defines the container that will be deployed to support the program in development. Specifically, it will use the image registry.access.redhat.com/ubi8/nodejs-14:latest, and sources should be placed in the /project directory of the container. Two endpoints are also defined, one to access the micro-service, the other to help the debugger attach to the process, during debugging sessions.

The commands install, run, debug and test indicate which commands to execute to respectively build, execute, debug and test the application. For example, the npm install command will be executed in the container to build the application, then npm start will be executed to start the application.

To deploy the micro-service, the component outerloop-build indicates how to build the production image (by using ./Dockerfile, and creating an image whose name is defined by the variable CONTAINER_IMAGE defined at the beginning of the devfile). Then, two other components outerloop-deployment and outerloop-service define the Kubernetes resources to deploy to the cluster. Note that the first one defines a Deployment that will help deploy a container using the image built with the previous outerloop-build component. And, the second outerloop-service component will help expose the deployment created by outerloop-deployment component.

The starterProjects section at the end of the Devfile indicates a list of starter projects, that can be downloaded to have an example of program deployable with this Devfile.

Devfile registryโ€‹

We can see through the previous example that a Devfile is generic enough, with only a few specific values, like the endpoints and the image names. A Devfile written for a specific language and framework can be used by most of the programs written using this language and framework, with minimum personalization.

A Devfile registry is available at https://registry.devfile.io, containing Devfiles for a large variety of languages and frameworks, and you can deploy your own registry to make accessible your own Devfiles.

Introducing odo v3โ€‹

You can find the instructions to install odo v3-alpha1 from this release page. The binaries are accessible here.

Initializing a projectโ€‹

The odo init command is the first command to use, before starting to use odo with your project. The goal of this first step is to get a suitable Devfile for your project.

odo init will search for Devfiles in the Devfile registries. By default, odo is configured to access only one Devfile registry (the one specified above), and you can modify the Devfile registries odo is accessing using the command odo preference registry.

This odo init command offers two modes, either interactive, or manual. The interactive mode will help you discover the appropriate Devfile. To use the interactive mode, you just need to enter odo init in your command line.

If you execute this command from a directory containing sources, odo will try to recognize the language and framework you are using, will search into the Devfile registries that you have configured for the most appropriate Devfile, and give you the choice to use it, or to search for another one. 

$ odo init
  __
 /  \__     Initializing new component
 \__/  \    Files: Source code detected, a Devfile will be determined based upon source code autodetection
 /  \__/    odo version: v3.0.0-alpha1
 \__/

Interactive mode enabled, please answer the following questions:
Based on the files in the current directory odo detected
Language: javascript
Project type: nodejs
The devfile "nodejs" from the registry "DefaultDevfileRegistry" will be downloaded.
? Is this correct? (Y/n)

If you answer No here, or if you run the odo init command from an empty directory, odo init will help you choose the appropriate Devfile. The command will also help you make some personalization on the Devfile, by personalizing the endpoints and the environment variables for the container that will be deployed during the development phase.

? Select language: javascript
? Select project type: Node.js Runtime
 โœ“  Downloading devfile "nodejs" from registry "DefaultDevfileRegistry" [961ms]
Current component configuration:
Container "runtime":
  Opened ports:
   - 3000
  Environment variables:
? Select container for which you want to change configuration? NONE - configuration is correct
? Enter component name: my-nodejs-app

Your new component 'my-nodejs-app' is ready in the current directory.
To start editing your component, use 'odo dev' and open this folder in your favorite IDE.
Changes will be directly reflected on the cluster.

Finally, if you start the odo init command from an empty directory, it will give you the choice to download one of the starter projects listed in the Devfile.

The development phaseโ€‹

Now that a Devfile is present in the current directory, you can run your application in the development mode, using the odo dev command. This command will create a Deployment in the cluster that will help start a container as defined in the Devfile. Then, the sources present in the current directory will be synchronized into the container, and the commands to build and run the application will be executed from inside the container.

At the same time, a port-forwarding will be done for each endpoint defined in the Devfile, so you can access the container ports through local ports in your development machine.

Finally, odo will watch for changes in the current directory. When files are modified, added or deleted, odo will synchronize the changes to the container, and will restart the build and run commands from inside the container.

$ odo dev
  __
 /  \__     Developing using the my-nodejs-app Devfile
 \__/  \    Namespace: prj2
 /  \__/    odo version: v3.0.0-alpha1
 \__/

โ†ช Deploying to the cluster in developer mode
 โœ“  Waiting for Kubernetes resources [6s]
 โœ“  Syncing files into the container [439ms]
 โœ“  Building your application in container on cluster [3s]
 โœ“  Executing the application [1s]

Your application is now running on the cluster
 - Forwarding from 127.0.0.1:40001 -> 3000
 - Forwarding from 127.0.0.1:40002 -> 5858

Watching for changes in the current directory /home/phmartin/Documents/tests/devto-deploy
Press Ctrl+c to exit `odo dev` and delete resources from the cluster

To be able to debug the application, you will need to run the odo dev --debug command instead.

When you have finished the development session, you just need to hit Ctrl-c to stop the odo dev command. The command won't terminate immediately, as it will delete the resources it has deployed on the cluster before exiting.

The deployment phaseโ€‹

When you are satisfied with your program, you may want to deploy it. The first step would be to build the container image using a Dockerfile, instead of using a generic image as during the development phase. The second step would be to deploy personalized resources, instead of the Deployment used during the development phase.

At the time of this blog post, no Devfile within the default Devfile registry contains instructions for the deployment phase. By using the Devfile provided as an example above, the command odo deploy will build the container image using the Dockerfile present in the directory, and then deploy a personalized Deployment using the container image and a Service into the cluster.

$ odo deploy
  __
 /  \__     Deploying the application using my-nodejs-app Devfile
 \__/  \    Namespace: prj2
 /  \__/    odo version: v3.0.0-alpha1
 \__/

โ†ช Building & Pushing Container: quay.io/phmartin/myimage
 โ€ข  Building image locally  ...
STEP 1/7: FROM docker.io/library/node:17
STEP 2/7: WORKDIR /usr/src/app
[...]
STEP 7/7: CMD [ "node", "server.js" ]
COMMIT quay.io/phmartin/myimage
 โœ“  Building image locally [6s]
 โ€ข  Pushing image to container registry  ...
[...]
Writing manifest to image destination
Storing signatures
 โœ“  Pushing image to container registry [8s]

โ†ช Deploying Kubernetes Component: my-node
 โœ“  Searching resource in cluster 
 โœ“  Creating kind Deployment [50ms]

โ†ช Deploying Kubernetes Component: svc
 โœ“  Searching resource in cluster 
 โœ“  Creating kind Service [57ms]

Your Devfile has been successfully deployed

At any moment, you can check if a component has been deployed by using the odo list command.

$ odo list
 โœ“  Listing components from namespace 'prj2' [61ms]
 NAME             PROJECT TYPE  RUNNING IN  MANAGED 
 * my-nodejs-app  nodejs        Deploy      odo

When you are done with this application or if you want to undeploy it to work on development mode again, you can use the odo delete component to undeploy the component from the cluster.

$ odo delete component
Searching resources to delete, please wait...
This will delete "my-nodejs-app" from the namespace "prj2".
 โ€ข  The component contains the following resources that will get deleted:
    - Deployment: my-node
    - Service: svc
? Are you sure you want to delete "my-nodejs-app" and all its resources? Yes
The component "my-nodejs-app" is successfully deleted from namespace "prj2"

Demoโ€‹

]]> Parthvi Vala https://github.com/valaparthvi Philippe Martin https://github.com/feloy <![CDATA[odo 2.5.0 Released]]> https://odo.dev/blog/odo-250-release 2022-01-14T00:00:00.000Z 2.5.0 of odo has been released!

Notable changes in odo 2.5.0โ€‹

Support for ephemeral field in Devfile volumes definition (#5279 @feloy)โ€‹

odo now supports Devfile volumes that are defined as ephemeral. If a volume is defined with ephemeral: true odo will create it as a Kubernetes emptyDir volume.

Example of an ephemeral volume definition inside devfile.yaml

- name: volume-test
  volume:
    size: 1Gi
    ephemeral: true

Delete outer loop resources with odo delete --deploy(PR#5276 @valaparthvi)โ€‹

You can now delete resources that were deployed using odo deploy via the odo delete --deploy command. odo delete --all now deletes everything from the cluster related to the given Devfile including outer loop resources.

Delete commandDeletes resources from clusterDeletes local devfile.yaml
odo deleteYES (deletes resources created using odo push)NO
odo delete --deployYES (deletes resources created using odo deploy)NO
odo delete --allYES (deletes all resources created by odo)YES

Add suppport for cpuLimit, cpuRequest and memoryRequest (PR#5252 @anandrkskd)โ€‹

odo now supports specifying additional resource constraints for container components in Devfile as introduced by Devfile v2.1.0.

You can use the following constraints:

Devfile container fieldKubernetes equivalent in Pod specification (spec.containers[].)Description
memoryLimitresources.limits.memoryDescribes the maximum allowed memory for the container.
memoryRequestresources.requests.cpuDescribes the minimum memory that the container requires.
cpuLimitresources.limits.cpuDescribes the maximum allowed CPU cores for the container
cpuRequestresources.requests.cpuDescribes the minimum number of CPU cores that the container requires.

You can learn more about resource management in Resource Management for Pods and Containers section in Kubernetes documentation

Example of a Devfile container with all available resource constraints:

components:
  - name: runtime
    container:
      image: registry.access.redhat.com/ubi8/nodejs-12:1-36
      memoryLimit: 1024Mi
      memoryRequest: 512Mi
      cpuLimit: '1'
      cpuRequest: 200m
      endpoints:
        - name: "3000-tcp"
          targetPort: 3000
      mountSources: true

You can specify custom Service Binding mappings using odo link command.

For example, with the following link command

odo link PostgresCluster/hippo --map pgVersion='{{ .database.spec.postgresVersion }}'

Odo will generate ServiceBinding resource similar to

apiVersion: binding.operators.coreos.com/v1alpha1
kind: ServiceBinding
metadata:
  creationTimestamp: null
  name: myapp-postgrescluster-hippo
spec:
  application:
    group: apps
    name: myapp-app
    resource: deployments
    version: v1
  bindAsFiles: false
  detectBindingResources: true
  mappings:
  - name: pgVersion
    value: '{{ .database.spec.postgresVersion }}'
  services:
  - group: postgres-operator.crunchydata.com
    id: hippo
    kind: PostgresCluster
    name: hippo
    version: v1beta1

You can find more information about how to compose custom binding data in Service Binding Operator Documentation

As with every release, you can find the full list of changes and bug fixes on the GitHub release page

]]> Tomas Kral https://github.com/kadel <![CDATA[odo 2.4.3 Released]]> https://odo.dev/blog/odo-243-release 2021-12-14T00:00:00.000Z 2.4.3 of odo has been released!

Notable changes in odo 2.4.3โ€‹

Features/Enhancements:โ€‹

odo deploy command #5228 (@feloy)โ€‹

In Devfile specificion v2.2.0 new component image and command group deploy were introduced. odo deploy command uses those features to allow users, deploy their application as it would be deployed in production. To build container images odo deploy requires Podman or Docker to be installed on your machine.

You can find example of how to use image component and deploy command group in devfile.yaml in devfile-nodejs-deploy repository.

Demoโ€‹

$ git clone https://github.com/kadel/devfile-nodejs-deploy
$ cd devfile-nodejs-deploy
$ odo project create nodejs-example
$ odo create
$ odo deploy

asciicast

Know issues wth odo deployโ€‹

  • Resources deployed using odo deploy can't be deleted using odo #5246
  • odo deploy doesn't work without running odo create or odo push first. #5289
  • There is no odo command that would show if odo deploy was executed or not and what is its status #5248

Bug fixes:โ€‹

]]> Tomas Kral https://github.com/kadel <![CDATA[odo 2.0.0 Backward Incompatible Changes]]> https://odo.dev/blog/breaking-changes-in-odo-2.2 2021-05-04T00:00:00.000Z odo 2.0.0 Backward Incompatible Changes

Backward Incompatible Changes in odo 2.0.0โ€‹

This document outlines the backward incompatible changes that were introduced in odo 2.2. With the increased adoption of Devfile we have started to reduce odoโ€™s dependency on S2I(Source-to-Image). If you no longer work with Source-to-Image containers, this does not apply.

  1. odo create --s2i <component-type> will create a converted Devfile based component on the S2I images of that component type.

    odo create --s2i nodejs

    Output -

    $ odo create nodejs --s2i
    Validation
     โœ“  Validating component [424ms]
    Conversion
     โœ“  Successfully generated devfile.yaml and env.yaml for provided S2I component

    Please use `odo push` command to create the component with source deployed

    The above command would generate a devfile.yaml which would be using the S2I images and variables that are part of the nodejs.

    This change will not break any existing S2I components. Although you are encouraged to convert them to devfile using odo utils convert-to-devfile.

  2. Currently devfile components do not support --git and --binary components hence we still use S2I component flow to create them.

    $ odo create java --s2i --git ./build.war
    Validation
     โœ“  Validating component [431ms]

    Please use `odo push` command to create the component with source deployed

    Observe that there was no conversion done here.

  1. odo env set DebugPort won't work with converted devfile components, you would need to use odo config set --env DEBUG_PORT instead.

    Currently, the wildfly and dotnet component types do not work when converted. We have an issue open for this - https://github.com/redhat-developer/odo/issues/4623

Known bugs and limitationsโ€‹

Frequently asked questionsโ€‹

  1. Why does odo fail create to URL using odo url create for a component created using odo create --s2i even though odo url create is allowed for devfile?

    • It wonโ€™t fail in the sense that if you tried the conventional s2i approach and try to create odo url create it would fail with url for 8080 port already present as there would already be one for you. Refer - https://github.com/redhat-developer/odo/issues/4621

  2. How to understand the status of the debug?

    • odo env set DebugPort won't work, instead you would need to use odo config set --env DEBUG_PORT - this is because the s2i to devfile converted devfiles don't have a debug type command defined in them. We would fix this too.

  3. If every component will now be reported as devfile component, then what about existing S2I components?

    • They should work as is. Check odo list for a simpler check. Somethings might still break since it is quite complex to make things work across the board.

  1. If oc based checks in tests are not going to work, is there an alternative odo support around it ?

    • It wouldโ€™t be right to say that you cannot use oc based checks, but they would break because now the s2i components are being converted to devfile, odo would generate a Kubernetes Deployment but the oc would try to find a DeploymentConfig on the cluster.
]]> Girish Ramnani https://github.com/girishramnani <![CDATA[odo 2.0.1 Release]]> https://odo.dev/blog/odo-201-release 2020-10-28T00:00:00.000Z 2.0.1 of odo has been released!

What's newโ€‹

Secure starter project supportโ€‹

With this release, you can now deploy a component directly from a secure registry.

$ odo create nodejs --registry <secure registry name> --starter --starter-token <starter project token>

App comandsโ€‹

A series of new commands have been added to app.

You can now list, describe and delete an app with the following commands:

  $ odo app list
  $ odo app describe <app-name>
  $ odo app delete <app-name>

PROJECT_SOURCE env variablesโ€‹

PROJECT_SOURCE now works as an environment variable when specifying a workingDir inside a devfile.yaml.

 $ export PROJECT_SOURCE=/tmp/foobar/
- exec:
    commandLine: mvn -Dmaven.repo.local=/home/user/.m2/repository spring-boot:run
    workingDir: ${PROJECT_SOURCE}

Full changelogโ€‹

New features:

  • odo url delete should work without arguments #4106
  • When using a devfile with multiple starter projects, odo should ask the user which one to use #3812
  • Add support for overriding composite commands #3759
  • Release 2.0.1 of odo #4152 (cdrage)
  • feat: Allow composite commands to be overridden #4043 (johnmcollier)
  • Update build version to 2.0.0 #4022 (cdrage)
  • Adds app commands for devfile components #4007 (mik-dass)
  • Update integration testcases and e2e testcases for ppc64le support #4000 (sarveshtamba)
  • Save PROJECT_SOURCE for containers mounting source #3979 (maysunfaisal)
  • Secure starter project support #3743 (GeekArthur)

Code Refactoring:

Bugs:

  • Nit: odo url list shows :// before it is pushed #4109
  • odo storage create should create without a path #4101
  • odo push fails for s2i components #4071
  • odo devfile push command tests failed with error "Failed to create the component: error while waiting for deployment rollout: watch channel was closed"" #4058
  • odo create: --s2i flag is broken #4048
  • Overriding parent devfile's commands no longer works #4038
  • Unable to mount bootstrap volume to deployment config sub path "ODO_S2I_DEPLOYMENT_DIR" on 4.6 cluster #4015
  • component volumeMount path validation error #4005
  • devfile volume component size bug #4004
  • odo rewrite should preserve "unknown" properties of 'metadata' (and other optional properties?) per devfile schema #3968
  • Beta release: Operator Hub does NOT work & tests are disabled (tracking issue) #3932
  • Switching from run to debug mode shows no build but build occurs #3929
  • odo allows devfile commands with duplicate ids #3886
  • Odo fails when devfile component container name is really long #3698
  • nit: dont show url as :// in odo url list #4111 (girishramnani)
  • Update vendor-update makefile target #4086 (johnmcollier)
  • read s2i paths from both Config and ContainerConfig #4068 (kadel)
  • Fixes message indicating no build when run mode is switched #4066 (mik-dass)
  • Update configure-installer-tests-cluster-ppc64le.sh script to import right imagestream for tests. #4065 (sarveshtamba)
  • Default vol mount path to vol name if absent #4045 (maysunfaisal)
  • make odo list's output for no components consistent #4029 (girishramnani)
  • Don't allow duplicate command IDs #4001 (johnmcollier)
  • 3968-add more optional metadata #3987 (yangcao77)
  • Update s2i image for the library change on s390x plaftorm. #3974 (zhengxiaomei123)
  • add container name validation during creation and push #3959 (yangcao77)
  • Fix deletion of files and folders created during watch #3890 (mik-dass)

Tests:

Documentation & Discussions:

  • Unexpected mention of 'crc' in 'kubernetes prerequisites' #4113
  • fix windows installation instructions #4077
  • Update debugging page on how to debug via application + IDEs #3971
  • installing odo documents changes for IBM Z platform #3913
  • Developer CLI odo doc needs update #3878
  • odo cli reference doc still pointing to old reference examples #3870
  • Add documentation of storage commands for devfile components #3761
  • Update deploying a devfile documentation #4133 (cdrage)
  • Add links to new Kubernetes Slack #4128 (cdrage)
  • Update secure registry documentation #4099 (cdrage)
  • Update doc to support installation on IBM Power for the latest version.[skip ci] #4049 (sarveshtamba)
  • Fixes sections in Opreator Hub documentation #4041 (dharmit)
  • Update doc to support installation on IBM Z for the latest version.[skip ci] #4040 (zhengxiaomei123)
  • Update the installation page and blog #4032 (cdrage)
  • Add blog post regarding 2.0.0 GA release #4026 (cdrage)
  • Update asciinema on the README #4020 (cdrage)
  • Fix minor docs issue in community page #3999 (cdrage)
  • Update the debugging documentation #3972 (cdrage)
  • Adds a document regarding the usage of storage commands. #3936 (mik-dass)

Closed issues:

  • Create Windows Chocolatey package #4078
  • Discussion about PVC usage for non root containers in OpenShift default namespace #4053
  • Openshift 4.6 code freeze interoperability testing #3994
  • Setup periodic testing on internal openstack #3953
  • Beta testing on windows and macOS #3952
  • $PROJECT_SOURCE env variable #3781
  • Download of starter project stored in a secure repo #3574
  • Support downloading starter project from secure repository/host #3567

Merged pull requests:

]]> Charlie Drage https://github.com/cdrage <![CDATA[odo 2.0.0 GA Release]]> https://odo.dev/blog/odo-200-release 2020-09-24T00:00:00.000Z 2.0.0 of odo has been released!

What's newโ€‹

Changes to the default deployment methodโ€‹

Devfile is a file format that is used as odo's new deployment engine. Starting from 2.0.0 onwards, Source-to-Image (S2I) is no longer the default deployment method. S2I is still supported and can now be accessed with the --s2i flag from the command-line.

Learn how to deploy your first devfile using devfiles from our Devfile tutorial.

Example on how to download a starter project and deploy a devfile:

$ odo create nodejs --starter
Validation
 โœ“  Checking devfile existence [22411ns]
 โœ“  Checking devfile compatibility [22492ns]
 โœ“  Creating a devfile component from registry: DefaultDevfileRegistry [24341ns]
 โœ“  Validating devfile component [74471ns]

Starter Project
 โœ“  Downloading starter project nodejs-starter from https://github.com/odo-devfiles/nodejs-ex.git [479ms]

Please use `odo push` command to create the component with source deployed

$ odo push

Validation
 โœ“  Validating the devfile [132092ns]

Creating Kubernetes resources for component nodejs
 โœ“  Waiting for component to start [5s]

Applying URL changes
 โœ“  URL http-3000: http://http-3000-nodejs-foobar.myproject.example.com/ created

Syncing to component nodejs
 โœ“  Checking files for pushing [1ms]
 โœ“  Syncing files to the component [868ms]

Executing devfile commands for component nodejs
 โœ“  Executing install command "npm install" [4s]
 โœ“  Executing run command "npm start" [2s]

Pushing devfile component nodejs
 โœ“  Changes successfully pushed to component

Deploying a custom Kubernetes controller with odoโ€‹

With the release of 2.0.0 deploying operators is now out of experimental mode.

Learn how to deploy your first Kubernetes custom controller from our installation guide.

Example on how to deploy your first Operator:

$ odo catalog list services
  Operators available in the cluster
  NAME                          CRDs
  etcdoperator.v0.9.4           EtcdCluster, EtcdBackup, EtcdRestore

$ odo service create etcdoperator.v0.9.4/EtcdCluster

odo debug is no longer in technical previewโ€‹

The odo debug command is no longer in technical preview.

Learn how to debug your component via the CLI or VSCode.

Full changelogโ€‹

New features:

Code Refactoring:

  • "odo link" help message should not check for ClusterServiceVersion support #4008
  • API version and schema version tests should be migrated to devfileV2 #3794
  • Do not check for CSV when initializing odo link command #4010 (dharmit)
  • Update odo debug --help screen #3963 (cdrage)
  • Clarify description of the force-build flag in help text for odo push #3958 (johnmcollier)
  • Switch to use project instead of namespace in env #3951 (GeekArthur)
  • Remove the namespace flag from odo #3949 (johnmcollier)
  • Migrate devfile cmd validation to validate pkg #3912 (maysunfaisal)
  • Remove command group type init #3898 (adisky)

Bugs:

  • "odo link -h" shows same message for 3.x & 4.x clusters #3992
  • make goget-tools fails due to go mod dependency #3983
  • Handle edge case when index file is commented in .gitignore #3961
  • Java component build execution requires pom.xml #3943
  • default registry not initialized when user already has a preference.yaml file #3940
  • odo url create shouldn't require a port if only one port exists in the devfile #3923
  • odo push with alternate --run-command should push complete file set upon new pod creation #3918
  • converting s2i items to devfile items does not set the Endpoint's name properly #3910
  • Unexpected EOF during watch stream event decoding, watch channel was closed. #3905
  • odo debug serial tests script panic out #3897
  • Default URL does not propagate to .odo/env/env.yaml and you cannot delete it. #3893
  • Breaking component create without exposing port #3882
  • odo registry list causes panic if preference has not been setup #3842
  • odo watch goes into infinite push loop if ignore flag is used #3819
  • 'odo create' should properly validate devfiles #3778
  • context flag does not work with devfile url create #3767
  • odo log is unusable for multi container components #3711
  • "odo registry add" adds registry for invalid url in devfileV2 #3451
  • Prints help message based on backend cluster #3993 (dharmit)
  • s2i component fix: use Config instead of ContainerConfig for port detection #3957 (kadel)
  • 3923- url creation with optional port flag #3950 (yangcao77)
  • Add mandatory file ignores when using --ignore flag #3942 (maysunfaisal)
  • Fix default registry support #3941 (GeekArthur)
  • Update s2i image from library for ppc64le #3939 (sarveshtamba)
  • update s2i to devfile conversion as per new url design #3930 (adisky)
  • Add test-case for validating devfiles on component create #3908 (johnmcollier)
  • Improve URL format validation #3900 (GeekArthur)
  • implement odo describe for devfile #3843 (metacosm)

Tests:

  • Test failures while running test-cmd-push test suite on ppc64le #3539
  • Test failures while running test-cmd-storage test suite on ppc64le #3531

Documentation & Discussions:

  • Update installation page to include instructions for VSCode / IDE's #3970
  • Update docs according to schema changes in the command and component struct #3925
  • Help for odo push -f should explain that the full set of project source is pushed to the container #3919
  • Make the odo.dev front page documentation simpler #3887
  • Add debug examples for "odo debug -h" #3871
  • Remove technology preview feature for debug command #3869
  • Update devfile "odo.dev" doc #3868
  • Documentation for Operator Hub integration in v2 #3810
  • Document on converting s2i to devfile #3749
  • Adds a blog folder #4003 (cdrage)
  • Document odo and Operator Hub integration #3982 (dharmit)
  • Add instructions on how to install VSCode plugin #3977 (cdrage)
  • Update installation page to indicate beta-1 #3960 (cdrage)
  • Remove references to Docker support #3954 (cdrage)
  • Updates docs to use the new schema changes for commands and components #3928 (mik-dass)
  • Update commands ouputs in docs. #3927 (boczkowska)

Closed issues:

  • Determine if we want to keep Docker support in experimental mode, or disable it #3955
  • rename --namespace flag in odo push to --project #3948
  • rename odo env variable namespace to project #3947
  • Test failures while running test-integration and test-e2e-all test suite on ppc64le #3945
  • "unknown flag: --s2i" while running odo test suite 'test-generic' on ppc64le #3934
  • odo make commands fail on ppc64le after latest changes. #3891
  • Downstream release of the odo cli #3852
  • clonePath should be supported in odo #3729
  • Move devfile command validation to validate pkg #3703
  • make test throws "Errorf format %w has unknown verb w" error on ppc64le with latest master #3607
  • Move Operator Hub integration out of Experimental mode #3595
  • Move container image used in springboot devfile to some odo owned image repository #3578
  • Move the devfile feature set out of the experimental mode #3550
  • JSON / machine output support for Devfile Components #3521
  • Component push throws error of "Waiting for component to start" on ppc64le #3497
  • odo project create throws error of connection refused on ppc64le #3491
  • Tests for devfiles in odo devfile registry #3378

Merged pull requests:

]]> Charlie Drage https://github.com/cdrage