Comments (10)
@amisevsk I'm not sure generateName
really makes sense here. Let me explain my initial reasoning:
During the discussions that happened in the context of devfile 1.0 some months ago, about possibly adding the workspace target namespace
as a devfile attribute, it was finally concluded that:
- the devfile is mainly the description of the structure of the workspace, what the workspace contains,
- and so we should avoid adding devfile attributes for information about where and how related workspace instances will be used.
So in the context of Che, target namespace, as well as debug mode more recently, were implemented on the Che-server side as parameters of the Start Workspace
API endpoint.
It seems to me that generateName
somehow falls into the same category: it is mainly a matter of how a given implementation (Che server for example) will name workspace instances from the workspace structure definition provided as a devfile. Not sure it requires a distinct generateName
field for that, especially knowing that we don't expect the Devfile 2.0 syntax to be a pure Kubernetes resource at the top-level anymore.
But I might be missing some point, and if a generateName
(or similar) field is really meaningful and useful, let's change the currently implemented proposal.
from api.
I am not sure I understand the need to identify the devfile by its name. I think we're actually talking about 3 things in the discussion above:
- A standalone
devfile.yaml
in a VCS. Even here, I don't necessarily see a hard reason for the devfile to have a name, because its identity is tied to the repo it lives in. - A workspace object in k8s - IMHO here devfile is akin to
PodSpec
- while a pod does have a name,PodSpec
doesn't. - A workspace template as an object in k8s - again, the identity stems from the k8s object, not from the spec.
Now if you wanted to assert whether the 3 things above are actually the same structurally - I think it is much safer to actually compare the devfiles in them structurally than to rely on a "name". After all 2 independent authors of 2 standalone devfiles may choose the same name for a completely different structure and it would be an error to consider them the same.
Coming back to the issue of devfile version - here I like @davidfestal's schemaVersion
because clearly conveys the purpose of that value - it is the version of the devfile schema, not that of the devfile itself.
from api.
I already implemented a proposal of this in the current devfile schema on the master
branch.
I pulled the name
property back to the top-level
and changed the old apiVersion
(which was falsly K8S-like) to schemaVersion
, since here we're interested in the version of the schema itself, not the K8S API.
This gives:
name: "devfile example"
schemaVersion: "2.0.0"
projects:
components:
...
Of course naming can be changed for something better.
from api.
duplicate of #10 ?
from api.
@davidfestal are we dropping generateName
from the spec? Pulling name
out to the top level may be confusing if it's pseudo-optional.
from api.
In the same vein, should the devfile schema really have a name? If I simplify the picture, we could consider the devfile a spec of a workspace k8s object. As far as I am aware specs don't have a name of their own.
from api.
I agree, I tend to lean towards either no name or name and/or generateName. How is the name
field in a devfile intended to be consumed?
from api.
In the same vein, should the devfile schema really have a name? If I simplify the picture, we could consider the devfile a spec of a workspace k8s object. As far as I am aware specs don't have a name of their own.
Well, the content of the devfile (apart from name and version) is the spec of the workspace structure. In fact the part of the devfile schema is the same (or derived from) the DevWorkspaceTemplateSpec
Go struct.
When this workspace template spec is used in the context of a K8S CRD, it is referred in both a DevWorkspace
(workspace instance) or a DevWorkspaceTemplate
(workspace template stored for further use/reference). But, as native K8S CRD objects, both have metadata/name
and apiVersion
fields in addition to the DevWorkspaceTemplateSpec
struct itself.
Similarly on the Devfile side, the same workspace template spec schema also defines most of the devfile content. But this doesn't mean that the complete devfile schema doesn't need a name and a version. The main difference is that, in the case of the devfile, unlike K8S CRDs, we can add name
and version
fields wherever we want inside the overall devfile 2.0.0 schema.
How is the name field in a devfile intended to be consumed?
How the name would be used is the responsibility of the implementation that uses the format I assume.
But a typical example is the way the existing Che server works: it would derive the name of the workspace instance it creates, from the name of the devfile (which is fact is a workspace template), according to rules that are Che-specific.
But if the devfile has no name at all, it seems to me that we are removing a quite important aspect of the workspace template semantic which is the identity of the template.
To summarize, it seems to me that:
- we should keep the identity of the workspace template provided by the devfile =>
name
, - but could remove the additional instruction about how workspace instances should be created from a devfile =>
generateName
from api.
Reviewed and agreed
from api.
Closing this as it has been implemented in the spec.
from api.
Related Issues (20)
- library generator should generate containers with commands defined in devfile HOT 3
- support devfile 2.3.0 in devfile library HOT 5
- Update Registry .ci Scripts for CI Operator HOT 5
- [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 3
- 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`
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.