Open Stack

On Fri, Apr 29, 2016 at 03:27:29PM -0500, Emilien Macchi wrote:
> Hi,
> 
> One of the most urgent tasks we need to achieve in TripleO during
> Newton cycle is the composable roles support.
> So we decided to build a team that would focus on it during the next weeks.

Note that there is some confusion regarding the "composable roles" term -
what we're discussing here is the effort to decompose services within the
existing roles, which is a precursor to fully composable roles.

There are two BPs related to this:

https://review.openstack.org/#/q/topic:bp/refactor-puppet-manifests
https://blueprints.launchpad.net/tripleo/+spec/refactor-puppet-manifests

This is about breaking up the monolithic puppet manifests into per-service
profiles in puppet-tripleo

https://review.openstack.org/#q,topic:bp/composable-services-within-roles,n,z
https://blueprints.launchpad.net/tripleo/+spec/composable-services-within-roles

This is about consuming the per-service profiles via a new per-service
template definition (a new internal template API for service configuration
via heat templates)

Both can be tracked independently, but the composable-services-within-roles
BP depends on the refactor-puppet-manifests work.

Then, there is a final step which is enabling user defined additional roles
(e.g groups of nodes not deployed via the fixed Controller/Compute/*Storage
groups) - I proposed a possible approach for this in our summit session,
and will raise a BP to track this work (hopefully will have a prototype
implementation posted soon).

> We started this etherpad:
> https://etherpad.openstack.org/p/tripleo-composable-roles-work
> 
> So anyone can help or check where we are.
> We're pushing / going to push a lot of patches, we would appreciate
> some reviews and feedback.

Thanks, I think the etherpad will be helpful to focus reviewer attention -
please ensure the patches are tagged with one of the BPs above as
appropriate too.

> Also, I would like to propose to -1 every patch that is not
> composable-role-helpful, it will help us to move forward. Our team
> will be available to help in the patches, so we can all converge
> together.

To clarify, I think we should block any new services from landing in the
"old" non-composable interface, but it's probably not reasonable to block
everything (in particular high priority bugfixes) that touches the old
monolithic manifests, we should try to minimise the rebase pain for
composable services though.

Steve