On Wed, Jun 14, 2017 at 6:24 PM, Alex Schultz <aschu...@redhat.com> wrote: > 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.
I would like to propose that once we have https://review.openstack.org/#/c/472731/ in place, we would force our users to generate roles_data.yaml instead of providing a default file. One direct benefit for that would be to solve this kind of case: https://bugs.launchpad.net/tripleo/+bug/1671859 (and possibly decrease deployment time when using custom roles). One way to do it could be: Pike - Validate roles data with https://review.openstack.org/#/c/472731/ - Make CLI generating by default the current default config (when not using custom roles) (if not the case already) - Document the CLI (in progress by Alex) and deprecate the roles_data file, make it clear in the documentation for our users. Queens - Remove the default roles data from THT - Make the roles data file management as required in the doc Does it make sense? > 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 -- Emilien Macchi __________________________________________________________________________ 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
