Project goals and expectations -- why "no" to various good feature requests

Archives Ansible Project
1

Just a note for newcomers…

Ansible is a minimal system. It’s codebase desires to stay small, and be as super easy to understand as we can make it.

This means saying no to a lot of features, but it’s been considered in a way that means what most people will want to do is possible, just not always in the exact way you personally might want to do them. The core will always grow slowly and conservatively. Making the app super easy to contribute to, use, and keep totally in your head at all times is a major goal.

When I built this tool, I designed it for people who didn’t want the complexity. I also wanted to make the OSS management tool that was the easiest to write modules for.

So, going forward, all decisions are made around those original goals. As we pick up more and more audience, that will not change.

When I say “No” to a feature request or idea, I’m not really just saying No to that idea, but I’m saying “I want to hold to those original project goals and not alienate that original audience”.

So, for instance, dry-run mode is never going to happen – I personally think that idea is unreliable, but worse it would make it incredibly hard for people to contribute modules. And that audience is more important than the audience that needs dry-run mode, or diffs of file changes, or 4 different types of output, etc.

Basically, we’re going to do what’s good enough for 80% of the users out there, slightly favoring simpler options, rather than trying to do everything.

I think if you try to do everything well, you can’t concentrate, and you end up not doing anything very well, and you acquire a lot of bugs. So we’re going to evolve slowly and keep the core super small and tight.

–Michael

2

I do relate to the goals of the project, however the functionality we are discussing here (seeing the effect of changes, and more useful output) should address 80% of the existing/new users.

I'd be surprised to see a majority of the users not being interested to exactly see what the effect is of running a play on the system, without doing any harm. It helps with creating playbooks, templates and eases automation and makes changes auditable.

The effect on writing modules can be avoided if this mechanism is not mandatory and Ansible can report that a certain module does not implement the functionality. (For some of the modules it simply means doing nothing at all anyway)

So I am surprised this would alienate the original audience or that such additional functionality goes against the project's goals.

3

I do relate to the goals of the project, however the functionality we are
discussing here (seeing the effect of changes, and more useful output)
should address 80% of the existing/new users.

I'd be surprised to see a majority of the users not being interested to
exactly see what the effect is of running a play on the system, without
doing any harm. It helps with creating playbooks, templates and
eases automation and makes changes auditable.

You're referring to dry run mode, you can totally see the effect of running a play on a system.

Dry run mode is complex (defeating the goals of ansible being minimal) and also highly misleading, which is why we aren't doing it.

The best way to test is to test in cloned/staged environments, where you really know that you can't connect to your database or your service won't start because your config file is wrong.

The effect on writing modules can be avoided if this mechanism is not
mandatory and Ansible can report that a certain module does not implement
the functionality. (For some of the modules it simply means doing nothing
at all anyway)

I value consistency to be an extremely critical value in making a project usable, and we are going
to hold all modules to the same standard, so they all work the same way.

And I want them to be short, well audited, and not subject to having a lot of corner cases that are subject to bitrot.

Doubling the size of each module is bad for that.

So I am surprised this would alienate the original audience or that
such additional functionality goes against the project's goals.

Keeping things extremely small, tight, and maintainable is a goal above many others. As is consistency. I said this when I started that this is what I would always go back to, and people didn't believe me, and thought this would grow into some giant thing. It hasn't, because I'm holding true to that. It is small, it does lots, but not everything.

People are going to disagree, and I'm telling you why I disagree. But I'm not persuadable in that regard because that's not something I want for Ansible. In fact, I want to NOT have it.

With all due respect, it's kind of a little Red Hen situation, and this is one of the things I actually dislike most of Open Source. People have lots of demands, request ponies, request other people to do a ton of work for them, and are then shocked that they were asking for a pony from an alpaca farm (for free), and they get the response that someone is not interested in breeding ponies, but wouldn't you like a nice alpaca? We sell alpacas here. And we're giving them away (YESSS!!!!), but no, we won't raise a free pony for you, and have no interest in such, and they would mean taking time away from the alpacas. There is a sense of entitlement that I want to discourage. If there were a customer relationship, this might be different, where I'd be willing to sell out and implement a lot of business features I didn't believe in, but this is not that project.

This is not directed specifically at you, but in general -- in navigating a sea of people with different opinions, different people will have different opinions, and I'm not about to let the loudest person win every time. Lots of people like our "keep it simple" philosophy, and that is why you pick Ansible. You pick competitors for other things.

Dry run is not a good safety valve for detecting errors from config change and incurs too high development cost relative to the value provided, ergo, we will not be doing it.

--Michael

4

Well said, and one of the main reasons I think this project will succeed in a niche where others have only almost succeeded.

5

I was not just referring to dry run mode, I was more referring to having a diff as well. Even without a dry run mode, having a diff is useful to relate problems to changes.

In a repository you can see abstract changes, which may appear correct. On the system you can see the latest state only, but you cannot see what the previous state was. Havings diffs allow you to verify if the changes that were made were in fact what you expect.

…>8…

But I don’t have to persuade you, I’ll just write my own modifications.

I am extremely interested in your modifications. I would be interested in helping out. I think we need to be sure that whatever we come up with, it won’t break when Ansible changes its behaviour. Let’s hash it out off-list.

6

Side note -- Please don't reply to very old threads. This could be a
new topic.

Copy backup was being discussed in IRC today, skvidal said he may add it.

If you want to work on it first, coordinate with Seth.

7

I added it to my branch and sent a pullrequest today.

It's here:
https://github.com/ansible/ansible/pull/828

I've tested it with copy and template and it works.

you just add backup=true to copy commands.
-sv

8

I had hacked something into ansible early on in my environment similar
to this (not something pull-worthy as it's got some hardcoded paths
that work for me and probably not others, as well as the fact it's
"always on", not an option). But one piece of feedback I'd have is
that making a copy next to the existing file is probably not the best
way to do this. It's the way I initially did it, and then I ran into
trouble when I started managing files in /etc/cron.d, for example
(cron jobs started running twice). What I ended up doing is copying
the original files to /tmp/ansiblebackup. This leads to its own
problems and tradeoffs in complexity, though... for example, I just
drop the old file directly into that directory and append a datestamp.
Makes it easy to find, simple to understand, but obviously if I have
two files who are at different paths, but whose basename is the same
and I back them up at the same time, one gets overwritten by the
other. I don't care about that so much in my environment, but it's
probably not the best decision for a general solution. Another option
is to mirror the whole path into something like /tmp/ansiblebackup, so
if you copy in a new /etc/sudoers, for example, you end up with
/tmp/ansiblebackup/etc/sudoers.$datestamp.

matt

9

every .d directory I know - including cron.d and sudoers.d ignores files with a ~ extension.

If they do not then they should be fixed b/c every editor I can think of leaves those files.

I just checked the source of cronie and and both of their crontab. They also ignore files starting with #

I also just looked at the source of run-parts - the script which runs the cron.daily jobs.

And that ignores files matching all sorts of things - including:

# Ignore *~ and *, scripts
for i in $(LC_ALL=C; echo ${1%/}/*[^~,]) ; do
     [ -d $i ] && continue
     # Don't run *.{rpmsave,rpmorig,rpmnew,swp,cfsaved} scripts
     [ "${i%.cfsaved}" != "${i}" ] && continue
     [ "${i%.rpmsave}" != "${i}" ] && continue
         [ "${i%.rpmorig}" != "${i}" ] && continue
         [ "${i%.rpmnew}" != "${i}" ] && continue
         [ "${i%.swp}" != "${i}" ] && continue
     [ "${i%,v}" != "${i}" ] && continue

So - if you have a cron daemon that didn't know better then you should file a bug with your distro provider - they're shipping you bad stuff.

-sv

10

...

So - if you have a cron daemon that didn't know better then you should file
a bug with your distro provider - they're shipping you bad stuff.

Nope, I just wasn't aware of this general practice of .d's ignoring
files w/specific syntax, and I hadn't included that syntax in the
copies of files I was making. Thanks!

matt