Hey, so what happened to the whole concept of charms on the new charmhub? I almost can’t tell if charms are being abandoned or if it should just redirect to operatorhub.io?
Hi @szeestraten,
Charms aren’t going anywhere. We are changing the way that we participate in the conversation around software that operates software, however.
To that end, we’ve been referring to charms by the more general term “operators” in communication and documentation meant for people who are not yet familiar with Juju.
For more experienced and bought in folks, we might refer to charms and operators interchangeably. Operators are pieces of software that operate other pieces of software. Charms are Juju’s specific implementation of the operator idea.
And the goal of Juju is still to be as “charmingly” pleasant to use as possible.
I will tend to fill in with @szeestraten that changing terminology didn’t help me at all getting people to understand better or more about juju.
It’s super hard to explain juju as it is and concepts move, change name, new features coming in before old one get stable and documented. There are 2 charmstores active and I’m not sure what to teach really to new people trying to learn juju.
I was thinking to introduce juju to a broader developer community but I tend to think that might be a bad idea since the project is way to much in a constant Flux. Its too much ifs and buts.
I don’t know know how to influence how juju moves either at the moment. What is the project vision? Priorities are set by who? How can the community be affecting the project direction? Who is the community lead and how is it nurtured? Does it care?
These are all stuff that matters moving forward to me.
Hey Erik 
I’m ponderous of this also. This is pure conjecture, but there seems to be a concern that Juju has missed the K8s boat, and so the baby+bathwater have been thrown out. I see that the operator method of charm implementation is gaining a great deal of promotion, albeit within the same realm as ‘old’ Juju so I’m not sure the message is reaching the right audience? Admittedly I don’t spend a lot of time in areas where k8s gets a lot of ‘foot traffic’…
Additionally I’m wondering if I should be using the ‘reactive’ paradigm anymore or converting my charms to operator. In a brief glance it seemed like the operator implementation was k8s specific and that ‘generic’ platform agnostic operator charms would come later.
The Operator Framework is agnostic to kubernetes or normal machine/vm charms. It has been used to do both styles of charms. It took a lot of the learning from reactive about events, and put them into a system that makes them a bit more straightforward. (Rather than events just being strings, they are attributes and involve a registration step, so you have better visibility about where the event is generated, and what is reacting to the event.)
There is very little of throwing out all of the work that has been done that has already shown great utility. All of the existing charms continue to work, and while we don’t feel like ‘reactive’ is the easiest way to write charms, it is still viable and reactive charms continue to work.
Thanks for your reply.
I think I have to take a look and maybe rewrite/create new in the Operator Framwork. Is there any guidance on it for those coming from a Reactive Charm development, where the improvements are, what’s different etc?
Maybe it’ll be obvious when I start hacking.
Glad to hear charms are not going away.
To agree with @erik-lonroth, I’ve been around here for a while and I’m having a hard time explaining to my colleagues what these operators are.
Might I recommend having another go at the copy to actually explain what charms are and how these operators are related. For example the title What is a Kubernetes Operator? on /about does not really help me for all those charms such as the OpenStack charms that have nothing to do with k8s.
Agree we are in an awkward place. On the one hand, charms clearly defined the idea of ‘portable packages of operations code’, on the other hand, the Kubernetes community has adopted the term ‘operator’ for the same thing (when it is a container on K8s operating other containers on K8s).
For Juju people, the term charm is nice and short and distinctive. For Kubernetes people the question is ‘yes but do you have operators?’
Because Kubernetes has so much of the buzz, I felt it was a good idea to adopt the terminology from there. To be clear, I don’t like it much, it’s a long word, and explaining and operator to a telco operator is excruciating, but there we are.
I tried using the term ‘charmed operator’ to distinguish between the package (the charm) and the concept (the operator pattern in K8s-speak). But clearly that was not very successful.
Right now, our focus is on iterating on the charms-on-k8s development experience. I think with 2.9 with have the key elements well described, however there is a lot of new work in there (talking to the Charmhub by default, using snap-style revisions and channels, placing charms in sidecar containers inside the workload pod, and more). All of that makes me feel that we need to make some fresh hello-world charms that exploit that cleaner view of juju-on-k8s and then document, and tutorialise, that story.
One of the very good results of that work is that writing a charm for use on K8s and machines becomes much, much easier. We can really unify the worldview for people who care about both machine-based and K8s-based operations. And it seems to be coming together very tastefully.
So in short, I want to acknowledge the messiness of naming, and make the case that we all benefit if we can truly capture the zeitgeist of container-based workloads, given the growth in interest there. It would be tragic if we had all the right ideas, but people didn’t look at it because they got told by there existing vendor that they ‘need operators’.
Makes 100% sense.
Is there a rebranding of charms into operstors going on?
I don’t like that at all, since it would mean I have to reset all my effort I have put into teaching people about charms, which has been difficult as it is. Perhaps I am missing something here, but then again I don’t think this has been discussed at all in the community. I just woke up one day and there was a rebranding going on. Or did I miss out on that somehow?
Why not stay with the name charm and explain it as an implementation of an operator?
I’m confused.
I like the operator framework, but I can’t see a clear path for juju itself with this rebranding.
I miss a lot off communication with the juju community on this.
Agreed, I’ve been trying to explain the concept of Juju and charms to teams I interact with for a while now, and most of the time the buy in is pretty hard but once they see what it does they’re like “holy crap”!
The problem is, to get any trust or buy in at a corporate or “enterprise” level, we really can’t be switching the name or rebranding a reasonably mature solution every couple of months.
That kind of thing is very Oracle centric, and most of the products Oracle have ever rebranded or been indecisive with have suffered slow painful deaths.
Please don’t let Juju slip into the shadows and die a slow lonely death because people didn’t realise that it was rebranded.
Yeah, so this is all my fault.
The short version is simply that our good counterparts at other companies did an excellent job of taking the story of charms and then calling them ‘operators’ in K8s-space. Since they did a better job than we did, there is lots of buzz, and many people ask ‘do you have operators’. To which I would like to say ‘yes, and ours are charmed operators!’ hence the naming.
I’d rather like to keep using the term charm in various forms, because I think it’s much cleaner than ‘operator’, hence charmhub.io
So feel free to keep calling them charms, because I will. I’m describing the charm as a package for the code which does the operator thing, to people who want to hear about operators. But I wouldn’t mind at all if the term ‘charm’ wins out, because it says a lot more about the feeling of the code.
Also, @dvnt I have to say “holy crap!” is exactly the feeling we want people to have
This discussion has certainly matured well since 2021.
I would agree at this point, that the terminology lean into “operator” turned out to be a good move. It is nowadays possible to have a conversation about Juju with people also outside of our domain.
I think we should try to organize a more open discussion about Juju in the ecosystem to find out how it can reach out into new communities. It would strengthen the Juju ecosystem, which is still in need to mature as a given platform for operating large and complex software.
Its 2024 and juju snap is at highest version 3.2
