Open Stack

On Wed, Jun 14, 2017 at 6:24 PM, Alex Schultz <aschultz at redhat.com> wrote:
> 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.

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



-- 
Emilien Macchi