Open Stack

Does OSP support running each service in an LXC container as well?  What about nova-cells? How does it handle people who need to carry local changes?  What is the upgrade path like with OSP?

Asking, because in Philly the general consensus, I fel,t was people want to move away from the current system level package stuff and move towards: venv's, "lightweight packages", containers.  The only reason that was brought up to keep packages around was to solve the non-python lib stuff and using a depsolver (yum/apt) that doesn't suck (pip).  So I am pretty sure my wants are inline with what other people in the community are either already doing or moving towards.
___________________________________________

Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.


From: John Dewey <john at dewey.ws<mailto:john at dewey.ws>>
Date: Wednesday, July 8, 2015 at 11:43 PM
To: "Kris G. Lindgren" <klindgren at godaddy.com<mailto:klindgren at godaddy.com>>
Cc: Adam Young <ayoung at redhat.com<mailto:ayoung at redhat.com>>, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] OSAD for RHEL

This would not be acceptable for those running OSP.


On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote:

I should be more clear. My current thought is to have a venv packaged
inside an rpm - so the rpm includes the needed init scripts, ensures the
required system level binaries are installed, adds the users - ect ect.
But would be a single deployable autonomous unit. Also, have a versioning
schema to roll forward and back between venvs for quick update/rollback.
We are already working on doing something similar to this to run kilo on
cent6 boxen, until we can finish revving the remaining parts of the fleet
to cent7.

My desire is to move away from using system level python & openstack
packages, so that I can possibly run mismatched versions if I need to. We
had a need to run kilo ceilometer and juno neutron/nova on a single
server. The conflicting python requirements between those made that task
impossible. In general I want to get away from treating Openstack as a
single system that everything needs to be upgraded in lock step (packages
force you into this). I want to move to being able to upgrade say
oslo.messaging to a newer version on just say nova on my control plane
servers. Or upgrade nova to kilo while keeping the rest of the system
(neutron) on juno. Unless I run each service in a vm/container or on a
physical piece of hardware that is pretty much impossible to do with
packages - outside of placing everything inside venv's.

However, it is my understanding that OSAD already builds its own
python-wheels and runs those inside lxc containers. So I don¹t really
follow what good throwing those into an rpm would really do?
____________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.


On 7/8/15, 10:33 PM, "Adam Young" <ayoung at redhat.com<mailto:ayoung at redhat.com>> wrote:

On 07/07/2015 05:55 PM, Kris G. Lindgren wrote:
+1 on RHEL support. I have some interest in moving away from packages
and
am interested in the OSAD tooling as well.

I would not recommend an approach targetting RHEL that does not use
packages.

OSAD support for RHEL using packages would be an outstanding tool.

Which way are you planning on taking it?

____________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.







On 7/7/15, 3:38 PM, "Abel Lopez" <alopgeek at gmail.com<mailto:alopgeek at gmail.com>> wrote:

Hey everyone,
I've started looking at osad, and I like much of the direction it
takes.
I'm pretty interested in developing it to run on RHEL, I just wanted to
check if anyone would be -2 opposed to that before I spend cycles on
it.

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150709/ae506d87/attachment.html>