Machine id option to deploy

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Tue Apr 9 00:21:49 UTC 2013


On Mon, Apr 8, 2013 at 9:00 PM, Mark Ramm
<mark.ramm-christensen at canonical.com> wrote:
(...)
> I think it is very fair to say that proper placement/co-location is a
> prerequisite for that portion of the stacks feature, and that it would be
> incompatable with the "force-machine" style co-location contemplated here.

Right, you understand it properly.

>> - If the reason why it was placed in machine X is because of other
>> services in there,
>>    once you add-unit that service, it will fall onto another arbitrary
>> location because
>>    the reasoning, again, was lost.
>
> Right, it will not be "placed" properly in the future, but it still will be
> installable in a new unit (on a new machine) using the constraints which
> were recorded. This means you can't get the kind of density you might want
> while scaling out, because that information not only is not recorded, but is
> of a type that would be completely useless when adding another unit (it's
> just a machine ID.)

Right.

>> and so on.
>
>
> I think we all get that this is not an ideal solution.
(...)
> Hopefully that makes sense.  And I apologize if I'm missing something, as
> mentioned earlier I know this is a hot-button issue and I was not here for
> the previous round of discussion about it --  so I'm very aware of the
> possibility that I'm missing something important.  If so, please let me know
> so that I make sure I at least learn something!

I understand, and I won't try to influence your decision on this. I'm
just pointing something absent from the merge proposal, and that
apparently isn't even a consensus in this thread: this is poking holes
in the model of juju, with all the consequences that it has. You're a
developer and understand what this means. In code bases, many times
you sit down and are surprised that you can do something amazing very
quickly, because the pieces simply point you in the right direction.
This isn't it.. it's pointing in the misleading direction.


gustavo @ http://niemeyer.net



More information about the Juju-dev mailing list