Proposal: Changes to deployment of services and minor changes to the subordinates spec

[Benjamin Saller]

TL;DR:: Service will change from deployment at declaration (juju
deploy ...) to the first point when their requirements are satisfied.

There are a number of features we have intended to support for
sometime and new features related to ongoing work that would benefit
from a change to how deployment is made. This proposal should result
in a similar end-state given a set of existing juju command, its only
the intermediate steps that will be altered.  Given our expectations
around stacks its quite likely that the user of the system when that
feature lands would observe no change at all.


1. Required Relationships
    When a charm has one or more required relationships it will not be
deployed until such time as those relationships have been satisfied.

2. Subordinate services
    Deploying a subordinate service by itself doesn't include enough
information to place it anywhere, its not until relationships are
added that we can know which containers (and principal services) each
service unit of the subordinate should be bound.



Subordinate relations are currently defined with a subordinate: true
flag on a  given interface. This almost, but not quite, captures what
we actually want to express. As an illustration its possible to
imaging 2 subordinate services of a given principal service which
themselves have a relationship which is only valid in the context of
the container of the principal service. This would be the same
expression of a relationship as is used for subordinate to their
principal service. As a result of this (and because it allows us more
flexibility down the road) I'm suggesting that interfaces get a
'scope'  argument defaulting to 'global' which models relationships as
we see them today, and 'contained' for what we've been calling
subordinate relations. (Its also possible to imaging other scopes down
the road dealing with things like cross AZ relations). By joining a
'contained' relationship between the two subordinates in the above
example they can expect only to talk to units in their own containers.

Using this the rules for when we do deployment should make sense, here
are the cases as I see them.

A service with required relationships:
    Deployed when all required relations are satisfied.

A service with only optional (global scoped) relationships:
   Deployed on the call to juju-deploy.

A service with a required contained relation:
    Both the required relation and the principal side of the relation
must be deployed before a subordinate is deployed.

A service with an optional contained relation:
    This is an odd case and we might want to qualify contained
relations by saying they will always fallback to the implicit
juju-info relation and can be treated as always required. This is how
the current codebase handles it anyway.

Slightly more complex examples exist but the rules are the same. For
example a logging subordinate service (with a required contained
relation) might also have a required relationship to a master logging
service outside of the container. I this case the subordinate service
will not be deployed until the principal has been deployed, the
logging-master has been deployed and both required relationships are
satisfied.

Summary of Changes

- Implicit Interfaces
- Required Interfaces
- Modifications to deploy, add/remove unit, add/del relation and unit
agents to check on topology
  change if requirement sets for deployment are satisfied.
- Notify users at interaction points (deploy, add-relation) when we
can't do deployments yet by listing pending dependencies.


This does represent a change to the intermediate steps taken by the
system, but the end state at a series of commands should be the same.