Machine id option to deploy

[Mark Ramm]

On 04/08/2013 04:19 PM, Gustavo Niemeyer wrote:
> On Mon, Apr 8, 2013 at 5:09 PM, roger peppe <roger.peppe at canonical.com> wrote:
>> 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.
> That's a radically different view of the metadata for an environment.
> Units are a by-product of a configuration.. not the configuration
> itself.  If there are changes going in that break that rule, you'll
> reach a situation where orthogonal juju goals will become harder: no
> more trivial add-units, no more unit-less stack configurations, no
> more entangled expansions of units (scale A with B), etc.
This is a good point.  I think it is a very solid design goal of Juju to 
make the state data the single point of truth about the system -- if 
it's an important part of re-creating an environment it should probably 
be recorded in the state somewhere.

With that said, in this particular case: Once you --force-machine a 
unit, you will definitely get some limitations, but you don't loose all 
of good things you mention either.   You can still add-unit trivially to 
a service where the first machine was forced to be somewhere.  And if 
you are deploying things via subordinate charms you only force-unit the 
main service, so entangled-expansion still works.

But, the fact that you can't  explain the actual configuration of an 
environment from the state data does feel like a bad move -- and 
something we should be avoiding.

So, even if "force-unit" this is a nessisary short term solution, I 
think we should make sure we do not give up on the idea of an 
environment being (reasonably fully) defined by its state data.

--Mark Ramm