Open Stack

On Tue, Jun 13, 2017 at 11:11 AM, Alex Schultz <aschultz at redhat.com> wrote:
> 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.

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-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