[openstack-dev] [tripleo] Role updates

Jiri Tomasek jtomasek at redhat.com
Mon Jun 12 11:20:19 UTC 2017



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




More information about the OpenStack-dev mailing list