[openstack-dev] [tripleo] Role updates
emilien at redhat.com
Wed Jun 21 22:28:04 UTC 2017
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
>>>> 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
>>> In general I like the feature.
>>> I added some comments to your validations  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.
>> 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
>> 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 and out of tripleoclient. 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:
- 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.
- 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 like tripleoclient so I'm not sure
> this is actually an improvement. ¯\_(ツ)_/¯
>  https://review.openstack.org/#/c/474332/
>  https://review.openstack.org/#/c/474343/
>  https://review.openstack.org/#/c/472731/
>  https://github.com/rdo-packages/tripleo-common-distgit/blob/rpm-master/openstack-tripleo-common.spec#L21
>  https://github.com/rdo-packages/tripleoclient-distgit/blob/rpm-master/python-tripleoclient.spec#L36
>>>> Instead if you have an update to a role, please update the
>>>> roles/*.yaml file. I have proposed a change 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.
>>>>  https://review.openstack.org/#/c/445687/
>>>>  https://review.openstack.org/#/c/472731/
>>>>  https://github.com/openstack/tripleo-heat-templates/blob/master/r
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev