Re: [Openstack-operators] OSAD for RHEL

2015-07-21 Thread Jesse Pretorius
On 9 July 2015 at 05:54, John Dewey j...@dewey.ws wrote:

 IMO - registering the systems with subscription manager or pointing to in
 house yum repos should be included as part of system bootstrapping, and not
 a part of OSAD.  OSAD should simply install the specific packages for the
 alternate distro.


Agreed, trying to cater for all things that everyone wants in their
bootstrapping is a rabbit hole best not ventured into as it'll bloat the
project considerably.


 Might also be a good time to abstract the system packaging module into a
 higher level one which handles `yum` or `apt` behind the scenes.We can
 then manage the list of packages per distro[1].  Throwing this out as an
 idea vs copy-paste every apt with a yum section.


Ansible appears to be building this abstraction already for v2 [1], but has
a means to do this in an alternative way [2].

[1]
https://github.com/ansible/ansible-modules-core/blob/devel/packaging/os/package.py
[2] http://serverfault.com/a/697736
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] OSAD for RHEL

2015-07-14 Thread Adam Young

On 07/10/2015 02:25 PM, Kevin Carter wrote:


To be clear the present OSAD project really has no intention to bring 
package based installations of OpenStack. We'd certainly not reject 
the idea and wouldn't mind having an implementation spec for it 
but all of our current tooling and design principles have been based 
on the fact that we've move away from distro packages and on to 
upstream source as it pertains to OpenStack. The system as it stands 
today creates an internal repository of built wheels for your 
environment and all of the OpenStack services are installed within LXC 
containers, where possible and it makes sense. The installation of 
these bits comes from the internal wheel repository and uses pip and 
all of the pre / post config happens within the Ansible playbooks.




I understand your frustration with the packaging approach.  For a first 
approximation, getting the code for OpenStack/Python operations out of 
Pip makes sense.  Ideally, we would be able to support both approaches.  
Red Hat would not support a pip based install, but I am sure some Centos 
base users would be happy with pip.


We had the same general discussion around devstack.



One issue that will become a problem, for users of RedHat 
specifically, is the fact that RedHat has no LXC container templates 
(at least none that are publicly available) and even if someone were 
to make an official RedHat container template there'd be issues with 
the containers being able to connect to the satellite servers as well 
as other potential license problems.




I'd leave the issues with getting blessed RHEL LXC support to Red Hat.  
Making something that works for CentOS with publically available LXC 
containers there would be more what I expect from OSAD upstream.


What about Fedora support?  It seems to me that we would be far more 
likely to have something supportable with Fedora that could then be 
backported to CentOS?




I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 
containers and things seem to work OK but I'd not say that I have 
really put a lot of effort into it. That said, if its something that 
you'd all like to work on I'd be happy to help out to make it all go.




Sounds good.  I'll give it a try after the Keystone Midcycle.



--

Kevin Carter

*From:* Adam Young ayo...@redhat.com
*Sent:* Thursday, July 9, 2015 11:32 AM
*To:* Kris G. Lindgren; John Dewey
*Cc:* openstack-operators@lists.openstack.org
*Subject:* Re: [Openstack-operators] OSAD for RHEL
On 07/09/2015 02:16 AM, Kris G. Lindgren wrote:
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?


So, ignoring the Hypervisor for the moment, there is no reason that 
the rest of the controllers can't run in separate Containers.  I think 
a container based deployment would be fantastic.


venv is not really sufficient, as the system level binaries can still 
conflict (MysQL and LDAP both require system libraries for Keystone, 
for example)


From an Ansible perspective;  we need to  be able to share the HTTPD 
instance for Keystone and Apache, and getting that right will solve 
most of the issues deploying in a secure manner. Putting Them on 
separate hosts or containers should be a degenerate case, and thus be 
supported, too.









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 j...@dewey.ws mailto:j...@dewey.ws
Date: Wednesday, July 8, 2015 at 11:43 PM
To: Kris G. Lindgren klindg...@godaddy.com 
mailto:klindg...@godaddy.com
Cc: Adam Young ayo...@redhat.com mailto:ayo...@redhat.com, 
openstack-operators@lists.openstack.org 
mailto:openstack-operators@lists.openstack.org 
openstack-operators@lists.openstack.org 
mailto:openstack-operators@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

Re: [Openstack-operators] OSAD for RHEL

2015-07-14 Thread Kevin Carter
​


--

Kevin Carter
Racker, Developer, Hacker @ The Rackspace Private Cloud.

From: Adam Young ayo...@redhat.com
Sent: Tuesday, July 14, 2015 10:59 AM
To: Kevin Carter; Kris G. Lindgren; John Dewey
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] OSAD for RHEL

On 07/10/2015 02:25 PM, Kevin Carter wrote:

To be clear the present OSAD project really has no intention to bring package 
based installations of OpenStack. We'd certainly not reject the idea and 
wouldn't mind having an implementation spec for it but all of our current 
tooling and design principles have been based on the fact that we've move away 
from distro packages and on to upstream source as it pertains to OpenStack. The 
system as it stands today creates an internal repository of built wheels for 
your environment and all of the OpenStack services are installed within LXC 
containers, where possible and it makes sense. The installation of these bits 
comes from the internal wheel repository and uses pip and all of the pre / post 
config happens within the Ansible playbooks.

I understand your frustration with the packaging approach.  For a first 
approximation, getting the code for OpenStack/Python operations out of Pip 
makes sense.  Ideally, we would be able to support both approaches.  Red Hat 
would not support a pip based install, but I am sure some Centos base users 
would be happy with pip.

We had the same general discussion around devstack.



One issue that will become a problem, for users of RedHat specifically, is the 
fact that RedHat has no LXC container templates (at least none that are 
publicly available) and even if someone were to make an official RedHat 
container template there'd be issues with the containers being able to connect 
to the satellite servers as well as other potential license problems.

I'd leave the issues with getting blessed RHEL LXC support to Red Hat.  Making 
something that works for CentOS with publically available LXC containers there 
would be more what I expect from OSAD upstream.

What about Fedora support?  It seems to me that we would be far more likely to 
have something supportable with Fedora that could then be backported to CentOS?



I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 containers 
and things seem to work OK but I'd not say that I have really put a lot of 
effort into it. That said, if its something that you'd all like to work on I'd 
be happy to help out to make it all go.

Sounds good.  I'll give it a try after the Keystone Midcycle.



--

Kevin Carter

From: Adam Young ayo...@redhat.commailto:ayo...@redhat.com
Sent: Thursday, July 9, 2015 11:32 AM
To: Kris G. Lindgren; John Dewey
Cc: 
openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] OSAD for RHEL

On 07/09/2015 02:16 AM, Kris G. Lindgren wrote:
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?

So, ignoring the Hypervisor for the moment, there is no reason that the rest of 
the controllers can't run in separate Containers.  I think a container based 
deployment would be fantastic.

venv is not really sufficient, as the system level binaries can still conflict 
(MysQL and LDAP both require system libraries for Keystone, for example)

From an Ansible perspective;  we need to  be able to share the HTTPD instance 
for Keystone and Apache, and getting that right will solve most of the issues 
deploying in a secure manner.  Putting Them on separate hosts or containers 
should be a degenerate case, and thus be supported, too.







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 j...@dewey.wsmailto:j...@dewey.ws
Date: Wednesday, July 8, 2015 at 11:43 PM
To: Kris G. Lindgren klindg...@godaddy.commailto:klindg...@godaddy.com
Cc: Adam Young ayo...@redhat.commailto:ayo...@redhat.com, 
openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org
 
openstack-operators@lists.openstack.orgmailto:openstack-operators@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

Re: [Openstack-operators] OSAD for RHEL

2015-07-09 Thread Kris G. Lindgren
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 j...@dewey.wsmailto:j...@dewey.ws
Date: Wednesday, July 8, 2015 at 11:43 PM
To: Kris G. Lindgren klindg...@godaddy.commailto:klindg...@godaddy.com
Cc: Adam Young ayo...@redhat.commailto:ayo...@redhat.com, 
openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org
 
openstack-operators@lists.openstack.orgmailto:openstack-operators@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 ayo...@redhat.commailto:ayo...@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 
alopg...@gmail.commailto:alopg...@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@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.orgmailto:OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] OSAD for RHEL

2015-07-08 Thread Adam Young

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 alopg...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] OSAD for RHEL

2015-07-08 Thread John Dewey


On Wednesday, July 8, 2015 at 9:33 PM, Adam Young 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?
IMO - registering the systems with subscription manager or pointing to in house 
yum repos should be included as part of system bootstrapping, and not a part of 
OSAD.  OSAD should simply install the specific packages for the alternate 
distro.

Might also be a good time to abstract the system packaging module into a higher 
level one which handles `yum` or `apt` behind the scenes.We can then manage 
the list of packages per distro[1].  Throwing this out as an idea vs copy-paste 
every apt with a yum section.

[1] https://gist.github.com/retr0h/dd4cbd27829a3095f37a
  
  
  Kris Lindgren
  Senior Linux Systems Engineer
  GoDaddy, LLC.
  
  
  
  
  
  
  
  On 7/7/15, 3:38 PM, Abel Lopez alopg...@gmail.com 
  (mailto:alopg...@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@lists.openstack.org 
  (mailto:OpenStack-operators@lists.openstack.org)
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
  
 
 
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org 
 (mailto:OpenStack-operators@lists.openstack.org)
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] OSAD for RHEL

2015-07-08 Thread Kevin Carter
No opposition at all for adding in additional OS support. IMO it would be great 
in terms of support-ability and deployment perspectives. If you've not already 
checkout the #openstack-ansible channel and ping us if you have any questions.  

--

Kevin Carter
IRC: cloudnull


From: Abel Lopez alopg...@gmail.com
Sent: Tuesday, July 7, 2015 4:38 PM
To: openstack-oper.
Subject: [Openstack-operators] OSAD for RHEL

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] OSAD for RHEL

2015-07-08 Thread John Dewey
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 ayo...@redhat.com 
 (mailto:ayo...@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 alopg...@gmail.com 
   (mailto:alopg...@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@lists.openstack.org 
   (mailto:OpenStack-operators@lists.openstack.org)
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

   
   
   
  ___
  OpenStack-operators mailing list
  OpenStack-operators@lists.openstack.org 
  (mailto:OpenStack-operators@lists.openstack.org)
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
   
  
  
  
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org 
 (mailto:OpenStack-operators@lists.openstack.org)
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
  
  


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Re: [Openstack-operators] OSAD for RHEL

2015-07-07 Thread Kris G. Lindgren
+1 on RHEL support.  I have some interest in moving away from packages and
am interested in the OSAD tooling as well.

 
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.







On 7/7/15, 3:38 PM, Abel Lopez alopg...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators