15:05:09 <sdoran> #startmeeting ansible core IRC meeting
15:05:09 <zodbot> Meeting started Thu Aug 15 15:05:09 2019 UTC.
15:05:09 <zodbot> This meeting is logged and archived in a public location.
15:05:09 <zodbot> The chair is sdoran. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:09 <zodbot> The meeting name has been set to 'ansible_core_irc_meeting'
15:05:13 <sdoran> There we go
15:05:25 <sdoran> Sorry, I don't run this often enough.
15:06:25 <sdoran> #topic https://github.com/ansible/ansible/pull/59060
15:06:34 <sdoran> felixfontein: Are you around to discuss this?
15:07:19 <nitzmahone> o/
15:07:25 <sdoran> #chair nitzmahone
15:07:25 <zodbot> Current chairs: nitzmahone sdoran
15:08:07 <sdoran> Ok, we'll move on to the next topic then.
15:08:13 <sdoran> #topic https://github.com/ansible/ansible/pull/56549
15:08:13 <maxamillion> .hello2
15:08:14 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:08:18 <sdoran> #chair maxamillion
15:08:18 <zodbot> Current chairs: maxamillion nitzmahone sdoran
15:08:20 <maxamillion> sorry I'm late
15:08:25 * gundalow waves
15:08:25 <sdoran> resmo: You're up.
15:08:33 <sdoran> #chair gundalow
15:08:33 <zodbot> Current chairs: gundalow maxamillion nitzmahone sdoran
15:09:20 <resmo> yes, I am around
15:09:31 <sdoran> The floor is yours.
15:10:21 <resmo> https://github.com/ansible/ansible/pull/56549
15:11:03 <resmo> we didn't have enough quorum to vote for this, so I bring this up again
15:11:10 <nitzmahone> Looks ok to me at a glance
15:11:21 <abadger1999> I can see both sides of whether we want that.
15:11:28 <sdoran> #chair abadger1999
15:11:28 <zodbot> Current chairs: abadger1999 gundalow maxamillion nitzmahone sdoran
15:11:45 <nitzmahone> If someone's explicitly disabled the cache update, we should probably honor that
15:12:10 <resmo> and in case it fails, user can deal with it anyway
15:12:33 <abadger1999> on the one hand, we're updating the cache and the user doesn't understand why (because they said not to).  On the other hand, the automatic install of dependencies is transparent to the user and updating the cache is part of that transparent, behind the scenes thing.
15:12:33 <nitzmahone> Yeah
15:12:51 <abadger1999> Solid +0 from me ;-)
15:13:46 <nitzmahone> So long as it's defaulting to the sane behavior, if someone's explicitly disabled it, the proposed behavior LGTM
15:14:04 <gundalow> Is this a big enough change for porting_guide?
15:14:19 <abadger1999> resmo: By chance did you research the history of updating the cache there?
15:14:42 <abadger1999> I'm just wondering if it was added in response to a bug report.
15:14:45 <abadger1999> gundalow: ++
15:15:05 <resmo> no i didn't but it is a common way to first update cache
15:15:15 <gundalow> (Given we are discussing if it's right change or not, that feels like we should give heads up to users)
15:17:32 <maxamillion> I think I'm fine with the change so long as it's in the porting guide, it definitely sounds like "this is now actually doing what the user asked for" but we should certainly let users know that the behavior is changing just in case they didn't actually want that but didn't realize it because it "just worked"
15:17:41 <maxamillion> +1
15:17:57 <shertel> +1 since the default behavior seems sane. The porting guide entry also sounds like a good idea.
15:18:11 <gundalow> +1 to what you two said
15:18:19 <sdoran> Seems we could get stuck if the dependency can't be installed because it's not in the cache, and the task specifics the cache shouldn't be updated.
15:18:38 <sdoran> But maybe it's better to do what the author asked rather than try to be helpful behind the scenes.
15:18:57 <gundalow> principal of least surprise
15:19:00 <abadger1999> resmo: Hah!  looks like you added the apt-get update 0313c517e96d2308f71982750265163670198023
15:19:10 <resmo> boom
15:19:12 <abadger1999> (That's in ansible-modules-core
15:19:23 <abadger1999> apt: update index before trying to autoinstall python-apt
15:19:51 <sdoran> +1 (with a porting guide entry)
15:20:05 <sdoran> Any other votes?
15:20:23 * nitzmahone mumbles something about roosting chickens ;)
15:20:53 <sdoran> #agreed Merge https://github.com/ansible/ansible/pull/57266 once a porting guide entry is added
15:21:09 <sdoran> #topic https://github.com/ansible/ansible/pull/57266
15:21:22 <abadger1999> https://github.com/ansible/ansible-modules-core/commit/0313c517e96d2308f71982750265163670198023
15:21:48 <abadger1999> Sorry still exploring history o nthe last one... will discuss more with resmo in another channel as I discover more
15:22:37 <gundalow> sdoran: fyi, I just added something to the agenda
15:22:45 <sdoran> 👍
15:23:12 <maxamillion> gundalow: modifying the plane mid-flight are we? :)
15:23:38 <gundalow> maaaaaaybe
15:23:44 <gundalow> (because I forgot to add it earlier)
15:25:39 <sdoran> Any thoughts on #57266?
15:26:16 * nitzmahone isn't personally a fan of silent and unconfigurable retry behavior
15:29:07 <maxamillion> nitzmahone: +1 to that
15:30:54 <sdoran> #undo
15:30:54 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f6d4a2d03d0>
15:31:12 <sdoran> #undo
15:31:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f6d46709a50>
15:31:31 <sdoran> #agreed Merge https://github.com/ansible/ansible/pull/56549 once a porting guide entry is added
15:31:42 <sdoran> #topic https://github.com/ansible/ansible/pull/57266
15:31:50 <sdoran> Sorry, I had the wrong PR number.
15:33:11 <sdoran> Would exposing controls for this be better than making it a silent background implementation?
15:33:30 <abadger1999> Looks like people are leaning towards "this is okay if a retry count parameter is added" ?
15:33:35 <sdoran> Is it possible to just handle the retries in the task rather than in the module?
15:35:59 <nitzmahone> That's the ideal, but sometimes it makes sense to do in the module... But it should be configurable IMO if that's the case
15:36:40 <nitzmahone> At minimum disable, or ideally with max count/delay
15:36:52 <sdoran> Would a boolean toggle or number of retries be a better parameter?
15:37:49 <sdoran> Something like `retry_cache_update: yes` or `cache_update_retries: 2`
15:37:50 <shertel> or a timeout
15:39:43 <sdoran> So we're ok with this so long as it has an interface of some sort.
15:41:09 <shertel> +1
15:41:24 <sdoran> Votes for A) boolean toggle, B) int for number of retries, C) int for setting a max timeout
15:42:49 <sdoran> resmo: do you have an opinion? Do those options seem ok?
15:43:31 <resmo> sdoran: yes, I would take A + B
15:43:40 <resmo> wrong
15:43:44 <resmo> B + C :)
15:43:51 <abadger1999> Whatever interface eventually happens should probably revisit the code in apt to make sure it makes sense there as well.
15:44:06 <resmo> abadger1999: that is the next PR :)
15:44:07 <sdoran> That's the next PR up for discussion.
15:44:10 <abadger1999> :-)
15:44:23 <sdoran> I agree, though. They should have the same interface and behavior.
15:45:28 <resmo> so btw, I undertand C as max timeout between retries
15:46:23 <sdoran> B +1 for me
15:46:27 <shertel> I'd call that a delay. I think a lot of modules use a wait_timeout option as the total time and figure out the number of retries from that.
15:46:46 <shertel> but I'd be in favor of B + a delay option.
15:46:53 <sdoran> Though inevitably someone will ask for the ability to control the delay between retries.
15:47:10 <sdoran> And we've reinvented many task level mechanisms inside a module.
15:48:33 <shertel> for AWS modules it makes since, since we can retry just throttling/limit errors, but we wouldn't want to retry legitimate issues that won't resolve themselves. But in general it seems better to handle on the task.
15:49:06 <abadger1999> It seems like this makes sense if a module does several things and we only want to retry one of them.  Is that the case here?
15:52:12 <abadger1999> resmo: ^
15:54:44 <sdoran> We have about five minutes left in the meeting.
15:54:45 <resmo> it does 2 things update the cache und handle the repo files
15:54:53 <sdoran> Any more votes on this?
15:54:57 <gundalow> sdoran: would like to do my topic
15:56:09 <sdoran> Seems we haven't made a final decision on this interface.
15:56:28 <sdoran> But we would like some parameters to control the retry behavior.
15:56:41 <resmo> ack
15:57:43 <sdoran> resmo: Could you work on implementing parameters for max retries and a timeout?
15:57:57 <sdoran> Maybe talk with shertel more about the nature of the timeout behavior.
15:57:58 <resmo> sdoran: yes,
15:58:32 <sdoran> #action resmo to add parameters to `apt` and `apt_repository` for max retries and a timeout
15:58:47 <shertel> s/timeout/delay/ ? Sounds good to me.
15:59:06 <shertel> or per-retry timeout
15:59:24 <sdoran> resmo: We can continue the discussion in the relevant PRs.
16:00:05 <sdoran> resmo: Does this also cover PR #60527 or do we need to discuss that one specifically?
16:01:01 <resmo> it also covers this PR
16:01:18 <resmo> Fine to move on
16:01:23 <sdoran> Thanks!
16:01:33 <sdoran> #topic https://github.com/ansible/ansible/pull/60222
16:01:38 <sdoran> gundalow: You're up.
16:02:06 <gshippey_> FYI discount what was said about a regression
16:02:37 <gshippey_> I fed jon the wrong info there, fix was only PRed into devel as it stands
16:03:18 <abadger1999> <nod> Okay.
16:03:21 <gundalow> #chair gshippey_
16:03:21 <zodbot> Current chairs: abadger1999 gshippey_ gundalow maxamillion nitzmahone sdoran
16:03:45 <gshippey_> But in any case stein users are pinned to ansible 2.7 and our release cycles make it hard to fix bugs in ansible when theyre found
16:08:20 <sdoran> So the discussion is whether to backport this bugfix to 2.7 since it is in security and critical bug fix mode.
16:08:33 <sdoran> Essentially whether or not this constitutes a critical bug.
16:08:38 <shertel> this is unfortunate but it doesn't seem like it should be backported to 2.7. It looks like the initial bug report was opened for 2.5 https://github.com/ansible/ansible/issues/37921
16:08:38 <abadger1999> Yeah.
16:08:45 <gshippey_> Yes, thats what is boils down to
16:08:56 * resmo is leaving --> train o/ thanks
16:09:14 <sdoran> resmo: Thanks for attending!
16:10:13 <gshippey_> I guess the larger issue for us in away is the development cycles dont match well so its hard for us to continue to maintain a longer term project without your support 🤷 otherwise we're having to maintain our own forks through a whole release of openstack
16:11:06 <cyberpear> RHOSP 13 still requires 2.4...
16:11:42 <cyberpear> (the current long term release of RH OpenStack)
16:12:26 <abadger1999> <nod> Yeah, we probably need someone to talk that aspect through with you... it doesn't sound like the present way of doing it will satisfy either you or us.
16:13:14 <abadger1999> For that conversation, the first question is probably, what can we do to make upgrading to 2.8 (and 2.9, a2.10, etc) easier.
16:13:51 <gshippey_> 👍 I appreciate this bugfix is a push to call a critical fix as well
16:14:24 <sdoran> I agree with shertel. This is a rather unfortunate situation but does not appear to be a critical enough bug to justify a release. What's the scope of the impact?
16:14:40 <gshippey_> I guess by providing a longer time frame in which we can make fixes to older versions of ansible (you guys work in 4 months right??) particularly if its a module we use
16:14:41 <sdoran> Is it every single person using OpenStack Stein every day all day?
16:15:23 <sdoran> I guess it depends on how ofter they use os_router and os_subnet, which I suppose varies highly.
16:15:46 <gshippey_> Any one running the test suite over their real world instance that would like it to pass is likely to hit this issue
16:16:05 <sdoran> We definitely don't want to make using Ansible painful. But we also can't maintain all the old releases forever.
16:16:15 <gshippey_> http://codesearch.openstack.org/?q=os_subnet&i=nope&files=&repos=
16:16:25 <cyberpear> I use those several times a week, ftr
16:16:34 <gshippey_> thats os_subnets usage
16:16:37 <abadger1999> <nod> And I've been turning down backports that aren't critical.... so it needs to be jsutified as critical in some way.
16:16:37 <gundalow> gshippey_: I wonder if there are ways we can make it easier for projects to update
16:17:16 <abadger1999> @gundalow yeah, that's going to be the only long term way forward, I think.
16:18:01 <cyberpear> or time to make an LTS fork, only for certain use cases?
16:18:22 <cyberpear> debian is still making security patches to very old versions
16:18:37 <gshippey_> Im sure there would be projects that would be interested in an LTS
16:18:46 <gshippey_> outside of openstack
16:18:57 <abadger1999> an LTS could also work but (1) that's even longer term than making it easier for projects to update (2) Lots of figuring out to do around that.
16:19:03 <cyberpear> but in general, I'd be happier without breakage and stay current
16:19:26 <abadger1999> Collections are another thing that could help (if openstack starts managing their modules in collections, then they'd be able to control their own release schedule)
16:20:07 <gshippey_> That sounds like a good idea, I'll have to see if its been discussed before
16:20:42 <cyberpear> (I brought up the osp13 req for 2.4 because I learned the hard day it doesn't work with newer versions)
16:21:06 <gshippey_> Are collections a newer feature in ansible?
16:21:14 <cyberpear> the problem with openstack maintaining their own collection is that they require a CLA, which I'm (and others I'm sure) unable to sign generally
16:21:23 <cyberpear> gshippey_: new in 2.8
16:21:34 <gundalow> gshippey_: https://docs.ansible.com/ansible/devel/dev_guide/collections_tech_preview.html
16:22:34 <gshippey_> Interesting, could be something to work towards, at least it would give us greater oversight in this kind of situation
16:23:13 <gshippey_> I don't think we're going to come to a solution today and considering we're already running over time I think I'll have to let this one go
16:23:35 <gundalow> gshippey_: Have you seen https://docs.ansible.com/ansible/devel/porting_guides/porting_guides.html
16:25:17 <sdoran> We have run over quite a bit so far. Any conclusion around this topic?
16:25:55 <gundalow> If it's been agreed we aren't backporting it, I think that's all we can achieve today
16:28:49 <sdoran> Unfortunately, I haven't seen a strong case for considering this a critical bug fix.
16:29:21 <sdoran> Do we agree on that or do we want to discuss this more at the next meeting?
16:29:47 <abadger1999> <nod> I need at least some justification otherwise it opens the flood gates to everyone wanting to have a bug fixed in 2.7.x
16:31:04 <abadger1999> gshippey_: Assuming this doesn't get backported, another thing that openstack could try is shipping the updated modules as part of a role.  If you import the role early enough, the modules in the role would override the one that ansible provides.
16:31:53 <gshippey_> Unfortunately I think its a justification I dont have outside of its a maintenance headache for us, @abadger1999 thanks for your suggestion, I'll see if we can do it that way
16:33:10 <sdoran> #agreed https://github.com/ansible/ansible/pull/60222 is not a critical bug fix and not eligible to be backported to 2.7
16:33:20 <sdoran> Wrapping up now since we are pretty well over.
16:33:27 <sdoran> Thank you all for coming.
16:33:29 <sdoran> #endmeeting