Changing the Juju data back-end

It’s no secret that the Juju team is hard at work switching out the current MongoDB persistence layer and replacing it with Dqlite.

While Juju-sans-Mongo will come out with a future major version, if you happen to be using Juju 3.2 or greater, you are already getting the benefits of Dqlite, because it backs our leases system - a significant improvement over the prior custom store built upon Hashicorp’s Go Raft implementation.

As work continues moving the various domain concerns over to the new backing, we obviously have an emergent relational data model. This is a great asset to comprehension of the Juju domain, so I thought I’d show how it’s looking so far.

This is the controller schema:

And this is the model schema:

The average Juju user or charm author likely doesn’t need to know Juju with this intimacy, but if it piques the curiosity of anyone, I can keep these up-to-date as we go. They’re going to get a lot bigger.

9 Likes

this is a gold nugget for those of us who have had to navigate the schema to understand (and/or fix) certain behaviors.

image

Does this map 1-to-1 to the output of juju dump-model?

Indeed. It’s (been to-date) a missing foundational statement about the domain.

It will not.

The major entity tables will be roughly the same, but there are necessarily some differences; at least:

  • The lack of RI in (schema-less) Mongo means that some collections have reference counters in order to use for transactional guaranties. We now have real RI, so these dissappear.
  • Some collections embed types/lists/maps wholesale. In the new relational model, these are extracted into new tables.
  • Some enumerated lists from the Juju code-base are represented as lookup tables in the new model.
  • There exist join tables for many-to-many relationships.
1 Like

ah, understood, thanks, @manadart .

Storage looks like this (subject to change). I’ve omitted some joins to the larger model for clarity.