You are welcome to join the meetings, proposals and submit issues for changes.
On Fri, Aug 17, 2018 at 11:42 AM Ilsa Loving <ilsadlov...@gmail.com> wrote: > And yes, I know that. Now. > > My point is that that's not good enough. It's not acceptable to make > wide-ranging fundamental changes to the system, and then say "It's in the > docs. You need to read the docs." > > If Ansible is going to make changes so significant that it is guaranteed > to break existing playbooks, then it *cannot* follow the traditional > upgrade path where you simply update the version number of the > rpm/deb/whatever, and toss it into the pile for upgrading. Each release > needs it's own versioning as part of the name (ie: have ansible2.5, > ansible2.6, etc.) so that people can be assured that when they do a yum > update, then their stuff will still work afterwards. Apache did this when > they went from 2.2 to 2.4. People had plenty of issues during the > transition, but surprise upgrades that broke their infrastructure wasn't > one of them. > > I've been doing a lot of reading, and have come across a very large number > of people who share the same frustrations. Ansible is supposed to make > sysadmin lives easier. Instead, people have had to resort to > version-locking Ansible (as we have done), or implementing entire > continuous delivery paths just for Ansible. Or they've given up on it > entirely and reverted back to bash scripts, cause bash scripts don't break > every 3-6 months. > > IMO that is absolutely absurd. Infrastructure is not software. It's > infrastructure. It has to be solid, because everything else depends on > it. If Ansible is to be a key element in managing infrastructure, it too > has to be solid. Why should I use something that adds to my workload > instead of reduces it? > > Ilsa > > On Friday, 17 August 2018 11:14:32 UTC-4, Jonathan Lozada De La Matta > wrote: >> >> I think you misunderstood our comment and taking it a little far. They >> are going to be changes to software, all of them makes changes. But, like >> mentioned before we have docs and notices for this exact reason. >> >> On Fri, Aug 17, 2018 at 10:51 AM Ilsa Loving <ilsad...@gmail.com> wrote: >> >>> The issue was that the person that originally wrote the scripts quit, >>> and we were parachuted in as emergency resources to try to get everything >>> going. And Ansible just happened to put out an update to 2.5 in the same >>> time frame, so when we did 'yum install ansible', we had no way of knowing >>> that the version we were installing was different from the one he was using. >>> >>> But you're right, it was completely our fault. We should have known >>> (apparently by osmosis) that Ansible changes it's APIs capriciously with >>> every single version, that backward compatibility is for losers, and that >>> all Ansible packages are treated as minor in-place updates so if you >>> haven't locked down the version ahead of time, a routine yum update will >>> break your entire setup. >>> >>> I mean, heaven forbid that someone might expect a critical operations >>> tool like Ansible to have a modicum of stability between minor releases. >>> >>> On Thursday, 16 August 2018 18:34:13 UTC-4, Jonathan Lozada De La Matta >>> wrote: >>>> >>>> your issue was in " but it boils down to the fact that the 'upgrade' >>>> was unintentional and cost us three weeks of head scratching.". Ansible >>>> docs, changelogs and release announcements talk about all the changes that >>>> happened. If its something that happened in your environment then its not >>>> really ansible's fault. >>>> >>>> On Thu, Aug 16, 2018 at 5:40 PM Karl Auer <ka...@2pisoftware.com> >>>> wrote: >>>> >>>>> In three weeks of head-scratching you didn't realise the version of >>>>> A >>>>> nsible had changed, meaning you allow uncontrolled upgrades to your >>>>> production systems? >>>>> >>>>> Or in three weeks of head-scratching, knowing that Ansible had >>>>> upgraded, it didn't occur to you to read the release notes? >>>>> >>>>> It's a bit rough to blame Ansible for those... >>>>> >>>>> Regards, K. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 17, 2018 at 7:30 AM, Ilsa Loving <ilsad...@gmail.com> >>>>> wrote: >>>>> >>>>>> I'll skip the story since it's long, convoluted, and frustrating, but >>>>>> it boils down to the fact that the 'upgrade' was unintentional and cost >>>>>> us >>>>>> three weeks of head scratching. >>>>>> >>>>>> Thanks for the info. Now that I know how capricious Ansible is, we >>>>>> will need to reconsider how it is used, and how heavily. This kind of >>>>>> fundamental instability make Ansible a very high risk product to use. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> On Thursday, 16 August 2018 16:53:53 UTC-4, Kai Stian Olstad wrote: >>>>>>> >>>>>>> On Thursday, 16 August 2018 22.36.17 CEST Ilsa Loving wrote: >>>>>>> > This should theoretically add the instance to inventory so that >>>>>>> when we >>>>>>> > perform the following task later: >>>>>>> > # Perform server default tasks >>>>>>> > - include_tasks: set_server_defaults.yml >>>>>>> > delegate_to: "ec2_instance_host" >>>>>>> > become: true >>>>>>> > >>>>>>> > >>>>>>> > The task applies a number of changes such as yum updates, etc. >>>>>>> > >>>>>>> > But as soon as ansible is updated to 2.5+, this behaviour breaks >>>>>>> and >>>>>>> > instead applies all those server settings to the local host >>>>>>> running the >>>>>>> > playbook. >>>>>>> > >>>>>>> > So far our only solution has been to block updates and to keep >>>>>>> Ansible at >>>>>>> > 2.4, which is far from ideal. >>>>>>> > >>>>>>> > Does anyone have any insight as to why Ansible's behaviour would >>>>>>> change so >>>>>>> > fundamentally? This is a catastrophic disruption that has >>>>>>> seriously shaken >>>>>>> > our confidence in Ansible. >>>>>>> >>>>>>> Before upgrading it is crucial to read the porting guide >>>>>>> >>>>>>> https://docs.ansible.com/ansible/2.5/porting_guides/porting_guide_2.5.html >>>>>>> >>>>>>> for you, especial this >>>>>>> >>>>>>> https://docs.ansible.com/ansible/2.5/porting_guides/porting_guide_2.5.html#dynamic-includes-and-attribute-inheritance >>>>>>> >>>>>>> The short answer (for the long one read the links) the delegate_to >>>>>>> only applies to the include_tasks, not the tasks inside the include. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kai Stian Olstad >>>>>>> >>>>>>> >>>>>>> -- >>>>>> 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 ansible-proje...@googlegroups.com. >>>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/ansible-project/804d6159-b9bb-4283-a848-a6a30a82eb72%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/ansible-project/804d6159-b9bb-4283-a848-a6a30a82eb72%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Karl Auer >>>>> >>>>> Email : ka...@2pisoftware.com >>>>> Website: http://2pisoftware.com >>>>> >>>>> GPG/PGP : 958A 2647 6C44 D376 3D63 86A5 FFB2 20BC 0257 5816 >>>>> Previous: F0AB 6C70 A49D 1927 6E05 81E7 AD95 268F 2AB6 40EA >>>>> >>>>> -- >>>>> 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 ansible-proje...@googlegroups.com. >>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/ansible-project/CA%2B%2BT08R4vDm%3Dr5AGUUNox2yC-aPzO%3DAhfK_vP-orLHzaLVoGpg%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/ansible-project/CA%2B%2BT08R4vDm%3Dr5AGUUNox2yC-aPzO%3DAhfK_vP-orLHzaLVoGpg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> >>>> Jonathan lozada de la matta >>>> >>>> AUTOMATION CONSULTANT - AUTOMATION PRACTICE >>>> >>>> Red Hat Consulting Services <https://www.redhat.com/> >>>> >>>> jloz...@redhat.com >>>> >>>> >>>> >>>> >>>> -- >>> 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 ansible-proje...@googlegroups.com. >>> To post to this group, send email to ansible...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/35b35e98-d3eb-4c61-94f4-4273557b91cb%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/35b35e98-d3eb-4c61-94f4-4273557b91cb%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> >> Jonathan lozada de la matta >> >> AUTOMATION CONSULTANT - AUTOMATION PRACTICE >> >> Red Hat Consulting Services <https://www.redhat.com/> >> >> jloz...@redhat.com >> >> >> >> >> -- > 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 ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/54e706d0-fd39-438b-87f4-cc8ac0c943d0%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/54e706d0-fd39-438b-87f4-cc8ac0c943d0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Jonathan lozada de la matta AUTOMATION CONSULTANT - AUTOMATION PRACTICE Red Hat Consulting Services <https://www.redhat.com/> jloza...@redhat.com -- 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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAFYJA%2BLXRTuZvRoQ9JZtir0s8pca0JCmemZvuaAS8nJqmFxydg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
