[tripleo] tripleo-operator-ansible start and request for input

Bogdan Dobrelya bdobreli at redhat.com
Thu Jan 9 11:38:04 UTC 2020


On 09.01.2020 11:20, Sagi Shnaidman wrote:
> Thanks for bringing this up, Alex
> 
> I was thinking if we can the third option - to have small "single 
> responsibility" roles for every action. For example:
> tripleo-undercloud-install
> tripleo-undercloud-backup
> tripleo-undercloud-upgrade
> 
> And then no one needs to dig into roles to check what actions are 
> supported, but just "ls roles/". Also these roles usually have nothing 
> in common but name, and if they are quite isolated, I think it's better 
> to have them defined separately.

+1
A role should do one thing and do it good (c) from somewhere

>  From cons I can count: more roles and might be some level of 
> duplication in variables.
> For pros it's more readable playbook and clear actions:
> 
> - hosts: undercloud
>    gather_facts: true
>    collections:
>      - tripleo.operator
>    vars:
>      tripleo_undercloud_debug: true
>    tasks:
> 
>      - name: Install undercloud
>        import_role:
>          name: undercloud-install
> 
>      - name: Upgrade undercloud
>        import_role:
>          name: undercloud-upgrade
> 
> Thanks
> 
> On Thu, Jan 9, 2020 at 12:22 AM Alex Schultz <aschultz at redhat.com 
> <mailto:aschultz at redhat.com>> wrote:
> 
>     [Hello folks,
> 
>     I've begun the basic start of the tripleo-operator-ansible collection
>     work[0].  At the start of this work, I've chosen the undercloud
>     installation[1] as the first role to use to figure out how we the end
>     user's to consume these roles.  I wanted to bring up this initial
>     implementation so that we can discuss how folks will include these
>     roles.  The initial implementation is a wrapper around the
>     tripleoclient command as run via openstackclient.  This means that the
>     'tripleo-undercloud' role provides implementations for 'openstack
>     undercloud backup', 'openstack undercloud install', and 'openstack
>     undercloud upgrade'.
> 
>     In terms of naming conventions, I'm proposing that we would name the
>     roles "tripleo-<command-base>" with the last part of the command
>     action being an "action". Examples:
> 
>     "openstack undercloud *" ->
>     role: tripleo-undercloud
>     action: (backup|install|upgrade)
> 
>     "openstack undercloud minion *" ->
>     role: tripleo-undercloud-minion
>     action: (install|upgrade)
> 
>     "openstack overcloud *" ->
>     role: tripleo-overcloud
>     action: (deploy|delete|export)
> 
>     "openstack overcloud node *" ->
>     role: tripleo-overcloud-node
>     action: (import|introspect|provision|unprovision)
> 
>     In terms of end user interface, I've got two proposals out in terms of
>     possible implementations.
> 
>     Tasks from method:
>     The initial commit propose that we would require the end user to use
>     an include_role/tasks_from call to perform the desired action.  For
>     example:
> 
>          - hosts: undercloud
>            gather_facts: true
>            tasks:
>              - name: Install undercloud
>                collections:
>                  - tripleo.operator
>                import_role:
>                  name: tripleo-undercloud
>                  tasks_from: install
>                vars:
>                  tripleo_undercloud_debug: true
> 
>     Variable switch method:
>     I've also proposed an alternative implementation[2] that would use
>     include_role but require the end user to set a specific variable to
>     change if the role runs 'install', 'backup' or 'upgrade'. With this
>     patch the playbook would look something like:
> 
>          - hosts: undercloud
>            gather_facts: true
>            tasks:
>              - name: Install undercloud
>                collections:
>                  - tripleo.operator
>                import_role:
>                  name: tripleo-undercloud
>                vars:
>                  tripleo_undercloud_action: install
>                  tripleo_undercloud_debug: true
> 
>     I would like to solicit feedback on which one of these is the
>     preferred integration method when calling these roles. I have two
>     patches up in tripleo-quickstart-extras to show how these calls could
>     be run. The "Tasks from method" can be viewed here[3]. The "Variable
>     switch method" can be viewed here[4].  I can see pros and cons for
>     both methods.
> 
>     My take would be:
> 
>     Tasks from method:
>     Pros:
>       - action is a bit more explicit
>       - dynamic logic left up to the playbook/consumer.
>       - May not have a 'default' action (as main.yml is empty, though it
>     could be implemented).
>       - tasks_from would be a global implementation across all roles rather
>     than having a changing variable name.
> 
>     Cons:
>       - internal task file names must be known by the consumer (though IMHO
>     this is no different than the variable name + values in the other
>     implementation)
>       - role/action inclusions is not dynamic in the role (it can be in
>     the playbook)
> 
>     Variable switch method:
>     Pros:
>       - inclusion of the role by default runs an install
>       - action can be dynamically changed from the calling playbook via an
>     ansible var
>       - structure of the task files is internal to the role and the user of
>     the role need not know the filenames/structure.
> 
>     Cons:
>       - calling playbook is not explicit in that the action can be switched
>     dynamically (e.g. intentionally or accidentally because it is dynamic)
>       - implementer must know to configure a variable called
>     `tripleo_undercloud_action` to switch between install/backup/upgrade
>     actions
>       - variable names are likely different depending on the role
> 
>     My personal preference might be to use the "Tasks from method" because
>     it would lend itself to the same implementation across all roles and
>     the dynamic logic is left to the playbook rather than internally in
>     the role. For example, we'd end up with something like:
> 
>          - hosts: undercloud
>            gather_facts: true
>            collections:
>              - tripleo.operator
>            tasks:
>              - name: Install undercloud
>                import_role:
>                  name: tripleo-undercloud
>                  tasks_from: install
>                vars:
>                  tripleo_undercloud_debug: true
>              - name: Upload images
>                import_role:
>                  name: tripleo-overcloud-images
>                  tasks_from: upload
>                vars:
>                  tripleo_overcloud_images_debug: true
>              - name: Import nodes
>                import_role:
>                  name: tripleo-overcloud-node
>                  tasks_from: import
>                vars:
>                  tripleo_overcloud_node_debug: true
>                  tripleo_overcloud_node_import_file: instack.json
>              - name: Introspect nodes
>                import_role:
>                  name: tripleo-overcloud-node
>                  tasks_from: introspect
>                vars:
>                  tripleo_overcloud_node_debug: true
>                  tripleo_overcloud_node_introspect_all_manageable: True
>                  tripleo_overcloud_node_introspect_provide: True
>              - name: Overcloud deploy
>                import_role:
>                  name: tripleo-overcloud
>                  tasks_from: deploy
>                vars:
>                  tripleo_overcloud_debug: true
>                  tripleo_overcloud_deploy_environment_files:
>                    - /home/stack/params.yaml
> 
>     The same general tasks performed via the "Variable switch method"
>     would look something like:
> 
>          - hosts: undercloud
>            gather_facts: true
>            collections:
>              - tripleo.operator
>            tasks:
>              - name: Install undercloud
>                import_role:
>                  name: tripleo-undercloud
>                vars:
>                  tripleo_undercloud_action: install
>                  tripleo_undercloud_debug: true
>              - name: Upload images
>                import_role:
>                  name: tripleo-overcloud-images
>                vars:
>                  tripleo_overcloud_images_action: upload
>                  tripleo_overcloud_images_debug: true
>              - name: Import nodes
>                import_role:
>                  name: tripleo-overcloud-node
>                vars:
>                  tripleo_overcloud_node_action: import
>                  tripleo_overcloud_node_debug: true
>                  tripleo_overcloud_node_import_file: instack.json
>              - name: Introspect nodes
>                import_role:
>                  name: tripleo-overcloud-node
>                vars:
>                  tripleo_overcloud_node_action: introspect
>                  tripleo_overcloud_node_debug: true
>                  tripleo_overcloud_node_introspect_all_manageable: True
>                  tripleo_overcloud_node_introspect_provide: True
>              - name: Overcloud deploy
>                import_role:
>                  name: tripleo-overcloud
>                vars:
>                  tripleo_overcloud_action: deploy
>                  tripleo_overcloud_debug: true
>                  tripleo_overcloud_deploy_environment_files:
>                    - /home/stack/params.yaml
> 
>     Thoughts?
> 
>     Thanks,
>     -Alex
> 
>     [0]
>     https://blueprints.launchpad.net/tripleo/+spec/tripleo-operator-ansible
>     [1] https://review.opendev.org/#/c/699311/
>     [2] https://review.opendev.org/#/c/701628/
>     [3] https://review.opendev.org/#/c/701034/
>     [4] https://review.opendev.org/#/c/701628/
> 
> 
> 
> 
> -- 
> Best regards
> Sagi Shnaidman


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando




More information about the openstack-discuss mailing list