[ryan_lane]

Yep. I understand that, but part of having an open source project is that others may find open bugs and decide to fix them because they're also having the same issue. Closing legitimate bugs hides them from the world and also gives people the impression that it's not something to fix.

The performance issue was very likely one of the more major deciding factors. Managing users was so slow that it was painful to do small iterative development. Slow performance is definitely a bug.

[mpdehaan2]

I think it's something that can be improved, yes. I'm not sure it's a bug, and I'm not sure it's really all that slow. We're talking about 0.5 seconds and maybe it could get down to 0.4? If you dig into the module I'm not sure what you would change. (Again, a fine discussion for ansible-devel probably? How would you solve it?)

In your case, managing a list of 80 users to be sure there or not, I might have suggested perhaps tagging that action and only running that every so often, but I do think that, in general, it wasn't a pressing thing for us.

There are going to be occasional tradeoffs to the way the task system does work (ability to be split declarative/imperative), but those are some of the prices to be had for the flexibility that can by (like "register:" versus the limitations of a server side compile up front).

I think I'm ok with that, all being said. It's how ansible came to be.

There are choices that you take building things one way versus another, and if we're down for time for a coffee and three spins around the office chair, or time for coffe and two spins around the office chair, it's still in statistical noise territory.

We have spent a lot of time optimizing the HECK out of the SSH transport, but no matter what, almost all deployments in any config tool, the majority of the time comes down to waiting on yum and apt. And yum and apt are brilliant and I love them, it's just where things lurk :)

[ryan_lane]

As a comparison, Salt checks the users, groups, ssh keys, etc. in under 1 second. Ansible to do the same set of actions was taking nearly 2 minutes. This was just to check, not even to take action.

So, yeah, the majority of time in an initial run is waiting on apt/yum, when nothing is changing the majority of the time is spent on checking things.

When you're making config management a part of your application's deployment process, waiting on checking is painful. This would have added 2 minutes to deployment time. When we doubled the number of users managed it would add 4. That's a really, really long time.

[jsosic]

CM tools are not supposed to do the deployment but configuration and management of environment. You should do deployments with a tool like Jenkins.

[reality_czech]

Ansible seems like a cool project... thanks for stopping by here.

One question, though. 0.4 seconds seems like a very long time to query one user/group, though. You should be able to query thousans of UIDs a second, minimum... unless you're using LDAP and you have a slow network or something. You could write a simple C program to query a bunch of UIDs and I bet it wouldn't even take a millisecond to run. So where is the overhead here for ansible? I apologize if this is a dumb question... I am not very familiar with the architecture.

[mpdehaan2]

it's definitely true that most of our users are deploying configs and applications so there's not a lot of user management, but the user management is definitely robust.

We're using GNU user tools in many cases for correctness and efficiency of not reinventing the wheel so you might wait a little more for them.

We're open to tuning but it's really not been a problem.

It's still statistical noise in the end, and, yeah, like we said, we've got more important things to work on first. It would be nice if we had time for everything, but this just doesn't rate in the grand scheme of things right now, still.

Someday, perhaps! Meanwhile, try things out, I don't think this will matter in practice for most folks :)