Re: [Openstack-operators] OSAD for RHEL
On 9 July 2015 at 05:54, John Dewey 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
Sorry for the blank reply, hot keys got the better of me :) @Adam Are there any plans to create a publicly available LXC template that we could used by others and when you say "I'd leave the issues with getting blessed RHEL LXC support to Red Hat" do you imaging RedHat providing images/templates to deployers wanting to deploy on RHEL? I noticed that the LXC tooling that RedHat provides is old and while functional its not using the lxc python 3 clients or libraries. Are there any plans to repack LXC using the available py3m packages that are in RHEL7.1? In terms of pip vs rpm/deb packages are there things that RedHat will not specifically support when using pip? Is it that any use of pip would invalidate general RHEL host support? I ask because we already have all of the tooling to support a source based deployment which has the ability to do rolling upgrades and while I've only experimented with adding RedHat as base host OS (tested using RHEL 7/7.1) it shouldn't be a huge forklift to get that work done though adding in distinct code paths for deployments powered by packages would be a lot more work. As for Fedora support, I dont think thats far off once we have a base RHEL/CentOS7 system running. -- Kevin From: Adam Young 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 <mailto:ayo...@redhat.com> Sent: Thursday, July 9, 2015 11:32 AM To: Kris G. Lindgren; John Dewey Cc: openstack-operators@lists.openstack.org<mailto: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
Re: [Openstack-operators] OSAD for RHEL
-- Kevin Carter Racker, Developer, Hacker @ The Rackspace Private Cloud. From: Adam Young 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 <mailto:ayo...@redhat.com> Sent: Thursday, July 9, 2015 11:32 AM To: Kris G. Lindgren; John Dewey Cc: openstack-operators@lists.openstack.org<mailto: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 mailto:j...@dewey.ws>> Date: Wednesday, July 8, 2015 at 11:43 PM To: "Kris G. Lindgren" mailto:klindg...@godaddy.com>> Cc: Adam Young mailto:ayo...@redhat.com>>, "openstack-operators@lists.openstack.org<mailto: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 mo
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 *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 mailto:j...@dewey.ws>> Date: Wednesday, July 8, 2015 at 11:43 PM To: "Kris G. Lindgren" <mailto:klindg...@godaddy.com>> Cc: Adam Young mailto:ayo...@redhat.com>>, "openstack-operators@lists.openstack.org <mailto: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 betw
Re: [Openstack-operators] OSAD for RHEL
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. 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'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. -- Kevin Carter From: Adam Young 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 mailto:j...@dewey.ws>> Date: Wednesday, July 8, 2015 at 11:43 PM To: "Kris G. Lindgren" mailto:klindg...@godaddy.com>> Cc: Adam Young mailto:ayo...@redhat.com>>, "openstack-operators@lists.openstack.org<mailto: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. 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 p
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 mailto:j...@dewey.ws>> Date: Wednesday, July 8, 2015 at 11:43 PM To: "Kris G. Lindgren" <mailto:klindg...@godaddy.com>> Cc: Adam Young mailto:ayo...@redhat.com>>, "openstack-operators@lists.openstack.org <mailto: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. 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" <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" <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-operator
Re: [Openstack-operators] OSAD for RHEL
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 mailto:j...@dewey.ws>> Date: Wednesday, July 8, 2015 at 11:43 PM To: "Kris G. Lindgren" mailto:klindg...@godaddy.com>> Cc: Adam Young mailto:ayo...@redhat.com>>, "openstack-operators@lists.openstack.org<mailto: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. 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" 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" 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
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" (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" > > (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
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" 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" 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 ___ 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
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" > (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
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" 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
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 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
+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" 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
Re: [Openstack-operators] OSAD for RHEL
On 07/07/2015 04:38 PM, Abel Lopez 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 > I have a change out there for adding support for alternate operating systems. (along with a blueprint). It's extreemly basic right now, but here are the links. It's on hold on my side (gentoo) for lack of manpower. https://blueprints.launchpad.net/openstack-ansible/+spec/os-ansible-for-gentoo-hosts https://review.openstack.org/#/c/199316/ -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators