Bug 1033261

The difficulty here will be ensuring classes can be composed and also only in supported manners.  I think higher level UIs for this are the way forward.

I think the other alternative is that we have some layer between quickstack & the base puppet modules that provide some form w/o trying to specify what the end-machine looks like.

jayg has been noodling on something like:  http://www.craigdunn.org/2012/05/239/ where a profile is roughly what a host group is today & the role is that missing in between abstraction.  

Either that or higher level UIs seem like a great idea moving forward.

Moving out of RHOS4.  This is forward looking.

To clarify terminology, Mike has the right idea, but in the example, profiles are the reusable chunks that compose roles, which in foreman parlance, are host groups.  Hopefully some combination of this plus whatever @dcleal and company are cooking up for ui magic will make this more palatable/flexible for the next (post 4.0) release.  However, at the current time, this is only in the research stages, so the rhos team needs to work with the foreman folks a bit as well as ref arch to see what combination of design approaches will solve this the best.

+1 

Actually, while working on adding monitoring with Nagios, I realized every service is a component Nagios needs to have defined, facing same structural issues.

As a matter of fact Nagios has "hostgroups" as well, bringing the question "What's the best way to build generic enough hostgroups?

Because a "controller" is a wrapper of services which are on some hosts, the latter being a user dependent choice makes it no candidate for Nagios hostgroup.

As we progressed away from All-in-One, the controller started breaking down in smaller controllers, such as neutron/swift/etc but again those are only user choices made based for some typical scenarios only, not offering the granularity OpenStack can.

Ultimately every OpenStack service need to be covered by a Puppet class to offer the bricks needed to be assembled someway, maybe using either:

- Roles (comment #3)
- Foreman multi-inheritance hostgroups 
- A dynamic puppet builder

This has taken place on the HA host group puppet modules but will not be backported to the non-HA hostgroups as we hope to eventually deprecrate them in favor of a single node cluster for simple setups.

Reopening this one,

For Openstack-puppet-modules CI we need to have All-In-One with both NonHA and HA scenarios available.

Part of the reason is technical, because it's easier to build up from existing working ground in our ocean of complexity and as a matter of fact we already have the AIO NonHA ready, tests are in progress. This latter version is using a "multilithic" (as opposed to monolithic) approach, providing the building blocks to assemble pretty much any scenario. Next step will be to consolidate with HA.

Also, because quickstack AIO can help consolidate our resources from Packstack.
Discussion in progress.

And consequently, from a functional viewpoint a NonHA AIO still makes sense.