13:02:19 #startmeeting AnsibleFest Contributors Summit: Morning Session 13:02:19 Meeting started Mon Sep 23 13:02:19 2019 UTC. 13:02:19 This meeting is logged and archived in a public location. 13:02:19 The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:19 The meeting name has been set to 'ansiblefest_contributors_summit:_morning_session' 13:02:23 ignore that, talking here 13:02:45 * jhawkesworth in ansible meeting 13:03:05 #chair gregdek abadger1999 acozine alikins bcoca ganeshrn gregdek jborean93 jillr jimi|ansible mattclay maxamillion jhawkesworth nitzmahone Qalthos samccann sdoran shaps sivel thaumos 13:03:05 Current chairs: Qalthos abadger1999 acozine alikins bcoca ganeshrn gregdek gundalow jborean93 jhawkesworth jillr jimi|ansible mattclay maxamillion nitzmahone samccann sdoran shaps sivel thaumos 13:03:09 #topic Intro 13:03:11 * gregdek waves 13:03:20 * sdoran sips coffee 13:03:45 so where is the bjn link ? 13:03:48 * geerlingguy wakes up 13:03:54 misc: it's coming 13:04:34 ok, so I am not missing something obvious :) 13:05:27 yay, now I got sound 13:06:16 https://bluejeans.com/7480904391 13:06:19 :) 13:06:23 Soooooory! 13:06:33 And Etherpad for the general session: 13:06:39 #link https://etherpad.openstack.org/p/ansible-summit-atlanta-2019 13:06:43 https://etherpad.openstack.org/p/ansible-summit-atlanta-2019-general-session 13:06:49 For the morning session specifically 13:08:11 oh nice, a red hat! 13:08:42 Old school ;) 13:09:26 #topic Data Presentation (Greg Sutcliffe ) 13:10:20 #info gwmngilfen is giving a presentation on using data to understand community stricture and aid governance 13:10:37 structure* 13:10:56 #undo 13:10:56 Removing item from minutes: INFO by gundalow at 13:10:20 : gwmngilfen is giving a presentation on using data to understand community stricture and aid governance 13:11:00 #info gwmngilfen is giving a presentation on using data to understand community structure and aid governance 13:13:46 big data... 13:13:48 ;) 13:13:50 :) 13:14:36 "some core committers are filtered" ... we need to get greg an updated list 13:14:45 +1 13:15:01 #info Ideas on how to use this data, ie what questions we should ask? 13:15:27 #action gundalow to give gwmngilfen updated list of committers 13:18:16 Who here is remote? 13:18:22 Is there a link to this tool? 13:18:25 Can we look into this data ourselves? / Is this representation available to use? 13:18:25 <- 13:18:36 At end of session, links will be provided 13:18:37 * resmo is thinking to create a bot hitting some modules doc... 13:18:47 cheater ^ 13:18:58 while true; do curl https://...; done :D 13:19:00 (don't want to potentially crash the tool while greg is presenting lol) 13:19:37 but without a tool crashing while doing a demo, is this really a demo ? 13:19:46 robertdebock: yes, this will all be fully public, the goal is for everyone to be able to use this data in real time 13:19:50 misc++ 13:19:54 felixfontein: you need spoof the UA though, too easy to filter out otherwise :) 13:20:11 iirc, we filter the docs data by unique IP 13:20:12 @gregdek, cool! 13:20:16 and run curl from a bunch of ec2 VM 13:20:22 automate the deployment with ansible 13:20:49 #info we will be pulling web stats from docs.ansible.com to add to the stats on module usage 13:20:54 gregdek: gundalow question: is there a stats, after which time it us unlikely a PR get merged? 13:20:59 (using serverless, it would be pretty cheap, I did the math for another cheating project) 13:21:15 resmo: queued, thx 13:22:06 #info We have stats to show the 80% merge time for various labels. The stats confirm that label/P1 and label/P2 get merged faster than others. Likewise label/bugs get merged faster than label/feature (or label/new_module) 13:22:07 what is the curve for new feature PR vs bugfix PR? 13:22:16 bcoca: selectable, I believe 13:22:34 This is a general overview of the tool 13:22:44 #info the merge time stats allows you to pick any two labels to compare 13:22:59 oh, which Greg is now showing... 13:23:02 And it would be interesting to see what type of module the PR's relate to; code, stable, preview, community, etc. 13:23:03 Do network! 13:23:19 i blame felix 13:23:22 is this data public? 13:23:31 yes, link will be shared afterwards 13:23:32 :D 13:23:42 he, i was going to 'credit' felix, but 'blame' also works ... 13:23:59 `git credit: command not found` 13:24:01 git s/credit/blame/ 13:24:06 jtanner: lol 13:24:15 robertdebock: Yup, I've seen that label/support:core and label/support:network get merged quicker than label/support:community 13:24:26 svn has the never used 'praise' 13:25:09 that's a intresting bias in the UX of the tool 13:25:11 #chair andersson007_ felixfontein decentral1se misc 13:25:11 Current chairs: Qalthos abadger1999 acozine alikins andersson007_ bcoca decentral1se felixfontein ganeshrn gregdek gundalow jborean93 jhawkesworth jillr jimi|ansible mattclay maxamillion misc nitzmahone samccann sdoran shaps sivel thaumos 13:25:39 #info We also have some stats on http://ansible.meetup.com 13:25:58 ansible it hot in pune 13:26:03 is* hot 13:26:10 atlanta should have a big fat dot for this week :D 13:26:39 if we arranged contrib summit through meetup.com, it definitely would 13:27:17 missing alaska, hawai, puerto rico and guam 13:27:24 If we arranged contrib summit through meetup.com, there would be 20 people here 13:27:41 we have meetups in hawaii? i'll organize 13:28:09 i think we're going to spain 13:28:10 bcoca: you're going to run a meetup in spain, yes? 13:28:22 that might have been all ricky though 13:28:28 So, AnsibleFest Barcelona next year?! 13:28:28 (j/k of course) 13:28:35 robertdebock++ 13:28:39 I am going to change my github location for hawaii and do PR 13:28:42 robertdebock: +++ 13:28:59 if we have budgjet to rent bars from my family members ... 13:29:15 #link http://stats.eng.ansible.com/apps/ 13:29:51 robertdebock: ++ 13:29:55 there's more on there than greg demo'ed, so click around 13:30:44 What a great talk, thanks @gemngilfen! 13:30:52 indeed! thanks! 13:30:57 yup, that was great 13:31:43 chance is increased by pinging people in #ansible-devel or appropriate channel 13:33:13 there's a set of features that would probably have to be correlated: 1) does the author have commit 2) does the author have supershipit 3) does the author have maintainership 4) are there other maintainers for the PR 5) many many previous PRs has the author gotten merged 6) how many significant contributors have reviewed .... and on and on 13:33:31 #topic Roadmap with Dylan Silva 13:34:24 #info thaumos / Dylan contributed to 0.12 in June 2012 and has been making trouble fo us ever since 13:34:47 "for us" stupid sticky r key 13:35:00 #action gregdek to clean his keyboard 13:35:44 lol 13:36:02 I'm interested what "goes in" Ansible, and what will be put in a collection. How to decide that? 13:36:17 BD 13:36:18 Have we DDoSed the stats.eng.ansible.com server yet? :P 13:36:21 err, TBD 13:36:29 * jtanner needs to clean keyboard too 13:36:39 #action jtanner to clean his keyboard 13:37:06 keyboard cleaning breakout at noon 13:37:16 shouldn't we stop the screensharing ? 13:37:19 are we not supposed to see anything on screen? 13:37:26 he doesn't have a preso 13:37:34 No, screen is blank here in Atlanta. 13:37:50 #info no preso on screen for this session 13:38:21 he alluded to the announcements being made tomorrow, so that's where the demo/slideware comes into play 13:39:08 #topic Open Questions / Q+A about collections 13:39:21 #topic Open Questions / Q+A about Core roadmap / collections 13:39:31 Remote people, please ask questions here and we will ask them in the room 13:39:41 #info question: what will go into ansible core and what will stay in collections? 13:39:59 wouldn't it wreck some havoc in the stats that were presented before ? 13:40:07 #info answer: all "content" will go into some kind of collection 13:40:20 misc: we're ready to change those tools to follow the new structure 13:41:04 misc: https://en.wikipedia.org/wiki/Goodhart%27s_law =) 13:41:21 yep, i'm aware :) 13:41:27 Everything? Or will there still be some content in core? 13:41:48 All content outside of core presents coordination problems. 13:42:05 yes, it does 13:42:54 I guess the "common" part of module_utils needs to have a rock solid backwards-compatible interface then 13:43:01 very true 13:43:12 I can see collections by vendors as to the 'official' distro of that collection. How will the cloud modules be released as a collection? In particular the AWS modules I'm wondering about 13:43:14 (and even worse for plugins...) 13:43:38 yes! give me more questions! 13:43:57 buried things are why general dashboards are tricky here 13:43:57 where are the collections "hosted"? do they go into github/ansbile/collection-xyz? 13:44:12 or not under ansible? 13:44:23 thaumos: ^ 13:44:28 resmo: I think matt is asking this question now 13:44:28 right now using ansible-collections as testing ground 13:44:39 github.com/ansible-collections is the intended org for collections that do not end up in someone else's org 13:44:41 https://github.com/ansible-collections 13:45:14 ^ most of those are just tests, might not reflect what the ending namespaces/colleciton names/structures look like 13:45:18 #info galaxy will be the way for users to get "a la carte" content if they so choose 13:46:05 #info initially, current idea for community collections will likely be in a single repo and multiple collections, will discuss later in dedicated collections session 13:46:06 Is there an option besides a la carte? 13:46:24 abadger: yes, we will bundle a new version of "batteries included" 13:46:42 That is a requirement 13:46:44 will that require playbooks to change? colleciton code does not work same as core 13:47:01 maxamillion is now speakign 13:47:06 gregdek: I do not think those batteries should be put into a collection. 13:47:17 That just makes unnecessary work. 13:47:25 Really big unnecessary work. 13:47:31 (Social, not technical) 13:47:39 abadger1999: as in, the very core modules should stay in core? 13:47:45 Yes. 13:47:57 not just modules, plenty of plugins 13:48:05 If we're going to ship it in the ansible tarball, then it should stay in core, not move to a collection. 13:48:06 Putting those core modules/plugins into, say, a core-modules collection would be problematic? 13:48:35 gregdek: lookup('ansible.core.file' vs lookup('file l 13:48:37 Well, the question is "what does the batteries included bundle look like". It may not be a tarball. 13:48:41 '^ they are not referenced teh same 13:49:00 also code in collections does imports differently, so they cannot just be 'copied' into core paths 13:49:05 It may be a single command in galaxy: "galaxy install ansible-batteries-included" or some such. 13:49:13 Still discussing that. 13:49:24 So install could be `pip install ansible && ansible-galaxy install batteries` 13:49:30 ^ is that the idea? 13:49:51 geerlingguy: I hadn't thought of that, but that would be an interesting idea 13:49:53 Yep, something like that in theory. 13:50:00 In practice, we don't know what the answer is yet. 13:50:11 * geerlingguy reserves the 'batteries' namespace :P 13:50:15 Heh 13:50:15 I guess as long as 'batteries' doesn't mean playbooks will need to change would be fine 13:50:17 If it's only a separate bundle, then it can be a separate collection. There is still extra manpower needed but not as much. 13:50:19 I was mostly thinking of the downstream distribution as a tarball, rpms, debs, etc 13:50:24 That's the idea. 13:50:35 We'll get into the namespacing discussion in the collections discussion. 13:50:43 Is there any idea of when this will be taking shape? 13:50:45 shaps: +1 13:50:56 Question: some (binary) modules are architecture dependent, I've not seen how collections deal with different architectures. 13:51:03 You need people managing the new project determining its release schedule, making sure that everything is in on time, testing the matrix of new release against all of the ansible versions that are supported, etc. 13:51:11 abadger1999: yes. :) 13:51:27 robertdebock: how are they dealt with today ? 13:51:35 It probably doubles the project-level work that you have to do. 13:51:42 It does indeed. 13:52:07 dmsimard They are not dealt with. I guess compile for all platforms, package it and let Ansible figure out what to use. 13:52:16 If you are going to include it in the ansible rpms/tarball, though, then that would be even more work. 13:52:30 Right. Which I think is what that's probably not the model. 13:52:46 because then you also have the social aspect of forcing those project decisions from ansible/ansible onto the new colection. 13:53:07 what about the new features for 2.10 already merged? 13:53:38 Yes. In the near term, new collections probably inherit workflow from ansible/ansible. In the longer term, collections can evolve their own governance. 13:53:39 abadger1999: which wouldn't really be different to how the releases go now, really 13:53:56 shaps: No..... 13:54:12 shaps: it's how releases are done now for the non-core modules. 13:54:32 ^ he is RM 13:54:50 just FYI in case you want to know how familiar he is with our release process 13:54:56 It definitely makes sense to me to separate the vmware, aws, docker, k8s modules, from core to me... they would benefit from external control and separate release schedules. 13:55:13 I am concerned there will be many flavors of the same collection on galaxy... 13:55:30 resmo: nginx roles? 13:55:37 bcoca: exactly 13:55:43 abadger1999: yeah, i'd be +1 for that 13:55:46 Ansible Galaxy Verified Accounts... 13:55:50 resmo: that's a risk, yes. That risk is exacerbated by a poorly managed upstream. 13:55:50 FYI, i have 3 core team members working full time on the automation of the various ideals about splitting and issue/pr migration, etc ... so we're still very much in the research phase of figuring out what actually works 13:56:14 But for something like the stat module..... where ansible won't work unless it is present, it feels a bit.... backwards? .. that the module is shipping on a separate release schedule. 13:56:26 it's a bit more difficult to write a module or plugin than a role, so while i'm sure there may be some of that i don't think it'll be as bad 13:56:49 but its easy to copy existing colleciton and add a plugin or patch existing and republish 13:56:58 license permiting 13:57:05 abadger1999: i agree with that specific example, and the migration team (coca, mkrizek and webknjaz) are going to be building demos to explain that ideal at a deeper level so that the larger audience understands why 13:57:07 abadger1999: it may be that the content comes out, but ansible and ansible-core-modules are tied to the same release schedule. Which does beg the question, why pull them out at all? 13:57:28 now speaking is chouseknecht, who is the Ansible Galaxy Lead 13:57:38 gregdek: that is why some of us want some content to stay in core 13:57:41 #info chouseknecht is discussing galaxy 13:57:44 gregdek: Yep. 13:58:12 abadger1999 bcoca it's a fair point. Something maybe to dig into during the next session. 13:59:12 Now speaking: geerlingguy 13:59:14 #info geerlingguy is asking questions about ui of galaxy 13:59:52 #info searchabilityt of collections will be key 14:00:27 #action gwmngilfen should have basic stats for collections in galaxy 14:00:30 Sorry I'm terrible about saying my name :P 14:00:35 :) 14:00:48 #action gregdek to think about stats on growth of collections and usage rate 14:01:32 #info maybe 10-30 people don't know what ansible-test is 14:02:11 geerlingguy, I'm also horrible at saying your name. ;-) 14:02:22 lol 14:02:38 anybody have a url for the ansible-test repo? 14:02:40 #info `ansible-test` is what does all the work when you push a PR to ansible/ansible 14:03:05 curious to look into the source code 14:03:16 https://github.com/ansible/ansible/tree/devel/test ? 14:03:17 what about the integration tests in ansible/ansible for modules going out to collections? 14:03:26 #info ansible-test is in the github.com/ansible/ansible (ie main) repo 14:03:37 resmo: that is one thing the migration team is working on, moving those tests 14:03:48 cool 14:03:51 they need to be rewritten to use the collection (wip) 14:03:53 resmo: yeah tests will move when the corresponding module moves out 14:04:00 unit tests also 14:04:00 which will make core tests soo much faster 14:04:04 DING DING DING 14:04:07 Back in 20 minutes 14:04:07 thanks dmsimard! 14:04:26 * geerlingguy has conspiracy theory that entire reason for collections was to make ansible/ansible test runs faster :P 14:04:56 ^ +1 14:05:00 fungi: It is embedded into the ansible/ansible repo. On disk, after install, it will be /usr/bin/ansible-test and %{python_sitelib}/ansible_test 14:05:07 geerlingguy: the way to run them faster is to disable them 14:05:15 abadger1999: thanks! 14:05:25 it's just to split the modules repo again 14:06:01 can someone stop the music? 14:06:01 not terribly important, but as a relative newcomer i'm curious to learn more about how the ansible developer community determines the ansible roadmap, if there is a session later this week anyone can recommend which is likely to cover such topics 14:06:37 shaps: not really, though similar pains 14:06:52 its also to enable core to have longer more stable releases, while making plugins relase at their own schedule 14:07:02 1/2 the time people want a new release is for 'features' in their plugins 14:07:18 This is the main part of the ansible-test implementation: https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test The script, specifically, is here: https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/cli/ansible_test_cli_stub.py 14:07:21 it also allows for more flexible maintainership 14:07:51 fungi: The roadmap is largely done internally right now :-/ 14:07:54 I'm mainly wondering how development of core and collections can be synchronized so that changes in core (new features, behavior changes, new ways for validation/documentation, ...) can be synced with collections which depend on this 14:07:56 abadger1999: thanks again! dmsimard beat you to the url 14:08:30 felixfontein: i dont expect collections to need that much synchronicity 14:08:42 abadger1999: got it, so... the ansible community is a mostly reactive one, and there is some elected leadership body designing the roadmap instead? 14:08:47 i do see a few cases (process plugins) .. but mostly we need a way to say 'collection ansible version compatiblity' 14:09:10 bcoca: docs? 14:09:12 felixfontein seems like the main thing is capturing in metadata and surfacing in Galaxy the versions of Ansible a collection has been tested against 14:09:21 resmo: one we figure out the mech ... 14:09:41 collections are WIP, so are collection docs (though you should have up2date ones on docs.ansible.com 14:09:52 felixfontein which is a case for amping-up the work on molecule 14:09:56 fair enough. I am curious. 14:09:56 https://docs.ansible.com/ansible/devel/user_guide/collections_using.html 14:10:11 fungi: the team that's paid (called the ansible core team) by red hat to work on ansible comes up with a set of features and publishes them. I think that some of the working groups (aws, docker, postgresql) might come up with their separate ideas and roadmaps of what they want in the next release... but I haven't participated in those discussions. 14:10:17 https://docs.ansible.com/ansible/devel/user_guide/collections_using.html 14:10:25 https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html 14:10:31 abadger1999: okay, great. thanks for the explanation 14:10:46 Hopefully we'd see more of that sort of thing when the working groups get full control of their content via collections. 14:11:15 fungi: we also have 2 weekly core meetings to make decisions, mostly on case by case bassis, not to control the roadmap (but does add to it) 14:11:28 business-controlled open source is a bit of a foreign concept to me, so trying to learn more about it 14:12:03 coming from community-driven projects, the difference in dynamics is intruiging 14:12:35 er, intriguing 14:12:40 fungi: Currently there are no elected leaders. We have two sorta overlapping splits.... (those paid by red hat vs everyone else) and (those with commit, those with commit-equivalent to a specific area, everyone else). 14:13:13 are there community governance documents which have any detailed explanations of that? 14:13:32 The core irc meetings are the place to get decisions made but it does suffer from a lack of attendance. 14:13:42 gundalow: ^ see fungi's last question. 14:14:09 fungi: I doubt it (except for the bit about going to a core meeting) because it's kind of ad hoc... and probably not the best way to do things. 14:14:38 thanks again, that's all great info 14:14:59 @fungi: you may find some answers to your questions around here: https://docs.ansible.com/ansible/devel/community/development_process.html 14:15:20 awesome, thanks webknjaz! 14:15:40 (For instance, when we vote in irc meetings, none of the things you need to know are written down: Is it simple majority of those present? Is it a majority of the absolute number of potential voters? Do committers vote or is it the paid by red hat people who vote? etc) 14:16:40 @fungi: also take a look at this wiki: https://github.com/ansible/community/wiki 14:16:58 excellent, thanks again 14:17:43 how many versions of ansible core should a collection support? the last 3 or 4, like core? 14:17:47 usually there's enough RH folks lurking that they would outnumber any vote where RH had a strong option 14:18:40 cyberpear: most of the time RH employees are not a voting block 14:18:47 geerlingguy gregdek sure I have a bunch of galaxy data, I'll ping later on and we can dig into it 14:18:51 rarely happens when we all agree ... and normally that is for a good reason 14:19:25 'no we are not rewriting ansible in ruby!' 14:19:46 I thought we had decided on rust? ;) 14:19:53 rustby 14:20:10 i used ruby as the one way to get unanimous core vote .. rust/haskell/golang will get disenters 14:21:38 bcoca: use ruby as a way to get an unanimous yes, or an unanimous no? 14:22:31 rewrite in bash 14:23:02 felixfontein: try proposing for next meeting to find out 14:23:02 why not in JVM bytecode? 14:23:09 geerlingguy: actually ... im 1/2 there 14:23:16 ^would remove py dep! :P 14:23:19 bcoca: no thanks, I don't really like ruby, to put it nicely :) 14:23:21 felixfontein: ironpython 14:24:19 the music stopped 14:24:23 so let's continue? :) 14:24:26 ah 14:24:30 or not 14:26:00 I was hoping too, but just bluejeans being laggy.... ;-) 14:26:48 you fooled me to rejoin! 14:27:00 the music went away, someone said a word, and then the music came back... 14:27:09 now there's a voice again 14:27:13 its not just that i would prefer a diff track, tis that BJ is choppy making it really annoying 14:27:17 announcing it will start again at 10:30 14:27:21 i.e. in 3 minutes 14:27:30 yep indeed 14:27:30 +1, the sound is choppy, I tought it was my side 14:28:34 felixfontein: How many versions a collection would support is an interesting question that I bet the collection-feature-owners anticipate being up to the author. 14:28:52 My guess is bluejeans is optimised for voices, so it mutes anything that doesn't sound like a voice 14:29:13 bj is optimized for maximum annoyance 14:29:31 An interesting question to go along with that and chouseknecht 's talk of testing would be.... if a collection wants to release for EOL ansible versions, will we be able to capture that the collection works with that version in the metadata? 14:29:33 abadger1999: I'm wondering specifically because the docker collection will probably be used by molecule, and molecule wants to support a certain set of core versions, so the docker collection should better do that too 14:29:52 Yeah 14:30:07 DING DING DING 14:30:08 so if we ever want to use new core features, we'll have fun with multiple branches like in core itself 14:30:13 #topic Collections 14:30:24 Please see screen 14:30:28 I can see the screen 14:30:38 https://etherpad.openstack.org/p/ansible-summit-atlanta-2019-general-session line 69 14:32:17 felixfontein: Either that or you'll have to choose. 14:32:28 from when on will the "no longer merge new stuff" rule be active? 14:32:41 #info proposal: new collection format for community collections: one repo, many collections 14:33:03 boo! 14:33:24 #info proposal: net new plugins will go into the new community collection 14:33:39 cyberpear: any detail on that "boo"? :) 14:33:46 felixfontein: 2.10 14:33:49 is everything in this new repo guaranteed to ship in the batteries included distro? 14:33:53 Won't one github repository for all collections coming from core cause many of the same issues we presently have with core? 14:33:59 shaps: once 2.10 is released, or like *now*? 14:34:00 #info one of the initial structures for Community Collections will be ~21 collections, matching the top level directories from https://github.com/ansible/ansible/blob/devel/lib/ansible/modules (ie cloud_community, clustering_community, crypto_community, ...) 14:34:19 he said "now", no grace period 14:34:21 cyberpear: part of this exercise is changing the definition of "batteries included". 14:34:32 I'd like to see tests of modules as a part of a collection, which would make local development (and testing) easier. 14:34:37 There will still be a single command to install all of this content. 14:34:37 if it is now "now", ansibot should maybe be stopped from merging, and people with commit rights should be told too 14:34:40 (permissions to merge, release schedules, getting issues to the right people, etc) 14:34:41 abadger1999: yeah, i think there is a lot of noise right now with the multirepo stuff 14:34:46 meta collections are also possible: so ansible.community could just be a list of N collections 14:34:56 robertdebock: mattclay is giving a talk/demo on that this week with ansible-test 14:35:01 felixfontein: remember, this is a proposal, so "now" is for some value of "now" 14:35:03 #info For now the Ansible Community Collections will live under github.com/ansible/ 14:35:19 jtanner cool! 14:35:19 how will security issues be handled? 14:35:32 gregdek: so now = not now, i.e. we can add new stuff until this is properly announced? 14:35:34 cyberpear: tbd 14:35:39 cyberpear: What specifically? 14:35:52 #chair cyberpear 14:35:52 Current chairs: Qalthos abadger1999 acozine alikins andersson007_ bcoca cyberpear decentral1se felixfontein ganeshrn gregdek gundalow jborean93 jhawkesworth jillr jimi|ansible mattclay maxamillion misc nitzmahone samccann sdoran shaps sivel thaumos 14:36:47 felixfontein: possibly, but there's a lot of new content that's blocking for various reasons. It may be that "some new content goes into ansible/ansible, some goes into new community repo," but we're proposing that at least some content go into the new community collection repo. 14:37:00 i'm curious about the possibility of permanently moving out certain collections into different spots (i.e. i think we'd be happy to host/move the openstack modules into opendev) 14:37:05 what is the cve/reporting/patching process? 14:37:22 most of the openstack-sdk team is on the ansible team anyways, so it'd just help maintain it in a more native place i guess 14:37:41 cyberpear: we'll need answers to that, but those answers will be "the process that the community can bear". 14:38:18 mnaser: yes, that will be your option. 14:38:23 #info The repository where a Collection lives could be anywhere, no requirement to be under GitHub. Ansible will continue to develop on GitHub 14:38:30 mnaser: does that answer your Q? 14:38:32 neat 14:38:32 yeah 14:38:35 very glad to hear that ansible galaxy will now have a way to publish without being tied to proprietary source code hosting platforms 14:38:44 fungi: yes, that was a requirement. 14:38:57 now speaking dmsimard (Mr Ara) 14:39:22 But that requirement cuts both ways, it also means that people can submit collections that don't have source at all, theoretically. We wouldn't advise it. 14:40:19 theoretically people can check compiled binaries into a github repo too ;) 14:41:14 only some of the aws modules are community, many are core/Supported. but they depend on the same mod_utils. how are we expected to manage this? 14:41:38 * cyberpear assumes all get moved to the same community repo 14:41:40 jillr: good one. :) wanna ask in the room? 14:41:40 he, iirc we have one in our repo (golang moduel test?) 14:41:58 it's in an integration test, but not available generally 14:42:00 gregdek: sure, also wanted it noted in channel :) 14:42:04 +1 14:42:35 "deprecated" or "removed"? 14:42:35 now speaking jillr 14:43:05 I like that answer so far :D 14:43:14 WOW, that's a good question! :) 14:43:16 lots of dancing in here 14:43:25 felixfontein: aye, we are trying to be open and honest here 14:43:30 #info module_utils will be forked. 14:43:34 downstream first development! 14:43:41 :( 14:43:47 (just like OpenShift 4.x) 14:43:53 when we de-couple modules from our core release cycle, we're going to have to maintain some level of compatibility 14:43:54 #info we're going to have to make sure that upstream and downstream are in sync, and that is on us to keep pace. 14:43:59 module_utils is not a 'block' there is very specialized/specific stuff 14:43:59 gundalow: that's really good :) 14:44:01 We don't have all the answers, that's the point of Contributors Summit, so we can collectively work this out 14:44:10 * jillr is super happy to mentor new AWS contributors!! now accepting folks who are excited about AWS maintenance 14:44:15 apropos to earlier question about source repo not necessarily being visible (https://github.com/ansible/galaxy/issues/2006) 14:44:16 This is definitely one of the Hard Problems. 14:44:35 oooh, I know some more modules which need more maintenance :) 14:44:49 long list ... 14:44:52 it's similar to how we deprecate yaml language things today for core 14:45:09 * abadger1999 doesn't like this answer.... would much rather than we only forked if there is an unresolvable different direction two sets of maintainers want to take. 14:45:15