Add Machine to uniter API

Add Machine to uniter API

This change adds the Machine entity
to the uniter API, to support coming
changes to the uniter. The uniter
will become responsible for watching
machine addresses and updating
relations.

Also, drive-by consolidation of Watch
methods into api/common.

https://code.launchpad.net/~axwalk/juju-core/api-uniter-machine/+merge/221332

(do not edit description out of merge proposal)

[axw, 2014-05-29 08:12:50]

Please take a look.

[fwereade, 2014-05-29 09:28:25]

First impressions from description: we don't want to expose it at this level of
abstraction. I think, if anything, that it needs to be on RelationUnit -- you
watch for changes in the address you're expected to expose in the current
relation. (And this is somewhat convenient, because it's then relatively easy to
get that information where it needs to go, ie into the relation.HookQueue.

The question of public addresses remains, though. I remain at least halfway
convinced that [having a relation with another service] and [being exposed on a
public network] are fundamentally the same, and should be modelled in the same
way: ie exposure on network X is presented to the uniter as near-as-dammit Just
Another Relation, with an address specific to some network, in which it's
expected to work exactly the same way re "private-address" in relation settings
-- and juju can then interpret and show it to the user.

But there's then some potential overlap with the "juju info" idea, and it
probably needs more thought: in particular, the map[string]string we have for
relation data is potentially problematic as user output in the same way that
config's restrictions make it suboptimal for input. Would you be free for a chat
about this tomorrow?

[axw, 2014-05-30 02:15:58]

On 2014/05/29 09:28:25, fwereade wrote:
> First impressions from description: we don't want to expose it at this level
of
> abstraction. I think, if anything, that it needs to be on RelationUnit -- you
> watch for changes in the address you're expected to expose in the current
> relation. (And this is somewhat convenient, because it's then relatively easy
to
> get that information where it needs to go, ie into the relation.HookQueue.

Correct me if I'm full of it, but the problem I see with that is that the
relation unit does not exist in state until it enters scope. Thus,
relation-address-changed cannot be fired prior to entering scope.

Alternatively, I suppose we could have another document for each unit which maps
relations to addresses. We'd have a new worker for each unit (machine?) that
watches machine addresses, filters them by network, and creates an entry for
each relation in the doc.

> The question of public addresses remains, though. I remain at least halfway
> convinced that [having a relation with another service] and [being exposed on
a
> public network] are fundamentally the same, and should be modelled in the same
> way: ie exposure on network X is presented to the uniter as near-as-dammit
Just
> Another Relation, with an address specific to some network, in which it's
> expected to work exactly the same way re "private-address" in relation
settings
> -- and juju can then interpret and show it to the user.
> 
> But there's then some potential overlap with the "juju info" idea, and it
> probably needs more thought: in particular, the map[string]string we have for
> relation data is potentially problematic as user output in the same way that
> config's restrictions make it suboptimal for input. Would you be free for a
chat
> about this tomorrow?

Yes, let's please have another chat in your morning, if you're around.

[fwereade, 2014-05-30 07:36:07]

On 2014/05/30 02:15:58, axw wrote:
> On 2014/05/29 09:28:25, fwereade wrote:
> > First impressions from description: we don't want to expose it at this level
> of
> > abstraction. I think, if anything, that it needs to be on RelationUnit --
you
> > watch for changes in the address you're expected to expose in the current
> > relation. (And this is somewhat convenient, because it's then relatively
easy
> to
> > get that information where it needs to go, ie into the relation.HookQueue.
> 
> Correct me if I'm full of it, but the problem I see with that is that the
> relation unit does not exist in state until it enters scope. Thus,
> relation-address-changed cannot be fired prior to entering scope.

The relation unit isn't a document, it's just a convenient abstraction that
combines a unit reference with a particular relation that unit's service is in
(and, given how horrible its name is *and* its evident capacity for generating
confusion, it's a sign that there's probably a clearer one struggling to get out
somehow). But units enter relation scope by calling a method on a RelationUnit,
and I'm suggesting that they should get/watch their address by calling a method
on RU as well.

WRT firing it before we enter scope: I think it *could* be done, but the
fiddliness is probably not worth it, and we can simply:

* enter scope, poking the address into relation settings as usual
* fire relation-created
* fire relation-address-changed

...and relax. This fits reasonably well with the model for remote relation
settings: when you handle -joined, you already have access to its settings, and
the immediately following -changed does not necessarily represent a real change.
It's about trying to let authors keep the event handling orthogonal: there's no
inherent contradiction in letting people see data they haven't yet been notified
about, it's just a bit weird and potentially confusing (so maybe not ideal, but
not intrinsically broken).

> Alternatively, I suppose we could have another document for each unit which
maps
> relations to addresses. We'd have a new worker for each unit (machine?) that
> watches machine addresses, filters them by network, and creates an entry for
> each relation in the doc.

Well, I think we *do* need a new worker, on the machine, that somehow keeps a
watch on the machine's addresses and updates them in state -- as pointed out in
one of the motivating bugs, the 15-minute cadence of instanceupdater is a bit
rubbish really. But I think we can do a bit better in terms of implementation
(prepare to observe the waving of the hands, to some degree):

As it is, we have Machine.SetAddresses and .SetMachineAddresses; this is because
neither of these (ie the info from the provider, and the info from the machine
itself) is quite sufficient to tell us everything we need to know in all
possible providers. So we track all the information we have, in the hope that we
can somehow synthesize it into a clear and unambiguous set of addresses on
particular networks. I would suggest that, at any time either of these is set,
we either execute or queue some code that inspects both sets of data,
consolidates them as much as possible, and determines a list of fully-specified
instance.Address~s. These addresses can then be indvidually written into a new
machineaddresses collection, keyed on m#<machine-id>#n#<network-id>. (I'm
imagining one address per network per machine: this in particular requires
cleverness in the context of container addressability, because when we add an
address for a container the provider only knows that the top-level machine has a
new address. This is where we need dimitern/mgz's input, tey are much more au
fait with the details there than I am.)

Then, from the POV of RU, it's easy. We have a unit we can use to look up the
machine; we have a relation we can use to look up the network (and today it's
even easier, because all we have is the flat internal network *anyway*, but IMO
we should still do it properly); and with those two we can construct the key to
the machinenetworks doc that we can read/watch. (One maybe-nice thing about this
is that we can, and *maybe* should, change EnterScope such that it no longer
takes args; the RU can be responsible for figuring out the initial
private-address on its own. And that'd reduce the ugliness of one particular
nexus of weird uniter code...)



> > The question of public addresses remains, though. I remain at least halfway
> > convinced that [having a relation with another service] and [being exposed
on
> a
> > public network] are fundamentally the same, and should be modelled in the
same
> > way: ie exposure on network X is presented to the uniter as near-as-dammit
> Just
> > Another Relation, with an address specific to some network, in which it's
> > expected to work exactly the same way re "private-address" in relation
> settings
> > -- and juju can then interpret and show it to the user.
> > 
> > But there's then some potential overlap with the "juju info" idea, and it
> > probably needs more thought: in particular, the map[string]string we have
for
> > relation data is potentially problematic as user output in the same way that
> > config's restrictions make it suboptimal for input. Would you be free for a
> chat
> > about this tomorrow?
> 
> Yes, let's please have another chat in your morning, if you're around.