Hi everyone, Some of you may have noticed the 'v2/' subtree in the code that is just getting started.
As such, some of you may either be like: (A) OOOH AWESOME! LET ME WRITE SOME PULL REQUESTS FOR THIS! or (B) AAARGGGGGH, I hope this is not like when FooApp went from version 2 to 3 and everything stops working! So, to clarify, here's what this is, here's what's up: - Ansible started as a "nights and weekends" project on my couch and grew at OSS rates that I think are mostly unprecedented. Greg DeKoenigsburg recently quoted that Linux took *11* years to get to get 100+ contributors, and Ansible got there in about 1. As a result, some of the patches and changes were things that were clever, but not always exactly the way they would be if we architected for them in the first place. Some of these examples are like how there's no "roles" class, or how we have a utils/ tree of functions that is decidedly not OO. Minor things, but over time, they add up, and can make some future additions harder. - As a more specific example of this, I'm a huuuge fan of hybrid OO/functional programming and TDD. Ansible's rapid evolution has made it hard to do those things at times. Ansible's code is solid and we greatly appreciate everything that went into it -- but it's not the "put it on the fridge" code that we aspire to create sometimes. So there are times when we need to revisit things, clean things up, and make ideas better organized and idiomatic. - We want to get to more of a culture of unit testing where as Ansible is *not* easy to mock various things right now, and we have to use integration tests for many features where we'd also like unit tests - We want to maintain *full and absolute* compatibility with all existing modules and language features. There is a possible chance, that we may seek to avoid the best we can, that some lookup or action plugins might have to change in a VERY VERY INSIGNIFICANT way. - We'd like to correct some sprawling constructors, like Runner() - More specifically, refactoring and cleanup is intended to give us some new particular capabilities: * block support -- try/except type logic that allows blocks of code to specify other code that can recover from errors without failing the playbook run, that does not have to emulated via simple "when" statements. * optional parallel asychroncity - there's a current architectural choice in ansible playbooks that makes things easier to read and study where each task must complete before going onto the next, and each set of hosts in a play must get the same number of task "objects". While this first things is something we want to keep as behavior, we don't need to require it, and the second is something we want to not require as well. For users that want to dive into the technical weeds, this would enable some new things - include + with_items back in full, roles having "with_items", and those items also including *inventory scoped* variables. This may also pave the way for running multiple plays at the same time, though this is not an immediate goal. * make way for future Python3 compatibility on the control node- requiring Python 3 will not be an immediate requirement for the control system, but something we want to eventually support as more distros may ship python3 default over time. We will deal with Python 3 in the modules at a *much later* point in time, as it's more important to work with stock python on distros. Nevertheless, we are expecting this time to come, but this is only a step in that direction. * line numbers on all errors throughout the application - show what task failed where, not just the name of the task. * in general, preserve the element of suprise by making it even MORE easy for new contributors to understand the core application and contribute to it, and add new features we didn't anticipate While this effort is going on, we're still spending significant amount of time merging things on the main project, core modules repo, and extras modules repo. The previous split of the modules into seperate repos also enables this effort by making it easier to identify new features that do *not* affect any of the v2/ tree efforts so far. In order to simplify the kick-off of this effort, we are *not* entertaining bug reports, pull requests, or feature requests on the "v2/" tree at this time as we're laying down foundations and getting patterns established -- and in fact -- most users of the devel branch won't even notice the v2 tree exists, nor is it included in Python packaging. Our anticipation is that somewhere in 1.9 (which is the plan, though, in the worst case, 2.0) timeframe, the 'v2/' tree replaces the main tree as we will have moved enough things over, and in userland, there will be almost nothing to notice. At the time this happens, devel will use that codebase, etc. Remember also that the 'v2' in the tree is a temporary path, and does not imply this is slated to line up with a 2.0, and in no uncertain terms should it be viewed to imply any incompatibilities in playbook language interpretation. Some *might* occur, but our plan is for none. I wanted to cross post this as not everyone is on ansible-devel, but please direct questions on this topic to ansible-devel specifically. Thanks! --Michael -- 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%2BnsWgxA-xvHvTTQGqipmxP1Qn7i%3DhFAPPfrNW74N%3Du5J3NMTA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
