git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 1/9/20 11:20 AM, 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

I would prefer that solution, since it allows to keep code stupid
simple, without block|when|other switches that can make maintenance
complicated.

Doing so will probably make the unit testing easier as well (thinking of
molecule here, mainly).

> 
> 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.
> From cons I can count: more roles and might be some level of duplication
> in variables.

We would probably need some common params|variables in order to avoid
duplication... The var part might be a source of headache in order to
avoid as much as possible duplications.

> 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

-- 
Cédric Jeanneret (He/Him/His)
Software Engineer - OpenStack Platform
Red Hat EMEA
https://www.redhat.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200109/42a24c5e/attachment.sig>