On Tue, Jun 13, 2017 at 6:58 AM, Dan Prince <dpri...@redhat.com> wrote: > On Fri, 2017-06-09 at 09:24 -0600, Alex Schultz wrote: >> Hey folks, >> >> I wanted to bring to your attention that we've merged the change[0] >> to >> add a basic set of roles that can be combined to create your own >> roles_data.yaml as needed. With this change the roles_data.yaml and >> roles_data_undercloud.yaml files in THT should not be changed by >> hand. > > In general I like the feature. > > I added some comments to your validations [1] patch below. We need > those validations, but I think we need to carefully consider adding a > hard dependency on python-tripleoclient simply to have validations in > tree. Wondering if perhaps a t-h-t-utils library project might be in > order here to contain routines we use in t-h-t and in higher level > workflow tools in Mistral and on the CLI? This might also make the > tools/process-templates.py stuff cleaner as well. > > Thoughts?
So my original implementation of the roles stuff included a standalone script in THT to generate the roles_data.yaml files. This was -1'd as realistically the actions for managing this should probably live within python-tripleoclient. This made sense to me as that's how the end user really should be interacting with these things. Given that the tripleoclient and the UI are the two ways and operator is going to consume with THT I think there is already an undocumented requirement that should be there. An alternative would be to move the roles generation items into tripleo-common but then we would have to write two distinct ways of then executing this code. One being tripleoclient and the other being a standalone script which basically would have to reinvent the interface provided by tripleoclient/openstackclient. Since we're not allowing folks to dynamically construct the roles_data.yaml as part of the overcloud deployment yet, I'm not sure we should try and move this around further unless there's an agreed upon way we want to handle this. I think the better work would be to split the tripleoclient/instack-undercloud dependency which is really where the problem lies. We shouldn't be pulling in the world for tripleoclient if we are just going to operate on only the overcloud. Thanks, -Alex > > Dan > >> Instead if you have an update to a role, please update the >> appropriate >> roles/*.yaml file. I have proposed a change[1] to THT with additional >> tools to validate that the roles/*.yaml files are updated and that >> there are no unaccounted for roles_data.yaml changes. Additionally >> this change adds in a new tox target to assist in the generate of >> these basic roles data files that we provide. >> >> Ideally I would like to get rid of the roles_data.yaml and >> roles_data_undercloud.yaml so that the end user doesn't have to >> generate this file at all but that won't happen this cycle. In the >> mean time, additional documentation around how to work with roles has >> been added to the roles README[2]. >> >> Thanks, >> -Alex >> >> [0] https://review.openstack.org/#/c/445687/ >> [1] https://review.openstack.org/#/c/472731/ >> [2] https://github.com/openstack/tripleo-heat-templates/blob/master/r >> oles/README.rst >> >> _____________________________________________________________________ >> _____ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs >> cribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev