10:50:33 <gundalow> #startmeeting Ansible Contributor Summit 2020
10:50:33 <zodbot> Meeting started Sun Mar 29 10:50:33 2020 UTC.
10:50:33 <zodbot> This meeting is logged and archived in a public location.
10:50:33 <zodbot> The chair is gundalow. Information about MeetBot at
10:50:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
10:50:33 <zodbot> The meeting name has been set to 'ansible_contributor_summit_2020'
10:50:42 <gundalow> #chair cybette gwmngilfen phips rbergeron gregdek
10:50:42 <zodbot> Current chairs: cybette gregdek gundalow gwmngilfen phips rbergeron
10:52:12 <cybette> #link Join via Bluejeans
10:56:58 <dmellado> morning all
10:57:08 <felixfontein> morning!
10:57:34 * jhawkesworth lurking/making lunch but trying to lend half an ear to things
10:58:21 <resmo> o/
10:58:27 <sshnaidm|off> o/
10:59:39 <resmo> just a little tip for the ones in the video conf, space bar enables microphone, kind of push to talk. very handy ;)
11:00:17 <madonius> is it toggling it or is it PTT-Like
11:00:19 <gregdek> I have been using Bluejeans for, like, 5 years now, and I never knew that.
11:00:33 <resmo> push to talk style
11:02:56 <dmellado> I'm a bit concerned about bluejeans, though
11:03:03 <dmellado> been behaving odd for a couple of days
11:03:06 * dmellado crosses fingers
11:03:30 <zodbot> gregdek: Error: Can't start another meeting, one is in progress.
11:03:36 <gregdek> LOL, ok!
11:04:31 <dmellado> :D
11:05:09 <felixfontein> congrats :D
11:06:16 <gundalow> #topic Welcome and intros
11:07:31 * gundalow #info To
11:07:55 <gundalow> #info Welcome to the 8th Ansible Contributors Summit
11:08:11 <cybette> if you are not on bluejeans or prefer not to speak, feel free to do a short intro here and I can relay it to bluejeans
11:08:44 <gundalow> #info We know the world has become a bit crazy recently, we really appreciate you taking the time to join us today, which is a real testament to the Ansible Community
11:09:58 <gundalow> #info We are now going round the virtual room doing introductions and 1) saying who we are Real & GitHub/IRC names 2) What our interest in Ansible is 3) What we'd like to get from today
11:11:38 <jpmens> when I click on 'speaker view' in bj I see gregdek eating; is that the way it's supposed to work? ;-)
11:11:57 <gregdek> I guess so!
11:12:13 <shaps> yeah, that's all this is about :D
11:12:19 <gundalow> jpmens: it's a laptop warmer :(
11:12:25 <gundalow> Also hello, glad you could make it :)
11:12:25 <dmellado> lol xD
11:12:34 <madonius> there are worse things :D
11:12:52 <felixfontein> greg 2 :)
11:13:53 <gwmngilfen> it's only confusing for everyone *except* me & gregdek  :P
11:18:10 <felixfontein> hehe :)
11:27:44 <jpmens> brits who try pronouncing foreign names; LoL ;-D
11:28:06 <gundalow> jpmens: well, I can't tab complete. It's reaaally difficult
11:28:11 <nitzmahone> Hey, could be worse, could be Americans pronouncing foreign names ;)
11:28:41 <jpmens> you have a point, but I think it's six of one and half a dozen of the other ;)
11:28:57 <gundalow> yup :)
11:29:31 <jpmens> gundalow: that's an idea for #getrichfast
11:31:19 <felixfontein> collections, yay! \o/
11:31:32 <nitzmahone> what's that? ;)
11:31:44 <cybette> #link Contributor summit attendance + info for swag:
11:31:49 <felixfontein> something which keeps us working for quite some time :D
11:33:23 <jimi|ansible> does jpmens win for having first kid/family member wander into frame to ask a question? :)
11:33:27 <nitzmahone> aka "job security" (or "this was such a tire fire you'll be fired at the end", not sure yet) ;)
11:33:47 <jpmens> ah, damn; I asked for a coffee
11:34:05 <nitzmahone> (or sometimes illogical)
11:34:32 <dmellado> jpmens: heh, I had the kid around (but I disabled the camera)
11:34:50 <dmellado> WFH it's proven challenging on COVID19 times
11:34:56 <gregdek> Yup.
11:34:59 <shaps> indeed
11:35:10 <madonius> yep
11:35:22 <gregdek> #topic Collection Overview
11:35:31 <jimi|ansible> I'm going on 7 years of WFH, my kiddos have jumped into many conference calls :)
11:35:42 <nitzmahone> fun to see them growing up :)
11:36:05 <felixfontein> hehe :)
11:36:40 <gregdek> #info Ansible was a single repo, but Ansible module growth has made a single repo less sustainable over time
11:37:17 <gundalow> #info Collections What/why/how overview
11:37:32 <zbr> decoupling (aka isolation) as each part can move at its own speed
11:37:56 <gundalow> #info Collections user guide:
11:38:09 <gundalow> #info Collections development guide:
11:38:37 <gregdek> #info collections allow developers to move at their own speed, but users just want a simple way to consume content without worrying about collection release cycles
11:40:10 <gregdek> #info with collections, there is no longer a single global namespace for modules, now each collection has its own namespace
11:41:06 <gundalow> #info Fully Qualified Collection Name (FQCN) = The full definition of a module, plugin, or role hosted within a collection, in the form namespace.collection.content_name. For example ``
11:41:32 <gundalow> #info See for a full list of Collection Terminology
11:44:41 <gundalow> #info `ansible/ansible:devel` is now `ansible-base` (ie without most modules)
11:47:06 <gregdek> #info With collections, we will introduce the idea of "execution environments", which are container-based virtual environments using ansible-base + ansible-runner + particular collection requirements, and that's what awx/tower will use to run content in the future
11:47:27 <gregdek> #info Execution environments allow for different environments for different users/use cases
11:47:51 <gundalow> #info Docs on the existing Ansible Tower and collections (not including "execution Environments")
11:49:04 <gundalow> #info q: with having namespaces, module names might not be unique different collection might have the same name. In a play we could define all namespaces, what would haben if you add 2 namespaces with a module named identically?
11:50:05 <jimi|ansible> it was originally intended to allow users to easily override core functionality
11:50:22 <jimi|ansible> ie. you don't like what our file module does you can easily drop one in to do what you want
11:50:30 <gundalow> #info module and plugins operate a first found. You can always use the FQCN (Fully Qualified Collection Name) ie rather than just using `ping` you could use `` or ``
11:50:31 <jpmens> 'easily'
11:50:31 <jimi|ansible> but yes it became very confusing
11:50:35 <gundalow> (^ made up example)
11:50:42 <jimi|ansible> jpmens: for some value of easy :)
11:51:26 <jimi|ansible> I don't think many people wanted to override the ec2 module for instance
11:52:50 <gundalow> Adding questions here:
11:53:34 <gundalow> #topic Molecule
11:54:39 <gundalow> #info zbr (The Molecule Maintainer) is doing a short presentation on Molecule
11:54:40 * jtanner wakes up
11:54:47 <gundalow> jtanner: mornin'
11:54:51 <jtanner> morning
11:54:56 <gregdek> #link
11:54:57 <webknjaz> @jtanner: morning
11:55:22 <gundalow> #info Molecule project is designed to aid in the development and testing of Ansible roles. Molecule provides support for testing with multiple instances, operating systems and distributions, virtualization providers, test frameworks and testing scenarios.
11:55:34 <gundalow> #info Molecule documentation
11:56:22 <gundalow> #info Slides which zbr is going through
11:56:41 <gundalow> #info If you are interested in Molecule feel free to join #ansible-molecule on IRC
11:58:56 <gundalow> #info Molecule has many drivers they can be found at
11:59:22 <gundalow> #info We are looking for people to help with Molecule, and especially the drivers (above URL)
12:02:51 <gundalow> Any questions on Molecule?
12:09:34 <mohitmkspy> how can we use ansible vars or env vars in molecule.yml ?
12:09:45 <TKersten> I have been working with Molecule and I found the complete environment a bit fragile. If not all versions matched it broke. Is there any improvement on that?
12:10:46 <madonius> I was about to mention your question TKersten
12:11:07 <mohitmkspy> for ex molecule version 2 and mol 3 is diff
12:11:14 <mohitmkspy> so lots of breaking changes
12:12:27 <shaps> zbr: What is the policy of adding new drivers from outside of molecule repo for example? If I wrote some cloud driver "foo". It's worth to have documentation about it <- From Sagi in chat
12:12:37 <TKersten> OK, Thanks. I'll surely look into version 3 in the very near future
12:12:58 <sshnaidm> Q: What is the policy of adding and using new drivers from outside of molecule repo for example? If I wrote some cloud driver "foo", what are my actions to use it as a driver? It's worth to have documentation about it
12:12:59 <tadeboro> We are using molecule for all of our integration tests for about 6 months now and we had almost no problems whatsoever.
12:13:56 <mohitmkspy> are we working on improving the molecule and its driver's documentation with examples ?
12:13:57 <resmo> question: will molecule the "default" how to test your ansible content (deprecates ansible-test?) cc mattclay ?
12:14:35 <rrey> Q: Geerlingguy blog post aside, is there any plan to integrate molecule in ansible-test ?
12:14:55 <rrey> ha nice resmo
12:15:03 <tadeboro> resmo: Molecule cannot run unit and sanity tests, so replacing ansible-test is not possible.
12:15:40 <sshnaidm> ansible-test is mostly a "linter" test, but it can be included in molecule testing
12:16:16 <sshnaidm> or maybe adjusted/tweaked for being used in molecule scenario as a one of "linter"s
12:16:16 <gundalow> #info Q: Can anyone create drivers A: Yes, only needs the Python entry point. If you think the driver maybe useful for others please ask in #ansible-molecule and we can host it (and provide CI) along side the existing drivers in
12:16:44 <felixfontein> does molecule also do change detection, as ansible-test can do?
12:16:53 <resmo> tadeboro: ok, right. what about "ansible-test integration"
12:17:09 <mattclay> sshnaidm: Linting is only one part of what ansible-test does (sanity tests). It also runs unit tests and integration tests.
12:17:44 <mattclay> resmo: ansible-test and Molecule cover different use cases. I don't see either one replacing the other.
12:17:54 <gregdek> I see the primary role of ansible-test as the place where we define the rules of what gets accepted into Ansible and what doesn't.
12:18:27 <rrey> I was wondering if molecule could be called by ansible-test to have a single test command.
12:18:32 <sshnaidm> mattclay, sorry, missed your reply, but can ansible-test be as one of sub-tests in molecule scenario for example
12:19:34 <tadeboro> The Sensu Go Ansible Collection uses ansible-test to run the sanity and unit tests, and we use Molecule for the integration tests.
12:19:35 <gundalow> ........
12:20:08 <rrey> I think we have several questions around ansible-test as well :)
12:20:11 <mohitmkspy> thanks for demo @zbr
12:20:14 <belfast77> Thanks for the talk @zbr
12:20:52 <shaps> gregdek: not just what goes into ansible or not, ansible-test is what I'd use to test the collection's modules in general
12:21:03 <shaps> Thanks zbr :)
12:21:36 <madonius> thanks
12:21:50 <gregdek> shaps: yes, speaking broadly, every collection that goes into "Ansible" should be using ansible-test to gate all modules
12:21:55 <gundalow> #topic Community Data
12:22:00 <gregdek> Thanks zbr!
12:22:06 <gundalow> .=.=.=..=.=.=..=.=.=..=.=.=..=.=.=..=.=.=..=.=.=..=.=.=.
12:22:08 <gundalow> .=.=.=..=.=.=..=.=.=..=.=.=..=.=.=..=.=.=.
12:22:09 <gundalow> .=.=.=..=.=.=..=.=.=..=.=.=.
12:22:58 <shaps> +1000 gwmngilfen for using i3 :D
12:23:07 <gundalow> #info gwmngilfen is now presenting how the Community Team uses data to make decisions
12:24:56 <gundalow> DING DING DING Reminder: If we didn't answer any questions please add them to and we will go though them later on
12:25:12 <gundalow> ^ Particularly important for questions around Collections
12:25:36 <digigrate_> is link to the committers map metrics available to general public?
12:25:49 <gregdek> All of this data should be public.
12:25:59 * jimi|ansible -> more coffee, brb
12:26:14 <gregdek> Is this url accessible?
12:26:21 <gregdek> digigrate_: ^^
12:26:31 <gundalow> then click on `meetup maps`
12:26:32 <shaps> gregdek: yeah
12:26:39 <gregdek> #link
12:26:52 <digigrate_> gregdek: yes!
12:26:57 <gundalow> All, have a look at the graphs that are being shared
12:27:33 <gundalow> rrey: This (grafana #1 for number of contributors) is your great work :)
12:27:45 <rrey> \0/
12:29:28 <ikhan> gundalow: question for Greg Sutcliffe - is he only keeping track of collections under ansible-collections org or also other vendor collections that moved to their own Github organizations?
12:30:09 <zbr> what counts as a contributor? a raised PR or a merged PR?
12:30:14 <gundalow> ikhan: we can graph anything which we can access via Git (doesn't have to be GitHub). If you have others you'd like to add just ping gwmngilfen a list of URLs
12:30:39 <gundalow> zbr: Merges (in the future we may look at issues and PRs)
12:30:57 <zbr> I know for sure that lots of people refused to cotribute because they said: "why to fix this when i will be able to make use of it only in 1y+ from now, mainly because of the backporting policy.
12:30:58 <ikhan> gundalow: ++ thanks!
12:31:16 <dmellado> Yeah, that's interesting, I do wonder about the metrics for contributions, would only MERGE then be counted? do you count also open PR ?
12:31:29 <gundalow> zbr: Yup. One of the nice things about Collections is they can be released much more frequently
12:31:53 <gregdek> zbr: in my opinion, for *success* we should be measuring merged PRs -- but we could very well consider "non-merged" PRs as a different critical metric -- who's leaving a lot of PRs on the doorstep?
12:32:17 <shaps> and possibly why are those PRs being left there
12:32:19 <zbr> gundalow: yep, this should motivate people to contribute, bad part is that it will take at least one year to really see the benefits, as they first need to upgrade to 2.10 to be able to benefit from patches on collections.
12:32:19 <gregdek> A good thing I can toss on gwmngilfen's todo list :)
12:33:11 <jimi|ansible> zbr: it's always a process - when we did 2.0 there were a lot of people on 1.x for quite a while
12:33:21 <rrey> it would help identify struggling maintainers too
12:33:22 <dmellado> I'd also look at this -been there for a logn time- as a good sample on stats from an open source project
12:33:25 <dmellado>
12:33:27 <gundalow> danieldm For the moment we are only looking at merges. Once the repos are fully open (ie we allow easier moving of PRs from ansible/ansible to the individual repos) we will start tracking Issue and PRs backlog. Growing backlog is going to be a concern for (say)
12:33:56 <acozine> o/
12:33:59 <dmellado> gundalow: gotcha, makes sense!
12:34:04 <gregdek> Hi acozine!
12:34:15 <gundalow> zbr: ah, I think I miss answered your question. People could use ansible-2.9 and the collections should work
12:34:17 <acozine> good morning, folks!
12:34:23 <gundalow> acozine: Hi :)
12:34:46 <gundalow> Reminder we are using for questions for later talks
12:35:09 <jtanner> 2.9.0 should fundamentally work with collections, but that does not mean all collections+plugins are going to work with 2.9 as their import paths are likely to diverge greatly
12:35:13 <gundalow> #action gundalow to add to Collection stats
12:35:34 <gundalow> #action ikhan to privide gwmngilfen with lists of other repos to add to
12:35:38 <zbr> gundalow: hmm, i almost forgot about that. this could be game changer. For sure collections are clearly the right change moving forward.
12:36:00 <ikhan> gundalow: sure will get that info
12:37:01 <gregdek> Hey ikhan, good morning :)
12:37:18 <ikhan> gregdek: good morning!
12:37:25 <gundalow> #chair dmellado ganeshrn ikhan jimi|ansible nitzmahone acozine rrey shaps digigrate_ digigrate madonius belfast77  tadeboro jpmens sshnaidm mattclay resmo Pilou TKersten webknjaz
12:37:25 <zodbot> Current chairs: Pilou TKersten acozine belfast77 cybette digigrate digigrate_ dmellado ganeshrn gregdek gundalow gwmngilfen ikhan jimi|ansible jpmens madonius mattclay nitzmahone phips rbergeron resmo rrey shaps sshnaidm tadeboro webknjaz
12:38:02 <acozine> ah, I just discovered the livestream
12:38:09 * acozine is still waking up
12:38:15 <felixfontein> good morning acozine :)
12:38:22 <shaps> hi acozine :)
12:38:23 <felixfontein> (and everyone else who showed up recently)
12:38:58 <acozine> hallo felixfontein shaps gregdek gundalow
12:40:10 <rrey> \0/
12:40:30 <nitzmahone> #meetingtopic Ansible Contrib Summit 2020 - main stream @
12:40:55 <gundalow> nitzmahone: oh, nice I didn't know that feature
12:41:02 <nitzmahone> cheers
12:41:07 <dmellado> quick  q here regarding the stats, would the plan be to also store data regarding authors/commits? if so, things might've been messed a bit up by the migration to collections
12:41:41 <gundalow> AFAIK we didn't maintain git history on migration move
12:41:49 <dmellado> that's my main concern
12:42:13 <dmellado> just noticed it lately when working on some collections and seeign gblame as
12:42:40 <rrey> yeah it kind of mess with code ownership :/
12:42:44 <zbr> it is extreamly hard to maintain history on such moves, when merging is easier but slitting is not practically possible
12:42:46 <sshnaidm> dmellado, yeah, for a real blame you'll need to look at previous version in github
12:42:56 <gundalow> ah, `git blame` (finding who to ask about something) can be an issues, mean you'd need to do a git blame on the original (now deleted) files in ansible/ansible
12:43:30 <dmellado> CaptTrews yeah xD
12:43:36 <rrey> I tried to keep it on a keycloak collection, but it also mean that we keep the thousand contributors from ansible/ansible
12:43:42 <dmellado> so you'd have to go back there and so
12:43:49 <sshnaidm> in openstack I wanted to preserve a history, but it was too much overhead
12:43:52 <felixfontein> there's the tag 'pre-ansible-base' in ansible/ansible which is the last commit when everything was still there
12:44:03 <felixfontein> will be useful for running `git blame` against :)
12:44:06 <dmellado> so I know it's a huge change, and that that might've been too much complex to handle
12:44:13 <zbr> as i said in the past, if you endup using `git blame`, is a sign that code was not properly documented. git commit is not the place to document changes.
12:44:14 <sshnaidm> felixfontein ++
12:44:15 <madonius> felixfontein: one has to actually know that, right?
12:44:27 <dmellado> but I wonder if there'd been some way to keep git history over there
12:44:32 <felixfontein> madonius: so far, yes, I don't think it is documented yet
12:44:38 <gundalow> #info git tag `pre-ansible-base` in ansible/ansible is the commit before most of the modules got `git rm`'ed
12:44:40 <dmellado> as it might also mess data/stats quite a bit
12:45:12 <madonius> zbr: you are correct, but reality and theory do not diverge, in theory… :/
12:45:29 <zbr> true
12:45:49 <rrey> Q: to have this metrics relevant you'll need to be aware of collections created right ?
12:46:11 <rrey> how can one opt in for the metrics ?
12:46:32 <gundalow> rrey: could you expand on that?
12:46:51 <resmo> is this only for collections under github/ansible-collections?
12:47:07 <gundalow> rrey: or maybe jump on the call and ask
12:47:11 <resmo> (collection in galaxy might have a private git repo right?)
12:47:15 <rrey> sure. If I start a collection it won't be in the radar if it is outside ansible-collections
12:47:32 <sshnaidm> gundalow, I think it's question about including metrics of collection outside of ansible
12:47:45 <rrey> yep
12:47:45 <gundalow> ah, OK
12:47:50 <dmellado> how do you plan to scale this to the n repos on collections?
12:48:08 <sshnaidm> gundalow, like openstack modules :)
12:48:13 <acozine> felixfontein: madonius if either of you would be willing to author a paragraph about "how to git blame on pre-collection changes to a module", I'm happy to merge that into
12:48:18 <gregdek> At some point, we'll have policies for having new collections included in the Ansible distribution. When we start doing that, pulling in stats will be one of the activities that happens there.
12:50:59 <felixfontein> madonius: if you want to write that, feel free :)
12:53:15 <madonius> I am not quite sure where I would put that
12:53:44 <madonius> or if "developing collections" would be the right place… :/
12:54:10 <acozine> that's the closest we have so far . . . at least it's aimed at developers working on collections
12:54:34 <madonius> ideally it would be something along the lines of "if you are reading this then you want to go there"
12:54:36 <rrey> afk
12:54:55 <acozine> we'll need to expand content about collections on the developer side
12:54:58 <gundalow> Returning in 15 minutes
12:55:12 <gwmngilfen> dmellado: if I can scale to crawling ansible/ansible, i can handle the collections. at least for now :)
12:55:30 <nitzmahone> #topic 15m break, back @ 14:10 UTC
12:55:39 <gwmngilfen> for comparison, crawling the entire ansible-collections org currently takes ~20mins, crawling ansible/ansible takes ~17 hours :P
12:55:43 <gundalow> Reminder you can add questions to
12:56:14 * nitzmahone suspects `gwmngilfen` is Welsh with that collection of consonants?
12:56:57 <gwmngilfen> nitzmahone: good guess. I'm not, but there is a connection which is much longer and more convoluted than you could guess :P
12:57:17 <nitzmahone> Sounds like a good story for San Diego :)
12:57:35 <gwmngilfen> if people want to see some of my other work, please try not to ddos the server :D
13:00:42 <madonius> gwmngilfen: thanks for the insights :)
13:00:58 <gwmngilfen> my job^w pleasure :D
13:03:49 <gwmngilfen> #info is the url for the contributor stuff, if anyone missed it above
13:04:41 <jtanner> gwmngilfen:  i presume that's cumulative sums? any intent to track active over date ranges?
13:04:58 <jtanner> something like how many were actually active in a given month / week / etc
13:05:29 <gwmngilfen> right, cumulative unique contributors, broken down by week
13:06:42 <gwmngilfen> jtanner: i do have non-cumulative contributors on the prototype dashboard I shoed, so that will probably stay
13:06:47 <gwmngilfen> iirc that is also weekly
13:06:49 <jtanner> k
13:06:56 <cybette> gundalow: when we get back from break, might be good to let those who joined later to do intros. e.g. acozine , ikhan  etc.
13:07:39 <jtanner> what i'm most interested in is showing whether or not a collection has active maintenance or if it's just rotting, despite how many people may have contributed historically
13:09:08 <rrey> jtanner it could be a nice indicator on galaxy that could help choosing between 2
13:10:14 <gwmngilfen> jtanner: thats fair, for sure. the cumulative stuff only really applies during the migration phase, I think, as a way to see how we're doing regaining momentum. after that, it's back to standard line graphs.
13:10:29 <ikhan> @jtanner it also depends if the code is relatively stable in collection and there is not a whole lot of request/need of new features - you may not see a whole lot of activity on that collection
13:10:38 <felixfontein> gundalow: time's up!
13:10:51 <jtanner> yeah, it's nice to see cumulative either way. not trying to diminish it's usefulness
13:11:35 <jtanner> ikhan:  true ... but how do we know it's still being used or people have given up because it's  always broken
13:12:02 <gwmngilfen> thats a hard problem, for sure
13:12:23 <gundalow> #topic Intros part 2
13:12:27 <gwmngilfen> you cant normalise by issues/PRs, they're correlated for sure
13:12:47 <gundalow> #info Just doing another round of intros for people that have joined the call since we started earlier
13:13:38 <digigrate_> acozine: ‘word weaver’ for a living!
13:13:54 <gregdek> jtanner: seems like the "time to response by maintainers" might be a good answer to that question. If every issue/PR gets a quick response from its maintainers, we can probably surmise that it's "well maintained".
13:14:19 <gwmngilfen> thats true. also many issues that dont have attached PRs, perhaps?
13:14:24 <gwmngilfen> especially open ones
13:14:30 <jtanner> and the converse: if they never respond, what can we assume?
13:14:56 <gregdek> I think that's a pretty clear case: no response + no closure = no maintainership
13:15:38 <sshnaidm> acozine, prior to changelog storage, could we consider choosing changelog tool for collections? Should be the same? For example in case some collection wants to use a different one, like reno
13:15:41 <gundalow> In the collection repos I expect we will be a lot stricter about closing issues that don't have any comments
13:15:46 <zbr> indeed, i would like to see a "time to respond from cores" measured/reported
13:16:06 <ikhan> jtanner: that's a good point.  I hope someone in community is complaining that something stopped working with those stale collections.  It is hard to test every collection especially if those platforms are not available for testing.
13:17:42 <gwmngilfen> jtanner: what does "cores" mean here? the maintainers of a given collection?
13:17:49 <acozine> sshnaidm: so far we've looked at reno and at towncrier . . . open to other suggestions if folks know about other tools
13:17:51 <jtanner> zbr ^
13:18:00 <gwmngilfen> oops
13:18:15 <gwmngilfen> same colour in my client for some reason :P
13:18:25 <zbr> on molecule-* we use release-drafter: mainly using PR title + labels to automate release not creation.
13:18:42 <sshnaidm> acozine, I suppose it's the topic to discuss?
13:19:07 <gwmngilfen> it's offical, ansibot is a sham, jtanner just does it all :P
13:19:09 <acozine> sshnaidm: yes, thanks for posting that
13:19:16 <jtanner> i'm the spammer
13:19:46 <gundalow> #topic ansible-lint
13:20:08 <gundalow> #info zbr is giving an presentation on ansible-lint
13:20:10 <gwmngilfen> zbr: what does "from the cores" mean here? the maintainers of a given collection?
13:20:21 <gwmngilfen> oh, you're speaking, it can wait :)
13:21:08 <resmo> sshnaidm: acozine so what ever "ansible" choose for changelog, it only should be a recommendation, every project should be free to choose a tool. So basically this reduces to changelog being just a link to the actual changelog file.
13:22:02 <sshnaidm> resmo ++
13:22:59 <acozine> resmo: we will probably end up with a policy of "you may handle changelogs any way you want, however, if you want changes from your collection included in {{ ACD_changelog_file }}, here's how"
13:23:22 <resmo> acozine: that would be perfectly fine for me.
13:25:06 <gundalow> #info ansible-lint docs:
13:25:25 <gundalow> #info ansible-lint repo:
13:26:15 <acozine> madonius: we need to overhaul for the NWO, turning it into a Collections Maintainer Guide - that's another potential spot for the docs on finding pre-collections-migration code changes
13:27:47 <sshnaidm> Would be great to have auto-ansible-lint that will fix lint issues. Like autopep8 that fixes pep8 issues
13:27:58 <fobhep> 1. what is the best pratice to lint a whole directory containing ansible-files that are not a playbook. so far I am doing it like this ansible-lint $(find . -type f -name "*.yml" -o -name "*.yaml") is there any better way? ansible-lint is not working recursively afaik?
13:27:58 <fobhep> 2. how would I make ansible-lint know about a collection I installed?
13:28:49 <jtanner> sshnaidm:
13:29:58 <agaffney> sshnaidm: pep8 is all code formatting, where not all ansible-lint issues are. you can't easily automatically fix an unnecessary use of command/shell
13:30:09 <sshnaidm> jtanner, ack, but this is for YAML issues only
13:30:44 <sshnaidm> agaffney, yeah, like autopep can't fix all issues as well, only easily solvable
13:31:15 <sshnaidm> for example ansible-lint rule can contain "fixme" code section, which can be applied in autofix
13:31:24 <agaffney> and modifying YAML in-place while preserving formatting and comments is...tricky
13:31:27 <webknjaz> @sshnaidm: linters cannot know what the intention of the user was. "autofixing" things would bring more harm
13:31:45 <agaffney> indeed
13:32:07 <fobhep> yes
13:32:09 <fobhep> what is the best pratice to lint a whole directory containing ansible-files that are not a playbook. so far I am doing it like this ansible-lint $(find . -type f -name ".yml" -o -name ".yaml") is there any better way? ansible-lint is not working recursively afaik?
13:32:10 <fobhep> how would I make ansible-lint know about a collection I installed?
13:32:57 <jtanner> iirc, ansible-lint is only scoped to playbooks/task files ... ansible-review attempted to look at other things like vars
13:34:08 <fobhep> cool, thanks
13:34:38 <belfast77> do you have to exclude ansible vault files or vault inline ?
13:34:41 <fobhep> how would I make ansible-lint know about a collection I installed?
13:34:42 <shaps> jtanner: yeah, I think that was the purpose of ansible-review, but not sure what the state of it is
13:35:07 <jtanner> curious what zbr's thoughts are on ansble-review's future
13:35:30 <sshnaidm> cool, didn't hear about ansible-review before..
13:35:31 <belfast77> ok thanks
13:35:43 <jtanner> iirc, awcrosby had been researching/chatting about it with willthames a while back and there was some idea that maybe it could be ported back to ansible-lint
13:35:57 <sshnaidm> seems like it stopped in 2019
13:39:58 <shaps> thanks (again) zbr :)
13:40:22 <gwmngilfen> zbr++
13:41:12 <felixfontein> loud enough
13:41:28 <gundalow> #topic Collections: User Experience
13:41:52 <gundalow> #info nitzmahone is now explaining about how we ended up with `ansible-base`
13:42:14 <gundalow> Questions were around how small could we make ansible-base (gh/ansible/ansible)
13:42:59 <jpmens> should I be seeing slides on bj?
13:43:03 <gundalow> We did a prototype of ansible with no modules, there was no way that this could be useful
13:43:07 <gundalow> jpmens: no slides
13:43:11 <jpmens> ta
13:43:17 <gundalow> ah, let me screen share some docs
13:44:15 <gundalow> #info Definition of ansible-base
13:44:21 <gundalow> Is my screen readable?
13:44:28 <jpmens> gundalow: yes
13:44:31 <gwmngilfen> fine here
13:44:32 <jtanner> mostly
13:44:56 <gwmngilfen> maybe bump it one more zoom level to be sure
13:44:56 <gundalow> I'm sharing above URL
13:49:20 <jpmens> first bit o' good news: ansible-doc -l becomes fast again! ;-)
13:49:46 <jpmens> (with 69 modules only)
13:50:00 <jpmens> disclaimer: I invented it :)
13:50:37 <abadger1999> At the moment, I think that distributions and other system packagers will package ansible-base into one package.  They'll package the same collections as ACD includes into other packages.  Then they'll create an ansible package which depends on all of those.  Thus when a user installs ansible (example: yum install ansible )  it will pull in the ansible-base and collections packages.
13:51:13 <zbr> ansible-devel broke molecule CI last week but it was easy to fix it by adding an extra line to install the removed docker modules.
13:51:57 <jtanner> community.general or did those move again?
13:52:07 <zbr>
13:52:15 <felixfontein> jtanner: community.general
13:52:27 <felixfontein> no plans to move anywhere else AFAIK
13:53:35 <jtanner> tbh, i would think those would be a great candidate for their own collection
13:54:33 <gundalow>
13:54:56 <zbr> my power-tip: setup CI to run on ansible-devel and you will not be hugely surprised on upcoming changes
13:55:01 <felixfontein> jtanner: they'd need more maintainers for that
13:55:02 <digigrate_> So… batteries included, no more? what will be the new phrase? ‘not so many batteries included’?
13:55:04 <sshnaidm> Q: Are collections dependencies on user to install? It won't be deps of ACD, right?
13:55:12 <jtanner> felixfontein: that's probably true
13:55:37 <felixfontein> jtanner: I'm happy to maintain some of them as long as I use/need them, but there are others which have not so active, or simply no real maintainers
13:56:12 <zbr> you can have "non-voting" CI on ansible-devel, so you learn about breaking things and have time to *gradually* transition your code
13:56:15 <nitzmahone> sshnaidm: correct; controller-side collection deps (and related metadata, etc) are part of the execution environment concept
13:56:29 <felixfontein> and the docker community is somewhat winding down it seems, like docker-py development has been very inactive over the last 9 months or so
13:56:53 <jtanner> felixfontein: yeah, but that could be  another reason to move them out of general ... so they can safely die
13:56:54 <sshnaidm> nitzmahone, ack, thanks
13:56:55 <nitzmahone> So just installing the collections doesn't try to address any deps the collection might have
13:56:57 <odyssey4me> gundalow: why 'ansible-base' vs 'ansible-core' - there have been references to 'core' for a long time afaik
13:57:00 <gregdek> Let's be clear, though: "pip install ansible" will install all of the collections that have been broken out. ACD is a packaging of all collections currently in Ansible 2.9 that should look identical to "Classic Ansible" -- and ACD is really just "Ansible" to most users.
13:57:04 <felixfontein> jtanner: true :)
13:57:19 <felixfontein> jtanner: though there are quite some better candidates for *that* in community.general ;)
13:57:27 <jtanner> felixfontein: definitely
13:57:42 <jtanner> i think you know as well if not better than most
13:58:00 <gundalow> odyssey4me: good question. Mostly because `core` (ie ansible core) is an overloaded term
13:59:08 <odyssey4me> gundalow: it is rather overloaded - fair enough
14:00:26 <resmo> jpmens: and additionally to your comment, many customers want to test in their staging environment, so the testing gets more complex, because they have to test new ansible with existing verison collection and new collection releases with existing ansible. seems work does not go away ;)
14:00:27 <zbr> offline install needs to be documented in the same page where we document galaxy install collection, thing should be enough.
14:02:13 <abadger1999> Warning note...... *Just for testing*  You'll want to remove these packages after installing them.
14:02:27 <abadger1999> python3 -m pip install -i ansible
14:02:27 <gundalow> #actions Docs need updating  to make it clearer how Collections can be released offline (without access to
14:02:52 <abadger1999> (I just put those there.... I'm testing that right now too)
14:03:06 <jtanner> it might be helpful to have a "if i used to x to install ansible and do y with it, now i should do z" doc
14:03:07 <resmo> question: I assume we get a few RCs before final release?
14:03:16 <gregdek> resmo: oh yes :)
14:03:25 <TKersten> Q: But how do I get the complete set, batteries included?
14:03:25 <nitzmahone> resmo: nah, do it live ;)
14:03:37 <jtanner> TKersten: what are the "batteries" to you?
14:03:43 <sshnaidm> Q: can I set a git url in requirements.yml?
14:03:43 <nitzmahone> TKersten: `pip install ansible` - just like before
14:04:00 <fobhep> Q: do I need to specify also  collections:  ansible.builtin ? for best pratice usage
14:04:05 <fobhep> ?
14:04:10 <resmo> nitzmahone: ;)
14:04:23 <jpmens> what does ACD stand for?
14:04:24 <zbr> gundalow: please also add "installing from local tar"  like file:/// ... kind of install, this needs to be covered too.
14:04:31 <nitzmahone> Ansible Community Distribution
14:04:31 <abadger1999> Ansible Community Distribution.
14:04:40 <jtanner> if you needed to always  put "ansible.builtin" in the collections keyword, that would be annoying to the point that we would have made it transparent.
14:04:47 <TKersten> nitzmahone: If that's all, then that should be doable.
14:04:47 <TKersten> jtanner: What I mean is just a set like we have now
14:04:49 <zbr> acd-disorder :D
14:04:57 <fobhep> jtanner: exactly my point
14:05:05 <fobhep> ok
14:05:09 <fobhep> so not :D
14:05:10 <fobhep> thanks
14:05:38 <jtanner> fobhep: the "builtins" are still in their  previous locations and still accessible without FQCNs or collection keyword usage
14:05:39 <jpmens> gregdek: it wasn't clear to me; thanks for the clarification
14:06:00 <sshnaidm> zbr, it's supported, run ansible-galaxy collection install /path/to/tar
14:06:36 <zbr> sshnaidm: i know the answers, but i mention here because I know that they are missing from the docs, and it took some time to findout.
14:06:51 <sshnaidm> zbr, it's in ansible-galaxy --help
14:07:14 <abadger1999> Eventually the names we call things by should change.  So well' start calling  current ansible  => ansible-base    and acd => ansible
14:07:23 <fobhep> question: currently you can use modules via "short name" or fqcn - the short names do not to seem to work for filters
14:08:19 <fobhep> so even if I add a collection in a playbook via "collections" I have to use the fqcn to access a filter form the collection. is that intended behavior?
14:08:20 <zbr> sshnaidm|afk: in fact you underlines another place which lacks documentation, the CLI, only doc piece is "Role name, URL or tar file" does not seem as a good enough for me.
14:08:42 <nitzmahone> fobhep: please add that one to the collections questions, I can talk about that one
14:08:48 <nitzmahone> (in the etherpad)
14:08:51 <fobhep> sure
14:09:11 <gregdek> afk bbiab
14:12:13 <TKersten> But does this mean we get a lot of `ansible-collection......` packages?
14:12:13 <TKersten> Not that that is bad, but just curious
14:12:57 <felixfontein> TKersten: depends how OS packagers will package the collections
14:13:21 <resmo> gregdek: thinking of roles on galaxy, they might use e.g. modules for configure let's say mysql or postgres db, so they depend on collections. what is unclear today is, a galaxy role does not handle that dependency (yet), so they would create a collection with a role in it and depend on other collection (because that is possible today) but I have the feeling this is not how is was meant to work
14:13:55 <TKersten> felixfontein: OK, sounds reasonable. But I can imagine it would not be that bad
14:14:22 <gregdek> resmo: that's a good question. Not sure what the answer is, tbh, but I'm not close enough to the details at this point.
14:14:25 <resmo> so users create collections which causes more problems, we don't want to deal with
14:16:34 <jpmens> gundalow: exactly! before/after situations would be great to document!
14:16:53 <rrey> and reassuring
14:16:57 <jpmens> specifically from pov end-user (i.e. admin), later on maybe for developers
14:17:06 <jpmens> rrey: +1
14:17:20 <shaps> should that be part of the porting guides?
14:17:34 <rrey> shaps +1
14:18:18 <rrey> I think redhat will have to to a lot a communication around this (meetups, videos, etc ...)
14:18:43 <rrey> it must be very easy to end user to find an answer around this change
14:18:47 <gundalow> #action DOCS: "if i used to x to install ansible and do y with it, now i should do z" (install everything; use everything and one new collection; Use a new module in a collection; I don't care about collections I just want to do my day job)
14:19:00 <gundalow> #action DOCS: Need some diagrams
14:19:10 <belfast77> so currently we install ansible via RPM from Red Hat Sat6, are collections going to be available in Red Hat offical repos?
14:19:20 <jpmens> gregdek: indeed much more 'separate things' and they also need, imo, different 'language' :)
14:20:33 <gregdek> jpmens: yep. A lot of this is storytelling, and we haven't been able to focus on that because we were still working out what the story was.
14:20:41 <rbergeron> rey: yes, lots of this stuff will need tons of communication. Meetups are interesting right now, obviously :) but having a set of some standard content for folks to use at meetups (virtual, in-person someday, or otherwise) will be a thing.
14:20:42 <gregdek> Now I think we're much clearer on the story.
14:20:49 <digigrate_> a tl;dr point of view of the changes in packaging would be hlepful.
14:20:50 <fobhep> another thing from customer pov is also that people are reluctant to install anything other than RPMs.
14:21:03 <nitzmahone> belfast77: we should talk later- need specifics from you
14:21:09 <gregdek> fobhep: yes :)
14:21:24 <fobhep> there needs to be some work on convincing I guess to use ansible-galaxy as somehting "not evil"
14:21:28 <fobhep> like using pip in production
14:21:30 <abadger1999> jpmens:   Did you see that I wrote this earlier:  python3.8 -m pip install --user --upgrade -i   ansible     For offline install, one way to get that would be to download the two tarballs that are there and pip install them.
14:21:40 <TKersten> I was planning for a Meetup about the Collections. But due to corona-stuff I have to postpone or make it virtual
14:21:52 <jpmens> abadger1999: I didn't; thank you
14:22:04 <nitzmahone> belfast77: the "official paying customer" packaging story is still WIP, so we'd be curious to understand how you do things today
14:22:18 <gregdek> TKersten: hoping that cybette can help you with some virtual logistics, bluejeans dial-ins, things like that, if you need
14:22:26 <madonius> TKersten: why not virtual?
14:22:27 <abadger1999> jpmens: Note that those are just for testing.... after you're done testing them out, you'll want to pip uninstall ansible ansible-base
14:22:55 <cybette> TKersten: yes I'll be in touch with organisers to offer infra/logistics support for virtual events
14:23:20 <jpmens> cybette: virtual stickers, please. :-) <3
14:23:39 <belfast77> @nitzmahone  sure, I can fill you in (I'm just a little concerned I might lose some good tools if they are moved to different Red Hat repos)
14:23:39 <cybette> jpmens: :D
14:23:52 <jtanner> repeat question?
14:24:02 <abadger1999> (At some point I'll create tarballs with versions lower than 2.10 so that you can install them for testing now but they'll be upgraded once 2.10 final comes out)
14:24:05 <TKersten> gregdek: That would be lovely. I'll keep that in mind
14:24:06 <TKersten> madonius: Probably. Depending on the time corona takes. But I love to see and people. Otherwise we would also have virtual rijsttafel and that is not at the top of my list :-)
14:24:19 <TKersten> cybette: Thanks, we will be in touch
14:26:27 <cybette> jpmens, TKersten :  we're also looking into vendors who offer drop shipments to make it easier to distribute swag to virtual event attendees (need to see how this can be scaled)
14:26:38 <resmo> I am +1 tarballs, but without a need of galaxy server.
14:27:42 <gundalow> #action gundalow to tidyup Collections content migration & ACD
14:27:43 <TKersten> cybette: That sound good. I can imagine shipping lots of small stuff can cost a lot.
14:29:00 <belfast77> I work with Enterprise PCI/Security Environments which have no internet connections
14:29:29 <rbergeron> @gregdek can you add that point as a note in the meeting minutes
14:31:27 <gregdek> #agreed ansible-galaxy cli needs a clear mechanism to install collections via source  if the provider makes the source available
14:32:44 <rrey> main issue around this : We can't use requirement.yml if the collection is not on galaxy
14:33:08 <tadeboro> Sample multi-collection repo:
14:33:14 <acozine> #action extend user-facing documentation of how to install collections (include options beyond ACD)
14:33:16 <gregdek> rrey: This is something that geerlingguy is reminding us about continually :)
14:33:23 <rrey> so it means one has to do gruntwork on CI (wget _ ansible-galaxy collection install )
14:33:54 <rrey> gregdek I'm not surprised
14:34:04 <nitzmahone> #action belfast77 / nitzmahone to connect with product management around downstream packaging needs
14:34:27 <acozine> #action overhaul to be a Collection Maintainers page
14:35:22 <gundalow> #actions DOCS: detail the different packaging systems (PyPi, deb, etc, Galaxy) for ansible-base, ACD, individual collections
14:36:16 <acozine> #agreed collections changelogs can use any solution maintainers prefer, however, we will develop a procedure for amalgamating them based on one solution
14:37:14 <gundalow> #topic Collections: Development and Contributor
14:37:22 <gwmngilfen> 2 million? wow
14:37:41 <jimi|ansible> 1 million was the ec2 module
14:37:46 <jimi|ansible> (kidding)
14:37:48 <acozine> heh
14:37:50 <gundalow> #info webknjaz is now explaining how the migration happened from a technical perspective
14:37:51 <belfast77> lol
14:37:53 <gwmngilfen> lmao
14:38:02 <shaps> ec2 was way more than that :D
14:38:06 <gundalow> thanks to webknjaz as I put him on the spot about 15 minutes ago
14:38:26 <gwmngilfen> webknjaz++
14:39:02 <rrey> bye IRC, see you in person next time !
14:39:08 <jimi|ansible> o/
14:39:11 <gundalow> rrey: Thanks!
14:39:14 <shaps> o/
14:39:15 <gwmngilfen> o/ rrey
14:39:23 <tadeboro> o/
14:45:16 <gregdek> No questions, just glad you were able to take care of it :)
14:45:27 <gregdek> Good overview of some of the issues involved
14:45:45 <belfast77> Thanks webknjaz !
14:45:47 <cybette> webknjaz ++
14:45:51 <gregdek> Thanks webknjaz :)
14:45:54 <webknjaz> thanks :)
14:46:06 <madonius> afk
14:46:08 <gundalow> #topic 15 minute break
14:46:09 * resmo away for dinner, bbl later
14:46:10 <felixfontein> thanks!
14:46:14 <shaps> thanks webknjaz!
14:46:19 * felixfontein needs to fetch some water, I ran out of water some time ago
14:51:46 <cybette> Btw for those who joined later, please add your attendance + info (for swag) here:
15:00:49 <gundalow> #chair shertel acozine
15:00:49 <zodbot> Current chairs: Pilou TKersten acozine belfast77 cybette digigrate digigrate_ dmellado ganeshrn gregdek gundalow gwmngilfen ikhan jimi|ansible jpmens madonius mattclay nitzmahone phips rbergeron resmo rrey shaps shertel sshnaidm tadeboro webknjaz
15:01:11 <shertel> #info related issue regarding collection installation
15:01:11 <gundalow> DING DING DING Btw for those who joined later, please add your attendance + info (for swag) here:
15:01:55 <resmo> gundalow: start recording...
15:02:04 <shaps> cybette: ^
15:02:28 <gundalow> #topic Thanks
15:02:36 <gundalow> headdesk
15:02:40 <gundalow> #undo
15:02:40 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fdfffe20890>
15:02:43 <resmo> rbergeron: omg...
15:02:47 <gwmngilfen> Carol Chen++
15:02:50 <felixfontein> good morning rbergeron!
15:03:08 <odyssey4me> :) rbergeron long time!
15:03:52 <nitzmahone> #topic new join intros
15:05:45 <gundalow> #topic Collections development status
15:05:54 <rbergeron> resmo: which part :)
15:06:35 <odyssey4me> SWAG?!?! :p
15:06:36 <belfast77> hey @odyssey4me hello from Hampshire
15:06:41 <belfast77> :)
15:06:49 <nitzmahone> If I sign up twice, do I get twice the swag? ;)
15:06:52 <odyssey4me> belfast77: erm, username checks out ;)
15:06:58 <gregdek> lol
15:07:39 <resmo> rbergeron: UTC-7!
15:07:40 <odyssey4me> belfast77: ah, you're from the hampshire devops meetup?
15:07:50 <belfast77> yup that's me
15:08:14 <gundalow> #info Collection Status
15:09:43 <gundalow> #action gundalow status.rst update aws repo names
15:12:53 <rbergeron> resmo: yeah. abadger1999 is as well, and nitzmahone too
15:13:17 <rbergeron> odyssey4me: YES! i haven't seen you since fosdem last year before you started at red hat :)
15:13:19 <nitzmahone> and mattclay
15:13:47 <gundalow> #info Most Collections can be found at
15:13:49 <gundalow> Example
15:13:52 <odyssey4me> rbergeron: man, that is a long time
15:14:12 <gundalow>
15:15:30 <gundalow> Python imports
15:16:21 <abadger1999> Note about python imports: we also support relative imports in 2.10 so imports can be changed to relative if people want to (relative is usually shorter)
15:16:27 <jpmens> community collections in galaxy have an A logo which makes me think they're supported, but gundalow just said they're not; confusing.
15:16:57 <gregdek> jpmens: so! different logos is part of the issue here.
15:17:25 * jpmens is trying to be constructive :)
15:17:26 <gregdek> The Red A / Red Hat is the logo for Company Supported. The Teal A is the logo for Community Supported.
15:17:36 <abadger1999> So `from import grafana_argument_spec` could be `from ..module_utils.base import grafana_argument_spec`
15:17:43 <gwmngilfen> #action gwmngilfen to work on tracking which parts of community.general are getting large
15:17:44 <jpmens> gregdek: wow; I didn't know that
15:17:55 <gregdek> No, that's a great point. That's part of the branding discussion, and it's not clear yet. Still in process.
15:18:10 <gregdek> Basically, we're looking at the Fedora / RHEL metaphor here.
15:18:29 <gregdek> Except that in that case, RHEL kept the Red Hat logo, and the community had to create their own logo.
15:18:49 <gregdek> In this case, community will inherit the old logo, and the enterprise version will have the new Red Hat logo.
15:18:52 <jpmens> red A on white background to make it completely different?
15:19:12 <gregdek> Actually, we'll probably phase out the Red A entirely in favor of a Red Hat brand.
15:19:13 <jpmens> gregdek: which is the 'new' RH logo?
15:19:14 <misc> "fedoransible"
15:19:25 <resmo> misc: lol
15:19:25 <jimi|ansible> ansidora
15:19:32 <acozine> misc: that's better than ansibora
15:19:36 <cybette> - > Community vs Red Hat logos
15:19:40 <jimi|ansible> o_O
15:19:57 <gregdek> So imagine the logo here:
15:19:58 <cybette> (for now, I think changes are in progress)
15:20:08 <gregdek> Except instead of the Red A, it'll be the Red Hat.
15:20:48 <jpmens> gregdek: no mention of official/comunity on that page ;)
15:20:49 <gregdek> Again, changes in motion, and as such, always subject to change -- but it's our intention to inherit the classic Ansible logo to refer specifically to the community activities / projects / bits.
15:20:57 <gregdek> jpmens: no, there isn't, lol -- part of the issue.
15:21:20 <gregdek> We've been strengthening our hand to take over key bits of, some more work to do yet.
15:21:32 <gregdek> But we're getting there. Everyone understands the need for brand clarity. Now we just have to do it.
15:21:46 <nitzmahone> #topic routing/redirection in 2.10
15:21:48 <nitzmahone> #info
15:22:10 <belfast77> So if an Enterprise customer is installing from RPMs now, they will lose access to those modules without going back to their security teams to get approval for community supported modules ?
15:22:37 <abadger1999> belfast77: That sounds correct to me.
15:22:47 <gundalow> #info nitzmahone is now talking about how 2.9 playbooks will still work out of the box when people install Ansible 2.10
15:23:16 <abadger1999> belfast77: And there may be rpms provided by EPEL or something outside of Red Hat.  But not by Red hat itself.
15:23:18 <odyssey4me> belfast77: as far as I understand it, the expectation is that the 'ansible' package will be a virtual package which depends on 'ansible-base' (the core stuff) and another package with the comunity stuff in it.
15:23:45 <shaps> belfast77: if you plan on installing the ansible RPM then I guess no
15:24:30 <abadger1999> My current understanding is that red hat won't be providing an ansible RPM; they will provide an ansible-base RPM.
15:24:51 <resmo> .oO(collections in library...?)
15:25:07 <gundalow> resmo: ?
15:25:12 <abadger1999> Or was it library (module_utils) in library?
15:25:21 <resmo> just thinking loud but never mind...
15:25:30 <shaps> abadger1999: ah, so 'ACD' is not going to be packaged by RH?
15:26:12 <gundalow> shaps: ACD (ie the `ansible`) package will contain supported and unsupported content
15:26:39 <shaps> k, sounds reasonable
15:26:39 <abadger1999> shaps: AFAIK, it won't be packaged as an RPM by RH.  There's a new thing called execution environments which tower is going to use.  There may be one which is based on ACD (and a different execution environment based on pure ansible-base).
15:26:42 <jpmens> collection CNAMEs
15:27:05 <abadger1999> I'm unclear whether execution environments will be useful/distributed outside of tower, though.
15:27:06 <shaps> jpmens: it will be DNS's fault in the end :)
15:27:13 <misc> jpmens: collection round robin
15:27:17 <jpmens> shaps: of course
15:27:32 <jpmens> misc: sounds just about right :)
15:27:56 <shaps> abadger1999: yeah, nitzmahone mentioned exec environments earlier
15:28:03 <gundalow> One of the requirements of Collections has been to make easier to avoid having unsupported content installed (if you are installed the supported RPM)
15:28:15 <gwmngilfen> jpmens: +1 CNAMES is it.
15:28:15 <gwmngilfen> Kris Buytaert will be delighted it :P
15:28:29 <gwmngilfen> *delighted to hear it
15:28:31 <shaps> but will ACD still be shipped in
15:28:41 <odyssey4me> heh, leave it to jpmens to use a DNS metaphor :)
15:28:44 <gregdek> shaps: my guess is that RH ships ansible-base as an RPM because they'll have to in order to support other RH Ansible usage... but don't hold me to it, no decisions made yet there afaik
15:29:19 <shaps> as long as I can grab an RPM from I'm happy, not bothered too much about how/what RH ships
15:29:38 <shaps> ACD RPM that is
15:29:38 <gregdek> Do you care if it's full ACD or ansible-base?
15:29:41 <gregdek> Ah, ok
15:30:12 <gregdek> That's probably a question for abadger1999
15:30:28 <odyssey4me> personally, I'm really liking that collections can release independently so that we can pick up bug fixes much, much faster
15:30:31 <gregdek> I don't know why we couldn't ship both an ACD tarball and an ansible-base tarball, but I don't know the details
15:30:35 <abadger1999> shaps: I've heard that there will no longr be rpms shipped on
15:30:40 <gregdek> odyssey4me: that's the hope!
15:30:45 <belfast77> if the repo changes, it means I have to raise a security risk assessment and proxy whitelisting change, etc ... oh joy :)
15:31:10 <abadger1999> I could put acd tarballs there since we'll be generating that for pypi as well.
15:31:24 <gregdek> 👍
15:31:46 <gregdek> omg, irccloud has emojis like slack, lol
15:31:47 <shaps> I guess acd tarballs will be fine as well
15:32:15 <gwmngilfen> gregdek: and they render properly on a matrix client. THE FUTURE IS HERE
15:32:22 <gregdek> SHUT UP! wow
15:32:25 <odyssey4me> lol gundalow my thinking exactly
15:33:02 <abadger1999> belfast77: Yeah... and if you're doing things according to github repo..... There will not be a unified repo for all the collections that go into acd.  There's scripts to generate ACD but ACD itself is just a conglomerate of several other collections.  So the repositories for the code will be those upstream collections.
15:33:22 <gundalow> #topics Collection docs
15:33:37 <gundalow> #topic Collection docs
15:34:06 <gundalow> #info acozine is now talking about how Collection documentation will be generated
15:34:23 <nitzmahone> abadger1999: I didn't look at the script yet, are you pulling from Galaxy or N collection repos?
15:34:28 * gwmngilfen pays attention, docs == webstats... :P
15:34:51 <misc> each time I read "ACD", I think we are 1 letter close to maintain the rock band naming of ansible release (like Ansible Community Distribution of Collection would be perfect)
15:35:05 <jpmens> ACID
15:35:16 <gundalow> #info 2.9 module index <- Based on the directory structure under `lib/ansible/modules/` (before modules were deleted)
15:35:29 <abadger1999> nitzmahone: The current script pulls from galaxy.  I need to talk to legal about GPLv3 obligations.  If the ruling from them is, galaxy doesn't constitute source so you need to pull from the git repo, then I'll have to change that.
15:35:52 <gundalow> #info  2.9 Module URL
15:36:08 <jpmens> advertisement ;)
15:39:27 <gregdek> misc: you are not the first person to make that observation ;)
15:39:31 <rbergeron> ;)
15:39:33 <rbergeron> lol
15:39:58 <gwmngilfen> time to go help with kids. cya tomorrow folks, will be around if anyone has data ideas :)
15:39:59 <gundalow> #info Example Collection doc
15:40:22 <gregdek> Thanks gwmngilfen!
15:42:17 <gundalow> #info Collection level (plugin index)
15:42:29 <gundalow> #action DOCS: Table showing old and new URLs
15:45:18 <gundalow> Any questions on Collection docs?
15:45:53 <odyssey4me> I'm wondering what sort of standard interface needs to be in place to make this publication work?
15:46:27 <odyssey4me> I know that there's been some discussion around changelogs/release notes... and that's free to each collection to handle their own way.
15:46:44 <gregdek> acozine: I have experience, but it's not... good or recent :)
15:46:59 <felixfontein> odyssey4me: it would be nice if there's a common machine-readable format used by all collections
15:47:08 <gundalow> odyssey4me: for module & plugin documentation just follow what was done in ansible/ansible. Also use `ansible-test sanity` which will check for most common issues in module documentation
15:47:09 <felixfontein> no matter which tool collections end up using
15:47:19 <gregdek> Fortunately, it's a flat list of URLs that needs to be generated once, correct?
15:47:42 <felixfontein> (I was just talking about changelogs, porting guides, release notes)
15:47:50 <tadeboro> Any plans on providing an "official" tool for exracting the API docs from the modules?
15:48:29 <felixfontein> tadeboro: you mean the tool which creates the .html files for
15:49:06 <tadeboro> felixfontein: the tool that takes the module source and creates a rst actually.
15:49:25 <felixfontein> tadeboro: that's the tool; rst -> html is done by sphinx
15:49:47 <gundalow> tadeboro: at the moment that's in ansible/ansible docs/
15:50:06 <tadeboro> But this tool is really not available to external collections.
15:50:18 <gundalow> ....................................
15:50:31 <gundalow> acozine is now talking about porting_guides and changelogs
15:50:45 <gundalow> #info 2.9 Porting Guides
15:50:49 <jpmens> tadeboro: ansible-doc opens the module and reads the metadata from the module; it will also support modules  in collections
15:50:50 <felixfontein> tadeboro: I know that abadger1999 is working on the tool, though not whether it is planned to release it officially (like ansible-test)
15:51:09 <odyssey4me> gundalow: FYI there's also a sphinx extension in which autodocuments roles and modules like this
15:51:20 <gundalow> tadeboro: Is this because you'd like to host your own docs?
15:51:27 <gundalow> odyssey4me: Nice, thanks for sharing
15:51:53 <felixfontein> gundalow: I think it would be really great if that tool could be opened, especially for companies who have internal collections they do not publish, and want to generate docs for them
15:52:07 <felixfontein> (also for collection developers to see how their docs will look like)
15:52:58 <nitzmahone> The plugin->rst stuff could probably be done as a special case in ansible-doc, but the thought of trying to package/support html generation is ... :O
15:53:22 <tadeboro> Yeah, we needed to document one of our collections and we hacked together a tool that mimics what ansible-doc does and then integrated the output in our Sphinx site.
15:53:29 <abadger1999> tadeboro: yeah, what I'm currently working on is tightly integrated into the ansible build process..... I was thinking last week (as I worked on other htings) that it might be nice to extricate that into something else. I hadn't thought about its own tool but I could see the benefit of that.  I'd have to talk to acozine about that and also think about how that would impact the time requirements.
15:53:33 <nitzmahone> A couple of internal "live" HTML generators for Automation Hub etc are in the works
15:53:48 <nitzmahone> Those are MUCH simpler to deal with than , eg the sphinx pile we use internally
15:54:06 <gundalow> #action Document (best case separate tool chain) that allows people to build module docs outside of Ansible. Or perhaps Collection Explorer. Link to this from dev_guide.
15:54:11 <tadeboro> This is the tool that we currently use:
15:54:30 <sshnaidm> gundalow, maybe I missed, but is ACD going to be released once a half year with ansible-base? Does it mean the new code of collection will be available there only once in half year too?
15:54:32 <gundalow> #info There is a tool that allows you to view locally installed Collection documentation
15:54:42 <tadeboro> The collection that we document:
15:54:51 <nitzmahone> sshnaidm: I think abadger1999 will address that next
15:55:01 <tadeboro>
15:55:06 <abadger1999> @sshnaidm I can talk about that in the next section.  Please remind me if I forget to talk about that explicitly.
15:55:13 <sshnaidm> abadger1999, cool!
15:55:21 <tadeboro> ^ the generates site
15:55:27 <tadeboro> abadger1999: Great!
15:55:27 <gundalow> sshnaidm: I expect collections to be released more freequently
15:55:33 * nitzmahone almost brought that up in the docs discussion, but it makes more sense in the ACD discussion
15:55:49 <gundalow> and collection releases will most likely speed up as we have more confidence and experience
15:56:11 <zbr> i hope that acd would release as often as possible, as long it passes CI testing.
15:56:13 <gundalow> tadeboro: If you have a mac you can use locally to view collection docs
15:56:28 <sshnaidm> abadger1999, maybe worth to mention about changelog tool that we mentioned before
15:56:35 <nitzmahone> Basically collections could be any cadence, ACD will be a regular snapshot of some collections + an ansible-base release pin, and ansible-base will be the slowest cadence
15:56:56 <sshnaidm> acozine, oops, meant to you (about changelog tool) :)
15:57:06 <abadger1999> heh, I was about to say... ;-)
15:57:34 * nitzmahone leaves the other details for abadger1999 to fill in :)
15:57:56 <zbr> but i hope we will have a “latest” permalink for docs, not one with version on it.
15:58:05 <sshnaidm> abadger1999, feel free :)
15:58:17 <gundalow> #action gundalow Summit (and hackathon) writeup to Reddit
15:59:00 <abadger1999> zbr We are discussing how to do both the latest and devel permalinks.  latest is probably very easy to transition.  devel will be a little harder but we think we have a plan for that.
15:59:00 <nitzmahone> zbr++
15:59:35 <odyssey4me> gundalow: As an aside, I'd like to say that the snacks and drinks at this conference are top notch. ;)
15:59:42 <abadger1999> devel would be "the devel branch of the ansible/ansible git repo plus the latest version of collections in ACD  posted on galaxy"
15:59:50 <gundalow> odyssey4me: haha, that made me laugh
15:59:52 <nitzmahone> odyssey4me: i disagree ;)
16:00:07 * jillr passes nitzmahone some tea and scones
16:00:08 <felixfontein> abadger1999: so no devel of collections themselves?
16:00:14 <abadger1999> felixfontein: correct.
16:00:15 <odyssey4me> nitzmahone: you can never please everyone :p
16:00:41 <nitzmahone> odyssey4me this is the same crap I have at home
16:00:46 <abadger1999> felixfontein: at least, at the moment, I haven't figured out a good way to do devel of collections.
16:01:22 <gundalow> #topic 15 minute break
16:01:23 <felixfontein> abadger1999: I guess that makes it more important that collections can build their own 'devel' docs to see how they look like
16:01:23 <jpmens> gundalow: how much more leg-streching will we have to do today?!? ;)
16:01:34 * acozine heads to the kitchen to look for snacks
16:01:35 <abadger1999> felixfontein: because I wouldn't be sure whether the devel branch of a collection would make it into the next major release of ACD or not.
16:01:35 <odyssey4me> nitzmahone: you should speak to the manager
16:01:36 <jpmens> it's exasusting
16:01:39 <gundalow> jpmens: how much more would you like?
16:01:43 <abadger1999> felixfontein: yeah... good point.
16:01:53 <nitzmahone> #topic 15min break, back at 16:15UTC
16:01:55 <gundalow> jpmens: oh, I assume you are just walking to the kitchen
16:01:56 <acozine> jpmens: next time we meet in person, we can do Contributor Summit Yoga
16:02:08 <felixfontein> abadger1999: true. collections will probably use all kind of different workflows...
16:02:15 <jpmens> acozine: we will not meet in person, then, unfortunately ;)
16:03:41 <cybette> I had snacks (finnish/swedish candy) and activities planned but.... oh well, next time :)
16:03:56 <abadger1999> @acozine we probably want to write down felixfontein's point somewhere: the fact that we aren't building docs of the developing branch of a collection makes it more important that collections can build their own 'devel' docs to see how they look.
16:05:23 <acozine> abadger1999: ack
16:06:11 <jpmens> cybette: what kind of activities? leg-stretching? ;-)
16:06:52 <cybette> weight lifting (at the bar) :P
16:07:40 * nitzmahone NAKs treats from jillr, clearly your TreatsOverIP impl is still WIP
16:08:31 * jillr shoves a second scone into the router, cause what could possibly go wrong there?
16:08:35 <cybette> 🍺 💪
16:08:42 <jpmens> +1
16:08:53 <nitzmahone> jillr: pics or it didn't happen ;)
16:09:08 <madonius> cybette: I I'd be happy with a snackathon
16:09:18 <nitzmahone> that's every day at my house
16:09:30 <nitzmahone> (and I have the waistline to prove it)
16:10:04 <cybette> madonius: sounds fun! (and dangerous)
16:10:21 <madonius> nitzmahone: is a veteran, we are safe
16:10:34 <cybette> nitzmahone: yeah, and even more so nowadays...
16:11:32 <nitzmahone> cybette: feel free to include swedish/finnish candy in swag shipments :)
16:12:01 <nitzmahone> don't want it to go to waste :D
16:12:24 <cybette> nitzmahone: I'm thinking of how to optimize that because some swag are in raleigh
16:12:48 <cybette> oh but the finnish ones are already gone (in my tummy). the swedish ones I was going to get when we were in gothenburg
16:12:51 <odyssey4me> nitzmahone: you'd rather it goes to waist then? :)
16:13:03 <cybette> lol
16:13:04 <nitzmahone> heh, and they postponed the replacement of the janky old shipping tool :(
16:13:13 * nitzmahone groans
16:13:20 <cybette> yeah
16:13:50 * nitzmahone had first experience with that recently to return old laptop to IT
16:13:54 <felixfontein> I was really looking forward to scandinavian snacks
16:14:08 <felixfontein> now I have to stick to nuts
16:14:31 <cybette> nitzmahone: lucky you, I had to deal with it on a weekly basis
16:15:41 <cybette> felixfontein: hmmm I'll see what I can do
16:16:09 <felixfontein> cybette: it's ok, they're usually better when they're fresh anyway :)
16:16:26 <felixfontein> and hopefully we'll travel there next year
16:16:29 <odyssey4me> cybette: I'd bet felixfontein is really keen on getting his hands on some Surströmming
16:16:32 <felixfontein> (this year probably won't work...)
16:17:01 <felixfontein> odyssey4me: definitely not, I don't like seafood ;)
16:17:46 <cybette> odyssey4me: hahah oh dear
16:17:53 <nitzmahone> #topic ACD
16:18:06 <gundalow> #topic ACD (the ansible package) bulid process
16:18:18 <gundalow> oh, sorry nitzmahone
16:18:29 <nitzmahone> no worries, yours was more specific :)
16:18:50 <abadger1999>
16:19:30 <gundalow> #info abadger1999 is now talking about how the new `ansible` package will be built
16:19:47 <gundalow> #info shows what `ansible` package will look like on disk
16:21:06 <zbr> really happy to see that pip install method is supported
16:21:19 <felixfontein> hmm, is there a ansible module encapsulating `ansible-galaxy collection install`?
16:21:32 <jpmens> what happens if ansible.posix exists in 2 different directories?
16:21:58 <webknjaz> FYI it's already in ansible/ansible@devel
16:22:15 <gundalow> #action DOCS: "How do I X" what happens if ansible.posix exists in 2 different directories?
16:22:47 <zbr> jpmens: i guess python import tules apply, the first one found in PYTHONPATH, it will be loaded.
16:23:03 <webknjaz> exactly
16:23:03 <odyssey4me> I'm guessing that this means another ansible.ini config option and corresponding bash env variable to specify paths to search?
16:23:25 <webknjaz> ANSIBLE_COLLECTIONS_ROOT
16:23:31 <abadger1999>
16:24:26 <webknjaz> @zbr:
16:25:11 <resmo> re
16:25:21 <gundalow> #info possible ACD Build process
16:31:50 <abadger1999>
16:32:27 <gundalow> #info ACD build scripts (work in progress)
16:33:14 <gundalow> #info ACD parse_args
16:33:23 <abadger1999>
16:34:04 <felixfontein> I'm missing
16:34:27 <abadger1999>
16:37:37 <abadger1999>
16:38:15 <zbr> interesting to see that this uses yaml format intead of pip constraint format, bit weird
16:38:42 <abadger1999>
16:39:03 <jillr> felixfontein: for mod utils? it'll be  ;)
16:39:20 <zbr> i would have prefered a native constraints format because in the future we may need tpo use additional constraints, like python version specific ones
16:39:27 <felixfontein> jillr: too bad, I really was looking forward to :)
16:39:30 <abadger1999> python3.8 -m pip install --user --upgrade -i ansible
16:39:31 <resmo> question: abadger1999 in bugfix releases e.g. 2.10.1, do also bugfix version releases get into acd?
16:40:14 <jillr> felixfontein: it was an option! I was worried it would cause too much confusion though
16:41:36 <felixfontein> jillr: I'm quite sure it would. they way it's now is definitely better. though less funny :)
16:42:08 * jillr parks the aws namespace on galaxy, so felixfontein can't release an April Fools collection next week!
16:42:31 <felixfontein> lol
16:42:51 <zbr> we could try to release a 3.0 on the 1st :D
16:43:10 <felixfontein> zbr: lol!
16:43:50 <resmo> abadger1999: how does a collection get into that list?
16:44:22 <zbr> resmo: you need to know the right people ;)
16:44:58 <gregdek> in 2.10, basically it's in if it came out of 2.9.Longer term, we need clear requirements for collections to
16:45:13 <gregdek> included as new collections.
16:45:25 <gregdek> We don't have those yet, but we will.
16:47:18 <zbr> testing would be required because without it, someone would break the acd with their own reqs
16:48:10 <gundalow> #action ACD Testing:  testing would be required because without it, someone would break the acd with their own reqs
16:48:27 <zbr> if we have our own sanity job that is part of their merge-gate, we should be safe.
16:48:54 <zbr> at least their would not be able to merge a change that break the *building* of the acd.
16:48:57 <tadeboro> Will the certified collections be automatically included in the ACD?
16:49:33 <rbergeron> either way: I think the initial bar will likely be fairly low, and the community will likely figure out how to level up the appropriate types of testing and whta levels of testing are required over time to be included.
16:49:39 <zbr> if zuul-ci is going to be used for testing changes, it would be very easy to assure they would not break it
16:50:39 <gundalow> zbr: Yup, I expect that for most community collections we will use Zuul to do the tag & publish into Galaxy. We could add some pre-checks there before the tag can be done
16:50:50 <zbr> we do this with podman where openstack stack has ci jobs testing that a change in podman would not break openstack.
16:50:58 <zbr> it will work just fine
16:51:17 <madonius> I am going to try this "outside" people have been talking about lately… See you!
16:51:30 <gundalow> madonius: Thanks for your time. Did you do the swag survey?
16:51:43 <madonius> yep :D
16:51:49 <belfast77> I appreciate this is a community discussion I work with syadmins and Ansible Core paying customers, none of then use "python pip install",  with the split would people be sitting with old module versions, whilst ACD marches on?
16:51:51 <zbr> maybe we should rename acd to "the bazar"
16:51:57 <madonius> (important stuff has to be important, right?)
16:52:08 <acozine> madonius: o/
16:52:09 <rbergeron> zbr: that is correct. It's entirely possible that we could do something like at least a basic periodic test with zuul to do something like that. over time we could certainly get to a point where we did that more frequently and using gating, etc. rather than just for feedback.
16:52:15 <cybette> madonius: thanks for joining today, see you !
16:52:26 <madonius> thanks for organising
16:52:37 <nitzmahone> belfast77: sort of, also something we can cover in our talk about product packaging
16:52:38 <madonius> I did enjoy it and learn a ton
16:53:00 <webknjaz> zbr: LOL, +1 for bazar. GRAND BAZAR
16:53:15 <acozine> zbr: bazaar, or bizarre?
16:53:24 <gundalow> #topic Cloud Collections
16:53:24 <webknjaz> zbr: I saw you rofling tho
16:54:02 <nitzmahone> belfast77: ACD is one of several ways to install content; esp for capital-S-Supported by Red Hat content, there will be some prepackaged options, as well as "official" ways to get supported content
16:54:11 * webknjaz releases ansible-grand-bazar==3.0.0 on Apr 1st
16:54:29 <abadger1999> belfast77: The answer is possibly.
16:55:08 <abadger1999> The way the resolution works, things installed with pip are the last thing in the lookup.
16:55:16 <gundalow> #info jillr now explains how the different Cloud Collections are setup
16:55:36 <gundalow> #info Ansible Cloud Team: AWS, VMware
16:56:53 <rbergeron> some of the certified collections are likely to be included in their upstream form in ACD. they may have different life cycles / policies depending on the vendor, but i suspect that if one is a customer that those collections should be downloaded from automation hub rather than the version in ACD.
16:58:10 <rbergeron> for vendors who aren't open sourcing that content or aren't choosing to work upstream, that's their choice -- but we certainly are making them aware of the benefits of doing their work publicly upstream and collaborating with the broader community.
16:58:12 <abadger1999> belfast77: So if you only pip install via either acd or pip install some package that a collection owner decides to upload to pypi, and then pip upgrade that, the upgrade will be found.  But then if you use ansible-galaxy to install a new version, the ansible-galacy version will be found.
16:58:31 <sshnaidm> Openstack collection is mirrored to github though
16:58:42 <sshnaidm> but not developed there, yes
16:59:03 <abadger1999> belfast77: And so, even if you upgrade the pip installed version, it will not take precedence over the older ansible-galaxy version.
16:59:08 <jillr> right, good note, all of the openstack project repos have read-only GH mirrors
16:59:17 <sshnaidm>
16:59:46 <gundalow> #info Release notes & Changelog fragments
17:01:11 <sshnaidm> jillr, also podman modules moved to "containers" github namespace:
17:03:25 <felixfontein> there's a "scripts/inventory" directory in community.general for example
17:03:39 <resmo> question: a vendor can "take over" the cloud modules in community.general? is that correct? I mean, I wrote most of the vultr integration, vultr can come and take it over?
17:03:40 <sshnaidm> it's possible to see in scenario files
17:04:04 <gundalow> #action jillr check where inventory scripts (not plugins) are
17:04:48 <sshnaidm> resmo, +1, maintainers of various multiple community modules is an interesting topic
17:05:40 <felixfontein> good that modules are GPL :)
17:05:56 <gundalow> #action DOCS: search for `contrib` as that directory no longer exist
17:06:05 <sshnaidm> but who will have merge rights to community modules repos?
17:06:20 <zbr> sshnaidm: zuul only!
17:06:30 <felixfontein> sshnaidm: depends on the repo
17:06:42 <sshnaidm> if it's same ansible core, it won't help with burden and bottleneck
17:06:54 <felixfontein> usually a set of maintainers. community.general will be special (more similar to ansible/ansible)
17:07:09 <gundalow> #action DOCS: search for `contrib/inventory` in docs to point people to the new individual repos (and new directory structure)
17:07:30 <Goneri> in the case of community.vmware, it's a mix of VMware employees, Ansible core and some comunity conyributors
17:08:00 <leogallego> are there plans to get the Proxmox module in the community.general repo?
17:08:36 <belfast77> @abadger1999  @nitzmahone thanks very much for your answers earlier
17:08:56 <rbergeron> leogallego: since it's an existing module in ansible, it should be getting pulled into the community.general collection/repo
17:09:14 <leogallego> rbergeron++ thank you
17:09:16 <zodbot> leogallego: Karma for rbergero changed to 1 (for the current release cycle):
17:09:38 <gundalow> #topic Community Process for Collections
17:09:38 <rbergeron> LOL zodbot ;)
17:09:39 <felixfontein> rbergeron: leogallego: but it's not there right now
17:09:52 <felixfontein> ah wait, they are
17:09:56 <felixfontein> looked at the wrong place...
17:10:00 <abadger1999> I'm happy to give information that I have and say when something still needs discussion :-)
17:10:22 <rbergeron> felixfontein: i was about to have a moment of thinking i was absolutely insane :)
17:10:24 <felixfontein>
17:10:25 <gundalow> #info Contributor Collection status
17:10:49 <felixfontein> rbergeron: you're definitely not! (as far as I can judge ;) )
17:11:22 <leogallego> felixfontein, ohhh look at that, i was looking for the proxmox directory
17:12:14 <felixfontein> leogallego: I think it's the same structure as before; was there a proxmox directory?
17:13:01 <felixfontein> what's the state of the PR/issue mover?
17:13:12 <nitzmahone> endless Matts on the core team
17:13:26 <felixfontein> :)
17:13:54 <felixfontein> hi gundalow's son :D
17:15:39 <shaps> for issues I'd close and link to the correct collection
17:15:41 <zbr> is not possible to use transfer option?
17:15:46 <gregdek> shaps: +1
17:16:12 <felixfontein> I'd probably like some issues transferred
17:16:17 <gundalow> CI run for a collection
17:16:23 <zbr> shaps: if transfer is not possible, it make sense to close them with just link, it be a forced-cleanup, not really bad.
17:16:24 <felixfontein> but it's probably easier to recreate them one a case-by-case basis
17:17:06 <zbr> felixfontein: indeed, it someone takes time to recreate them, it means it is still valid.
17:17:26 <gregdek> It would be nice to put a link in every issue that says "if you want to re-file, click this button" which then autofills a new issue in the right place, with proper ownership as well
17:17:37 <gregdek> Make it dead-easy to reopen in the right place
17:17:48 <zbr> but one hint: make a bot that does close tickets with a limit per day, so we spread the load
17:18:09 <odyssey4me> gregdek: sounds shiny :)
17:18:13 <cybette> #link Survey link:
17:18:21 <felixfontein> gregdek: sounds good! there definitely must be a link back to the old issue, thpough
17:18:27 <cybette> (also in etherpad)
17:18:29 <gregdek> Yes, absolutely.
17:18:32 <nitzmahone> at least 100% virtual solves the "IF YOU WANT TO BE HEARD YOU MUST USE A MIC" problem :)
17:18:46 <jillr> I thought there was a fork of ansibot somewhere that did something like what gregdek is describing, but I don't know more than that
17:18:48 <odyssey4me> nitzmahone: ++
17:19:16 <gundalow> Thank you everybody for your time
17:19:24 <resmo> Thanks ansible community team! take care!
17:19:24 <acozine> stay healthy everybody
17:19:35 <felixfontein> thanks everyone as well! it was a nice contributor summit :)
17:19:39 <shaps> thanks everyone!
17:19:39 <zbr> Thanks!
17:19:43 * felixfontein waves
17:19:50 <nitzmahone> Cheers all, sad not to meet in person, but been a good day! See you 'round the interwebs
17:19:51 <resmo> o/
17:19:52 <tadeboro> Bye all. o/
17:20:12 <gregdek> #endmeeting