18:00:12 #startmeeting Ansible Community Meeting 18:00:12 Meeting started Wed Apr 14 18:00:12 2021 UTC. 18:00:12 This meeting is logged and archived in a public location. 18:00:12 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:12 The meeting name has been set to 'ansible_community_meeting' 18:00:12 #topic Agenda https://github.com/ansible/community/issues/539 18:00:12 abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping! 18:00:16 #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics 18:00:22 o/ 18:00:23 * samccann waves 18:00:24 o/ 18:00:24 \o\ 18:00:31 Hi :-) 18:00:34 Hello :) 18:00:35 #chair jillr samccann tadeboro dmsimard abadger1999 18:00:35 Current chairs: abadger1999 dmsimard felixfontein jillr samccann tadeboro 18:00:38 sorry, I'm out today - getting my first COVID vaccine jab 18:00:40 o/ 18:00:44 #chair lmodemal andersson007_ 18:00:44 Current chairs: abadger1999 andersson007_ dmsimard felixfontein jillr lmodemal samccann tadeboro 18:00:47 acozine: congrats! :) 18:00:48 acozine: congrats and take care 18:00:56 acozine: congratulations! 18:00:57 acozine: hurrah! 18:01:08 I'm excited and a little nervous about side effects 18:01:11 but mostly really happy 18:01:18 * acozine waves 18:01:22 Good luck acozine! 18:01:45 thanks everybody! 18:02:15 #topic Updates 18:02:19 #info No more collections can apply for inclusion in Ansible 4 18:02:19 #info Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 12 days 18:02:35 o/ 18:02:45 #chair aminvakil 18:02:45 Current chairs: abadger1999 aminvakil andersson007_ dmsimard felixfontein jillr lmodemal samccann tadeboro 18:02:52 Maybe we should do another round of reviews in a review day like last time before the approval deadline 18:03:20 dmsimard: There is not much happening, so not sure if we can do much. 18:03:45 Most collection did not even respond to the feedback from the first round of reviews. 18:03:50 I saw that some collections are moving to semver but I haven't followed up to see if there were other outstanding issues 18:03:53 :-/ 18:04:23 I think the netapp collections are worth looking at again; I think infoblox also did something, and dellemc also had some changes 18:04:41 netapp collections are almost there, yes. 18:04:41 I unfortunately didn't manage to really look at any of them again so far 18:05:18 any other updates ? gundalow/cybette ? 18:06:01 * dericcrago waves 18:06:13 #chair dericcrago 18:06:13 Current chairs: abadger1999 aminvakil andersson007_ dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro 18:06:27 I think the next 4.0.0 alpha is coming up today? tomorrow? 18:06:27 #info There's Red Hat summit coming up April 27th, there's bound to be Ansible things in it: https://www.redhat.com/en/summit 18:06:52 (no need to #chair me) - ansible-core 2.11.0 is still on track to ship end of April 18:06:55 Yeah, today 18:07:07 #info ansible-4.0.0a4 coming out today. 18:07:13 #info ansible-core 2.11.0 is still on track to ship end of April 18:07:17 thanks nitzmahone 18:07:17 #info #info No more collections can apply for inclusion in Ansible 4 18:07:17 #info Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 12 days 18:07:20 meh 18:07:21 #undo 18:07:21 Removing item from minutes: INFO by felixfontein at 18:07:17 : Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 12 days 18:07:22 #undo 18:07:22 Removing item from minutes: INFO by felixfontein at 18:07:17 : #info No more collections can apply for inclusion in Ansible 4 18:07:35 #info likely next ansible-4 prerelease will be ansible-4.0.0beta1 on April 27th 18:07:39 copy'n'paste fail :) 18:08:13 heh 18:10:12 so, I guess the first topic is by tadeboro on semantic versioning. it's not really that urgent anymore, but I guess it still makes sense to discuss it 18:10:16 #topic Allow non-semantic versioned collections in Ansible 18:10:16 #info Discussion: https://github.com/ansible-community/community-topics/issues/7 18:10:19 Background: the netapp collections did not use semver (that's now switched) 18:10:22 Question: do we want to allow such collections? (Right now our requirements say no.) 18:10:31 o/ sorry for being late 18:10:36 #chair cybette 18:10:36 Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro 18:10:58 (the clock is late, lol) 18:11:05 cybette: oh the irony haha 18:11:09 netapp still does not use semver in a strict sense, but it should be good enough for inclusion. 18:11:39 felixfontein: I would tend to side with "no" here due to how we use semver to control the introduction of breaking/incompatible changes in the aggregate community package 18:12:02 what's the not quite semver part of netapp? 18:12:11 I fully agree, I'm against including any collection which doesn't stick to semver 18:12:24 They can skip minor versions. 18:12:34 A lot of our tooling relies on semver to tell about compatibility. So if semver isn't used, it will cause issues. We can probably work around most of those by manually fixing ranges of permissible versions but it will be extra work. 18:12:35 I would even suggest to kick out collections that are actively not using semver (I don't mean accidents, these happen, but intentionally ignoring semver) 18:12:35 samccann: they're using year as major versin, month as minor version, and then a patch version 18:13:12 tadeboro: I agree with you that we'll be okay if they're just skipping minor versions. 18:13:15 abadger1999: +1, it "can" be done manually but I can see it get out of hand if there's too many of them 18:13:33 netapp now follows semver on a repository level. But unfortunatelly, they host 6 collections in that repo that all share the same tags ... 18:13:44 yep, skipping minor (or major or patch) versions is fine for me, since that doesn't affect the main guarantees semver gives 18:13:51 jillr: Hmm.... Do they also make guarantees about compatibility? 18:14:08 abadger1999: not sure yet, reading in https://github.com/ansible-collections/netapp/issues/93 18:14:12 Like, "We will only introduce backwards incompatible changes in our first release of hte year" ? 18:14:23 abadger1999: so far, no, they deprecate by date and that's it I think 18:14:26 abadger1999: their reply: https://github.com/ansible-community/community-topics/issues/7#issuecomment-816858851 18:14:32 netapp stopped using year as major version. 18:14:36 abadger1999: so whenever a version after a deprecation date is released, it should have breaking changes 18:14:42 `We strive to maintain backwards compatibility. If there is a strong enough justification, we will increase the Major release number to indicate a chance of a breaking change.` 18:15:02 ah ok, so it looks like they just started with the year (from their old scheme) as the current major versin 18:15:07 Netapp will stay on 21.x.y from now on until compatibility break. 18:15:08 18:15:13 jillr: that is my understanding as well 18:15:17 cyb-clock chimes: 15 min into the meeting 18:15:33 Okay, that should be fine as long as our policies remain that we'll accept forward-compatible new features into ansible minor releases. 18:15:38 All things considered, I gave a thumbs up as ar as the versioning is concerned. 18:16:11 so with the latest change, netapp is fine I think (or does someone disagree?) 18:16:21 yeah I'm +1 what they're doing now 18:16:33 +1 18:16:34 +1 18:16:36 +1 18:16:37 makes sense to me 18:17:01 +1 18:17:12 +1 18:17:32 +1 18:17:41 +1 18:17:55 +1 18:17:59 +1 18:18:02 #agreed the versioning aspect of the netapp collections is ok for inclusion with their new versioning system 18:18:25 OK, I will add more info to the ticket and close it. 18:18:35 tadeboro: thanks for bringing it up 18:19:10 I don't think we're done with that ticket yet? 18:19:29 we only discussed the netapp collection, not the question "Including Ansible Collections that do not follow semantic versioning" in general 18:19:31 in the sense that we are keeping the rule of required semver ? 18:20:23 from my POV semantic versioning is (next to licensing) the most important condition for a collection to be included - if that's not satisfied, a collection must not be included 18:20:31 O, right, I forgot I formulated the issue in a broader way. 18:20:54 felixfontein: +1 18:21:02 how are you all feeling about that? is it actually necessary to emphasize this more? 18:21:10 SO I guess the conslusion is: we still require semver, but netapp's versioning is compatible enough for now. 18:21:30 A lot of the things we do depends on it. So I would have to see a compelling example of why a collection cannot use semver to change my mind 18:21:34 tadeboro: +1 18:21:42 +1 18:21:56 I agree that we should keep the semver requirement. 18:22:00 * gundalow waves 18:22:07 tadeboro: is not skipping versions actually a requirement for semver? I cannot find it in the rules 18:22:10 VOTE: We still require semver. netapp's versioning is considered compatible enough that we accept it as semver for our purposes. 18:22:16 +1 18:22:21 #chair gundalow 18:22:21 Current chairs: abadger1999 aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro 18:22:23 Oops, sorry if I jumped the gun. 18:22:36 semver only talks about incrementng versions IIRC. 18:23:03 tadeboro: yes, I only found the increasing requirement, but skipping versions also satisfies that one 18:23:18 And I interpret increment as i++ 18:23:32 i++ is weird with float numbers :p 18:23:52 dmsimard: strings with two '.' are not floats ;) 18:24:05 imaginary floats 18:24:07 I suppose, until YAML thinks it's a float 18:24:19 tadeboro: you can also increment by two 18:24:29 dmsimard: if you stick to the semver version format, it will never do that 18:24:45 that only happens with X.Y style versions 18:24:51 interesting 18:25:28 anyway, +1 to abadger1999's, even though I think that netapp actually satisfies semver now 18:25:37 *vote 18:25:39 +1 18:25:42 +1 18:25:44 +1 18:25:44 +1 18:25:45 +1 18:25:47 +1 18:25:53 * dmsimard already voted 18:26:00 true :) 18:26:07 +1 18:26:08 heh vote early vote often 18:26:54 :) 18:27:00 +1 18:27:11 My search-foo is failing me right now. I canot find a definitive answer about incrementing more that one. And most of the stuff actually talks about bumping things ... ;) 18:27:43 #agreed We still require semver. netapp's versioning is considered compatible enough that we accept it as semver for our purposes. 18:28:10 tadeboro: I cannot find anything either 18:29:21 NetApp is following the "spirit of SemVer", though not the "letter of SemVer", I'm OK with that. And I think it's right that any thing (like NetApp) that doesn't fully match should be reviewed here 18:30:19 cyb-clock chimes: 30 min past the hour, and 20 min on topic of allowing non-semver collections 18:30:26 gundalow: I'm still not convinced that they don't follow the "letter of SemVer". do you have more information on this (I assume you also mean the increases)? 18:31:58 (but I guess that's something we should discuss after the meeting...) 18:32:04 #topic Remove Python 2.6 requirement 18:32:04 #info Discussion: https://github.com/ansible-community/community-topics/issues/6 18:32:07 #info Proposal: https://github.com/ansible-collections/overview/pull/165 18:32:07 https://github.com/ansible-collections/overview/pull/165 | open, created 2021-04-07T16:50:26Z by abadger: RHEL6 went EOL on November 30, 2020. 18:32:13 I will write our conclusion and observations into the ticket. We can determine what exactly semver is later. 18:32:18 tadeboro: thanks! 18:32:30 tadeboro++ 18:32:30 jillr: Karma for tadeboro changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:32:39 abadger1999: do you want to say something about this one? 18:33:29 There's been some discussion in the issue ticket. 18:34:27 I can be on board with the ideas that felixfontein proposed. 18:35:31 felixfontein: (lag) yes I meant the increases. I'd seem some mention that numbers should only be incremented by one. Though I've not read this in the spec 18:36:06 I don't use Python 2.6, and I'll try to support it in the collections I'm working on as long as ansible-core supports it (in ansible-test), so in the end I'll be happy with everything we decide 18:36:07 So if people here agree, I'll change the guidelines PR to emphasize that python-2.6 is only there to support a distro which isn't even fully supported anymore (RHEL6's python no longer receives fixes for most CVEs, for instance). 18:36:15 samccann: I think we also need something in the ansible pakcage docs 18:36:39 IIRC cyberpear was more interested in Python 2.6 18:37:01 * cyberpear arrives late 18:37:02 samccann: Something to tell end users that despite ansible-core supporting python-2.6, many of the collections that make up ansible do not support python-2.6 18:38:00 yeah sounds like a good idea abadger1999 18:38:01 #chair cyberpear 18:38:01 Current chairs: abadger1999 aminvakil andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro 18:38:31 Cool, I will get together with you after the meeting to try to determine where and then I can propose some content for you to wordsmith. 18:39:07 cyberpear: Doe that sound like an okay way forward to you? 18:39:11 at the very least, I'd want to not purposely break py2.6 w/o a good reason 18:39:17 but it sounds good as you said it 18:39:34 *as abadger1999 said it 18:39:52 cyberpear: I think, even under the current guidelines, individual collections can abandon python-2.6 just because they want to. 18:40:04 sure 18:40:08 Okay :-) 18:40:12 Just making sure :-) 18:40:19 Since sanity tests still run on python 2.6, removing support for python 2.6 is almost as difficult as making sure code works under python 2.6 ;) 18:40:39 Heh. True. 18:40:52 I know we made sure our collections are sanity-clean on 2.6 just to avoid dealing with 100 lines of ignore entries. 18:40:57 insanity tests! 18:41:02 Okay, if there' sno objections, I'll make updates to these PRs for next week. 18:41:13 +1 18:41:24 all of the cloud collections will be dropping py2 support in the next few months, so we'll need to figure out how to make sanity tests work regardless 18:41:55 abadger1999: sounds good to me 18:42:06 jillr: you'll need to add a huge amount of ignore.txt entries :) 18:42:35 jillr: FYI you can run `ansible-test (sanity|integration)` with `--python` to only run on specified versions, not all. Making Galaxy/AH happy is more work. https://github.com/ansible-collections/community.ciscosmb/pull/27/commits/831e5ae48de5ee291e121f9a611f2e006d497126 18:42:44 I was hoping ansible-test config would materialize a bit sooner, but I cannot complain since I did not contribute anything yet. 18:43:39 gundalow: we already have it working for our regular CI, but it sounded like there's 2.6 testing in the package build? 18:44:06 jillr: AH import runs sanity tests with no --python flags. 18:44:25 This is the sole reason we made sure our 2.6 sanity is clean. 18:44:28 gundalow: that way, `ansible-test sanity --docker -v` will fail on the collection 18:44:52 ah, gotcha 18:45:07 the only clean way for 2.9, 2.10 and 2.11 is to add ignore.txt entries 18:45:08 (py2.6 is only important for modules that manage a linux distro that might have py2.6... cloud modules need only work on whatever is supported for the controller, IMO.) 18:45:10 we already have one 3-only collection, I'm not worried about AH. so it sounded like there was something else checking for 2.6, thus I assumed it was the package build 18:45:16 cyb-clock chimes: 45 min into the meeting, and 13 min on topic "Remove Python 2.6 requirement" 18:45:49 dmsimard: do you want to discuss LTS again today? 18:45:54 yes 18:46:05 ok :) then let's do that next 18:46:19 I think about 2.6 we'll wait til next week for abadger1999's update 18:46:22 #topic What are the implications of maintaining and supporting past major releases of the ansible package 18:46:25 #info Discussion: https://github.com/ansible-community/community-topics/issues/1 18:46:28 #info writeup: https://hackmd.io/plQlGzcFRFGLnPXIeg3cwQ 18:46:59 It is not easy to condense everything into a one liner that everyone can vote on so I have put a summary at the bottom which I will paste here for posterity 18:47:20 > There are benefits to a longer maintenance cycle and while we are open to the idea, it is a non-negligible amount of work without even considering the implications of patching collections that do not backport bug and security fixes. 18:47:32 > Maintaining a single major version of the ansible package for six months while providing the ability to install and update collections out-of-band leveraging ansible-core and ansible-galaxy is likely a good middle ground until the need for a longer maintenance cycle is voiced by the wider community. 18:49:13 Does that make sense ? In essence, we are leaving the door opened because we are not against the idea. This packaging and versioning we are using is still relatively young and we can revisit this later if people feel we really need it. 18:50:07 sounds sensible 18:50:45 yeah makes sense. Keep things as is for a few more releases and see how much (if any) demand surfaces for longer maintenance cycles. 18:50:58 the problem with installing manually with ansible-galaxy is that once you installed a collection manually, installing a newer Ansible version does not overwrite that collection anymore 18:51:22 which is probably not what a random user (who didn't read the instructions too carefully) expects 18:51:36 felixfontein: do you think that is fixable ? I'm not familiar enough with these waters 18:51:47 I like leaving the door open but not committing to doing it without someone from the community who wants to work out the problems and drive it forward. 18:52:13 dmsimard: It's not really fixable because it was a design decision at the core leel. (I pretty much agree with the decision too) 18:52:44 abadger1999: because it's two different paths ? i.e /usr/lib/python vs ~/.ansible/ansible_collections 18:52:53 to clarify: it's not that the collection isn't updated, but a collection explicitly installed in any of the user collection paths will mask one installed at the system/PythonLib level 18:53:00 It's similar to how if you have both an rpm install of ansible and a pip install --user ansible, the pip installed one will always take precedence 18:53:08 ah, right 18:53:24 dmsimard: yeah, two different paths. 18:54:15 though, if someone did `pip install --user ansible` but sysadmin installed a system-wide collection, the system-wide would rule 18:54:15 TBH I'm not sure at all how to improve on this situation, except documenting it better (though I guess some people will still not notice) and not recommending to use `ansible-galaxy collection install` for collections included in Ansible (which is not compatible with the open door :) ) 18:54:47 probably can't do much better than warning about this case if we can detect it 18:55:25 we definitely should put in the collection readmes a note about manual updating 18:55:34 cyberpear: Hmm... That depends, right? if the systemwide one was installed into %{python_sitelib}/ansible_collections, then the --user one would rule? 18:55:41 felixfontein: so to make sure I get this right, would uninstalling the ansible package before installing ansible-core and collections works ? 18:55:50 It's not necessarily even something that's warning-worthy- it's an expected and supported scenario 18:55:53 abadger1999: if the system-wide one is in /etc/ansible... 18:56:06 cyberpear: yeah. Just two different use cases. 18:56:20 abadger1999: you're correct in that case, the user wolud override the one included w/ system-wide ansible package, but not system-wide standalone collections 18:56:22 dmsimard: depends what you mean by 'works' :) 18:56:26 roughly analogous to `sudo pip install foo` and `pip install --user foo` 18:57:00 felixfontein: well, I mean you shouldn't run into unexpected precedence issues if the ansible package is gone 18:57:01 The fact that someone has done the latter doesn't generate a warning from the former- it's completely legit 18:57:25 nitzmahone: makes sense 18:57:48 dmsimard: depends on where else they installed things ;) if they have the same collection (with different versions) in the system-wide collections folder and the user collection folder, they have the same problem 18:58:20 sure, but people get confused about that all the time with just python dependencies across different interpreters anyway 18:58:20 right now the only way to find out is to run `ansible-galaxy collection list` and look for collections that show up more than once 18:59:28 * samccann needs to drop for another meeting 18:59:33 #unchair samccann 18:59:33 Current chairs: abadger1999 aminvakil andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal tadeboro 19:00:12 * lmodemal hard stop at 3pm. 19:00:23 as an action item, should we vote ? do we keep the issue opened ? 19:00:26 cyb-clock chimes: 1 HOUR into the meeting, and 14 min on topic "To LTS or not to LTS" 19:00:27 See you all next week! 19:00:34 see you lmodemal 19:00:53 bye lmodemal! 19:01:02 and bye samccann! 19:01:13 :) 19:01:29 I think we should vote for "do nothing now and revisit this topic after a few releases". 19:01:35 Probably (1) Some sort of vote that we're not planning on making an LTS right now. (2) Move your document into the github repo (or community docsite) somewhere. 19:01:36 dmsimard: vote on what exactly? 19:02:12 felixfontein: abadger1999's #1 and tadeboro :) 19:02:19 Also mention the outcome in the bullhorn since we were talking more positively about doing an LTS at contributor summit 19:02:19 This starts at 2 Eastern now? 19:02:39 I'd say punt on LTS until we have a breaking release of ansible-core that leaves some folks out in the cold 19:02:43 apple4ever - yes 19:02:47 apple4ever: it was moved an hour earlier after DST changes to accomodate later hour in EMEA/APAC 19:02:48 #chair apple4ever 19:02:48 Current chairs: abadger1999 aminvakil andersson007_ apple4ever cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal tadeboro 19:03:02 Ah shoot I didn't know. Well I'll update my reminder thanks. 19:03:23 * cyberpear has to jump to another meeting, will keep half an eye here 19:03:34 cyberpear: every 'major' ansible-core release is breaking someone ;) 19:03:53 say, one that drops support for a particular python 19:04:11 apple4ever: if you subscribe to https://github.com/ansible/community/issues/539 you will find out ;) (it's a lot less spammy now as well) 19:04:20 VOTE: No plan for a LTS maintenance release for the Ansible community package for now, anyone from the community can bring the topic up again for discussion at a later release and we can revisit the topic 19:04:28 +1 19:04:32 +1 19:04:35 +1 19:04:35 +1 19:04:37 +1 19:04:42 +1 19:04:43 +1 19:04:43 +1 19:04:50 +1 19:05:21 +1 19:05:45 #agreed No plan for a LTS maintenance release for the Ansible community package for now, anyone from the community can bring the topic up again for discussion at a later release and we can revisit the topic 19:05:59 I will take the action of writing something up in the bullhorn about it 19:06:12 dmsimard: thanks a lot! 19:06:20 #action dmsimard to write a summary of the LTS discussion in the bullhorn 19:06:24 #topic open floor 19:06:36 since we're already at over one hour, let's continue with open floor 19:06:44 does anyone have something that should be discussed today and wasn't covered yet? 19:08:05 Somewhat off topic but I just want to plug that ara 1.5.6 is in release candidate and should be released tomorrow, it's been ~2 months in the making and has a significant UI refresh :) 19:08:16 If you want to check it out, the live demo is up to date: https://demo.recordsansible.org/ 19:08:20 Nothing else from me 19:08:28 * dmsimard is in HTML overdose 19:08:49 dmsimard: looking cool! 19:09:13 dmsimard++ thanks for doing ara! 19:09:14 cyberpear: Karma for dmsimard changed to 4 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:09:32 cyberpear: I'll probably have something about it for the bullhorn, will add it to the issue 19:09:40 er, cybette ^ 19:09:44 :D 19:09:53 too many similar characters for my autocomplete 19:11:13 hehe :) 19:11:21 happens a lot I think ;) 19:11:32 Cool :-) 19:12:19 I guess it's time for closing the meeting then? 19:12:24 +1 19:12:46 #endmeeting