Open sed-i opened 2 months ago
Are you're thinking some helper methods and some @abstractmethod
's that the charm has to implement?
@abstractmethod
's that the charm has to implement
Experience wise I was hoping that ops would implement everything. Or as much as possible. Privkey mgmt seems pretty basic need for the vast majority of charms. That's why something like a mixin came to mind.
@jdkandersson I'm curious what your thoughts are on this, particularly given https://github.com/canonical/paas-app-charmer/pull/46
I think it is true that private key management is a common requirement across charms and there should be some common library or shared code for it. It would also probably fit in quite well into the charm tech team as a home
I'm not sure if it 100% fits into the ops
library since how to implement key rotation seems like it would be something the charm should implement. So perhaps it should be located in some other library? The ops
library seems to be most focussed on managing interactions between the charm and juju
I'm also curios about what the requirements of this kind of private management keys would look like?
We'd like to give this some thought as part of our charm libraries work in 25.04.
@sed-i If you can comment on specific requirements, that'd be great to seed the discussion.
Most server apps need a private key. Vault/manual or not, it is probably going to be mediated via juju secrets. Since the lifecycle of secrets/privkey is probably closer to the hearts and minds of OF folk, and since we probably want some uniformity in this basic feature, I wonder if something like an ops-provided mixin could work.
Getting, rotating etc. workflows should probably be the same across charms, so it would be great if ops provided a building block like that.
The main advantage I see over a charm-lib is that users won't need to deal with manually observing custom events. I'm imagining a "plug and play" ux similar to rust traits. Not sure if it's feasible but wanted to share the general idea with you.