Open Stack

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" <sorrison at gmail.com> wrote:

>
>> On 27 Jul 2015, at 11:25 pm, Emilien Macchi <emilien at 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, maybe a misunderstanding of how to
>> use the modules.
>> 
>> Good luck,
>
>Thanks,
>
>Sam
>
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators