18:03:26 #startmeeting Ansible Community Meeting 18:03:26 Meeting started Wed Jun 8 18:03:26 2022 UTC. 18:03:26 This meeting is logged and archived in a public location. 18:03:26 The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:03:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:03:26 The meeting name has been set to 'ansible_community_meeting' 18:03:26 #topic Agenda https://github.com/ansible/community/issues/645 18:03:26 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping! 18:03:30 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 18:03:33 #topic Updates 18:03:36 sorry for being late :) 18:03:42 o/ 18:03:48 #chair jillr 18:03:48 Current chairs: felixfontein jillr 18:03:54 hey there felixfontein 18:04:00 o/ 18:04:04 hi jill :) 18:04:06 #chair acozine 18:04:06 Current chairs: acozine felixfontein jillr 18:04:12 o/ 18:04:21 .hellomynameis gotmax23 18:04:22 gotmax[m]: gotmax23 'Maxwell G' 18:04:29 0/ 18:04:30 #chair gotmax[m] 18:04:30 Current chairs: acozine felixfontein gotmax[m] jillr 18:04:33 #chair samccann 18:04:33 Current chairs: acozine felixfontein gotmax[m] jillr samccann 18:04:39 let's see who's around today :) 18:04:58 #chair gotmax 18:04:58 Current chairs: acozine felixfontein gotmax gotmax[m] jillr samccann 18:05:19 hey gotmax welcome 18:05:37 * gotmax[m] is half asleep thanks to having a great insomnia filled night 18:05:46 hi all 18:06:01 o/ hope everyone is doing well 18:06:50 ooch. insomnia is no fun 18:06:58 #chair orandon[m] 18:06:58 Current chairs: acozine felixfontein gotmax gotmax[m] jillr orandon[m] samccann 18:07:04 indeed! 18:07:57 o/ 18:08:05 Hi mariolenz! 18:08:18 #info Ansible 6.0.0rc1 has been released. It now contains a `ansible-community` CLI tool which allows to print the Ansible version 18:08:22 #chair mariolenz[m] 18:08:22 Current chairs: acozine felixfontein gotmax gotmax[m] jillr mariolenz[m] orandon[m] samccann 18:10:13 cool! 18:10:38 #chair andersson007_ 18:10:38 Current chairs: acozine andersson007_ felixfontein gotmax gotmax[m] jillr mariolenz[m] orandon[m] samccann 18:12:06 Should we start the removal process for [google.cloud](https://github.com/ansible-community/community-topics/issues/105)? And maybe for `community.google`, too? 18:13:48 o/ 18:13:58 #chair resmo 18:13:58 Current chairs: acozine andersson007_ felixfontein gotmax gotmax[m] jillr mariolenz[m] orandon[m] resmo samccann 18:14:32 mariolenz[m]: that's a good question 18:15:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:16:41 I think moving the content to a community collection (no matter whether community.google or something else) would only work if someone would re-activate the generation code and keep it maintained 18:16:53 felixfontein: Well, toumorokoshi from Google even agrees that they don't maintain it at the moment. 18:17:29 Good reason to remove it, isn't it? 18:17:30 mariolenz[m]: that's why I say "re-activate" :) 18:17:48 so yeah, I don't see any other good solution than removing it for now 18:18:00 well, removal means that it will be removed from Ansible 8.0.0 in ~a year 18:18:50 so basically we'd start with announcing that we plan to remove it in 8.0.0, and give community some time (>= one month) to consider this 18:19:16 feels like enough for new maintainers to come 18:19:20 if someone wants to step up, they'll have some time to get familiar with the problems and try to figure out how to create a working fork, or become a maintainer for community.google 18:19:25 if nobody does, it will be gone in Ansible 8.0.0 18:19:51 agreed, and if someone wants to pick it up after the 8.0 release, they can easily request adding it back into the package 18:20:01 +1 18:20:12 exactly 18:20:34 +1 18:20:38 this thing is "autogenerated", shouldn't this continue to work? https://github.com/GoogleCloudPlatform/magic-modules 18:20:41 just to walk through the timeline from user perspective - come Ansible 7, they start getting deprecation warnings? 18:20:43 #topic Removal of google.cloud and community.google from Ansible 18:20:54 #info Process: https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst#unmaintained-collections 18:20:56 or they see it in the porting guide that it's going away? 18:21:15 samccann: there will be no deprecation warnings, the deprecation will only happen via announcements (Bullhorn and changelog 18:21:47 so step 1 is to announce that we plan to deprecate it in The Bullhorn and in the collections' issue trackers 18:22:05 then wait for >= 1 month, and have a vote in the steering committee whether we consider the collections unmaintained 18:22:07 in a pinned issue 18:22:07 resmo: in theory maybe/probably, but someone would then need to maintain a fork of the generator and patch it as-needed as the APIs evolve 18:22:21 if we vote for them being unmaintained, we'll announce deprecation in the changelog and in The Bullhorn 18:22:38 andersson007_: only for the issue trackers we have control of :) 18:22:58 felixfontein: ah, ok 18:23:13 google.cloud is in https://github.com/ansible-collections/, so the community team should be able to pin that issue 18:23:28 cool 18:23:52 who wants to write the announcements? I'd suggest to first create a gist so we can wordsmith, and when everyone's happy we can post that to the repo and to Bullhorn 18:24:12 felixfontein: is it possible to announce deprecation in the porting guide as well (in this example, Ansible 7 porting guide)? I get the feeling that gets more attention (though I have no stats to back up that feeling so i could be wrong). 18:24:55 samccann: yes, we can do that by editing the changelog.yaml file in ansible-build-data 18:25:12 felixfontein: I can draft an announcement 18:25:16 coolness thanks 18:25:36 samccann: see https://github.com/ansible-community/ansible-build-data/blob/main/6/porting_guide_6.rst#major-changes and https://github.com/ansible-community/ansible-build-data/blob/main/6/changelog.yaml#L60 :) 18:25:49 acozine: that would be great :) 18:26:19 #action acozine draft an announcement for the git repos of google.cloud and community.google and The Bullhorn 18:26:40 👍 18:27:56 cool :) 18:28:09 that'll be the first time we remove something from Ansible without a replacement 18:30:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:49 speaking of replacement ;) 18:31:00 :) 18:31:04 vultr? 18:31:18 I'm still planning review the new vultr collection, maybe I'll manage this week... 18:31:39 I guess it's too late to get into ansible 6? 18:31:53 the current state of the inclusion request is "First review in progress", is that still accurate? 18:31:56 andersson007_: do you know? ^ 18:32:08 resmo: it's too late for Ansible 6.0.0, but not for 6.1.0 or 6.2.0 :) 18:32:26 feature freeze for 6.0.0 was two (?) weeks ago 18:32:29 felixfontein: yep 18:32:41 felixfontein: but you can start 18:33:08 there's only one thing about testing 18:33:30 ah, you mean the question on CI for release commit? 18:33:42 yep 18:33:45 #topic CI requirements for release commit for collections included in Ansible 18:33:58 since nobody else is suggesting a topic, we can talk a bit about it :) 18:34:07 +1 18:34:27 it sounds trivial but in gh workflow this is not as simple as I have expected 18:34:31 so we are currently requiring that CI runs and passes for the commit which releases the collection (i.e. the one tagged, and from which the collection is build) 18:34:32 How are we going to handle collections whose tests already fail? 18:34:39 e.g. fortinet.fortios 18:34:51 They can add the ignore files? 18:35:11 gotmax[m]: they violate the requirements anyway... I think they are in the process of trying to fix at least the sanity tests, but they seem to need more time for it 18:35:38 Yes, they are. There's a LOT of failures. 18:36:04 I think that everyone agrees that sanity tests must pass. if someone disagrees, please speak up now ;) 18:36:14 so the question is more for unit and integration tests 18:36:22 hmm 18:36:44 no the question is more like can we run the sanity tests automated and trigger a release manually 18:37:12 (not trigger a release which triggers the sanity tests, which must pass) 18:37:36 resmo: how does the release process you have in mind works? 18:37:47 felixfontein: I also wanted to discuss longer term maintenance for `ansible` (https://github.com/ansible-community/community-topics/issues/1), but it might be better to punt that to another meeting where I'm more awake. 18:38:09 for the collections I know about, basically you first create the commit, push it, and only once CI passes (or enough of it passes) you tag it and push the tag (which starts the actual release) 18:38:56 felixfontein, I tag the collection which triggers the tests (integration and sanity) and wait for the green dot. then creating a gh release which triggers the galaxy publish workflow 18:38:58 gotmax[m]: we already discussed that topic multiple times I think, did you look at the older discussions (or tried searching for them)? 18:40:13 so "releasing" is just a manual button push only triggers the publishing. The policy was, that this should trigger the tests and then publish, as I understood it 18:41:02 felixfontein: I skimmed the past discussion. I believe it was decided against for now, but still left on the table for future discussion once ansible (the community package) becomes more mature. 18:41:27 *discussions. I think there were two meetings where it was discussed. 18:41:33 resmo: what's the problem with your workflow? (maybe I'm missing something) 18:42:35 anyway integration and unit tests are not mandatory for collections, only sanity tests. Currently the requirements say that all tests (sanity, integration, units) MUST be run when releasing and they must be green, otherwise the release must not be published. i suggest replacing it with `all tests` -> `sanity tests` 18:42:58 gotmax[m]: I think the main problem still is that while we can publish more 5.x.0 releases or 5.10.x releases (or whatever the last minor release will be) for some time, these will likely get no more collection updates (or only for very few collections) since most collections do not provide LTS support for the versions included in Ansible 18:43:25 and even automated releasing is not mandatory, so maintainers can load tarballs manually if they like 18:43:30 gotmax[m]: so only a tiny part of the LTS version would be actually LTS, and most of it would be frozen, even if security bugs show up 18:43:44 draft announcement: https://gist.github.com/acozine/ca91028352e21481521c5022c0114393 18:44:26 andersson007_: I'd still require that full CI runs and mostly passes, I don't see why the release commit should be different from other commits, but I think it's ok if some of the tests fail 18:44:43 felixfontein: Well, if more collections don't get on board, we'd have to reconsider the no patching collections policy. 18:44:54 I believe you maintain separate branches for (at least some) of your collections? 18:45:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:45:18 andersson007_, felixfontein this working says, that the release process must trigger the tests, I would like to change it to first pass the tests and then release "tests MUST pass (sanity) before a release is published 18:45:28 gotmax[m]: reconsidering the 'no patching collections policty' would be a can of worms, especially from a legal point of view 18:46:10 acozine: cool thanks! 18:46:18 acozine: thanks for the draft! i'll take a look tomorrow. i think it makes sense to put the link in the topic 18:46:42 felixfontein: Distributions patch software all the time. Doesn't the GPL have a no warranties clause, anyways? 18:47:10 s/working/wording 18:47:20 acozine: should I comment on it here (once the discussions are over), or in the gist's comment form? 18:47:46 felixfontein: sure, comments on the gist's comment form are good 18:48:11 if there's somehwere better to put it, I'm happy to copy it there, GH is where I was doing something else 18:48:13 felixfontein, andersson007_ if the tests passed 5 days ago and there was no commit, why should we start another test integration test run (which can take > hour in my case) 18:48:27 andersson007_: happy to add a link to the title, but link to what? 18:48:53 > because it is unmaintained. 18:49:00 There should be a comma before the because 18:49:01 gotmax[m]: I'm not a lawyer and I don't plan on becoming one, so I cannot really tell you whether what distributions do is fine or not. 18:49:02 acozine: to the gist 18:49:06 * gotmax[m] enters grammar police mode 18:49:11 add it to the topic 18:49:17 about google 18:49:53 resmo: there usually is a new commit for a release, or how do you add the changelog for example? 18:50:01 ok just hearing that we may have found some new maintainers at google for those collections btw 18:50:07 acozine: `add` -> `to add` 18:50:32 Also, deprecation warning makes it sound like it will be printed by the ansible CLIs which I thought wasn't the case? 18:50:33 Gundalow knows but isn't online right now. We may want to hold off on announcing for another week or so to be sure? 18:50:35 felixfontein, we don't trigger full integration tests for changelogs 18:50:40 hi 18:50:54 hi jtanner 18:50:59 #chair jtanner 18:50:59 Current chairs: acozine andersson007_ felixfontein gotmax gotmax[m] jillr jtanner mariolenz[m] orandon[m] resmo samccann 18:51:29 > but you must [install it from GitHub](https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#installing-a-collection-from-a-git-repository). 18:51:33 ah, andersson007_ gotcha, here it is: https://github.com/ansible-community/community-topics/issues/105#issuecomment-1150274885 18:51:39 It will still be on Galaxy, no? 18:51:45 acozine: thanks! 18:51:54 resmo, in that case CI passes for the release commit, but isn't full CI? 18:52:03 i use my email as a TODO list 18:52:14 felixfontein, yep 18:52:37 felixfontein, sanity but not integration 18:52:38 Maxwell (@gotmax) (He/Him): ah, yes, it will still be on Galaxy, I can change that bit 18:52:42 resmo: do we require that everything that possibly runs in CI is run for the release commit? 18:53:44 I wouldn't add the announcement to https://github.com/ansible-community/community-topics/issues/105 until we discussed it in the gist 18:54:01 felixfontein, it says "Currently the requirements say that all tests (sanity, integration, units) MUST be run when releasing" 18:54:11 "All CI tests MUST pass for the commit that releases the collection." 18:54:23 it's from the requirements 18:55:07 in the checklist: "all CI tests run against a commit that releases the collection; if they don't pass, the collection won't be released" 18:55:10 hmm, if you interpret it this way, "All CI tests MUST run against every pull request and SHOULD pass before merge." is already wrong for quite a few collections 18:55:39 for example community.general and community.aws and amazon.aws do not run every test they have in CI against every PR, but only the ones that apply to the modified files 18:55:59 "felixfontein: Distributions..." <- THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK 18:55:59 AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. [GNU General Public License](https://www.gnu.org/licenses/gpl-3.0.en.html) 18:56:02 (they probably do run for every commit though) 18:56:30 which CI tests on which repo(s)? 18:56:45 mariolenz[m]: please use gist/pastebin and dont paste in this channel 18:56:48 mariolenz[m]: so how is that related to running CI for release commits? 18:57:29 mariolenz: Thanks! FTR, this type of clause is pretty standard across FOSS licenses. 18:57:52 i'd be happy with any clarification for that paragraph about testing and would avoid definitely forcing resmo to remove integration and unit tests to get into the package:) 18:58:48 hehe, I mean, tests ARE green but running them over and over again, doesn't make them GREENER ;) 18:59:01 (oh, pasted definitely to the wrong place..) 18:59:08 they take >35min on each run 18:59:57 Sorry, just wanted to answer the question from Maxwell (@gotmax) (He/Him) about the GPL warranty clause. 19:00:56 so basically we also have to change the part on running tests for PRs 19:01:11 and potentially commits to the main branch as well 19:01:29 because they use the same formulation as the one for releases 19:02:33 as the time is over, i'd suggest continuing the related discussion in the topic 19:02:44 yes. 19:02:50 #topic open floor 19:03:03 let's have a quick open floor. does anyone have something very quick that wasn't discussed yet? 19:03:42 running all tests against PRs is not possible because the gh secrets (api keys for cloud) won't be available for these PRs 19:03:53 also ... cost 19:04:00 Nothing else from me :) 19:04:16 resmo: yes, but the requirements are also asking for that, if you read them that way :) 19:04:29 ansilbe/ansible used to run all tests against all PRs, then travis basically flagged us as DoS 19:04:38 bcoca: lol 19:04:41 yes, I know. 19:04:50 CI is a mess. 19:04:50 ok, I'm ending the meeting, feel free to continue chatting 19:04:52 #endmeeting