Open Stack

On Fri, Sep 26, 2014 at 2:01 PM, Angus Lees <gus at inodes.org> 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.
> 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.
>
> 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".
>

Do you have a minimal template that shows what you are trying to do?
(just to demonstrate the circular dependency).


> - 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'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.
>

Gus we are working at improving standalone (Steven Baker has some patch out
for this).


>
> (I'm sure this can be fixed, if it wasn't already just me using it wrong
> in the
> first place.)
>
> - As far as I know, nothing in a heat/loadbalancer/nova stack will actually
> reschedule jobs away from a failed machine.  There's also no lazy
>

This might go part of the way there, the other part of it is detecting the
failed machine
and some how marking it as failed.
 https://review.openstack.org/#/c/105907/

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.
>
>
> So: I think there's some things to learn from the kubernetes approach,
> which
> is why I'm trying to gain more experience with it.  I know I'm learning
> more
> about the various OpenStack components along the way too ;)
>

This is valuable feedback, we need to improve Heat to make these use case
work better.
But I also don't believe there is one tool for all jobs, so see little harm
in trying
other things out too.

Thanks
Angus


>
> --
>  - Gus
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140926/ca1f5615/attachment.html>