Support for new features in devfile 2.1

[deboer-tim]

/kind feature

Goal

Feature #4589 will be used to adopt the devfile 2.1 library, react to any breaking changes, and do any urgent new features in order to support devfiles created with 2.1 that are almost equivalent to current 2.0 devfiles. This feature will be used to add support for all other new features and complete 2.1.

The Devfile 2.1 spec (https://github.com/devfile/api/milestone/4) has the following changes:

New support

• Top level attribute def (issue 239) - will be handled via feature Initial adoption of devfile 2.1  #4589
• Extend Volume components to support more features (issue 310)
• Add a link to an external website (issue 38)
• Better support of resources settings (issue 131)
• Add attributes free-form map field for tool-specific fields in a number of places (issue 169)

Cleanup

• Remove sparseCheckoutDir (issue 128)
• What are valid name values? (issue 201)

Dev workspace related

• Commands scoped to a project (issue 165)
• Root folders for projects (issue 385)
• Remove devfile.projects[].github (issue 340)

Not applicable/internal fixes, etc

• Extending DevWorkspace Status fields (issue 370)
• Remove plugins from devfile schema (issue 407)
• Provide and publish types for different languages (issue 353)
• Make vscodeLaunch / vscodeTask more generic (issue 344)
• Parse plugin component and add component, command and events to the main devfile obj (issue 240)
• Attributes overriding fails when overriding for non primitive attributes (arrays or objects) (issue 263)
• The metadata filed should allow additionalproperty to be backward compatible (issue 236)
• Define a way to contribute environment variables to all the workspace POD containers (issue 149)
• Define the devfile 2.0 equivalent of the Devfile 1.0 chePlugin preferences (issue 170)

Based on the categorization above, 'Cleanup' and 'Not applicable' should not affect odo, so there are 5 issues for new support, and 3 dev workspace related-issues.

Proposal

Use this feature to explicitly reject 'workspace' devfiles that contain features odo cannot easily handle. If commands are scoped to a project or contain project root folders, odo will output a message like "This devfile contains support for multiple projects (a workspace) and is not supported by odo".

We can always discuss how odo might support some of these features later, but we can handle as a separate feature and this avoids odd user errors in the meantime. Doing this makes it clear that a dev workspace is not currently supported in odo.

Acceptance Criteria

• Review Devfile 2.1 plan to confirm no additional items and categorization above (https://github.com/devfile/api/milestone/4)

New support

• Extend Volume components to support more features (issue 310) - Devfiles containing persistent and external types must work (created Add support for ephemeral volumes. #5131 to track this)
• Better support of resources settings (issue 131) - Resource limits should be applied such that applications that exceed these limits fail. (tracked in support for cpuLimit, cpuRequest, memoryRequest #5132)

Dev workspace

• Using a devfile with project-scoped commands should give an error. (this was eventually not added to devfile Commands scoped to a project devfile/api#165 (comment))
• Using a devfile with root project folders should give an error. (roots were not included in devfile Root folders for projects devfile/api#385)

Optional / stretch

• Add attributes free-form map field for tool-specific fields in a number of places (issue 169) - Confirm if there are any reasons why odo would need to use tool-specific info. (more info in Support for new features in devfile 2.1 #4640 (comment))
• Add a link to an external website (issue 38) - Provide a command that opens a browser on the embedded website url.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kadel]

/remove-lifecycle stale
/lifecycle frozen

[dharmit]

As a part of researching this issue, we need to figure how many features mentioned in the issue description are already available for use in odo. Then list the ones which odo doesn't support yet and figure out how we pick them in upcoming sprints.

/remove-kind feature
/kind epic
/triage needs-information

[dharmit]

/assign @kadel

[kadel]

[ ] Add attributes free-form map field for tool-specific fields in a number of places (issue 169) - Confirm if there are any reasons why odo would need to use tool-specific info.

odo levareges tools-specif attributes for selective push this feature is documented at https://github.com/openshift/odo/blob/main/docs/public/using-devfile-odo.dev.push.path-attribute.adoc

[dharmit]

All items in acceptance criteria checked. Closing this issue.

/close

[openshift-ci]

@dharmit: Closing this issue.

In response to this:

All items in acceptance criteria checked. Closing this issue.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.