Machine id option to deploy

William Reade william.reade at canonical.com
Mon Apr 8 19:38:03 UTC 2013


On Mon, 2013-04-08 at 15:05 -0300, Gustavo Niemeyer wrote:
> 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.

>From my response to the CL:

There will certainly be constraints that address the use cases enabled
by this in a more sophisticated way.

This capability solves real problems and makes real users content; it
makes heavy use of existing code; and it's actually orthogonal to the
constraints/assignment mechanism (so I don't fear serious pollution from
the approach).

IMO the biggest problem is that by implementing it we demonstrate
implicit approval of the approach, and that misrepresents our intent.
So, rather than "--to", please go with "--force-machine".

The users will be happy despite the extra typing, and the option can be
clearly documented to ignore constraints: the eventual impact will be, I
hope, that people graduate from --force-machine as juju becomes more
sophisticated.

Cheers
William




More information about the Juju mailing list