Machine id option to deploy

[Gustavo Niemeyer]

On Mon, Apr 8, 2013 at 6:26 PM, Tim Penhey <tim.penhey at canonical.com> wrote:
> Gustavo, I'm having difficulty trying to work out what your issue is here.
>
> Where I think we are in agreement is the following:
>  * Users want to be able to place multiple units on a machine, and we
> need to provide a way to do that.
>
> Is the issue in how we define the placement?
>
> To me, constraints are about provisioning an appropriate machine onto
> which the unit will be placed.  However using a --force-machine type
> parameter, the user is saying "I know better" and we should do that.

To me constraints is about defining placement. Place this unit onto a
machine with X amounts of memory, X amounts of CPU, a fast disk, a
machine that is not running anything else that is taking a lot of CPU,
a machine that is running memcached, and so on. This is a continuum.

> I don't see this as a way to stop a trivial add-units from working.

Why is unit X running in machine M?  With "juju deploy -to N", you
know that, the code doesn't. As long as this is the case, the system
is blocked from doing anything interesting with that information.

> If we tried to enforce a unit level constraint to say "install on
> machine X", then this would have more of an impact in trying to add more
> units where it would try to duplicate the unit constraints.

The point is exactly to not have "install U on M", but to have the
real *intention* of the action encoded onto the system, so that this
intention can be preserved in future actions, and whenever this
environment is deployed again in the future, even if it's a completely
different provider, and it makes no sense to be talking about machine
M anymore.


gustavo @ http://niemeyer.net