On Thu, Oct 29, 2020 at 5:32 AM Bogdan Dobrelya <bdobreli@redhat.com> wrote:
Hi,
In today TripleO client development we invoke ansible playbooks instead of Mistral workflows. I believe this may only be justified for non-trivial things. Otherwise please just import python modules into the client command actions without introducing additional moving parts in the form of ansible modules (that import the same python modules as well).
Ansible brings declarative DSL that sometimes can better and simpler and faster describes things to do and shape inputs data, than if the same would be done in python, in the client.
What should be the trivial thing and non-trivial then?
Well, I think that example [0] illustrates such a trivial thing. A new playbook [1] would only install a few packages then "returns" back into python and calls a new ansible module [2]. And that new module only wraps [3] the same code being removed from the client:
from tripleo_common.image import build ... manager = build.ImageBuildManager(<args>)
I see no point of adding a new playbook and a new module for that trivial example. Those 4 packages could (and should) be as well installed from the client caller code without any ansible involved in the middle IMO.
While I can agree to a certain extent, there's actually some good reasons to even move trivial bits into ansible. Personally I'm not certain the switch to using ansible under the covers from some cli actions is an improvement (questionable logging, error handling isn't great), there is a case for certain actions. As we discussed at the PTG, the overcloud image building process is one of those things that actually has to be executed on bare metal. If we wanted to continue to look at containerizing the cli, we need to be able to invoke this action from within the container but build on an external host. This is something that is trivial with the switch to an ansible playbook that isn't available when running under the pure python as it exists today. Container builds would be another example action that is required to run on a bare metal host. Additionally the movement of this invocation to an ansible module also allows the action to be moved into something like the undercloud installation as an optional action as part of the deployment itself. It's not exactly without merit in this case. I don't really care one way or another for this action, however I don't think it's as simple as saying "oh it's just a few lines of code so we shouldn't..."
[0] https://review.opendev.org/#/c/759954/
[1] https://review.opendev.org/#/c/759953/3/tripleo_ansible/playbooks/cli-overcl...
[2] https://review.opendev.org/#/c/759953/3/tripleo_ansible/ansible_plugins/modu...
-- Best regards, Bogdan Dobrelya, Irc #bogdando