Machine id option to deploy

Kapil Thangavelu kapil.thangavelu at canonical.com
Tue Apr 9 00:35:22 UTC 2013


On Mon, Apr 8, 2013 at 8:21 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> 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.
>
>
co-location is distinct from the real world use case that users want to
achieve via force-machine. that use case is not a request for co-location
its about density for cost. its not a request for co-located units as
additional units to services are deployed. Its not clear though that
service level constraints properly capture this except as a transient state
with the added value that its recorded on the unit level, which is where
william was going i think with the disconnect of historical constraints
with current constraints. In the same way that such historical information
is effectively wasted, because its not captured except at individual
resource level, its not clear why its so important to capture the
historical value of force-machine. The current constraints of the service
are the state of the user intent and the model.

cheers,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130408/dc305540/attachment.html>


More information about the Juju mailing list