Comments (11)
I prefer the alternative proposal. Having each type (containers, kubernetes, etc) under component be an array of elements (of length 0, 1, or many), makes things easier to read / understand in my opinion
from api.
I was thinking of it a little bit different from the alt version.
Current
components:
- chePlugin:
registry:
id: redhat/vscode-yaml/latest
- chePlugin:
registry:
id: ms-vscode/go/latest
- cheEditor:
registry:
id: eclipse/che-theia/latest
registryUrl: "external-registry-url"
- container:
image: some container image with required build tools
name: "build-tools"
Alternative 2
components:
- component:
type: chePlugin
registry:
id: redhat/vscode-yaml/latest
- component:
type: chePlugin
registry:
id: ms-vscode/go/latest
- component:
type: cheEditor
registry:
id: eclipse/che-theia/latest
registryUrl: "external-registry-url"
- component:
type: container
image: some container image with required build tools
name: "build-tools"
Alt 2 provides a more extensible model. If we use the current proposed schema, then any change would need to be done in Go code. However, I can see how this may take more work to validate.
I do not think the language should drive the data structure but it can inform how it is made.
from api.
@joshuawilson this looks redundant:
components:
- component:
type: ...
I would rather have the component spec directly without prefixing it with component:
:
components:
- type: ...
And that corresponds to the devfile 1.0.0 format (and if there is an agreement that this is the best alternative I am perfectly fine with it).
from api.
@joshuawilson afaict, the following alt2 syntax proposal ...
components:
- component:
type: chePlugin
registry:
id: redhat/vscode-yaml/latest
- component:
type: cheEditor
registry:
id: eclipse/che-theia/latest
registryUrl: "external-registry-url"
- component:
type: container
image: some container image with required build tools
name: "build-tools"
... seems to move the problem encountered with the old Devfile 1.0.0 syntax, to a lower level (under the intermediate component
level):
You may have distinct sub-schemas (according to the type
field) under the same field name (component
), which makes declarative validation (validation by the schema itself) harder it seems and, afaik, makes it very difficult to serialize/unserialize in some languages that don't have polymorphic subtyping (like GO).
OTOH, the whole idea of devfile 2.0.0
current proposal is to avoid having different sub-schemas under the same field name, in a way that would be at the same time:
- nice for the human end-user,
- and the recommended way to express polymorphic fields GO-wise and K8S-wise.
Some pointers about the context that drove this initial design;
- https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#unions
- https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190325-unions.md
- https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190425-structural-openapi.md
from api.
I prefer the alternative proposal. Having each type (containers, kubernetes, etc) under component be an array of elements (of length 0, 1, or many), makes things easier to read / understand in my opinion
I assume this adds a constraint on the order in which components have to be described, since they would be gathered by type ?
from api.
I am not sure if it is a concern of the current effort for Devfile 2.0 but IMHO the "clustering" by component type, reflected in the schema, makes it kinda hard for the devfile spec to be interoperable, e.g. reused by other "processors" than Che/ODO without the need to add explicit support for them in the source code.
E.g. in my dreamt up world, I would like to support multiple IDEs with a single devfile, maybe using something like this:
components:
- type: chePlugin
id: redhat/java/latest
- type: eclipseDesktopPlugin
id: org.eclipse.jdt
- type: gitpodFeature
id: java-support
...
Is that something we want to address in any way or is it out of scope?
Or, given the majority of examples above, are we maybe considering externalizing the IDE configuration into some other part of the devfile than components - something in support of #5?
from api.
@metlos In your example:
components:
- type: chePlugin
id: redhat/java/latest
- type: eclipseDesktopPlugin
id: org.eclipse.jdt
- type: gitpodFeature
id: java-support
the 3 components are in fact structurally equivalent, have the same sub-schema, and thus to me they seem to be the same type of component.
The fact that they would define different types of plugin would probably fit into the encapsulated plugin definition itself (currently the meta.yaml
format in devfile.1.0.0).
Sure we initially called this component type chePlugin
, but in fact if you look into the meta.yaml
format it already covers 3 flavors of plugins: pure Che plugin (cf che-machine-exec
, theia editor), Theia plugin or VsCode plugin.
So it seems to me that, while discussing this matter, we should avoid mixing component type, which drives distinct component sub-schemas, and what a plugin type field could be, i.e. a way to provide more insight about how a given plugin should be installed / used.
from api.
@metlos that's an interesting scenario and I think we should take it in consideration. Your sample with the current proposal would look like:
components:
- chePlugin:
id: redhat/java/latest
- eclipseDesktopPlugin:
id: org.eclipse.jdt
- gitpodFeature:
id: java-support
...
or, if I am interpreting @davidfestal answer correctly:
components:
- plugin:
id: redhat/java/latest
- plugin:
id: desktopEclipse/org.eclipse.jdt
- plugin:
id: gitpodFeature/java-support
...
What's wrong with those?
from api.
What I didn't take into consideration and what we discussed with @davidfestal before he posted his answer here was that the distinction between the different plugin types (e.g. theia/eclipse/gitpod/codewind/...) can happen in meta.yaml
of the plugins and that all we then need is to be "forgiving" when applying such plugins to workspace (e.g. a eclipse IDE plugin in the devfile shouldn't make it impossible to use in Che).
from api.
Discussed and agreed to go with "Current proposal"
from api.
Implemented
from api.
Related Issues (20)
- [Spike] Investigate open api configuration issue with `x-go-types-import` on index/server
- Add test devfile registry deployment to devfile library testing workflow
- Add test devfile registry deployment to index generator testing workflow
- Fix external references in test sample entries
- devfile special envs cannot be defined last in the env list HOT 5
- Devfile Registry nightly run fails for `ollama` stack HOT 3
- for a single minor version, library should support all previous patches with latest schema
- Copy odo-devfile starter projects to devfile-samples org HOT 2
- Publish `0.3.0` release for registry-operator HOT 4
- Spike: Enable Konflux build pipeline
- Update lastModified For Stacks/Samples Without Versions HOT 3
- Implement Multi Arch Support For Devfile Repositories
- [Spike] Investigate documentation updates for pod - container overrides
- Community Registry Showing Default Date for lastModified
- Error logged with Quarkus stacks related to telemetry usage HOT 1
- Error logged with Quarkus stacks related to LogManager
- Update `odo` to `v3.16.1`
- Add DCO to docker plugin repo
- Bump up `github.com/docker/docker` to `v25.0.6` version. HOT 4
- Release `devfile/api` new `v2.3.1` version HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from api.