Closed phil-abb closed 3 months ago
Original post from @Haishi2016
It's unclear to me the relationship between properties and configurations. It seems a configuration refers to a property. If they are linked, what's the point of separating them out? I think "properties" already represent something that is "configurable"?
We'll be discussing that part of the proposal more next week (it will be a different PR). The difference is what is under the configuration section is information for the WOS to be able to provide a UI enabling a customer to provide any required/optional inputs. I'm aware of some use cases where the values for these parameters would be provided from places and not shown in the UI. The idea is to make the parameters section more extensible in the future and not to tie all parameters to needing a UI element (configuration).
Original post from @Haishi2016
There a few places where the ${} syntax is used. We need to clarify on the exact syntax rules of such expressions - such as do we allow mixture of these expressions with constants, do we anticipated recursive expressions, and where these expressions can be sued.
Correct. What I have above are just some examples. If Margo decides to adopt the idea of allowing parameter values to come from other sources (e.g., the device) we'll need to define the expected format and what these keys/IDs are. This may not be something we want to adopt for V1 but I do have some use cases for it.
I guess the pointers point to specific paths in Helm values file. This format doesn't natively work for Docker compose or other artifact formats that might get introduced in the future. Maybe we shouldn't specify the exact injection path (which also makes maintenance hard) but use a Margo-specific templating stage to allow declared properties/configurations to be injected into corresponding artifacts through "margo expressions" in the artifacts.
This is just a format we were using internally since it was based on a specification. I think it could be parsed and used in other places besides helm charts but there might be a better way of doing it.
@Haishi2016 Can you give an example of what you're talking about? I'm not sure if I follow exactly what you mean.
@Haishi2016 in your other post you raised a question about the use of dataType
In the parameter section, schema and dataType are two separate fields. Propose to merge them into one schema field to reduce possible errors that a user choose a schema that is incompatible with a dataType - such as "maxLength" won't make sense for a boolean value.
I don't have a problem with moving the dataType
to the schema because of the reason you state. However, this would indicate all settings
would need to have a schema even if there are no validation rules. This may not be a big deal but it is an impact to think about. This trade-off might be worth it to make the schema rules more consistent.
This is a proposal for updates to how parameters/properties are defined in the application description document. The goal is to make this more flexible for future cases where some property values are coming via inputs from the customer but other property values are coming from other sources (e.g. the device) and not the customer.
properties
instead ofparameters
targets
pointer
instead ofkey
components
instead ofappliesTo
prefix
and/orsuffix
to append to the value provided for the parameter.properties
from theconfiguration
sectionsections
andschema
are pretty much the same just under aconfiguration
section instead of combined with theproperties
Simple Hello World Example
Complex Example