# Ansible Runner API and v2 Refactor **URL:** \ **Category:** Ansible Developer\ **Created:** [December 19, 2014, 4:33pm UTC](https://forum.ansible.com/t/ansible-runner-api-and-v2-refactor/17110 "2014-12-19T16:33:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Adam\_Miller](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@Adam\_Miller](https://forum.ansible.com/u/Adam_Miller)\ **Post date:** [December 19, 2014, 4:33pm UTC](https://forum.ansible.com/t/ansible-runner-api-and-v2-refactor/17110/1 "2014-12-19T16:33:05Z")
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 [0] - [http://docs.ansible.com/developing\_api.html](http://docs.ansible.com/developing_api.html) ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [December 19, 2014, 5:26pm UTC](https://forum.ansible.com/t/ansible-runner-api-and-v2-refactor/17110/2 "2014-12-19T17:26:06Z")
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. ---
**Author:** ![Adam\_Miller](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@Adam\_Miller](https://forum.ansible.com/u/Adam_Miller)\ **Post date:** [December 19, 2014, 5:52pm UTC](https://forum.ansible.com/t/ansible-runner-api-and-v2-refactor/17110/3 "2014-12-19T17:52:10Z")
> 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 ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [December 19, 2014, 6:38pm UTC](https://forum.ansible.com/t/ansible-runner-api-and-v2-refactor/17110/4 "2014-12-19T18:38:05Z")
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. ---
**Author:** ![Adam\_Miller](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@Adam\_Miller](https://forum.ansible.com/u/Adam_Miller)\ **Post date:** [December 19, 2014, 7:12pm UTC](https://forum.ansible.com/t/ansible-runner-api-and-v2-refactor/17110/5 "2014-12-19T19:12:25Z")
> 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