On Wed, Feb 24, 2016 at 10:34 AM, Stephen Granger <[email protected]> wrote: > Any chance there will be documentation for the api similar to Ansible > modules? (I'm looking for an AWS Lambda example using the 2.0 api after > seeing Jose article) > > I like the way things have been broken apart with Ansible 2.0 into smaller > contained components, especially with how some of the modules have been > rewritten.. It was slightly painful to begin with but it certainly does > allow for flexibility and makes it easier for more complicated use cases. > > Admittedly I haven't figured out how to run a playbook via the new api yet > either.
It is my hope that the 2.0 API will be stable for a good long time, and documenting it would be a great and useful project for someone that isn't the core team. --g > On 24 February 2016 at 06:13, Brian Coca <[email protected]> wrote: >> >> The API is not the product, the Ansible command line tools are, the API is >> there for the tool usage and it not the main interface. This has always been >> the case and stated in many occasions and in the documentation. >> >> Runner was not simple (no class with a thousand+ line __init__ method is) >> and was full of errors as many features were 'bolted in' and was sorely >> needing a redesign. It might have been 'simple to call' but it was not easy >> to maintain nor extend. >> >> We removed runner and derived over a dozen classes that now handle the >> same functions in a much cleaner way internally. This also allowed us to >> correctly test the code and now validate plays, many previously silent >> errors are now caught. Adding new features is much simpler and clearly >> defined, as is the inheritance of such features, things are much more well >> defined and predictable. We also made many parts of the code more >> configurable and were able to push features to the plugins that were >> previously hardcoded. >> >> As much as this has made it easier to maintain and extend Ansible, it has >> made the API interface more complex, but that, again, is something that we >> use internally for the command line tools, which have not really changed >> their interface and maintained their simplicity. >> >> Long story short, NO we do NOT want runner back. It is easy enough to >> create other helper classes to simplify the interface for 3rd party, but it >> is not something the current project focuses on, our focus is the set of CLI >> tools which our main user base depends on. >> >> >> ---------- >> Brian Coca >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/CACVha7e3%2BLLcJpSq8%3DpzGMqKNfFtetVjcpiN6FcHQ9VTavUzdg%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Steve > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CA%2BemtqsScdVQ6kZd8UaX74dk2uNzSFygoik%3DTLnSO_Z5UoZVFQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- Greg DeKoenigsberg Ansible Community Guy -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAM1FbhFvTs1eaVHn7f-SBbqX5vKc6CWTfjLq%3DXwa7JGM9s8tCA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
