Re: [openstack-dev] [tripleo] Role updates

[Emilien Macchi]

On Wed, Jun 14, 2017 at 6:24 PM, Alex Schultz  wrote:
> On Tue, Jun 13, 2017 at 11:11 AM, Alex Schultz  wrote:
>> On Tue, Jun 13, 2017 at 6:58 AM, Dan Prince  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].

 

Re: [openstack-dev] [tripleo] Role updates

[Alex Schultz]

On Tue, Jun 13, 2017 at 11:11 AM, Alex Schultz  wrote:
> On Tue, Jun 13, 2017 at 6:58 AM, Dan Prince  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-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: 

Re: [openstack-dev] [tripleo] Role updates

[Alex Schultz]

On Tue, Jun 13, 2017 at 6:58 AM, Dan Prince  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-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

Re: [openstack-dev] [tripleo] Role updates

[Dan Prince]

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?

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

Re: [openstack-dev] [tripleo] Role updates

[Dmitry Tantsur]

On 06/13/2017 12:00 AM, Alex Schultz wrote:

On Mon, Jun 12, 2017 at 2:55 AM, Dmitry Tantsur  wrote:

On 06/09/2017 05:24 PM, 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.
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].



Hi, this is awesome! Do we expect more example roles to be added? E.g. I
could add a role for a reference Ironic Conductor node.



Yes. My expectation is that as we come up with new roles for supported
deployment types that we add them to the THT/roles directory so end
user can also use them.  The base set came from some work we did
during the Ocata cycle to have 3 base sets of architectures.

3 controller, 3 compute, 1 ceph (ha)
1 controller, 1 compute, 1 ceph (nonha)
3 controller, 3 database, 3 messaging, 2 networker, 1 compute, 1 ceph (advanced)

Feel free to propose additional roles if you have architectures you'd
like to have be reusable.


Ok, here we go: https://review.openstack.org/473788.

I guess it's expected that such deployments should still be done with `-e 
environments/services/ironic.yaml`, right?




Thanks,
-Alex




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/roles/README.rst

__
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


__
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

Re: [openstack-dev] [tripleo] Role updates

[Alex Schultz]

On Mon, Jun 12, 2017 at 2:55 AM, Dmitry Tantsur  wrote:
> On 06/09/2017 05:24 PM, 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.
>> 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].
>
>
> Hi, this is awesome! Do we expect more example roles to be added? E.g. I
> could add a role for a reference Ironic Conductor node.
>

Yes. My expectation is that as we come up with new roles for supported
deployment types that we add them to the THT/roles directory so end
user can also use them.  The base set came from some work we did
during the Ocata cycle to have 3 base sets of architectures.

3 controller, 3 compute, 1 ceph (ha)
1 controller, 1 compute, 1 ceph (nonha)
3 controller, 3 database, 3 messaging, 2 networker, 1 compute, 1 ceph (advanced)

Feel free to propose additional roles if you have architectures you'd
like to have be reusable.

Thanks,
-Alex


>>
>> 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/roles/README.rst
>>
>> __
>> 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

__
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

Re: [openstack-dev] [tripleo] Role updates

[Jiri Tomasek]

On 12.6.2017 10:55, Dmitry Tantsur wrote:

On 06/09/2017 05:24 PM, 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.
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].


Hi, this is awesome! Do we expect more example roles to be added? E.g. 
I could add a role for a reference Ironic Conductor node.


Hi, thanks for doing great work in this and bringing up the topic!

I'd like to point out one problem which we've been dealing with for 
quite a while now which is TripleO UI and CLI interoperability. The main 
reason why we introduced Mistral 'TripleO' API is to consolidate the 
business logic to single place which will be used by all TripleO 
clients, so all will use the same codebase and not diverge. This has 
been established and agreed on quite a long time ago but it occurs that 
the problem of diverging the codebases still creeps in.


Main problem is that CLI (unlike all other clients) still tends to 
operate on local files rather than a deployment plan stored in Swift. 
Result is that new features which should be implemented in single place 
(tripleo-common - Mistral Actions/Worklflows) are implemented twice - in 
tripleoclient and (usually later for no real reason) in tripleo-common. 
Roles management is exact example. There is a great effort made to 
simplifying and managing Roles, but only by CLI, regarless of other 
clients need to do the same. This causes us having to maintain 2 
codebases which have the same goal, increases development time and other 
costs.


So my question is: How much effort would it be to change CLI workflow to 
operate on plan in Swift rather on local files? What are the pros and 
cons? How do we solve the problem of lacking features in tripleo-common?


Recently a changes in tripleo-common have been made which make 
operations on Swift plan much simpler. All the data about deployment is 
kept in Swift in templates/environment files and plan-environment.yaml 
(which replaced mistral environment data structure) so 
importing/exporting plan is much simpler now. If CLI leveraged this 
functionality, there would not be any need for user to store CLI command 
which was used for deployment. All the data are in plan-environment.yaml.


Let's take a look at Roles management example. Alex mentions removing 
roles_data.yaml. Yes, there is no need for it. Deployment plan is 
pre-created with undercloud install already, so CLI user could list 
available roles and use command which sets roles (takes list of roles 
names), this calls Mistral action/workflow which stores this selection 
in plan-environment.yaml in Swift and regenerates/updates j2 templates. 
Same with anything else (add environment files add/modify templates, set 
parameters...). Then user just fires 'openstack overcloud deploy' and is 
done. In case of need, user can simply export the plan and keep the 
files locally to easily recreate same deployment elsewhere.


What are the reasons why CLI could not work this way? Do those outweigh 
having to implement and maintain the business logic at two places?


Thanks,
Jirka





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/roles/README.rst


__ 


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



__
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

Re: [openstack-dev] [tripleo] Role updates

[Dmitry Tantsur]

On 06/09/2017 05:24 PM, 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.
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].


Hi, this is awesome! Do we expect more example roles to be added? E.g. I could 
add a role for a reference Ironic Conductor node.




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/roles/README.rst

__
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