Open Stack

On Tue, Jun 13, 2017 at 6:58 AM, Dan Prince <dprince at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev