Open dhiguero opened 3 years ago
@dhiguero Thank you for bringing up this issue, this is exactly what we want to fix in the v0.2.2 release of OAM spec.
The root cause of this issue, as you've already posted, is ComponentSchematic
mixed workload schema (i.e. template + parameters) and configuration values (i.e. .workloadSettings
) in the same object. This caused a lot of confusion and make it very tricky to manage the underlying workload instance in implementation, because a ComponentSchematic
could be a instance or a template depending on how user defines it.
Thus, we decided fix issue by splitting all the schema related fields into a seperate object named WorkloadDefinition
in v1alpha2, then deprecate ComponentSchematic
, and use a new object named Component
to represent the configuration values of workload.
In this context, the objects that will be shared across applications are always definition objects (because they ARE templates)
Note that the changes above is not fully reflected in v0.2.1 spec release, for example, the .parameters
are still defined in Component
, this is not correct and it should be moved to WorkloadDefinition
. Another TODO is we should add .template
to WorkloadDefinition
. Hence, we began to work out v0.2.2 spec release (the current working draft).
While at the same time, we decided to finish v0.2.2 on implementation side first so to get enough feedback from community, especially on how to do templating and parameterizing. It's why KubeVela project comes out and why we experimented using CUE as the template and parameters in definition objects. The feedback is great in general, and we also received feedback that we should support Helm chart as template in definitions, which indeed makes sense to me.
Based on these feedbacks, we've almost completed the v0.2.2 release of OAM spec on KubeVela side today, it evolves from the current release naturally like below:
Detailed examples can be found here: Application
, Definitions
.
Note that we temporarily removed the .parameterValues
part in Application
. This doesn't mean it will be deprecated, on the contrary, this feature is so valuable that worths a seperate object to reflect the idea of "runtime configuration of the app". Hence, after the Application
+ Definitions
spec are released, some follow up model objects im my mind will be:
ApplicationBinding
which carries the runtime configuration values to override the values in Application
. The key difference here is we can even override the traits values in this case. The user scenario will be cross-envs deployment.ApplicationDeployment
which handles rollout and traffic of the Application
. Previously rollout
is a trait (i.e. part of the app), it works, but it makes more sense to define rollout separately since it need to handle multiple revisions of the app.In implementation,
Component (C)
+AppConfig (AC)
will still be long term supported as backward compatibility for existing v0.2.1 based platforms. Note that this also means C + AC will NOT be part of core OAM spec in the future
So back to this issue, I feel we can ignore the v0.2.1 release (Component + AppConfig), and directly look at the change from v1alpha1 to v0.2.2 release. The change is below:
In detail:
ComponentSchematic
is replaced by WorkloadDefinition
, and all schema related features will be moved to definition object (i.e. parameters and template).Traits
is renamed to TraitsDefinitions
. ALL the definition objects are sharable and reusable across apps.ApplicationConfiguration
is renamed to Application
, and it still represents the whole instance of the app.
.workloadSettings
is moved to this object (done in v0.2.1)..parameterValues
is not needed any more as what Application
contains are all parameter values. For runtime configurations like ApplicationBinding
, it's non-goal for v0.2.2.A demo workflow for v0.2.2 could be found here.
Hopefully above background and summarize could help to explain what's happening (v1alpha1 -> v0.2.2), so we can evolve the spec following this direction together.
We are also eager to onboard more maintainers to join the team and fix the spec alongside with the implementation.
Thanks @resouer for the comprehensive response on this issue. We will take this into consideration for our next release, and we are looking forward to extend our collaboration in the community.
We have found an issue related to the expectations of what happens with a component on an ApplicationConfiguration entity. Launching the containerized-workload example once, and then copying the ApplicationConfiguration, changing its name, and launching it again produces the following output:
On the ApplicationConfiguration spec related to the
component
it saysWe believe this is a desired and expected outcome since it will improve reusability and we already have a
parameterValues
attribute. In this way, we think that having reusable components among different ApplicationConfigurations would be ideal. From other parts of the spec, this approach seems to be expectedWe are aware of other proposed entities such as the ComponentSchematic which are defined as
One alternative to introduce this feature using the current entities could be to modify the ApplicationConfiguration to include a new reference so it is clear for the runtime that we expect to make a new copy of a component (creating a new instance) instead of linking it to an existing one:
What do you think?