Track request: 4.0 for snap juju-db

Could we please get the track ‘4.0’ added for the snap ‘juju-db’ (https://dashboard.snapcraft.io/snaps/juju-db/).

As per Process for aliases, auto-connections and tracks, can you at least give a rationale for the request?

Oh, sorry, sure. Juju will essentially use the tracks to ensure the right version is used as well as isolate versions of juju from chages to juju-db (i.e. juju 2.6 will use 4.0 (currently 4.0.9) juju 2.7 might use 4.1 etc.).

This allows us to essentially tie down a version of juju-db to be used by juju while still being able to have newer builds of juju-db (that doesn’t break the existing versions of juju).

1 Like

… ok and presumably you want to retain the ability to make updates to 4.0.x at the same time as 4.1.x?

yes correct. And just generally have 4.0.x separate to 4.1.x.

OK, this matches the requirement of a track.

+1

Thanks @sparkiegeek :slight_smile:

1 Like

+1 from me on track semantics and naming. I wonder why this is separated from juju itself; surely juju can’t operate without a database so it would make sense to bundle that with juju itself, right? I’m starting to see a pattern of reinventing shared components/libraries with snaps (evident in some track requests in the forum). But that’s orthogonal to the juju-db track: +1 :slight_smile:

  • Daniel

The primary delivery/packaging mechanism for Juju’s mongo database is via apt.
Having mongo installed via snap is not production ready - it is behind a feature flag and is not for general use. There are a number of problems we need to solve on the snap side before we can make this the default packaging mechanism, the primary concern being how we manage and control database upgrades. Certainly epochs and cohorts will play a part in that but for today, mongo via a snap is experimental and in place to enable us to start testing server side transactions with mongo 4.
Given the above, we don’t need to, or want to (yet), consider packaging mongo with the juju snap.

To build on @wallyworld comment; It’s the Juju controller that uses the database and not the client. The controller isn’t installed via snap so there isn’t any reason to bundle it.
We would also shy away from coupling the db to the client snap as we wouldn’t want a Juju release to force a DB restart (as the newer version is refreshed) on the controller with zero warning.

Thanks for the extensive details/explanation!

The 4.0 track for juju-db has been created. Enjoy!

  • Daniel