18:02:32 #startmeeting Ansible Community Meeting 18:02:32 Meeting started Wed Nov 4 18:02:32 2020 UTC. 18:02:32 This meeting is logged and archived in a public location. 18:02:32 The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:02:32 The meeting name has been set to 'ansible_community_meeting' 18:02:40 the intent with including tests ouput was for galaxy to present the coverage repors in the UI ... but that idea died on the vine 18:02:41 o/ 18:02:48 I wonder if I ever get used that the meeting starts at 19:00 :D 18:02:49 #chair abadger1999 felixfontein tadeboro dericcrago dmsimard 18:02:49 Current chairs: abadger1999 dericcrago dmsimard felixfontein gundalow tadeboro 18:02:51 hi 18:02:55 #chair andersson007_ 18:02:55 Current chairs: abadger1999 andersson007_ dericcrago dmsimard felixfontein gundalow tadeboro 18:03:05 welcome to the community meeting! 18:03:10 o/ 18:03:19 #topic agenda: https://github.com/ansible/community/issues/539#issuecomment-720085949 18:03:23 #chair cybette 18:03:23 Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow tadeboro 18:03:35 * dericcrago waves 18:03:35 * samccann waves 18:03:38 Ola 18:03:43 #chair sagredo 18:03:43 Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow sagredo tadeboro 18:04:03 #chair jtanner 18:04:03 Current chairs: abadger1999 andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner sagredo tadeboro 18:04:06 jtanner: thanks for the info! 18:04:09 * alongchamps waves 18:04:24 Missing from agenda link: discussion about re-scheduling community meeting 18:04:42 hi 18:04:50 dmsimard: true :) 18:04:57 #chair aminvakil alongchamps 18:04:57 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner sagredo tadeboro 18:05:15 gundalow said he's away for the first 5 minutes, so we should discuss it once he's back 18:05:17 #chair samccann 18:05:17 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner sagredo samccann tadeboro 18:05:39 oh, I accidentally chaired sagredo instead of samccann. sorry for that! 18:05:46 #unchair sagredo 18:05:46 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner samccann tadeboro 18:05:58 sagredo: you are of course free to take part in this meeting if you want :) just give a shout 18:06:12 #topic announcements 18:06:20 something about a rule of having less unique first 3 letters in nicks :) 18:06:22 #info Ansible 2.10.2 has been released 18:06:26 heja there... first community meeting for me. how does this work 18:06:31 #chair rockaut 18:06:31 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro 18:07:01 #info The Bullhorn 13 has been sent today https://mailchi.mp/redhat/the-bullhorn-13 18:07:27 rockaut: check what's the current topic, and join in the discussion if you have any comments/questions 18:07:29 I guess that's the main news, at least from my side 18:07:39 rockaut: Basically just discuss along with the rest of us. If you have something specific to talk about which isn't on the agenda, bring it up at open floor. 18:07:58 (y) great 18:08:04 rockaut: also good to take a look at the agenda before the meeting (if you have a chance) https://github.com/ansible/community/issues/539 18:08:11 maybe let's discuss the first topic, and then switch to the meeting time (hopefully g. is around by then) 18:08:15 One day we might have some more formality around voting but we haven't gotten big enough to need that yet. 18:08:30 indeed :) 18:08:37 #topic Should we merge small number of modules/plugins from companies? 18:08:55 #info https://github.com/ansible/community/issues/539#issuecomment-714454605 18:09:07 #info we started discussing it last week: https://meetbot.fedoraproject.org/ansible-community/2020-10-28/ansible_community_meeting.2020-10-28-18.02.html 18:09:29 #info for larger set of new modules/plugins, we ask submitter to create their own collection 18:09:41 the question is, what do we do if there are only 1-2 modules right now, but there might be a lot more later? 18:10:09 if we accept them now, they maybe should be moved later, and moving is always annoying :) 18:10:17 how big if a jump is it to go from one module to a whole collection, in terms of effort? 18:10:33 s/if/of 18:10:40 CI/CD setup is probably the biggest issue. 18:11:00 collections keep it modular, and I like going down the right path the first time, personally 18:11:10 yes. though setting up tests for your modules isn't that much easier, especially when it is about cloud modules or things like that 18:11:16 tadeboro: is that something we can help with? 18:11:32 if they start in community.general, you need to go through deprecations and teach your users about the new FQN they have moved in once you move to a new separate collection 18:11:35 dmsimard: to some regard, yes. depends on how much resources you have for it ;) 18:11:40 But I think this is almost a solved problem because collection template contains almost everything needed to get an initial thing up and running IIRC. 18:12:02 out of a user perspective I would say to start even small one in an own collection. It's anoying if you have to look at versioning for this too. 18:12:05 jtanner: yes, and the c.g maintainers have some hassle for moving, and redirecting later support requests 18:12:06 It would be a whole new thing to learn (you don't need to know about collections at all to write a module for community.general) and you'd have to devote effort to release engineering stuff. 18:12:08 agree with jtanner - it's a bigger user problem when they move out of c.g. 18:12:51 a concrete instance of such a request is https://github.com/ansible-collections/community.general/pull/772, where one inventory plugin for a cloud provider (yandex cloud) is added 18:12:52 https://github.com/ansible-collections/community.general/pull/772, | closed, created 2020-08-13T14:47:00Z by st8f: Yandex.Cloud inventory plugin [affects_2.10,community_review,feature,has_issue,inventory,needs_triage,new_contributor,new_plugin,plugins] 18:13:01 A somewhat related question - do we allow anything new into c.g etc? 18:13:15 by someone working for yandex, that is. if it would be a community contribution, I wouldn't mind accepting it 18:13:21 samccann: we do 18:13:28 but what if then the module doesn't end up in any collection because the one doing it isn't interrested in maintainer role? 18:13:53 rockaut: that's the other side of the story :) 18:14:46 rockaut: Is it fair to place that burden on c.g maintainers? I would say that maintainers have the final say here. 18:14:48 what about the idea of c.g/c.n being 'tech preview' so to speak. As in no implied support even from community, user beware it's a testing ground for new ideas etc? 18:15:16 or if not there, then community.newstuff :-) 18:15:20 samccann: problem is that it already has several other uses, like 'dumping ground' and also 'home of well-supported and much used modules' 18:15:24 before accepting a new module/plugin in c.g, we should make sure that a collection would not be a better fit to avoid incurring the cost of a move in the near future 18:15:33 how can you quantify c.g's "testing" nature vs any other collection? 18:15:34 I've thought about that, though I think you end up with all the bad sides of trying to store metadata (support) in the repo structure, ie ansible-modules-core vs ansible-modules-extra 18:15:59 dmsimard: +1 18:16:25 I don't like the idea of a separate collection for all the things 18:16:37 jtanner: parts of c.g are well-tested, some have unsupported tests, many parts are not tested at all 18:16:48 I like the idea of community.{newstuff|incubator|etc}. 18:17:01 felixfontein: how does an end user know parts are what? 18:17:06 it's essentially a smaller version of ansible/ansible before the purge :) 18:17:08 there's no point to wait while yandex creates a lot of stuff for a separate collection:) Better to have something rather than nothing 18:17:15 jtanner: they don't. 18:17:36 andersson007_: they can release a collection with one plugin right now, there's no need to have a collection with many things in it 18:17:37 hence the idea to segment bits out into separate collections 18:17:39 rockaut: After I learned today that ansible weighs 40 MB, I vote to keep each module in its own collection ;) 18:17:39 is there an equivalent of community.beta already? 18:17:40 rockaut: neither extremes are desirable outcomes but I think it is logical to regroup things that fit together into a collection 18:17:43 It feels like this is a valid (developer) use case but adding the use case to community.general has too many negative repercussions for user expectations. 18:17:54 dericcrago: nothing like that yet 18:18:14 dericcrago: a problem with community.beta is: what happens if things outgrow beta? do we have to move them (and annoy users)? 18:18:16 absolutely on regrouping but just things that belong together 18:18:39 I don't want to blanket band any company from contributing net-new modules to c.general, though that's where I'm leaning 18:18:45 a user might not want orphaned modules just because nobody likes them. 18:18:45 felixfontein: Yes, we do. But to me it's about expectation setting. 18:18:50 moving content sucks bigtime for 2.9 users. it's only a bit annoying for 2.10 users. 18:18:54 users should expect that to happen eventually. 18:19:10 abadger1999: for new content we require tests, so it's getting better :) 18:19:23 (in a community.beta.... but they don't for community.general) 18:19:47 What would be the pros of `community.beta` over `community.general`? 18:20:02 "beta" does imply, "this may not always work" to me, and if it outgrow's beta then it probably needs it's own collection as there is active maintenance / improvements happening? 18:20:02 Question: what if we would find a bunch of people which would agree to MAINTAIN orphaned collections ... that would solve things then? 18:20:23 c.g is included in the ansible package, right ? would an hypothetical beta collection be ? 18:20:24 Maybe with an metadata tag like orphaned 18:20:24 `community.beta` by the name, suggests users be cautions. This is new stuff, will eventually move etc 18:20:48 s/cautions/cautious/ 18:20:54 rockaut: finding (and supporting) mainainers is always a good thing. In particular it helps the PRs and issues been resolved 18:21:09 c.g is included in `ansible` 18:21:12 samccann: i don't think many users will use modules in community.beta then 18:21:33 We are "teaching" our customers to select their collections just like they select libraries for their development projects: see how well maintained the thing is, is it certified, etc. So having things in separate collections makes this easier. But this is maybe less relevant for the Ansible community. 18:21:46 aminvakil - true, but then any new module would suffer from 'does anyone want/need this besides the creator?" 18:21:48 I dont think many users will use community.beta as a whole if it is 100MB then again :D 18:22:00 and if the creator is willing to maintain, they create a collection for their stuffs. 18:22:08 rockaut: if it's "our" collection we'll make sure it won't grow that much ;) 18:22:21 What do programing languages do for this? I'm not aware of a PyPI `beta` package for example 18:22:24 dmsimard: I think yes. But it would need documentation about the expectations. 18:22:46 Is there a Python Package equilevant of community.general? 18:23:07 gundalow: Not that I would know of. 18:23:19 You mean on pypi? No, not at the moment. It's possible to do that (the technology would support that) but core discourages that idea. 18:23:36 and also, it would conflict with the ansible package. 18:24:06 well... another question: are there actually that many such small things incoming so it worth doing that much thoughts? dont you think that most people may just throw them at galaxy as themselfes? 18:24:30 gundalow: pypi recognizes semver and pre-releases (say, 2.10.0rc1) and they can be installed with "pip install --pre" 18:24:34 there are cases where they could work together and also ways in which we could make them play nicer together but no one seems to want to champion that yet. 18:24:53 I think gundalow was thinking more about the nature of the package: does PyPI contains package that is just a bundle of other packages with beta quality stuff. 18:25:19 i dont think pypi does have such 18:25:21 tadeboro: thanks, that was a better way of explaining it 18:25:28 thats what versions are for imo 18:25:30 yes-ish 18:25:56 so like a metapackage ? an "empty" package that just depends on other packages ? 18:26:13 most of the ones I've seen are along the lines of "I have had 20 years in software and built up a collection of unrelated code that I use in every new work project I undertake. Here it is" 18:26:50 I'm happy to accept that one of the reasons companies might not want to setup their own collection is through lack of understanding what they need to do. Improving docs is on the list 18:27:18 But those are still "maintained" by someone in a separate and are not pushed to some giant beta package that holds just about anything. 18:27:31 I wonder if companies would be willing to set up their own collection if they get help for setting it up, and then they have to take care themselves. or whether they except help all the time 18:27:59 both 18:28:25 @dmsimard: strictly speaking, that's not semver but PEP440-compliant versions 18:28:37 ++ 18:29:21 just had a look at https://github.com/ansible-collections what if there is a new tag which marks such collections? 18:29:48 No matter what, we always end up with "who will maintain this from now on" question. 18:30:18 tadeboro: indeed. 18:30:27 you could counter with "why was it accepted in the first place" 18:30:27 tadeboro thats true but from an user perspective it might be "acceptable" 18:30:43 also it might attract newcommers to have a look at it 18:31:07 @gundalow: here's an example of a beta release on PyPI -- https://pypi.org/project/pip/20.3b1/ 18:31:33 felixfontein: after setting the collection up, what issues will be created "maintaining collection wise" not "maintaining modules", so that companies will need help about that? 18:31:57 But newcommers can also have a look at the code in the separate repo. All they need to be able to do id find it. And this is what I currently see as a bigger issue right now. 18:32:00 Stepping back a bit, Collections are a first class citizen. In Galaxy you can search for stuff by company, product or tags (cloud, monitoring, database) 18:32:00 If community.general ends up growing it's going to have 45,000 modules in and no one can find anything 18:32:24 tadeboro: could you please clarify what issue you are referring to? 18:32:41 gundalow: Serching ansible galaxy is not the nicest experience if you are "browsing" for new stuff. 18:32:45 gundalow +1 for that 18:33:01 let's assume that Galaxy searching will improve 18:33:38 aminvakil: I guess they need someone who watches ansible news (bullhorn; https://github.com/ansible-collections/overview/issues/45; ...) and makes sure that their collection still works and tests are working 18:34:20 if you don't want to invest personell for that, your collection's quality will decline over time 18:34:44 it's not a huge investment, but sometimes a lot more than what companies want to invest 18:35:23 again ... if those abandoned modules end up in c.g or so they might even break more there. so splitting them out is better imo. This way they end up aboned but nobody cares 18:35:41 yep, it won't be that huge, but as tadeboro said, it ends up with "who will maintain this from now on" question after a while:) 18:36:02 the historical answer is "nobody" 18:36:44 and the future one is it too? the ansible team then marks them as stale/abandoned and users know 18:36:51 if something is unmaintained in c.g, it will receive minimalist maintenance, like if tests start breaking, they get disabled. 18:37:03 Strawman 1: 18:37:04 1. Companies shouldn't but 2+ modules into c.g. (or where we can see the number of modules growing). 18:37:04 2. We will improve documentation on maintaining/releasing (and https://github.com/ansible-collections/collection_template) to make it easier for people 18:37:04 3. We may look at improving `ansible-galaxy collection init` to pull in some of https://github.com/ansible-collections/collection_template 18:37:04 4. If Companies ask for help we will provide guidance. We will NOT do the work for them 18:37:06 (except if they are trivial to fix, or if someone is bored, etc.) 18:37:50 sounds reasonable. 18:37:54 and it would be a small thing to add a "works with ansible <= 2.12.3" for core maintainers to don't include them somewhere. 18:38:08 so individual modules can get in to c.g. but if it becomes 2 or more, then break them out? seems workable for me 18:38:15 5. Repo should be in their own GitHub org (not gh/ansible-collection) 18:38:16 does 1. include 1 module/plugin where it can be expected there will be more soon? like a first plugin/module for a cloud service? 18:38:25 felixfontein: yup. I think so 18:38:39 Me wearing my maintainer hat, I would try to keep as much stuff out of c.g as possible. In my experience, collecting things together is PITA, but splitting then is even worse. 18:39:01 any opportunity to simplify the transition process from one module in c.g. to a collection? 18:39:17 tadeboro: for me the line is community contributions vs. companies 'donating' modules/plugins for their own stuff 18:39:46 4 and 5 sound good:) 18:39:46 tadeboro: telling community contributors "create your own collection" is very harsh, and should be reserved for extremely specialized stuff that probably will never be used by anyone else 18:39:51 gundalow: strawman proposal makes sense to me, I would add that we should validate when including a first module that a second one (or more) isn't already planned 18:40:12 felixfontein: I was talking about company-sponsored stuff. 18:40:14 I'm not sure I like the line between community and company maintainers..... 18:40:38 Or at least.... most of the arugments about company modules also apply to community modules. 18:40:40 tadeboro: ok. I fully agree w.r.t. that. 18:40:46 how many companies would even consider to dont do their own collection if they are realy wanting it? 18:41:03 I think geerlingguy had once proposed that c.g shouldn't accept any new content. 18:41:08 abadger1999: I think it's more about "I'm a storage vendor and have 15 modules" 18:41:16 advantages of strawman 1 18:41:16 a. Contributor Avoids c.g being even more of a dumping group 18:41:16 b. User: Avoids FQCN changing over time 18:41:16 c. Maintainer: Avoids `runtime.yml` and deprecation hell 18:41:16 d. User: Better searching in Galaxy (search for `monitoring`, find all of those modules 18:41:16 e. Contributor: All the general advantages of having a dedicated collection (ie I'm only interested in these PRs, not all 90 in c.g) 18:41:18 vs an individual contributor 18:41:44 I need to drop off for 10 minutes 18:41:50 I'm almost for geerlinguy's idea as long as there's some support for people who just have one module and want to get it included into ansible. 18:41:51 abadger1999: Well, I maintain a collection for a vendor, and most of the bugs I get are not related to collection at all. Users just happen to find a bug while using ansible. Not sure if this is something a c.g maintainer should deal with. 18:42:33 (thinking outside of the box, that could even be something like a github action that automates the releasse-to-galaxy workflow) 18:42:35 abadger1999 what you mean with included in ansible? 18:42:37 I'm also for severely restricting what goes into c.g/c.n 18:42:52 rockaut: in the ansible tarball. 18:43:06 I like the idea of `c.beta` instead of `c.g` because it doesn't group `c.g` and any movement out of `c.beta` shouldn't be *that* much of a surprise to anyone 18:43:13 tadeboro: such issues go on the stack of open issues that nobody ever looks at, if there are no active maintainers for the module in question ;) 18:43:15 actually I thought that has an ending date as such 18:43:17 s/group/grow/ 18:43:26 dmsimard: That is true.... but is the storage vendor the important difference there or the "here are 15 modules related to this one product" ? 18:44:15 I would say if five community members showed up with a total of 15 modules for a single product, they should also be asked to make a new collection, right? 18:44:20 any grouping from c.g to c.whatever is breaking things for users. even worse they might end to then transition to c.other again 18:44:53 abadger1999: I think so. that usually doesn't happen so quick though, for the first months there are only 1-2 modules, then a third one pops up, then a couple of months later maybe a fourth, etc. 18:45:23 tadeboro: yeah, that's definitely a good point. 18:45:27 rockaut: if they use ansible-base 2.10, it's not that much of a problem :) it's mainly a huge PITA for 2.9 users 18:45:36 It's easier to tell a vendor that they need a collection for their 15 modules than to turn an individual contributor away for his one module 18:46:15 would it be the worst thing in the world to not accept every module submitted? 18:46:31 dmsimard: yeah, it is easier.... but the experience for users and other c.g maintainers is still the same if we let them in, right? 18:46:31 Maybe being the evil then: who cares if they walk away? 18:46:43 or doing their own stuff 18:46:51 jtanner: we're already not accepting every module/plugin :) people have to survive andersson007_ and my reviews for example ;) 18:46:58 heh 18:47:09 If it's worth including 10 other people will pop up sooner or later 18:47:09 severe reviews felixfontein :) 18:47:19 andersson007_: yep, very nit-picky :) 18:47:26 * nitzmahone pictures some kind of secret fraternity ritual 18:47:28 jtanner: I don't think but the exercise is to formalize and put requirements or expectations on writing 18:47:30 (w.r.t. some formalities) 18:48:02 i think there's a certain level of acceptance that is needed. but the questions in my mind revolve around accepting things that are "good" without putting an undue maintenance burden on people who don't care about that niche. 18:49:11 which returns me to... maybe c.g isn't the place for these modules but simply throwing people at galaxy and github and saying, "create your own collection" is probably not sufficient either. 18:49:28 not just a maintenance burden but a packaging one too (re: size) 18:49:39 i don't see why the later is insufficient 18:49:57 galaxy should be the focal point, not our sprawling repos 18:50:12 Replace "throwing" with "showing how" and I think things are OK. 18:50:24 it's a lot more work to create a collection and releasing it, than just creating one plugin/module in an existing collection 18:50:43 +1 18:50:47 it will keep probably a lot of good submissions from happening 18:50:51 true, if the work you've deferred to the rest of the community doesn't count as effort 18:50:58 (way more bad ones too :) ) 18:50:58 felixfontein - would that difficulty be minimized some by having a good collection template to start from? 18:51:00 someone has to take care of getting the bit out the door 18:51:07 People arrive in open source to scratch their own itches. If you make it hard for people to share the results of their itch-scratching to other people then those people will only scratch their own itches without sharing. 18:51:16 samccann: only partially. it's still a lot more work, and it's harder to get help for it 18:51:44 people have been creating and sharing roles on galaxy for years ... i can't see how it's so burdensome to suggest the same for collections 18:51:50 opensource rashes :-) 18:52:09 So, to grow open source, you want to be welcoming and help people go from "I sovled my own problem ." to "I was easily able to let other people use the solution to my problem as well" 18:52:10 people starting with opensource will first doing their own thing anyways. Just then they will try to do more in communities 18:52:11 abadger1999: I see your point, but I still don't like the idea of c.g being some sort of dumping ground, *especially* if it's a case of "but this vendor just wanted one module to make its way into the pip install ansible version, pretty please" 18:52:27 geerlingguy: yes. I'm in agreement with you. 18:52:30 If we are going to make this whole collection experiment work at all, we can't have any "blessed collection" that gets special treatment 18:52:38 ++ 18:52:52 geerlingguy: that's why I'm suggesting (1) the strawman shouldn't be limited to companies. 18:52:54 also if people create their own collection, the risk of them getting abandoned is probably pretty high. and it's much harder to fork collections properly (and convince users to use that fork). 18:52:55 jtanner: what did we say to PRs that we weren't interested in ansible/ansible before ? was there a formal criteria for inclusion ? 18:53:23 dmsimard: the PRs sat and rot until the BU or the community team mangaed to find someone to hit the green button 18:53:32 BU=? 18:53:37 business unit 18:53:40 ah 18:54:08 Thats what I meant with "a bunch of people willing to" 18:54:30 the core team completely divorced themselves of new module PRs because it was just too much expectation 18:54:37 I don't think we cant find 5 people in the community willing to handle such collections 18:54:39 (2 & 3) We should consider whether we want to allow any additions to community.general at all. As part of this, what we can do to make it easier for people to create and publish their work as something other than community.general (either community.beta [still has many of the problems of community.general... just sets user expectations] or something like a incubator.* namespace where we can automate workflow for them) 18:55:56 hmm... what about a whole gh.com/ansible-incubator then? 18:57:00 +1 to adbadger1999 idea 18:57:02 about not accepting anything new for c.g: I think there are several levels: 1) not accepting anything new, 3) not accepting new module/plugin groups, 2) not accepting new modules/plugins for new products/services, 4) accepting as now 18:57:03 you have to immediately build out the rules for which the thing has graduated from "incubating" to "good for use" 18:57:06 rockaut: yeah, that could be part of the second idea. 18:57:06 this way those repos are clearly separated and differentiated from regular ansible-collection repos 18:57:07 heh abadger1999 even 18:57:38 when will a module in community.beta be a candidate to be dropped of ansible tarball then? or move out to its own collection or move to c.g? 18:58:10 felixfontein: Maybe we want to take a poll on each of those three starting with 4? That we narrow down our range of options? 18:58:12 that is an interesting point aminvakil - my nickel would be community.beta etc are NOT in the Ansible tarball at all 18:58:37 as incentive to put it into its own maintained collection 18:58:56 I agree with samccann 18:59:01 or when is a module ready for total deprecation+deletion? 18:59:04 samccann: Eh..... If it's still built for pypi, I'd be okay with that. 18:59:15 I wouldn't include c.beta in ansible as well 18:59:25 nobody will know about new stuff there 18:59:31 felixfontein: ^ 18:59:33 well why should a module be put in community.beta then? i mean what's the point? 18:59:46 users will use ansible galaxy to include them 18:59:56 c.beta will be like a black hole 18:59:58 andersson007_: true, but if we include it, the content should stick to certain standards 19:00:19 You can put it somewhere without having to worry about releasing and setting up CI/CD. 19:00:27 who sets the standard for "this is actually useful to somebody" ? 19:00:28 ^ what tadeboro said 19:00:32 felixfontein: yep, in c.g. we review all stuff 19:00:41 jtanner: +1 19:00:55 +1 19:01:00 samccann: but the idea is that someone has a single module. They want to give it back to the community to improve ansible. they don't have the time to learn about building collections, uploading to galaxy, etc. Right now, distribution on pypi is the only thing that links their contribution into the thing that they wnat to contribute to. 19:01:04 aminvakil - it's like an intermediary step between I wanna share this module / plugin and I want to maintain a collection 19:01:24 (Yeah, I agree with aminvakil saying "what's the point" then) 19:01:53 fwiw I don't know if "beta" would be the right word 19:02:11 felixfontein: +1 to that.... the nomenclature it bothered me too. 19:02:23 if a contribution only has to pass code smell and code quality reviews, without actually being useful to more than 1 person ... c.g. is a "dumping ground" 19:02:33 abadger1999 yeah I'm still debating that issue w/ jtanner's earlier thoughts - do we have to continue to include very module in Ansible (the package)? or Can we leave more and more to what users can find in Galaxy. I don't really know the 'future' of the project in that regard. Do we hope/expect Ansible the package to double in size in 2-3 years? 19:02:34 i'd suggest not making new contributors lifes more difficult 19:03:00 jtanner: we only merge things which look like they would be used by multiple persons :) 19:03:10 `community.toiletwater` 19:03:16 who makes that determination though? 19:03:17 so imo no c.beta needed 19:03:25 samccann: I do not hope, but I do expect..... that's part of gregdek's vision of what the ansible package is. 19:03:33 nitzmahone: I think sivel has the trademark on that ;-) 19:03:40 that was the pivotal core problem .. who knows enough about all the proprietary domains to say if this new module has any use? 19:03:40 I think prior to collections, we had to accept most modules as it was the only way to be a part of Ansible. But now with collections, people can put their stuff on Galaxy, and then Ansible the package could decide - hey that's a very useful/popular collection, maybe we add it to the Ansible package 19:04:26 andersson007_: +1 19:04:26 I always assumed that would be the way 19:04:36 (1 to do not make new contributors lives harder) 19:04:53 I know "we're just going to ship everything on galaxy" has come up before, but yikes for so many reasons 19:05:12 the "sense of belonging" by ending up in the ansible distribution was the ideal that splitting modules out of core was meant to get rid of 19:05:31 (well, one of many reasons) 19:05:46 I don't think that's an impression shared by everyone jtanner. 19:06:54 then i would counter by asking those people opposed to the idea if we should have also shipped roles with the distribution also 19:06:56 i have not thought this through, but can't there be a time limit (e.g. 6 months) for a module to be in community.beta? after that it should either go to its own collection or if it's used by multiple persons as felixfontein says be merged into one of existing collections. 19:07:03 Sense of belonging is important. things that I saw were "where is the maintenance burden being carried" 19:07:55 aminvakil: how do we know whether it's used by multiple persons? just because someone told their 10 friends "please create a GH account and write in this issue that you use this module" doesn't mean it's actually used :) also 6 months is a rather short timeline 19:08:14 there are ways to feel like part of the ansible community besides getting a poorly written module with no chance that anyone wants to use it into ansible 19:10:10 jtanner: +1 and +1 for "sense of belonging" 19:10:17 felixfontein: we're at 10 after the hour. 19:10:23 felixfontein - maybe there's something in galaxy (when it has module docs support) to track how often the new module page gets hits. Not perfect, but an indication of some amount of reference to it. 19:10:29 abadger1999: yep, I noticed too 19:10:32 Do we want to have a poll on your 1-4? 19:10:40 Or move to discussing meeting times? 19:11:13 felixfontein: right, i meant if current maintainers of collections feel that it's useful and can be merged to the current collections, move it it to the collection. 19:11:34 hmm, good question. I'm not sure whether it's already the right moment to start voting on putting quite restrictive measures on c.g 19:12:39 meta-vote: who wants to vote on restrictions on c.g today? +1 for vote on restrictions, -1 for not today 19:12:43 is it an emergency ? otherwise we can write down the proposals and take more time to discuss/decide at next meeting 19:12:49 +1 19:12:51 -1 19:12:52 #chair 19:12:52 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro 19:12:55 -1 19:13:01 -1 19:13:04 -1 19:13:04 +1 to a poll.... I'd like to know the terrain. 19:13:10 dmsimard: I don't think it's an emergency, that's why I would not vote today 19:13:15 -1 19:13:18 -1 19:13:18 -1, seems like more discussion needs to happen 19:13:23 abadger1999: poll = just asking for opinions, but not deciding? 19:13:28 Like, is banning everything new from c.g on the table? Is c.g being open to anyone who can pass review on the table? 19:13:31 Yeah. 19:13:51 I think that we can do. 19:14:06 +1 to what abadger1999 is suggesting - let's get a pulse (nonbinding vote :-) 19:14:19 POLL (won't end up in a decision!): if you'd have to vote now, would you: +1 allow more contributions to c.g (new plugins/modules), -1 diallow that? 19:14:30 +1 19:14:30 -1 19:14:34 +1 19:14:34 -1 19:14:41 -1 19:14:46 +1 19:14:59 -1 19:15:01 -1 19:15:22 +1 19:15:28 right now, we could rephrase: are you paid by ansible? +1 for no, -1 for yes ;) 19:15:30 -1 19:15:45 AAAAHAHAH omgosh felixfontein was wondering the same thing ;-) 19:15:45 -1 19:16:00 -1 to c.g; but +1 to something else that ends up associated with the ansible name (ansible package on pypi or ansible-extra-content or etc) 19:16:03 Heh :-) 19:16:05 I'm leaning towards -1 but I'm not in favor of a blanket ban 19:16:20 contrary to popular believe, the module count does not correlate to popularity or profit 19:16:25 belief* 19:16:29 To me, with my community hat on, that would be a big warning sign that any form of strict -1 is a bad idea :-) 19:16:36 please remember this is not about limiting new content to less things, like only allowing new modules for groups that already live in c.g, this is about denying ALL NEW plugins/modules 19:17:06 felixfontein: right, I'm -1 on "hard no to everything" but I'm also not +1 on "let's accept everything" 19:17:10 felixfontein: it seems that we're going to get bored w/o new stuff in c.g....:( 19:17:21 heh 19:17:25 andersson007_: I somehow doubt that, but it will definitely be less interesting ;) 19:17:39 felixfontein: definitely 19:17:52 I am for -2: move everything from c.g into smaller collections ;) 19:18:09 hmm. maybe we have to re-phrase the poll? with three options, one for absolutely no new content, one for much less new content, and one for continue like now 19:18:18 I think -1 on anything at all new in c.g, BIG +1 on "making a process for adding other collections to the Ansible "community distribution thingie that's not called ACD" 19:18:27 felixfontein: yeah, and pick all that you are okay with 19:18:35 felixfontein: could you please define much less new content? 19:18:48 otherwise I'm a big +1 for just undoing all the collections stuff and putting everything back into ansible core, or doing the ansible-modules-extra split again, because that's what c.g will be (IMHO) 19:19:17 geerlingguy: you want to go back to git submodules ? :) 19:19:24 because "much less" can't be quantified or really measured, it'll end up being who knows which elbows to rub 19:19:30 aminvakil: hard to say, there's isn't that much new content right now. one could for example say "no new modules/plugins for areas not yet covered", like a new github module is ok, but a new module for random_new_source_control_system is not 19:19:38 No, I'm saying if we're going to go to collections, then what's the point of having one super special blessed collection that gets more love and attention 19:20:00 why would I consider building a module and putting it in my own collection at all if I know the fast/easy path to getting it into Ansible is to try to squish it into c.g 19:20:20 geerlingguy: right now it's neither fast nor easy ;) 19:20:25 jtanner's point, exactly 19:20:31 and that you can abandon it afterwards and left someone else deal with it 19:20:40 the people who get their modules in will be partners, or people who know felixfontein, gundalow, abadger1999, me, etc. 19:20:44 (in general. sometimes people come up with well-polished stuff) 19:21:15 (yep) 19:21:20 hmm. I think we need a lot more discussion :) 19:21:25 and we will end up right back where we were last year, 3,000 open PRs that have modules that are half-polished but the few community maintainers will not be able to devote time to shepherding them 19:21:30 felixfontein: and more options 19:21:40 whether that takes a few months or a few years is debatable 19:21:56 knowing who can or being able to get a module into the distribution is political capital. it can be abused, will be abused and has been abused 19:21:58 so let's stop it for today. maybe create some concrete proposals of restrictions and paste them in https://github.com/ansible/community/issues/539, so we can discuss them next time? 19:21:59 But my key is: if we end up going that route, I know a lot of people who will see this as "ansible-modules-extra" split 2.0 and walk 19:23:13 #topic possibly change community meeting time 19:23:14 #chair 19:23:14 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro 19:23:32 I think for gundalow and me it would be helpful if the meeting is one hour later 19:23:43 no idea how that affects everyone else. some already stated they are not affected. 19:23:54 I'm okay with later, as current time is always in middle of lunch 19:23:54 felixfontein: right now it's at 18:00 UTC, isn't that actually more on the later side on things ? would earlier work too ? 19:23:56 now that we have so many people around, what are your opinions? or some completely different time? 19:24:00 As it's my first: idc 19:24:05 fine with later 19:24:28 I'm ok with later 19:25:06 19:00 UTC works for me too. 19:25:07 dmsimard: earlier isn't that great for me, it will just shift the problem to summer ;) 19:25:08 This is in the middle of my day so I have broad flexibility. 19:25:20 andersson007_: I think for you it could be worse 19:25:30 yeah it gets late in emea/apac 19:25:31 (I think you're one timezone further?) 19:25:39 felixfontein: yep:) 19:25:58 andersson007_: yep for timezone, or yep for worse? :) 19:26:13 felixfontein: for both:) 19:26:26 andersson007_: would earlier work better for you? 19:26:37 like two hours earlier? 19:26:42 felixfontein: no;) 19:26:47 (one hour earlier means the same problems we currently have in winter time will happen in summer time) 19:26:53 andersson007_: ok :D 19:27:36 so is one hour later worse for anyone than the current time? 19:27:44 please speak up now :) 19:27:50 #chair 19:27:50 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro 19:28:00 (gwmngilfen isn't on the list) 19:28:02 1 hour later wfm 19:28:20 We can also change when DST rolls around every time. 19:28:20 aminvakil? 19:28:20 1 hour later is better than earlier for me 19:28:34 1 hour later is better for me too 19:28:43 1 hour either direction wfm. 19:29:01 ok. should we try one hour later? and maybe reconsider for the next time change? 19:29:06 ok for me 19:29:07 back 19:29:16 gundalow: we're talking about meeting times now :) 19:29:25 sorry, I mean I'm back 19:29:33 :D 19:29:36 current proposal is one hour later, and look again when time is changed next time 19:29:41 +1 19:29:53 so far nobody said it's worse for them 19:30:15 I guess if nobody speaks up in the next few minutes, we'll meet at 19:00 UTC from next week on. 19:30:35 one hour later would be the same time as the molecule wg (I think) - just an fyi (if I'm right) :) 19:30:57 is the molecule wg meeting right now? 19:31:03 (because it's 1.5 hours later :) ) 19:31:11 dericcrago: ah, I think that's dead, remind me tomorrow and I'll show you how to remove it 19:31:14 the public project meeting on Tuesday is also at 19:00 UTC 19:31:26 yup, Molecule meeting hasn't happened in 2020 19:31:44 ok, then let's steal their time ;) 19:31:58 #agreed community meeting will start at **19:00 UTC** from next week on 19:32:00 (May 2019 was the last molecule meeting) 19:32:09 #topic open floor 19:32:14 does anyone have something for the open floor? 19:32:18 thanks, sorry for any confusion :) 19:32:24 (not to be confused with the open trapdoor in the floor) 19:32:32 dericcrago: nah, you are right to mention it 19:32:38 Just an FYI on plugin_utils 19:32:52 We'll discuss internally within the next week 19:32:58 oh right, I could have mentioned the proposal in announcements 19:33:14 nitzmahone: sounds good! 19:33:27 for anyone who wants to know what's this about: https://github.com/ansible/proposals/issues/186 19:33:35 #info https://github.com/ansible/proposals/issues/186 will be discussed by core team internally next week 19:33:36 IMO the ability to move beyond module minimum Python version sanity tips it to "we should do some form of that" for me. 19:34:04 (will be more important in 2.11+ as those drift apart more severely) 19:34:24 That's all from me 19:34:31 does anyone else have something? 19:35:33 dericcrago: you want to say hello 19:35:44 hello dericcrago :) 19:35:53 ah yeah, woot! 19:35:55 Hi everyone! :) 19:36:09 it's good to have you around! 19:36:23 I'm excited to be here 19:36:33 Happy to announce that dericcrago has joined my team (along side abadger1999) 19:36:49 Welcome :) 19:36:55 I can say hello next week :P 19:37:27 nice 19:38:01 dmsimard: :) 19:38:14 #chair 19:38:14 Current chairs: abadger1999 alongchamps aminvakil andersson007_ cybette dericcrago dmsimard felixfontein gundalow jtanner rockaut samccann tadeboro 19:38:20 Anyone got any thing else? 19:38:41 nightlies? 19:39:28 webknjaz: ah, yes 19:40:12 #topic Nightly builds of `ansible` 19:40:14 #info https://github.com/ansible-community/antsibull/pull/195 19:40:14 https://github.com/ansible-community/antsibull/pull/195 | open, created 2020-09-30T18:02:11Z by webknjaz: Add a workflow building nightlies 19:40:16 abadger1999: felixfontein 19:40:18 I think we found out last time (or inbetween meetings?) that some people would appreciate nightlies 19:40:40 yup, can't remember who, though yes 19:41:09 Someone with a CI problem (testing against ansible-base devel) 19:41:15 zbr maybe? 19:41:26 Is the remaining question: `The major question I have is where should the nightly artifacts live` 19:41:26 Yeah, people keep saying that they'd like it, others want a formal decision + a clear decision on where to host them 19:41:39 is this `ansible-base` nightlies? 19:42:01 I think nightlies are okay. Where do they need to live? And does the core team need to sign off on it? (Since it could potentially include both ansible and ansible-base) 19:42:16 samccann: definitely ansible-base. I think ansible as well. 19:42:19 @abadger1999: not only zbr, me too. I originally wanted them for the lint CI 19:42:22 Err reverse those. 19:42:33 definitely ansible and I think ansible-base as well. 19:42:54 Not sure what you mean by "include ansible-base"? 19:43:03 @samccann: it's both acd+base in my PR 19:43:28 I assume a nightly would be no different than the current thing that just has a ref to whatever core artifact version is being targeted 19:43:52 was it tadeboro who was also interested in nightlies? 19:44:01 or geerlingguy? 19:44:08 what would be an an ansible nightly that's different than the current release? 19:44:10 @nitzmahone: https://webknjaz.github.io/ansinight/ 19:44:17 They probably all are :-) 19:44:40 samccann: it includes the ansible-base devel version, and the latest collection releases 19:44:43 so it's more fresh 19:44:44 webknjaz: so how would I install from there with pip ? 19:44:58 samccann: It would look a lot like the current release but be built once a day. so ansible-base from the head of the devel branch and ansible using whatever the latest collections on galaxy were. 19:45:08 samccann: right now you cannot install ansible with ansible-base from devel 19:45:21 I think the ansible nightly would be a preview of what the next major ansible package would contain 19:45:31 @samccann: nightlies are the same as releases except they are updated every day and contain fresh Git devel 19:45:34 (ie, it would look like 2.11.0, not like 2.10.3) 19:45:42 I am interested, but now that most of the stuff I care about can work with ansible-base, this is less urgent. 19:46:02 ansible-lint can't, unfortunately 19:46:49 Ok so the Ansible part of that - it would get the latest patch release from Galaxy per collection? or the latest collection even if it's a major change? (2.x vs 1.x in Ansible 2.10?) 19:46:50 It seems like an ACD nightly should test against the released `ansible-base` artifact it's currently slated to ship with 19:47:12 samccann: I think latest collection, even if it is a new major release 19:47:42 dmsimard: something like `pip install --upgrade --extra-index-url https://webknjaz.github.io/antsibull/ ansible` (I didn't look up the cli arg so it's probably a little off) 19:47:44 but apparently different people have different ideas :) 19:47:48 Here's what's generated for that PR as it is now: https://webknjaz.github.io/antsibull/ 19:49:01 samccann: I think that it makes the most sense to get the latest collection even if it's a major change but I'm not a consumer of this so maybe webknjaz, tadeboro, zbr, geerlingguy, etc would be better to have the final word on that. 19:49:13 felixfontein: my worry - if the nightly has say 2.x for a collection, but the next Ansible release is still 1.x (I lost track of what would be in Ansible 2.11 and if it would allow breaking changes etc) 19:49:41 samccann: yeah, 2.11 allows breaking changes. 19:49:41 what I don't want is that a nightly has the absolute most recent collections, but for some reason the next Ansible release isn't allowed to go that far into the future. 19:49:58 ah ok... so there's no way my fears could come true then ;-) 19:50:11 If you limit all the deps to publicly released stuff *other* than ACD itself, it also makes the install much simpler, since you can just directly point at the artifact and let everything else come from prod PyPI 19:50:23 Yeah as long as that wouldn't happen nightlies could be helpful in some situations. 19:50:26 webknjaz: ^ Okay, so one thing that falls out of samccann's requirement would be that during the pre-release freeze period, nightlies would have to be built differently. 19:50:40 But I wasn't the one who requested them :) 19:50:59 sorry i'm out for today - long day here. gn8 19:51:22 webknjaz: since we'd start encoding compatibility guarantees at that point but 2.11 wouldn't have been released yet. 19:51:23 samccann: ansible's devel branch also has things that the next ansible-base 2.10.x release won't have 19:51:34 rockaut: Good night! And no need to apologize :-) 19:51:53 samccann: the problem is that everyone has different expectations from what exactly nightlies are :) 19:51:58 good night rockaut! 19:52:09 ;-) Austrian friendliness 19:52:41 good night rockaut 19:53:02 @abadger1999: so acd may need to become more permissive later but right now it's probably not a blocker 19:53:10 So the one use case I know of, does require targetting ansible-base devel. 19:53:41 What do you mean? 19:53:46 Coupled with felixfontein's point, that would mean targetting latest collections might also be okay. 19:53:57 Ah 19:54:31 for me the main use-case would be to be able to install ansible-base devel next to something which would make ansible-lint's requirements happy 19:54:47 FWIW in my mind "nightly" always means bleeding edge, sometimes broken, the latest no matter what 19:54:47 if I install the released ansible, it will uninstall ansible-base devel and install ansible-base 2.10.x instead 19:54:49 webknjaz: someone (I think zbr, in CI) wanted to be able to run ansible-base from devel + the ansible package. A nightly which requires the last stable release of ansible-base would not allow that. 19:55:26 Okay cool, so felixfontein has the same use case needs. 19:55:38 and it sounds like webknjaz, you have the same desire also. 19:55:46 Yep 19:56:19 So where do we publish the index? 19:57:03 samccann: So it seems like the need that people have right now, is counter to having the nightly be strictly "the next major version". around the time ansible-2.11.0alpha1 comes out, the nightly will track something more bleeding edge. 19:57:34 ah gotcha 19:57:45 samccann: is that okay? 19:57:47 I think so long as we make that clear 19:57:53 Cool. 19:58:10 like 'this is not a pre-alpha - this is cutting edge... expect to bleed' :-) 19:58:38 would be nice if it could even contain the latest git version of collections :) 19:58:39 gundalow? nitzmahone? Ideas about where to host this? You can see what would be generated from webknjaz's link. ( https://webknjaz.github.io/antsibull/ ) 19:59:01 that would make it easier for users to test merged changes before a release, with the collection having to do prereleases 19:59:16 (I'm thinking of c.g where a lot of things happen) 19:59:20 abadger1999: any reason not to use https://releases.ansible.com/? 19:59:22 felixfontein: hehe :-) That's going to be more work and higher chance of problems :-) antsibull-build can't deal with that yet. 19:59:39 Yeah, I'd suggest "anywhere but" :I 19:59:42 abadger1999: I know, it's more like a future enhancement ;) 20:00:06 Do we need to keep the old versions around, or could we just keep the last (say) 14? 20:00:11 @gundalow: I'd prefer GitHub Pages for it to be easy to deploy, unless we can point this domain there 20:00:15 gundalow: I don't think we'd have permissions to push there from a github action. I don't know that using that would match up with thaumos's push to make releases.a.c a source for supported content only. 20:00:27 webknjaz: are there traffic limits for GH pages? 20:00:33 ah, didn't know https://releases.ansible.com was going to be for supported stuff 20:00:53 Does this really make sense to publish as an artifact vs just "here's a script/container/whatever" that can grab whatever set of stuff you want? Seems like there's a lot of disagreement on what people want from it, so rather than trying to publish all the permutations as nightlies... 20:01:01 Published GitHub Pages sites may be no larger than 1 GB. 20:01:01 GitHub Pages sites have a soft bandwidth limit of 100GB per month. 20:01:02 GitHub Pages sites have a soft limit of 10 builds per hour. 20:01:41 @gundalow I think it keeps the last version only now but we could arrange something to facilitate more versions (although, it's probably useless) 20:02:08 I'm OK with latest only, I hadn't looked at the PR 20:02:34 nitzmahone: for me, having an empty dummy `ansible` package which just tells pip that `ansible` is installed would already be enough, it doesn't have to actually install anything :) 20:02:37 do people tend to use older nightlies in other projects? 20:02:45 @felixfontein: I don't think there's traffic limits but maybe there's a general repo size limit 20:02:56 How about GitHub pages for a single build. If we hit traffic limits we can look at moving it elsewhere 20:03:23 #info GitHub pages usage limits https://docs.github.com/en/free-pro-team@latest/github/working-with-github-pages/about-github-pages#usage-limits 20:03:41 I think just having the current nightly there (and no older one) would be fine as well 20:04:02 at most a couple of latest ones 20:04:19 so that people can switch between them to check when exactly something started breaking 20:04:22 @samccann: no, that's not the point of nightlies as I see it 20:05:23 PROPOSAL: Nightly build (only one copy) stored on GitHub pages 20:05:56 Sounds like folks are okay with the PR as it is, except it needs to migrate to a different repo or aquire some other domain? 20:06:15 * nitzmahone would suggest avoiding a custom domain 20:06:34 @gundalow: yep, that's my original intent 20:07:00 gundalow: I'd be both surprised and a little worried if we did hit the traffic limit on nightlies :-) 20:07:01 webknjaz: cool 20:07:20 How many people are using this? Should we be pushing them to use something else instead? 20:07:23 ;-) 20:07:23 @abadger1999: agreed 20:07:23 abadger1999: hehe, maybe 20:07:52 So should this be in a standalone repo under gh/ansible-community? 20:08:51 ok, we're more than one hour over. 20:08:55 we should really stop :) 20:08:56 gundalow: that would be fine with me... I just don't know what it should be. (Toshio: "naming things are hard. Ask gundalow to decide!" ;-) 20:09:14 Since almost nobody is using it, it's not time to care about limits + I don't really care about the URL either, it's just easier to have a self-contained/self-updating thing with just GH pages+actions 20:09:34 gh/ansible-collections/nightly-releases 20:10:01 does github have limitations if that thing ends up taking a lot of traffic ? 20:10:04 Unless anyone has a better suggestion 20:10:12 dmsimard: they will email me 20:10:13 (CI downloads things a lot) 20:10:36 as long as they don't shut down the whole of gh/ansible-collections because of it, I'm fine with putting it under there 20:10:39 If that's a problem, future gundalow will deal with it 20:10:53 gundalow: might I suggest ansible-community/nightly-builds rather than releases ? 20:10:56 nop they will email saying "erm, maybe you want a real CDN" 20:11:02 dmsimard: good suggestion 20:11:07 5 20:11:08 4 20:11:09 3 20:11:17 So the repo naming scheme is ansible-community.github.io/nightly-releases, sounds good to me 20:11:18 +1 for nightly-builds 20:11:31 I'll set that repo up now and give webknjaz admin 20:12:02 Excellent. Thanks :-) 20:12:04 ok. thanks everyone for this extra-long meeting! 20:12:09 #endmeeting