[tripleo] tripleo-operator-ansible start and request for input
[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/
Hey Alex, This is a great starting point! Thanks for sharing. I personally prefer the variables approach. This more-so aligns with the best practices for creating an Ansible role. An operator could provide a single variables file that has the booleans set for what they want configured. This also makes it easier to include/import the role once and then have it do multiple actions. For example, tripleo-undercloud can be used for both installation and backup. CI could even consume this to run "all the things" from the role by setting those extra variables. We provide the playbooks and the operators configure the variables for their environment. Long-term, I see TripleO consuming a single or few straight-forward Ansible variables files that define the entire deployment as opposed to the giant monster that Heat templates have become. Those are just my initial thoughts on the matter. I am interested to see what others think as well. Sincerely, Luke Short On Wed, Jan 8, 2020 at 5:20 PM Alex Schultz <aschultz@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/
On Wed, Jan 8, 2020 at 5:25 PM Alex Schultz <aschultz@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)
Another technically valid option could be: "openstack overcloud node *" to role: tripleo-overcloud action: node/import|node/introspect, etc. The role could have tasks/node/import.yml, tasks/node/introspect.yml, etc. It's to me another option to consider so we reduce the number of roles (and therefore LOC involved).
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.
Not sure but it might be slightly faster as well, since we directly import what we need. I prefer this proposal as well also because I've already seen this pattern in tripleo-ansible.
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/
Nice work Alex! -- Emilien Macchi
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@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
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@redhat.com <mailto:aschultz@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
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@redhat.com <mailto:aschultz@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/
On Thu, Jan 9, 2020 at 5:25 AM Sagi Shnaidman <sshnaidm@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
Good idea, and I tend to agree as well. If we really wanted a single undercloud role at some point, then we could always go back to the original idea, and have a tripleo-undercloud role that just included these other more fine grained roles. But, for now, I like the idea of smaller focused roles. -- -- James Slagle --
On Thu, Jan 9, 2020 at 3:20 AM Sagi Shnaidman <sshnaidm@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@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
participants (7)
-
Alex Schultz
-
Bogdan Dobrelya
-
Cédric Jeanneret
-
Emilien Macchi
-
James Slagle
-
Luke Short
-
Sagi Shnaidman