Machine id option to deploy

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Mon Apr 8 18:05:50 UTC 2013


I'm moving the conversation from the CL:

    https://codereview.appspot.com/8520043/

in here, since this is bringing back into life an old discussion about
per-machine ad-hoc assignments.

I'm also including juju@ in case people want to chime in with use cases.

On 2013/04/08 17:44:24, hazmat wrote:
> Constraints at a service level would prevent add-unit from working
> properly.  Are you referencing a unit level constraint independent of the
> service?

No, I'm really saying that service-level constraints are the way to
handle this.  As we've discussed quite a few times before, this -to
flag adds local knowledge to the specific instance of the deployed
environment that isn't encoded on metadata anywhere. The reason why
such unit was put onto a given machine is gone for good.

It's also far from obvious why it would be a good idea to manually
assign a unit to an individual machine id, when we have constraints
being able to be specified in the exact same command line, and with
the exact same goals of defining placement suitability. Hint: these
two options *conflict in their meaning*. It's a huge special case that
may easily bite, and does little good in comparison to the proper ways
of handling this.

We've also discussed before the alternatives: not only constraints
enable fine-tuning where things should be deployed, but we can also
have new constraints that define affinity between services, so that we
can determine what should be deployed with what. Some day these
constraints can also be richer, defining that certain services
shouldn't be deployed together because they both need significant CPU,
or memory, or disk.

William is heading the project technically now, so whatever he decides
takes precedence over my ramblings, but this is a detour in terms of
how the principles of juju were put in place and meant to work.

> fwiw I did do a preimpl call with william.

FWIW, I suggest sending that kind of decision to the list, so that
other members of the team (not me) may have a chance to influence the
decision and learn from the background of your thinking as well.


gustavo @ http://niemeyer.net



More information about the Juju mailing list