Skip to main content

odo 2.5.0 Released

· 3 min read

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