Machine id option to deploy

[William Reade]

On Mon, 2013-04-08 at 19:16 -0300, Gustavo Niemeyer wrote:
> That's unfortunately not true, because the reason why you deployed that unit
> on that machine is lost. There are many examples of why this is the case:

It should be noted, however, that much of our existing information is
itself ephemeral. Consider a unit placed on a machine by a sophisticated
constraints system, which did so quite rightly because there was a unit
of a --prefer-near service on that machine.

Time passes; the service constraints change, and the unit of the other
service is removed; the unit is now on a machine it "shouldn't" be on,
and there's no clear way to determine why.

ISTM that under even the most sophisticated placement system (and, for
that matter, the simpler one we currently have in place), the current
placement of a given unit may not necessarily reflect its service's
current constraints; and the constraints that applied when the unit was
first assigned may themselves no longer reflect the situation of the
machine it's currently assigned to.

So, I think that we may one day need a service-rebalancing (or
reconstraining, or whatever) story, that involves moving units to
locations that better suit their services' current constraints. This
seems to me to fit nicely with the spirit of juju, in stark contrast
with the "bad" placement techniques [0] we currently have available.

But in such a world, I believe that some users would want automatic
rebalancing; and some users would only rebalance explicitly; but a few
would want to maintain their meticulously handcrafted placement
decisions regardless. And... well, maybe those users wouldn't be getting
the most out of juju, but that's actually OK. The "bad" decisions have
their place, and have their audience, and the various groups of users
can coexist quite happily [1].

That's not to say there won't be challenges, of course, but I think
we'll be equal to them. Besides, the infrastructure to allow assignment
and constraints to interact nicely, and enable the interesting behaviour
in the first place, is (I think) both more pressing and more technically
delicate.

Cheers
William

[0] "bad" means constraint-set/add-unit interleaving, and use of
    --force-machine. It's not entirely a perjorative in this context.

[1] well, so long as a keen rebalancer doesn't have to share an
    environment with a fervent handcrafter, anyway.