Machine id option to deploy

[Mark Ramm]

On 04/08/2013 03:09 PM, roger peppe wrote:
> On 8 April 2013 19:05, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> wrote:
>> I'm moving the conversation from the CL:
>>
>>      https://codereview.appspot.com/8520043/
>>
>> in here, since this is bringing back into life an old discussion about
>> per-machine ad-hoc assignments.
>>
>> I'm also including juju@ in case people want to chime in with use cases.
>>
>> On 2013/04/08 17:44:24, hazmat wrote:
>>> Constraints at a service level would prevent add-unit from working
>>> properly.  Are you referencing a unit level constraint independent of the
>>> service?
>> No, I'm really saying that service-level constraints are the way to
>> handle this.  As we've discussed quite a few times before, this -to
>> flag adds local knowledge to the specific instance of the deployed
>> environment that isn't encoded on metadata anywhere. The reason why
>> such unit was put onto a given machine is gone for good.
> I think this is only a problem if units are ever recycled.
> I think we're leaning towards the approach that a unit, once
> added, lives once only and then dies forever.
>
> If that's the case, then the service's metadata doesn't
> matter so much - it's used once to work out where to put
> the unit and then is irrelevant.
>
> If we ever have some way of *moving* a unit  between
> machines, I still believe this approach can still work ok.
>
I think docker style containers open up a variety of possibilities 
because they support moving containers between machines, as well as 
visioning them --all without the overhead of virtual machines.  And I 
think we should be discussing if and how we want to integrate this kind 
of stuff into Juju "Real Soon Now."

Having containers for co-located services is more complicated to 
implement than the "hulk-smash" style of co-location contemplated in 
this CL.  And certainly isn't doable in the next couple of weeks.

But, fortunately, I don't think that force-machine stuff implemented 
here makes the work around proper co-location with containers and 
flexible constraints significantly more complex.

Obviously the two approaches would not be fully compatible, but if you 
have a "scale out" capable service it seems to me you can add a unit 
using the new constraints/container stuff and then kill the unit that 
was --force-machined and "upgrade" to the new and better world.  So, I 
don't think anybody is trapped in a bad place by this CL.

--Mark Ramm