On Tue, Jun 13, 2017 at 11:11 AM, Alex Schultz <aschu...@redhat.com> wrote: > 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.
As a follow up, I've taken some time to move the roles functions in to tripleo-common[0] and out of tripleoclient[1]. With this, I've also updated the validation patch with a small python script that leverages the tripleo-common work. Of course while writing this email I noticed that tripleo-common also pulls in instack-undercloud[3] like tripleoclient[4] so I'm not sure this is actually an improvement. ¯\_(ツ)_/¯ Thanks, -Alex [0] https://review.openstack.org/#/c/474332/ [1] https://review.openstack.org/#/c/474343/ [2] https://review.openstack.org/#/c/472731/ [3] https://github.com/rdo-packages/tripleo-common-distgit/blob/rpm-master/openstack-tripleo-common.spec#L21 [4] https://github.com/rdo-packages/tripleoclient-distgit/blob/rpm-master/python-tripleoclient.spec#L36 > > 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