I was just thinking, it seems like it could be useful to have a hook tool for letting the charm scale itself. Now, as the operator deploying a charm, I think I would want that to be an opt-in feature because I would want charms to go willy-nilly spinning up server resources that I have to pay for. If we did allow charms to scale themselves we might want to make the user consent required somehow.
I haven’t spent a lot of time justifying that idea yet but I thought I’d put it down.
Another related thought was that if I wanted to have a charm of mine connect to the Juju API to do things like scaling my charm or other charms, it could be useful to have a built-in relation of sorts that I could use to connect to the Juju API. So Juju itself would provide like a juju-controller relation that my charm could require. That way you would get all of the advantages of relations such as not needing to provide credentials manually and such.
The way we currently think about this is that we want separation of ‘operational logic’ from ‘business logic’. Operational logic is ‘how’ to scale, business logic is ‘whether and how much’ to scale.
The sequence of things that need to happen when a service scales is operational logic. Whether you are scaling on Azure or scaling on Kubernetes, the mechanisms of scaling are something that the experts in the software can decide and can encode in the charm.
But only the person running the deployment can correctly identify and encode the parameters for spending money - which is what scaling does, as you point out. Sometimes you want to spend that money, and sometimes you don’t. The same is even true for things like availability - sometimes you want to spend the money for failover units, and sometimes you don’t, and it should be a separate decision.
In the telco world, the OpenSource MANO (‘Management and Operations’) project OSM is building a telco-centric layer above Juju, where those business decision policies can be encoded. There, charms perform the pure operations role. If the business logic layer decides to scale, charms do the work.
For me, this is the right separation of concerns.
We have spent a long time figuring out how to do the operational layer well. Now seems like a reasonable time to start thinking about the higher layer too, but I would prefer to do that as a ‘thing above the juju model’ which decides what sort of model is appropriate. If you are interested in that, count me in.
We can empower charms to act with provider APIs via juju trust. Perhaps that command could be extended (or another command created) to facilitate other entitlements? This would allow the management/policy layer to set a charm’s operational boundaries.
