Constraints modeling shouldn’t be limited to the current list that we have now. Constraints tend to behave by allowing affinity modeling using a somewhat expressive language. Allowing the grouping of values to form more complex rules (for example; spaces spaces=space1,^space2 use space1, but not space2).
There are some shortcomings though. How do you express minimums and maximums or negates in a common language to provide anti-affinity rules across every value? How do we model not less than 2 cpus?
Although the biggest wart is that we don’t use them enough within Juju itself. Naming aside; series is a model config, yet should be an application constraint that could have a default model constraint. This hierarchy of series is re-implemented with model-config and used against the deploy-config as a poor man’s constraint system. I believe that Juju does itself a disservice by not modeling these correctly.
juju deploy mattermost --series="focal"
This should be:
juju deploy mattermost --constraints="series=focal"
Although semantically model-config series and the ideal of constraints series are almost the same, they have the same hierarchical design internally, but have different implementations, making it harder to reason about. The language for modeling constraints serves Juju as a whole better, it provides a concise common set of language to reason about, which is transferable between the values (cpu, zones, tags, spaces etc), which is unlike individual implementations (series for example). Others could be moved from model-config to constraints, but series is the one I’ve been working with recently.
I’d like to see constraints (or another work if that becomes a problem with anti-affinity) becoming the nomenclature of Juju, the default language to model affinity/anti-affinity for Juju. As a second step, we can tighten up the erroneous flags we leak into the CLI and just model as one.