4 ms·

In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. After I pointed out why this was in fact a valid bug, the bug wasn'

In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. After I pointed out why this was in fact a valid bug, the bug wasn't reopened, but instead left closed while I was told "you're welcome to submit a PR". Basically I'm being told the bug isn't important enough for the upstream to fix and that they care so little about the bug that they won't even leave it open for someone other than me to fix. It's generally considered a rude response in the open source world because it's telling users they aren't worth your time. It's a warning sign of an unfriendly upstream.

mpdehaan2 12y ago
Hi Ryan, I'm sorry you feel that way. In our case, we get a TON of bug report traffic - many are just user questions which we'll direct to the list, some are just nice to haves, we file most of the good ones, but not always. Though I would consider performance tuning of the user module not a bug, and I do not think the newline behavior of copying the file on the filesystem was a bug either. A discussion on ansible-project would have been welcome after you felt we had taken the wrong track, but when we feel some requests aren't worth our time, it's because we have a huge audience to serve and are triaging everything. We feel it would have been unfair to you to let it sit infinitely when we were unlikely to spend time on it.
- ryan_lane 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        CM tools are not supposed to do the deployment but configuration and management of environment. You should do deployments with a tool like Jenkins.
    - 12y ago
fred_durst 12y ago
> In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. Maybe that is what you might have said in your blog post instead of a snarky comment. Remember, many people in open source are not from the upper middle class United States / West Coast and will likely not pick up on clever passive aggressive jabs. I completely understand that they are great for being able to deny any accountability for your attacks, but it generally leads to a lot of misunderstanding. Especially from those who do not speak English as their first language. I really don't mean this to jump on you, but hopefully you might take it as some advice when dealing with large distributed projects that passive aggressive snark, I would guess, ends up actually going over the head of 50% or more of the people.
- ryan_lane 12y ago
  It wasn't meant as snark or passive aggressive. It's a common topic in open source projects, but it's possible that I was speaking towards an audience that already knows the topic. Sorry if I hadn't explained well, that's my failure.

mpdehaan2 12y ago

Hi Ryan, I'm sorry you feel that way. In our case, we get a TON of bug report traffic - many are just user questions which we'll direct to the list, some are just nice to haves, we file most of the good ones, but not always. Though I would consider performance tuning of the user module not a bug, and I do not think the newline behavior of copying the file on the filesystem was a bug either. A discussion on ansible-project would have been welcome after you felt we had taken the wrong track, but when we feel some requests aren't worth our time, it's because we have a huge audience to serve and are triaging everything. We feel it would have been unfair to you to let it sit infinitely when we were unlikely to spend time on it.

ryan_lane 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      CM tools are not supposed to do the deployment but configuration and management of environment. You should do deployments with a tool like Jenkins.
  - 12y ago

fred_durst 12y ago

> In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. Maybe that is what you might have said in your blog post instead of a snarky comment. Remember, many people in open source are not from the upper middle class United States / West Coast and will likely not pick up on clever passive aggressive jabs. I completely understand that they are great for being able to deny any accountability for your attacks, but it generally leads to a lot of misunderstanding. Especially from those who do not speak English as their first language. I really don't mean this to jump on you, but hopefully you might take it as some advice when dealing with large distributed projects that passive aggressive snark, I would guess, ends up actually going over the head of 50% or more of the people.

ryan_lane 12y ago
It wasn't meant as snark or passive aggressive. It's a common topic in open source projects, but it's possible that I was speaking towards an audience that already knows the topic. Sorry if I hadn't explained well, that's my failure.