Unit assignment to "unused" machines

Clint Byrum clint at ubuntu.com
Mon Dec 26 16:17:04 UTC 2011

Excerpts from William Reade's message of Mon Dec 26 04:25:16 -0800 2011:
> On Sun, 2011-12-25 at 11:44 +0100, Nick Barcet wrote:
> > One thing that we might miss when removing this assign_to_unused_machine
> > is the ability to "prestart machines" so that they are readily available
> > when we really need them.  Starting a machine takes time, specially on
> > bare metal, but anywhere else too, and I think we have been using this
> > "trick" to speed up demos.  A null charm was used to fire up "empty"
> > machines to that objective.
> So, I infer that you *have* been depending on the window between unit
> destruction and machine-trashing. ie, you've been deploying null charms
> and then, when you need a machine, destroying the null unit and adding a
> new one of the service you need, and trusting that you'll slip the new
> unit onto the machine before the PA gets round to trashing it.

I've not seen the PA terminate a machine without expliclitly saying
'juju terminte-machine'. Did something change recently?

> I personally don't think it'd be sensible for us to guarantee this
> behaviour in future -- IMO it's based on an implementation detail, and
> is already risky (...or possibly, if you've found it to be reliable,
> there's a bug that makes it so; still an implementation detail).

Right, its a workaround for the lack of pre-allocation.

> > Maybe we need to have a pre-provisioning option in 'juju deploy' to
> > allow for this behavior in a more sensible manner. For example:
> > $juju deploy --preprovision <myservice> 5
> > would do everything to start 5 machines, up to the install hook
> > (including it), but wait until a 'juju add-unit <myservice>' is called
> > to actually continue with other events?
> > 
> > This would also be useful for highly busy system that need to respond
> > quickly to change in their loads...
> Hmm... this is clearly valuable for orchestra, but how relevant is it to
> other providers? On EC2, the cost of 2 spare machines kept in reserve
> will be *exactly* the same as the cost of 2 additional machines actually
> running the service. (And unless/until we get some sort of autoscaling
> in response to load, you *still* have to manually add-unit to get the
> benefits, so it seems it would be all cost, with no actual benefits).

m2.xlarge's can often take 2 - 3 minutes to allocate. If you have a big
service that needs to transfer a lot of data to scale out (think a new
mongodb shard), knowing how long its going to take may be worth having
one machine "spun up" ready to morph into one of several services would
be rather useful I think. Not having it will just have users scratching
their heads as to why they can't do that.

> I'm wondering if there's some way we could enhance orchestra and the
> juju orchestra provider in concert, so we could support your use case
> without inflicting misfeatures on the other providers [0]; I seem to
> recall that, around UDS time, Dustin Kirkland was exploring options for
> quick reimaging of orchestra machines, but I don't remember any details.
> Does anyone know if there's been any progress on this front?

Since this feature is mostly just twiddling a few bits in ZK differently,
I think its probably not such a dangerous thing to have around.

More information about the Juju mailing list