One of the ideas we are prototyping at the moment is nesting the applications in a Juju model into groups called stacks.
Today, when you deploy a set of components, their applications are all visible in the model at the top level. So if you deploy OpenStack, you don’t see anything called OpenStack, but what you see are Cinder and Nova API and Keystone, etc. You see the applications that make up the thing.
If you are deploying two big, integrated scenarios on the same model, they all get mixed up in the same namespace.
Stacks would allow us to nest the namespace of applications in the model. This post is just to outline the idea for comment.
With stacks you would be able to hide all the complexity of OpenStack inside a stack called (drumroll…) openstack. Simplistically this would just look like a dotted name. So cinder becomes openstack.cinder. Imaging a deploy command like juju deploy cinder openstack.cinder. Now your status might show:
App Version ...
openstack.cinder ussuri
openstack.keystone ussuri
openstack.nova-api ussuri
...
As a follow-on idea, it might be interesting to associate a charm with the stack, so that the stack itself had some ability to offer integration points, and have a version etc.
This is in a sense like a bundle, but a smart bundle which persists in the Juju model. Today, when you deploy a bundle, Juju quickly forgets that all of those apps and relations came from a single named piece of YAML. But with stacks, that memory would persist in the form of the charm that drives that stack. In fact, instead of deploying all the applications, you might deploy just that one charm, which would manage the internal complexity of the stack model.
I assume that like a bundle, relations between a stack’s charms will be set up on stack deploy. Would those relations be defined in the stack’s metadata.yaml (similar to a bundle)?
If a stack includes an application like a database that another stack or charm deployment would also like to utilize (relate to) without need for spinning up more units of their own in the model, how would that play out?
In the scenario of a second stack that wants the same database charm, would new units be deployed by default unless told otherwise, or the reverse and new unit deployments have to be specified?
Would that required separation of units of the same application being deployed by different stacks be managed by simply specifying (overriding) the application’s name during deployment?
Removal of a stack would need to be careful about not removing application units that are related to another stack or independent application.
Could this namespacing scheme be extended to subordinate charms?
I think it is useful to have relations and config defined, bundle-style, yes. I’m not sure about the encapsulation of stacks (i.e. whether you can just go ahead and relate from outside to stack.mysql or whether you would only be allowed to do that if the database endpoint was somehow exported from the stack explicitly).
We already allow duplicate use of the same charm in a model, if you want two mysql databases for different purposes you can juju deploy mysql my_db_a and juju deploy mysql my_db_b and you get two different instances of the database that are completely independent, I think this allows for stacks to be explicit about what they want and where.
Subordinate charms are interesting - if you relate a subordinate to the stack charm itself, does it relate to every application? That’s can’t really be true given interface requirements.
Substacks make sense, yes, as do bundles with stacks.
