anik120
commented
1 year ago Makes sense to me. Feels like it should start in the deppy project, so that deppy can define "here's how to define properties, and here's how to define constraints", and then get it bubbled up to other components this is relevant to, eg fbc will probably need to just document whatever deppy defines
Not sure if this issue belongs here or in deppy. So we can move this to deppy if necessary.
Today, a bundle contains a collection of properties, which can be categorized into a few groups:
In the current state of the world, all of these are encoded as properties and are differentiated by a property type. Today, operator-controller iterates the property list looking for the property types it knows about, validating the required properties and evaluating the known/hardcoded constraint properties. Any unknown properties are ignored. This behavior is fairly reasonable if we expect that operator-controller will always control the set of supported constraints. However the design presents a problem for extensibility.
If, in the future, we want to make it possible for users to define and implement their own constraint types, then we can expect that bundles will start adding new properties where the property type value is the type of the custom defined constraint. In this case, the intent of the operator is most likely that they expect this custom constraint to always be evaluated and enforced. The problem is that if properties and custom constraints are co-mingled, there's no way to distinguish between a completely optional/inert property, and a constraint that the operator author intends to be honored. If this bundle is evaluated on a cluster that does not understand this extension constraint type, the current code will ignore it. The correct behavior (or at least the expected default behavior) is most likely "if a constraint type is unknown, consider the constraint to not be satisfied".
So my proposal: I think we should go ahead and split the bundle property list into a list of properties and a list of constraints. When operator-controller/deppy encounter an unknown property, no worries. When they encounter an unknown constraint, fail resolution.
This actually has some immediate benefits even without custom constraint types. If someone typo'd a
olm.package.requiredkey asolm.package.reqiured, we would currently just silently ignore that property and resolve without the intended dependency being required. If the typo'd key existed in theconstraintslist, we would detect that as an unknown constraint and fail resolution.