The purpose of this post is to tease out consensus on the purpose of the
core package in Juju.
I have a patch up to add units to the new model cache. The logic for the cache resides in
core and there is a worker that maintains the cache via a multi-watcher.
Multi-watcher deltas for units include slices of
PortRange. The multi-watcher DTOs for these types need to be converted to
network.PortRange, which would violate dependency-free requirement of the core package, necessitating the import of
I began what will be a migration of
core.network, but following some discussions I got to thinking if we move things into core because things in core need them, we’ll just end up moving more and more into core, defeating its purpose. Note that the validity of moving at least parts of network into
core is not being questioned; it is just the example at hand.
A lot of what is in core makes intuitive sense:
- Interfaces that can be imported without dragging in their implementation packages.
- Types, constants and validations that apply cross-package.
- Other fundamental concepts that are axiomatic to Juju and do not need other Juju packages.
But there are other sub-packages in core that include more “wholesale” implementations of parts of Juju - the model cache being one, Raft leases another.
So at this point the questions are:
- What is the stated purpose of the
- By what criteria should something reside in
- Are there things now under
corethat should not be there?