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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
