Open Stack

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.
>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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200109/1f850382/attachment-0001.html>