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

[Gustavo Niemeyer]

> 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.

It seems to make sense, but I'd prefer to avoid diving into details of
how required relations would work or affect the system at this time,
given that we have enough on the table already and won't be able to
work on it anytime soon.

> 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.

That's what's already in the specification, and what we agreed at UDS, right?

> 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.

That sounds like a great idea. +1

As a minor, the relation scope is the container, so "container" is
probably a better term for "scope:" within a relation.

> 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.

Maybe, but I'd prefer to discuss that when the time comes.

> 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.
i> A service with an optional contained relation:
>    This is an odd case and we might want to qualify contained

The mix being implied here doesn't sound right. The behavior of
subordinate services is peculiar and consistent independently from
whether a relation is required or not. In either case, the subordinate
service is only deployed when a relation is added, and even _after_ it
is deployed, adding a new relation to another service that does not
live within the same container (primary or not) will again re-deploy
it. Required relations will not behave like that, no matter how we
define them to be.

> Summary of Changes
(...)

We need a detailed list of changes to public APIs, command lines,
zookeeper, etc, that are necessary to implement subordinate services,
as we've agreed. Right now there are multiple branches _in review_
implementing those changes even though we didn't discuss or agree to
them, which means you'll have to go back and fix the branch, and
possibly change the approach entirely to satisfy the public API
review. This is making things much harder than they have to be.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.