Machine id option to deploy

[Gustavo Niemeyer]

On Mon, Apr 8, 2013 at 5:09 PM, roger peppe <roger.peppe at canonical.com> wrote:
> I think this is only a problem if units are ever recycled.
> I think we're leaning towards the approach that a unit, once
> added, lives once only and then dies forever.
>
> If that's the case, then the service's metadata doesn't
> matter so much - it's used once to work out where to put
> the unit and then is irrelevant.

That's a radically different view of the metadata for an environment.
Units are a by-product of a configuration.. not the configuration
itself.  If there are changes going in that break that rule, you'll
reach a situation where orthogonal juju goals will become harder: no
more trivial add-units, no more unit-less stack configurations, no
more entangled expansions of units (scale A with B), etc.

> I feel that deploy-to is possibly a first step towards placement, which
> I think can be seen as largely orthogonal to constraints,
> although naturally they will interact, and we will need to decide
> how they should do so.

Constraints are *exactly* that: a way to determine placement, and they
are a mechanism that enables us to continue expanding in all those
areas.

Of course, one can create as many features to solve the same problem
as one wants, but that doesn't mean it's a good idea to do so.

> I see constraints as choosing the suitability of a machine
> *in isolation* (that is, we can judge whether a machine satisfies
> a constraint by looking at that one machine only), whereas placement
> will have to deal with many possible machines (that is, it's potentially
> a function of all the available machines and the network and
> possibly physical topology too).

I'm missing the reasoning for these statements. Constraints can deal
with as many machines as needed to implement the constraints we want
to implement. There can be a constraint named named
with(myotherservice), for example.

> I believe constraints and placement are quite different problems,
> with different algorithmic complexities,  and trying to pretend we can
> implement placement with constraints
> will make life harder than we need it to be.

Again, missing the "because ..." part.

As I see it, we have a non-trivial feature called "constraints" that
is supposed to solve the placement of services and units. That's no
need to have another feature of additional complexity that we call
something else to solve the same problem.


gustavo @ http://niemeyer.net