Hi folks, a request for some tracks and ownership changes, but first a query.
To provide some jargon, JAAS = Juju as a Service, JIMM = Juju Intelligent Model Manager (A special Juju controller).
We have a Snap called JAAS used for managing a JAAS deployment, but the name of the Snap is a little misleading as it’s only a cli tool called “jimmctl” used by admins of the JIMM controller. Should the name of the snap reflect the tool it installs? I.e. Should this snap rather be called “jimmctl” (similar to kubectl)? I’ve already reserved the Snap name here.
Assuming “jimmctl” is preferable could I please,
Get two new tracks “1” and “2” for jimmctl v1 and v2.
Change ownership to Canonical.
Change ownership of “Jaas” snap to Canonical and could I get access to it and the ability to add collaborators.
I don’t want to delete the “jaas” snap in case it is being used.
Per the process stated by Guillermo, we need a 1-week voting/discussion period, so we’ll check back on the discussion and votes in a few days.
I have three questions before casting my vote.
What’s jimmctl’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream?
Is there some commitment from upstream on maintenance of old versions? e.g. is the “1” release still supported with security updates? Will it continue to be supported now that “2” is out, and for how long?
Are new versions backwards-incompatible? meaning, if I was running “1” and try to install “2”, will that just work, or do I need to migrate my data/configuration, or will things break horribly?
Hi Odysseus, thanks for the questions. I’ll forward this thread to folks on the team who will be able to give more concrete answers but I will try answer with what I can for now.
Currently active work is going on for v2 so the release cadence is every ~1-2 weeks. A new major is not expected going forward. JIMM aims to be backwards compatible where possible as one of its aims will be to allow Juju clients to connect to Juju controllers of various versions. Having said that, because this project tracks Juju in many ways, it’s possible there could be some change in Juju that forces a major bump in JIMM. This is not currently documented anywhere.
V1 is still in use and is the supported version for users of Juju<3.2, so while I don’t foresee many new features (if any) landing in v1, there will be support for security fixes.
The jimmctl CLI tool has no dependencies beyond files that exist in your local Juju directory. These files are currently compatible between Juju 2.x and Juju 3.x from my experience and so switching between jimmctl v1 and v2 also works fine. The reason for the different versions is that there was a breaking change in JIMM’s API between V1 and V2 so while the CLI tool from v1 can work in large parts with v2, some features don’t and if this divergence is to continue and the two versions are developed separately, this is the simplest solution.
I have nothing more to add to @kian90 answers other than you should see jimmctl/JIMM/JAAS as tools that are closely coupled with Juju, so any support commitment we make in Juju is likely to be reflected in the tools.
I also think name change makes sense as it better describes the intended functionality.
Yes, we do use risks in various other projects. The team that works on JAAS also works on Livepatch so we’re familiar with Snaps from their use there. Currently things will only be going to edge until we start to move towards a beta and eventually a full fledged release.
