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.
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.
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.
The first draft of the schema for the networking artefacts looks like this. There will likely be a couple of tweaks; this post will be updated if/when that happens.
