Machine id option to deploy

[Gustavo Niemeyer]

force-machine has no historical value, and that's itself the issue. The
real value is in *why* said machine was selected, for all the reasons given.

Also, colocation for density is still colocation. Strikes me as odd to draw
a line there.
On Apr 8, 2013 9:35 PM, "Kapil Thangavelu" <kapil.thangavelu at canonical.com>
wrote:

>
>
>
> 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/3c4e15a0/attachment.html>