Themes for 1.0, and future goals

Archives Ansible Project
1

Earlier I had stated that a 1.0 release doesn't mean a lot to me as a
milestone number. Though, given that Ansible has evolved to the
point where I want it to be, I think it's a bit of a coincidence that
1.0 is that number!

Language and implementation wise, Ansible has reached the goal I set
out for it. It is (generally) simple and accessible (though
sometimes folks push it a bit further than I intended -- I encourage
everyone to write as human readable playbooks as possible), but I
don't want to keep expanding it in an unbounded way. What I want to
do now is shift a bit in the way we are looking at releases, and
Ansible in general. This is a really high energy community, and I
want to shift it a bit, and I want us to slow down and spend some time
looking at a mostly stable set of code.

So, for 1.0, here is how I am going to be looking at pull requests --

(A) We are going to slow down adding new large features and make sure
we really need to have something. If 2000 people didn't need X
before, and we get a request for X, do we really really need X? Etc.

(B) We are going to try to stop moving code around. In the interest
of low bug counts, I want to see surgical pull requests, not large
code changes or refactorings. We have had a lot of churn
around template evaluation and variable precedence -- and lots of
great fixes, but I don't want to experience that kind of defect volume
again. So, code is largely going to become a boring
endeavor of keeping it running.

(C) We are going to try to bound the rate of growth of
modules/plugins, and concentrate more on making sure modules are solid
and cross platform, and fix problems where they are found. The
criteria
for addition of any new module is something that would be used by at
least 10-15% of the user base -- such that any bugs or limitations on
the module are found nearly *instantly*.

In summation, the goal for 1.0 should be to have a very uninteresting
changelog -- and take bugfixes for various modules and things when
they come in. I want to prevent Ansible from growing unbounded
on the core feature front, so it remains possible to fully understand
in a relatively short period of time.

So, if I seem like I'm closing too many pull requests, this is why...
it is because I think we're basically there, and our goals should
therefore change a bit.

--Michael

2

Hi Michael,
What are your thoughts on the future plans for the REST interface and potential web front end that came and went a couple times in the past few months? I’m definitely interested in something that would allow users to execute specific playbooks and get feedback from their execution via a web front end (test environment deployments are a great example), though I’m less interested in being able to manage inventory from such a front end, which was the initial thrust of ansible-commander a couple months ago. Hopefully I’m not the only one but I’d be curious about both your thoughts and whether anyone else is still interested in this :slight_smile:

thanks!
matt

3

Right ... I think our thoughts around inventory was that it was more
likely inventory would be managed by external scripts too, which is
why the REST interface around inventory did not exist. We still
should allow the inventory file location to be a directory such that
it can contain multiple files and/or scripts, or otherwise support
multiple inventory files with ":" as a seperator (either way).

As for triggering playbooks via a REST interface, I'm not against
it... though I don't think it's something core needs.

It would be great to have an example somewhere on github to point to,
and if using something like the keychain project to wrap SSH agent, it
does not seem to be *that* complex, though it should probably talk to
a job engine of some kind and include some callbacks.

In any event, it's not something I personally am going to be working
on, but it would be nice to have as a seperate project if someone
wants to build it.

--Michael