Hello all,
I was poking around the v2/ directory just to see how the refactor
is looking (mostly out of personal curiosity) and I noticed there's no
longer a Runner API as it exists in "current gen" Ansible[0]. I was
curious if the Runner API is something that's planned to go away in
the refactor, if it's not been migrated in the refactor code, or
possibly some other scenario.
Thanks,
-AdamM
Yes, it will change. Basically the signature of Runner has been getting unwieldy with the 20+ options it takes and we want it to just take in what is basically a task object.
Basically our idea is that /usr/bin/ansible will create an in-memory playbook for just that one “task” and execute it.
The Ansible playbook language remains compatible and the CLI will take the same options.
Output may differ somewhat in a few places (like from the output of /usr/bin/ansible)
v2 is coming along, but still working on some tuning - most of the plugins will be 100% portable, especially things like inventory and filters. action_plugins will probably not be compatible, but changes should not be heavy.
modules will be 100% compatible.
Yes, it will change. Basically the signature of Runner has been getting
unwieldy with the 20+ options it takes and we want it to just take in what
is basically a task object.Basically our idea is that /usr/bin/ansible will create an in-memory
playbook for just that one "task" and execute it.The Ansible playbook language remains compatible and the CLI will take the
same options.Output may differ somewhat in a few places (like from the output of
/usr/bin/ansible)v2 is coming along, but still working on some tuning - most of the plugins
will be 100% portable, especially things like inventory and filters.
action_plugins will probably not be compatible, but changes should not be
heavy.
modules will be 100% compatible.
Good to know, thank you for the information. I have some legacy things
that are a bit "odd" that I've written some scripts using the Runner
API and some custom modules that replaced ruby+mcollective for my use
case. I did so knowing that at some point I would need to update that
code after the new refactor because I remember reading that the API
compatibility wasn't guaranteed (understandably so). What should I be
looking at as a transition path for something that currently uses the
Runner API to the new refactored method? Or is it too early to be
asking such things? Am I just crazy? $other?
Thank you,
-AdamM
We’re mostly connecting plumbing yet so I think it may be a month or so before a /usr/bin/ansible using playbooks gets established – hard to say on exact dates and still a little too early to decide what the API will look like.
But shouldn’t be complex.
When it does, you should be able to figure out what the equivalent changes are by looking at the equivalent /usr/bin/ansible invocation – which I think will be much more simpler – and definitely more object oriented vs the large chunk of scalars
that get passed in now.
We're mostly connecting plumbing yet so I think it may be a month or so
before a /usr/bin/ansible using playbooks gets established -- hard to say on
exact dates and still a little too early to decide what the API will look
like.
But shouldn't be complex.When it does, you should be able to figure out what the equivalent changes
are by looking at the equivalent /usr/bin/ansible invocation -- which I
think will be much more simpler -- and definitely more object oriented vs
the large chunk of scalars
that get passed in now.
Sounds good, looking forward to all the great work everyone has been
putting into the refactor. Thanks again for the info.
-AdamM