[tripleo] tripleo-operator-ansible start and request for input
Alex Schultz
aschultz at redhat.com
Thu Jan 9 16:00:54 UTC 2020
On Thu, Jan 9, 2020 at 3:20 AM Sagi Shnaidman <sshnaidm at redhat.com> 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
>
Ok it seems like this is the generally preferred structure. We'll go
with this and I'll update my patches to reflect this. One issue with
this is the extra duplication in files but that might be minor.
> 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
More information about the openstack-discuss
mailing list