git.net

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

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


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