Community wishlist for Juju developers - workshop output

Greetings! :vulcan_salute:

This is the transcript from the workshop on providing developer input from the Juju community.

The complete resulting PDF is published here 2022-april - Community input for Juju developers.pdf (74.0 KB) - email addresses removed.

We had participation from EU+US timezones, independent and Canonical project leads. Massive thanx also to those that could add content from the US timezones prior to the event. We talked about those items aswell @heitor @jamesbeedy etc.

The workshop started with collecting new items from the participants and then walked through all items together producing this list. There was alot of discussions, feedback and comments and we also had some social time.

I hope participants wan’t to keep commenting about it in this thread.

Here is the list in no specific order or priority.


:building_construction: Desire: Actions with access-control

What: I would like to be able to restrict access to certain juju actions such that I can allow or not allow certain users to be able to run, let’s say security related actions or that perhaps reveals secrets. It could be more ways to achieve this.

Why: Juju actions is very powerful tool but anyone with “write” permissions can run all actions. For operations-staff, some actions - like “juju run-action get-admin-password –wait” is way too scary to let “anyone” have access to with simple write permissions. Its very much “all or nothing” here, which makes it problematic if I have many charms where some should not have this kind of access, where some other charms would be OK.


:building_construction: 2. Desire: Deploy juju controller via helm chart

What: I would like to provision a juju controller by means of helm chart.

Why: It is difficult to integrate juju to k8s infrastructure. Aka you need to run “juju bootstrap” from somewhere.


:building_construction: 3. Desire: Operating system agnostic instance provisioning

What: I would like to provision linux based operating systems other than ubuntu or centos using juju.

Why: Oftentimes software systems do not support ubuntu and the disconnection from juju and the other operating systems prevents juju from being used in many scenarios. @jose-phillips expanded about series vs bases which would allow future work towards this.


:building_construction: 4. Desire: Juju ecosystem installable via package manager

What: I would like to use apt/yum/dnf/pacman to install juju and charmcraft.

Why: We need to control our infrastructure and follow an enterprise way for software provisioning: well defined calendar for updates, production systems should never change before staging (this includes the juju client), ability to downgrade software in case the new version contains regressions, and so on. This all makes snaps unsuited for distributing software. We need proper packages (rpm, deb, etc) for the Juju ecosystem (Juju, LXD, charmcraft).


:building_construction: 5. Desire: Versioned docs What: I would like documentation to be versioned to each juju version

Why: Juju is complex and changing fast. We need to find information about the version we have in our controllers, but the forum posts are not tied to specific versions.


:building_construction: 6. Desire: license-aware systems

What: I would like the Juju ecosystem to show the licenses of the charms: Charmhub showing the licenses in the Charm’s page and juju info showing the licenses in the output.

Why: In enterprise environments, we have to follow specific rules on what licenses to use. Not having this information excludes juju from providing solutions to enterprise clients. @mcjaeger suggested a dedicated workshop for discussing publishing guidelines


:building_construction: 7. Desire: All documentation in the charm for charmhub

What: I would like to have the documentation ( go into the charm itself instead of having to mess with the discourse. Also, the format would be better off be forced to have some specific chapters to improve the quality of charms in the charmhub.

Why: Its very difficult to contribute and add to documentation and get it all look good in charmhub.


:building_construction: 8. Desire: A more demystified and monitorable controller

What: I would like controller (cluster) health to be easily monitored and generally more means and best practices to maintain the controller’s health over its lifetime, both in terms of scripts/utilities and documentation.

Why: The controller is an extremely critical component used to control almost our entire infrastructure, without it we are blind. It is stable, but after years of operation, dozens of upgrades and hundreds of units running it sometimes misbehaves (slow and resource demanding) and the cluster may even be out of sync without us knowing about it.


:building_construction: 9. Desire: More config option classes/types

What: *I would like to have a richer set of config options with “early sanity checks”. * So lets say “items” like “apple, pear, orange” would be the only allowed options.

Why: This would “prevent” missconfigurations early which would also help developers not having to do alot of coding to cover for wierd input etc. … also passwords/secrets option could have a great use.


:building_construction: 10. Desire: I would like a more streamlined CLI command structure.

Why: It would improve user experience.

Why: Not obvious whether it’s better to have commands that are verbose but clear vs. short but ambiguous. Verbose also helps discovery through grep. Maybe we should make continuous efforts to translate between the bottom-up, developer perspective and the top-down, user perspective.


Thank you for putting together your feedback. We really appreciate your input on things that would make your experience better. If you would like I can provide some feedback about where we are at with some of these, and my view on them. I’m not sure what the best way is to have essentially 10 different threads on the conversation, is it clearer if we break it into separate discourse threads? or just use quoting and do it inline for now?

1 Like

Thanx @jameinel - I think that just writing short in this thread, announcing that you are aware, is good enough. After all, this is a first encounter between a/the community and the development team. Lets explore ways to move forward together from this. The fact the you have seen this material and is now commenting on it, is a great first step.

What isn’t in the material, is that we talked about forming up a “users/community counsel” around Juju, which would work independently of Canonical. It could provide valuable input for you guys and also be able to provide perspectives that might otherwise be missed out on. A number of users has expressed interest in this and I will be calling for an initial meeting for those that initially has shown interest in this to discuss how we can work together. It will be open to participation for anyone of course and the ambition is currently focused on:

  • Make events continue
  • Beginner education.
  • Training the trainer.

I think we will be able to use this counsel to work with development teams and develop the link between devs and users in the community.


Thank you everyone for a very interesting workshop. I had a great time interacting with everyone.

During the workshop I talked a little about desire #2 and thought it best to also document my thoughts here so people in the future can also find this information. Fair warning that the opinions below are my own and I may be answering from a position of not enough information.

This is an interesting idea and one that has come up a few times for Juju around how best to give automation tooling the ability to deploy Juju without the need for running juju bootstrap my-kubernetes-cluster. Some things that we have active work and planning on are:

  • A Terraform Juju module for deploying charms and interacting with a Juju controller from within Terraform. It’s unclear yet if this will support bootstrapping via Terraform. @jnsgruk may be able to provide further details on this.
  • We are looking into ways to have the Juju client be able to output raw Kubernetes yaml for applying to a Kubernetes cluster.

I think the idea of a Helm chart is a very interesting one and running through all of the in’s and outs of it in my head in principle I think it could work. However with that said I think it could suffer some interesting problems:

  • The juju client and components would no longer own the installation of the Juju controller. i.e all of the work will have been done outside of the normal code paths we have. This can pose a management risk for production installation of Juju over the long run.

  • To do the work properly we would have to reflect a lot of the brain logic used in Juju for performing the bootstrap potentially into the Helm chart. The risk this creates is it’s now a new platform and code path that Juju core team would need to maintain creating the potential for new errors and conflicts. That is to say that the effort is not necessarily worth it.

  • With the next big release of Juju we plan to introduce the controller as a charm it self. This means that now during the bootstrap phase the client takes on a bit more responsibility for the initial bootstrapping of the Juju controller charm till it’s in more of a state to take over. Replicating this into a Helm chart would become more difficult over time.

  • Would helm charts be responsible for the upgrading of the Juju controller? If Juju is still performing it’s own upgrades as it does today then the information represented by Helm would become out of sync with the actual state of the deployment.

All of the above points hopefully go a little way to emphasizing some of the hurdles that would need to be overcome. Considering the work that is currently going on with other tools to offer different ways to bootstrap Juju I think they offer a more robust solution long term over a Helm chart that is much more manageable.

One way this problem could be solved in a not very neat solution but a functional one would be to quickly throw a Helm chart together that deployed the Juju client as a Kubernetes Job to run juju bootstrap against the same cluster with in cluster credentials.

This wouldn’t be an ultimate solution but it would be one that would satisfy the basic requirements of the request. If the community is interested in developing this solution then it’s something I would be happy to offer some help on with how to go about getting it done. It also has the benefit of not knowing how the internals of Juju work to get this up and running. It does however not solve all of the problems listed above.

Thanks for reading and please let me know if you have more information to help support this desire to continue the discussion.