Open Stack

On 26/09/14 00:01, Angus Lees wrote:
> On Thu, 25 Sep 2014 04:01:38 PM Fox, Kevin M wrote:
>> Doesn't nova with a docker driver and heat autoscaling handle case 2 and 3
>> for control jobs? Has anyone tried yet?
>
> For reference, the cases were:
>
>> - Something to deploy the code (docker / distro packages / pip install /
>> etc)
>> - Something to choose where to deploy
>> - Something to respond to machine outages / autoscaling and re-deploy as
>> necessary
>
>
> I tried for a while, yes.  The problems I ran into (and I'd be interested to
> know if there are solutions to these):
>
> - I'm trying to deploy into VMs on rackspace public cloud (just because that's
> what I have).  This means I can't use the nova docker driver, without
> constructing an entire self-contained openstack undercloud first.
>
> - heat+cloud-init (afaics) can't deal with circular dependencies (like nova<-
>> neutron) since the machines need to exist first before you can refer to their
> IPs.

I suspect that this now can actually be done with Software Deployment 
resources (which separate the creation of the actual servers from the 
inputs to the software configured on them, thus breaking the circular 
dependency).

>  From what I can see, TripleO gets around this by always scheduling them on the
> same machine and just using the known local IP.  Other installs declare fixed
> IPs up front - on rackspace I can't do that (easily).
> I can't use loadbalancers via heat for this because the loadbalancers need to
> know the backend node addresses, which means the nodes have to exist first and
> you're back to a circular dependency.

Again, Sofware Deployments should resolve that.

> For comparision, with kubernetes you declare the loadbalancer-equivalents
> (services) up front with a search expression for the backends.  In a second
> pass you create the backends (pods) which can refer to any of the loadbalanced
> endpoints.  The loadbalancers then reconfigure themselves on the fly to find the
> new backends.  You _can_ do a similar lazy-loadbalancer-reconfig thing with
> openstack too, but not with heat and not just "out of the box".
>
> - My experiences using heat for anything complex have been extremely
> frustrating.  The version on rackspace public cloud is ancient and limited,
> and quite easy to get into a state where the only fix is to destroy the entire
> stack and recreate it.

I don't know that Rackspace's version is "ancient" (afaik they chase 
trunk, so it's probably more recent than even Icehouse), but the Juno 
release should be much better on this front.

> I'm sure these are fixed in newer versions of heat, but
> last time I tried I was unable to run it standalone against an arms-length
> keystone because some of the recursive heat callbacks became confused about
> which auth token to use.
>
> (I'm sure this can be fixed, if it wasn't already just me using it wrong in the
> first place.)

Yeah, Heat only really supports a fairly limited subset of functionality 
in standalone mode. (I mean, it's probably the majority, but it's 
everything except the _really_ useful parts ;)

We're hearing more from users that they care about this, and by happy 
coincidence making technical changes from which a true standalone mode 
should fall out.

> - As far as I know, nothing in a heat/loadbalancer/nova stack will actually
> reschedule jobs away from a failed machine.

That's correct, although it is something we have already started looking 
at and plan to implement over the next few cycles.

> There's also no lazy
> discovery/nameservice mechanism, so updating IP address declarations in cloud-
> configs tend to ripple through the heat config and cause all sorts of
> VMs/containers to be reinstalled without any sort of throttling or rolling
> update.

Yes, I can't wait for Designate :)

cheers,
Zane.