state server updates
[GOAL]
We want to alow several state instances to be served from the same machine or,
in a high-availability context, to be able to have an arbitrary n-m mapping
from server processes to machines that the server processes run on,
with restrictions as deemed appropriate.
Alternative (possibly sufficient, but more focused) goal:
Enable a juju environment to boot from state servers
run within another juju environment.
Note: it is not clear where the "server" in multi-tenant server
refers only to mongod or also to the other state-related
agents, such as the API server and the provisioner.
[RATIONALE]
We can reduce the costs per juju environment by relaxing the requirement
that every juju environment must have a dedicated bootstrap node running
the state server.
If we do this we must, as a necessary consequence, allow a state server
to be able to run on an instance from a different environment than the
state that it is serving.
If we do things right, juju bootstrap will become less important, as
jujus will usually be started from other jujus. The only bootstrap we
usually do is to start a new state server on some other juju's machines.
It also potentially allows (in combination with changes to make all
agents communicate exclusively through the API) an environment that
can enforce arbitrary security policy, as the state server and other
environment-
the rest of an environment's instances.
Blueprint information
- Status:
- Complete
- Approver:
- Mark Ramm
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Katherine Cox-Buday
Whiteboard
[USER STORIES]
As a juju user I want to experiment with Juju without the overhead of setting up my own state server.
As a juju user I want to be able to create multiple environments, because (e.g.) I need both a production and staging environment.
As a juju administrator, I want to be able to enforce a given security policy.
[ASSUMPTIONS]
We need to break the current hard association between instance and
agent. One way to do this would be to make a machine agent able to run in
"hosted" mode where it manages a host environment but is itself running
within a juju unit from another environment
JAAS server and the hosted environments all run in the same cloud (provider type).
[RISKS]
Doing this breaks various assumptions currently made by
the juju code. In particular we currently assume that all
an environment's agents run on instances that are started
and managed by that environment.
[IN SCOPE]
[OUT OF SCOPE]
Creating hosted environment on a different cloud than the JAAS server is running (cross-cloud JAAS).
juju bootstrap is not responsible for creating the environment entity in JAAS mongo DB, as this will be a separate step (CLI / API call).
[USER ACCEPTANCE]
[RELEASE NOTE/BLOG]
Jaas provider does not support --upload-tools or sync-tools
Jaas will not support security expolits
Work Items
Dependency tree
* Blueprints in grey have been implemented.
