KEP-0013 External Application Formats #356
Conversation
There was a problem hiding this comment.
I must say I like this idea of extensions!
I am still trying to picture how will that look like from the user perspective though, can you maybe picture an example?
So I have mysql chart, I extend it, add plan and submit it. What I end up with?
I will have 1 framework: Mysql
I will have 2 frameworkVersions?: mysql- and
I will have 1 instance created from the second FV?
| The core functionality required by KUDO is the ability to turn | ||
|
|
||
| ```go | ||
| type StepArgument struct{ |
There was a problem hiding this comment.
so what is StepArgument? I cannot picture anything under that name. is it Instance? or... ?
There was a problem hiding this comment.
is it maybe ExecutionStep? 🤔 ActiveStep?
There was a problem hiding this comment.
This object is all that gets provided to the templating engine to be able to render the Kubernetes objects. It should contain all the info needed. It contains (currently planned) the FrameworkVersion, so the templates are available, as well as the parameter values in the Instance that is being rendered.
Some frameworks use other data provided by KUDO as part of their rendering, and this will also contain that data, though maybe it makes more sense to embed that in the parameter map. For example STEP_NAME, PLAN_NAME, etc.
|
|
||
| ### Engine Spec in FrameworkVersion | ||
|
|
||
| The Framework Version Spec would have a new field `Engine` that would specify the engine that should be used to Render steps into Kubernetes objects. Initial implementation will focus on adding one additional engine to support the execution of `Helm` charts. |
There was a problem hiding this comment.
can we really do just one? What about various helm versions? Do we expect that new helm library will be always able to process old templates? Is it true for v2 and v3?
There was a problem hiding this comment.
I was told by someone on the helm team that they should be backwards compatible. i.e. helm 3 can render helm 2.
|
|
||
| ##### Installation of Helm FrameworkVersions | ||
|
|
||
| Helm charts have a similar structure to KUDO Frameworks and the converstion, at installation time, of a Helm Chart into a Helm FrameworkVersion should be straightfoward. |
There was a problem hiding this comment.
so if I extend a helm chart, I will end up with two different frameworkversions installed?
| ### User Stories | ||
|
|
||
| - Allow running of a Helm Chart as a KUDO Framework | ||
| - Allow running of a CNAB bundle as a KUDO Framework |
There was a problem hiding this comment.
could we maybe focus on helm only for now? maybe put the rest to future work?
What type of PR is this?
/kind kep
What this PR does / why we need it:
Introduces KEP-0013 to accept a process non KUDO application formats
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
I did not address how KEP-0012 and KEP-0013 interact yet. Once one of them get merged we can adjust the other.
Does this PR introduce a user-facing change?: