Re: [Openstack-operators] [puppet] module dependencies and different openstack versions
Hi, I have same feedback as Robert, we use the openstack/puppet-[project] modules and they are quiet independent. We have our own module that integrates those modules as we need and we even deploy each service on different nodes so we need them to be independent and we could achieve it. Kind regards, Cynthia Lopes do Sacramento 2015-07-28 9:43 GMT+02:00 Van Leeuwen, Robert rovanleeu...@ebay.com: We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don¹t want it to mess with keystone (for one we don¹t support setting endpoints via an API) but also we don¹t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we¹ll may never move to the official keystone puppet module. The neutron module pulls in the vswitch module but we don¹t use vswitch and it doesn¹t seem to be a requirement of the module so maybe doesn¹t need to be in metadata dependencies? It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? Hi, In my experience (I am setting up a new environment) the modules can be used ³stand-alone². It is the OpenStack module itself that comes with a combined server example. The separate modules (nova, glance, etc) are very configurable and don¹t necessarily need to setup e.g. keystone. From the OpenStack module you can modify the profiles and it will not do the keystone stuff / database, etc.. E.g. Remove the ³:nova::keystone::auth² part in the nova profile. We use r10k to select which versions to install and it should be trivial to use Juno / Kilo stuff together (have not tested this myself). Regarding the vswich module I *guess* that that is regulated by the following: neutron/manifests/agents/ml2/ovs.pp: if $::neutron::params::ovs_agent_package So unsetting that variable should not pull the package. Cheers, Robert van Leeuwen ___ 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] [puppet] module dependencies and different openstack versions
We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don¹t want it to mess with keystone (for one we don¹t support setting endpoints via an API) but also we don¹t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we¹ll may never move to the official keystone puppet module. The neutron module pulls in the vswitch module but we don¹t use vswitch and it doesn¹t seem to be a requirement of the module so maybe doesn¹t need to be in metadata dependencies? It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? Hi, In my experience (I am setting up a new environment) the modules can be used ³stand-alone². It is the OpenStack module itself that comes with a combined server example. The separate modules (nova, glance, etc) are very configurable and don¹t necessarily need to setup e.g. keystone. From the OpenStack module you can modify the profiles and it will not do the keystone stuff / database, etc.. E.g. Remove the ³:nova::keystone::auth² part in the nova profile. We use r10k to select which versions to install and it should be trivial to use Juno / Kilo stuff together (have not tested this myself). Regarding the vswich module I *guess* that that is regulated by the following: neutron/manifests/agents/ml2/ovs.pp: if $::neutron::params::ovs_agent_package So unsetting that variable should not pull the package. Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [puppet] module dependencies and different openstack versions
We use the OpenStack modules, but glue everything together with a monolithic composition module (our own.) We do want to get to a place where we can upgrade/apply config/etc. each OpenStack component separately, but have’t tackled it yet. I think it will be possible, but will take some work. I have heard of a few others who have been working toward the same thing, though I don’t think there’s really anything concrete in the upstream modules yet. WRT the dependencies, we use r10k with a manually populated Puppetfile, so we don’t rely on the module metadata to determine which modules to pull in. That’s one way to get exactly what you want rather than all the dependency sprawl. Mike On 7/27/15, 5:10 PM, Sam Morrison sorri...@gmail.com wrote: On 27 Jul 2015, at 11:25 pm, Emilien Macchi emil...@redhat.com wrote: On 07/27/2015 02:32 AM, Sam Morrison wrote: We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don’t want it to mess with keystone (for one we don’t support setting endpoints via an API) but also we don’t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we’ll may never move to the official keystone puppet module. Well, in that case it's going to be very hard for you to use the modules. Trying to give up forks and catch-up to upstream is really expensive and challenging (Fuel is currently working on this). What I suggest is: 1/ have a look at the diff between your manifests and upstream ones. 2/ try to use upstream modules with the maximum number of classes, and put the rest in a custom module (or a manifest somewhere). 3/ submit patches if you think we're missing something in the modules. The neutron module pulls in the vswitch module but we don’t use vswitch and it doesn’t seem to be a requirement of the module so maybe doesn’t need to be in metadata dependencies? AFIK there is no conditional in metadata.json, so we need the module anyway. It should not cause any trouble to you, except if you have a custom 'vswitch' module. Yeah it would be nice if you could specify dependencies as well as recommended much like debian packages do. We use librarian-puppet to manage all our modules and you can’t disable it installing all the dependencies. But that is another issue… It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. We try to design our modules to work together because Puppet OpenStack is a single project composed of modules that are supposed to -together- deploy OpenStack. All the puppet modules we use are very modular (hence the name), the openstack modules aren’t at this stage. Ideally each module would be self contained and then if people wanted to deploy “openstack” there could be an “openstack” module that would pull in all the individual project modules and make them work together. It’s the first tip for writing a module listed at https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.h tml#tips I guess I’m just wondering if other people are having the same issue I am? and if so is there a way forward to make the puppet modules more modular or do I just stick with my own modules. In your case, I would just install the module from source (git) and not trying to pull them from Puppetforge. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? 1/ you're running Kilo, Juno and Icehouse in the same cloud? Wow. You're brave! We are a large deployment spanning multiple data centres and 1000+ hosts so upgrading in one big bang isn’t an option. I don’t think this is brave it is the norm for people running large openstack clouds in production. 2/ Puppet modules do not hardcode OpenStack packages version. Though our current master is targeting Liberty, but we have stable/kilo, stable/juno, etc. You can even disable the package dependency in most of the classes. The packages aren’t the issue it’s more the configs that get pushed out and so on, when config variables change location etc. with different versions this becomes hard. I'm not sure this is an issue here,
Re: [Openstack-operators] [puppet] module dependencies and different openstack versions
On 07/27/2015 02:32 AM, Sam Morrison wrote: We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don’t want it to mess with keystone (for one we don’t support setting endpoints via an API) but also we don’t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we’ll may never move to the official keystone puppet module. Well, in that case it's going to be very hard for you to use the modules. Trying to give up forks and catch-up to upstream is really expensive and challenging (Fuel is currently working on this). What I suggest is: 1/ have a look at the diff between your manifests and upstream ones. 2/ try to use upstream modules with the maximum number of classes, and put the rest in a custom module (or a manifest somewhere). 3/ submit patches if you think we're missing something in the modules. The neutron module pulls in the vswitch module but we don’t use vswitch and it doesn’t seem to be a requirement of the module so maybe doesn’t need to be in metadata dependencies? AFIK there is no conditional in metadata.json, so we need the module anyway. It should not cause any trouble to you, except if you have a custom 'vswitch' module. It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. We try to design our modules to work together because Puppet OpenStack is a single project composed of modules that are supposed to -together- deploy OpenStack. In your case, I would just install the module from source (git) and not trying to pull them from Puppetforge. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? 1/ you're running Kilo, Juno and Icehouse in the same cloud? Wow. You're brave! 2/ Puppet modules do not hardcode OpenStack packages version. Though our current master is targeting Liberty, but we have stable/kilo, stable/juno, etc. You can even disable the package dependency in most of the classes. I'm not sure this is an issue here, maybe a misunderstanding of how to use the modules. Good luck, -- Emilien Macchi 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
[Openstack-operators] [puppet] module dependencies and different openstack versions
We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don’t want it to mess with keystone (for one we don’t support setting endpoints via an API) but also we don’t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we’ll may never move to the official keystone puppet module. The neutron module pulls in the vswitch module but we don’t use vswitch and it doesn’t seem to be a requirement of the module so maybe doesn’t need to be in metadata dependencies? It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? Thanks, Sam ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
