Modelling Juju with a Planning phase

One of the problems that I believe Juju struggles with is how to correctly know in advance what may or may not apply when attempting to deploy a charm. The crude analogy “throw it at the wall and see what sticks” is well placed for how we sometimes attempt to deploy certain aspects of a charm.

Out inability to model certain aspects cause us to attempt to just try things and if it fails log it out in status and get the user of Juju to rinse and repeat. The feedback loop for this can be sometimes long and the efficiency that we know Juju can achieve can be lost.

I’ve run into this countless times over the years trying to implement various features;

  • LXD profiles: A user wants to apply a profile with a specific kernel only to find out later that kernel module isn’t available on the machine and so Juju attempts to apply it, but it doesn’t stick and we show an error to the user in the status output.
  • Architectures: A user wants to use a specific architecture for a given charm, except Juju doesn’t know upfront if that architecture is even available.

When I look at all these problems, they’re a basic modelling problem. Juju could know this information, the providers in Juju could tell us this information, yet we don’t model Juju in this way. I believe we should start to model in this way.

Planning:

The idea being quite a simple one, we improve the dry run capabilities that already exists within Juju and we make it a real concept. We insert a Plan phase when attempting to deploy a charm with Juju. The Plan phase would gather all the information as a series of assertions that we believe are critical to deploying to the substrate. Then ask the provider if the assertions are likely to work, we can either show a confidence rating or just error out. Juju could show the results from the planning phase to the user if we don’t believe the deploy will work. This would vastly improve the user experience with Juju.

I like this a lot.

In a sense, a bundle is a plan, but with no way to specify parts of it that may setup dependencies for other parts.

A better modeled bundle might include phases. Like, go ahead and deploy these machines, with these profiles and support charms, then bring up these other charms.

The problem isn’t unique to Juju. Any microservices architecture runs into the nightmare of unclear dependencies across a ballooning number of services in unknown states. If Juju helped folks reason about these things and manage them, that would be amazing.

(And also relevant, not just to “legacy” stuff like OpenStack, but to a lot of the new Kubernetes stuff.)

1 Like

I think the key point here is that the more definitively Juju models the world, the more definitively it can guide the user to success. This beauty of Juju comes from the clarity of the charm or bundle combined with the clarity of the Juju model.

What you are pointing out is that things which are critical, but not modelled, cannot be known until they are exercised. This is true of a lot of stuff (“will this service work today”) but it’s frustrating when its something structural which Juju really COULD have known about.

So a very big +1 to raising the bar on the quality of modelling (and even real-time updating of the model) so that the experience can be more on-rails.

Not sure I like the idea of making bundles more complicated in a declarative way. Instead, I think what you are looking for fits into stacks, where we have a charm-of-charms. The stack can look at the details and then know how to proceed (your phases would be code, not YAML). However, that still depends on the charm being able to ask Juju certain questions and get a definitive answer, and right now we are a bit haphazard with how we plan and implement the things Juju models.

1 Like

Also… does this need to be internal?

1 Like

Sorry I was still formalising this internally for myself, but you’re right we can do this in the open.

Is there a way to get this out into a post, so that me and others can understand from a purely conceptual point of view what stacks are. Most of the information I’ve heard about this is second hand and wavy at best.

Thank-you for this @sabdfl :+1: