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
