13:02:19 <gundalow> #startmeeting AnsibleFest Contributors Summit: Morning Session 13:02:19 <zodbot> Meeting started Mon Sep 23 13:02:19 2019 UTC. 13:02:19 <zodbot> This meeting is logged and archived in a public location. 13:02:19 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:19 <zodbot> The meeting name has been set to 'ansiblefest_contributors_summit:_morning_session' 13:02:23 <gundalow> ignore that, talking here 13:02:45 * jhawkesworth in ansible meeting 13:03:05 <gundalow> #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 <zodbot> 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 <gundalow> #topic Intro 13:03:11 * gregdek waves 13:03:20 * sdoran sips coffee 13:03:45 <misc> so where is the bjn link ? 13:03:48 * geerlingguy wakes up 13:03:54 <dmsimard> misc: it's coming 13:04:34 <misc> ok, so I am not missing something obvious :) 13:05:27 <felixfontein> yay, now I got sound 13:06:16 <gregdek> https://bluejeans.com/7480904391 13:06:19 <gregdek> :) 13:06:23 <gregdek> Soooooory! 13:06:33 <gregdek> And Etherpad for the general session: 13:06:39 <dmsimard> #link https://etherpad.openstack.org/p/ansible-summit-atlanta-2019 13:06:43 <gregdek> https://etherpad.openstack.org/p/ansible-summit-atlanta-2019-general-session 13:06:49 <gregdek> For the morning session specifically 13:08:11 <felixfontein> oh nice, a red hat! 13:08:42 <gregdek> Old school ;) 13:09:26 <gundalow> #topic Data Presentation (Greg Sutcliffe ) 13:10:20 <gundalow> #info gwmngilfen is giving a presentation on using data to understand community stricture and aid governance 13:10:37 <jtanner> structure* 13:10:56 <gundalow> #undo 13:10:56 <zodbot> 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 <gundalow> #info gwmngilfen is giving a presentation on using data to understand community structure and aid governance 13:13:46 <resmo> big data... 13:13:48 <resmo> ;) 13:13:50 <gregdek> :) 13:14:36 <jtanner> "some core committers are filtered" ... we need to get greg an updated list 13:14:45 <gregdek> +1 13:15:01 <gundalow> #info Ideas on how to use this data, ie what questions we should ask? 13:15:27 <gundalow> #action gundalow to give gwmngilfen updated list of committers 13:18:16 <gundalow> Who here is remote? 13:18:22 <geerlingguy> Is there a link to this tool? 13:18:25 <robertdebock> Can we look into this data ourselves? / Is this representation available to use? 13:18:25 <felixfontein> <- 13:18:36 <gregdek> 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 <jtanner> cheater ^ 13:18:58 <felixfontein> while true; do curl https://...; done :D 13:19:00 <gregdek> (don't want to potentially crash the tool while greg is presenting lol) 13:19:37 <misc> but without a tool crashing while doing a demo, is this really a demo ? 13:19:46 <gregdek> 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 <bcoca> misc++ 13:19:54 <shaps> felixfontein: you need spoof the UA though, too easy to filter out otherwise :) 13:20:11 <jtanner> iirc, we filter the docs data by unique IP 13:20:12 <robertdebock> @gregdek, cool! 13:20:16 <misc> and run curl from a bunch of ec2 VM 13:20:22 <misc> automate the deployment with ansible 13:20:49 <gundalow> #info we will be pulling web stats from docs.ansible.com to add to the stats on module usage 13:20:54 <resmo> gregdek: gundalow question: is there a stats, after which time it us unlikely a PR get merged? 13:20:59 <misc> (using serverless, it would be pretty cheap, I did the math for another cheating project) 13:21:15 <gregdek> resmo: queued, thx 13:22:06 <gundalow> #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 <bcoca> what is the curve for new feature PR vs bugfix PR? 13:22:16 <gregdek> bcoca: selectable, I believe 13:22:34 <gregdek> This is a general overview of the tool 13:22:44 <gundalow> #info the merge time stats allows you to pick any two labels to compare 13:22:59 <gundalow> oh, which Greg is now showing... 13:23:02 <robertdebock> And it would be interesting to see what type of module the PR's relate to; code, stable, preview, community, etc. 13:23:03 <pabelanger> Do network! 13:23:19 <jtanner> i blame felix 13:23:22 <pabelanger> is this data public? 13:23:31 <jtanner> yes, link will be shared afterwards 13:23:32 <felixfontein> :D 13:23:42 <bcoca> he, i was going to 'credit' felix, but 'blame' also works ... 13:23:59 <jtanner> `git credit: command not found` 13:24:01 <dmsimard> git s/credit/blame/ 13:24:06 <gregdek> jtanner: lol 13:24:15 <gundalow> robertdebock: Yup, I've seen that label/support:core and label/support:network get merged quicker than label/support:community 13:24:26 <bcoca> svn has the never used 'praise' 13:25:09 <misc> that's a intresting bias in the UX of the tool 13:25:11 <gundalow> #chair andersson007_ felixfontein decentral1se misc 13:25:11 <zodbot> 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 <gundalow> #info We also have some stats on http://ansible.meetup.com 13:25:58 <jtanner> ansible it hot in pune 13:26:03 <jtanner> is* hot 13:26:10 <felixfontein> atlanta should have a big fat dot for this week :D 13:26:39 <jtanner> if we arranged contrib summit through meetup.com, it definitely would 13:27:17 <bcoca> missing alaska, hawai, puerto rico and guam 13:27:24 <gregdek> If we arranged contrib summit through meetup.com, there would be 20 people here 13:27:41 <jimi|ansible> we have meetups in hawaii? i'll organize 13:28:09 <jtanner> i think we're going to spain 13:28:10 <gregdek> bcoca: you're going to run a meetup in spain, yes? 13:28:22 <jimi|ansible> that might have been all ricky though 13:28:28 <robertdebock> So, AnsibleFest Barcelona next year?! 13:28:28 <jimi|ansible> (j/k of course) 13:28:35 <maxamillion> robertdebock++ 13:28:39 <misc> I am going to change my github location for hawaii and do PR 13:28:42 <shaps> robertdebock: +++ 13:28:59 <bcoca> if we have budgjet to rent bars from my family members ... 13:29:15 <gregdek> #link http://stats.eng.ansible.com/apps/ 13:29:51 <resmo> robertdebock: ++ 13:29:55 <jtanner> there's more on there than greg demo'ed, so click around 13:30:44 <robertdebock> What a great talk, thanks @gemngilfen! 13:30:52 <felixfontein> indeed! thanks! 13:30:57 <misc> yup, that was great 13:31:43 <bcoca> chance is increased by pinging people in #ansible-devel or appropriate channel 13:33:13 <jtanner> 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 <gregdek> #topic Roadmap with Dylan Silva 13:34:24 <gregdek> #info thaumos / Dylan contributed to 0.12 in June 2012 and has been making trouble fo us ever since 13:34:47 <gregdek> "for us" stupid sticky r key 13:35:00 <gregdek> #action gregdek to clean his keyboard 13:35:44 <geerlingguy> lol 13:36:02 <robertdebock> I'm interested what "goes in" Ansible, and what will be put in a collection. How to decide that? 13:36:17 <jtanner> BD 13:36:18 <geerlingguy> Have we DDoSed the stats.eng.ansible.com server yet? :P 13:36:21 <jtanner> err, TBD 13:36:29 * jtanner needs to clean keyboard too 13:36:39 <gregdek> #action jtanner to clean his keyboard 13:37:06 <jtanner> keyboard cleaning breakout at noon 13:37:16 <misc> shouldn't we stop the screensharing ? 13:37:19 <bcoca> are we not supposed to see anything on screen? 13:37:26 <jtanner> he doesn't have a preso 13:37:34 <robertdebock> No, screen is blank here in Atlanta. 13:37:50 <gregdek> #info no preso on screen for this session 13:38:21 <jtanner> he alluded to the announcements being made tomorrow, so that's where the demo/slideware comes into play 13:39:08 <gregdek> #topic Open Questions / Q+A about collections 13:39:21 <gregdek> #topic Open Questions / Q+A about Core roadmap / collections 13:39:31 <gundalow> Remote people, please ask questions here and we will ask them in the room 13:39:41 <gregdek> #info question: what will go into ansible core and what will stay in collections? 13:39:59 <misc> wouldn't it wreck some havoc in the stats that were presented before ? 13:40:07 <gregdek> #info answer: all "content" will go into some kind of collection 13:40:20 <gregdek> misc: we're ready to change those tools to follow the new structure 13:41:04 <jtanner> misc: https://en.wikipedia.org/wiki/Goodhart%27s_law =) 13:41:21 <gwmngilfen> yep, i'm aware :) 13:41:27 <abadger1999> Everything? Or will there still be some content in core? 13:41:48 <abadger1999> All content outside of core presents coordination problems. 13:42:05 <bcoca> yes, it does 13:42:54 <felixfontein> I guess the "common" part of module_utils needs to have a rock solid backwards-compatible interface then 13:43:01 <jtanner> very true 13:43:12 <BobBoldin> 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 <felixfontein> (and even worse for plugins...) 13:43:38 <gwmngilfen> yes! give me more questions! 13:43:57 <gwmngilfen> buried things are why general dashboards are tricky here 13:43:57 <resmo> where are the collections "hosted"? do they go into github/ansbile/collection-xyz? 13:44:12 <resmo> or not under ansible? 13:44:23 <gwmngilfen> thaumos: ^ 13:44:28 <gregdek> resmo: I think matt is asking this question now 13:44:28 <bcoca> right now using ansible-collections as testing ground 13:44:39 <jtanner> github.com/ansible-collections is the intended org for collections that do not end up in someone else's org 13:44:41 <bcoca> https://github.com/ansible-collections 13:45:14 <bcoca> ^ most of those are just tests, might not reflect what the ending namespaces/colleciton names/structures look like 13:45:18 <gregdek> #info galaxy will be the way for users to get "a la carte" content if they so choose 13:46:05 <gregdek> #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 <abadger1999> Is there an option besides a la carte? 13:46:24 <gregdek> abadger: yes, we will bundle a new version of "batteries included" 13:46:42 <gregdek> That is a requirement 13:46:44 <bcoca> will that require playbooks to change? colleciton code does not work same as core 13:47:01 <gundalow> maxamillion is now speakign 13:47:06 <abadger1999> gregdek: I do not think those batteries should be put into a collection. 13:47:17 <abadger1999> That just makes unnecessary work. 13:47:25 <abadger1999> Really big unnecessary work. 13:47:31 <abadger1999> (Social, not technical) 13:47:39 <gregdek> abadger1999: as in, the very core modules should stay in core? 13:47:45 <abadger1999> Yes. 13:47:57 <bcoca> not just modules, plenty of plugins 13:48:05 <abadger1999> 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 <gregdek> Putting those core modules/plugins into, say, a core-modules collection would be problematic? 13:48:35 <bcoca> gregdek: lookup('ansible.core.file' vs lookup('file l 13:48:37 <gregdek> Well, the question is "what does the batteries included bundle look like". It may not be a tarball. 13:48:41 <bcoca> '^ they are not referenced teh same 13:49:00 <bcoca> also code in collections does imports differently, so they cannot just be 'copied' into core paths 13:49:05 <gregdek> It may be a single command in galaxy: "galaxy install ansible-batteries-included" or some such. 13:49:13 <gregdek> Still discussing that. 13:49:24 <geerlingguy> So install could be `pip install ansible && ansible-galaxy install batteries` 13:49:30 <geerlingguy> ^ is that the idea? 13:49:51 <maxamillion> geerlingguy: I hadn't thought of that, but that would be an interesting idea 13:49:53 <gregdek> Yep, something like that in theory. 13:50:00 <gregdek> In practice, we don't know what the answer is yet. 13:50:11 * geerlingguy reserves the 'batteries' namespace :P 13:50:15 <gregdek> Heh 13:50:15 <shaps> I guess as long as 'batteries' doesn't mean playbooks will need to change would be fine 13:50:17 <abadger1999> <nod> 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 <maxamillion> I was mostly thinking of the downstream distribution as a tarball, rpms, debs, etc 13:50:24 <gregdek> That's the idea. 13:50:35 <gregdek> We'll get into the namespacing discussion in the collections discussion. 13:50:43 <smolz> Is there any idea of when this will be taking shape? 13:50:45 <maxamillion> shaps: +1 13:50:56 <robertdebock> Question: some (binary) modules are architecture dependent, I've not seen how collections deal with different architectures. 13:51:03 <abadger1999> 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 <gregdek> abadger1999: yes. :) 13:51:27 <dmsimard> robertdebock: how are they dealt with today ? 13:51:35 <abadger1999> It probably doubles the project-level work that you have to do. 13:51:42 <gregdek> It does indeed. 13:52:07 <robertdebock> 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 <abadger1999> If you are going to include it in the ansible rpms/tarball, though, then that would be even more work. 13:52:30 <gregdek> Right. Which I think is what that's probably not the model. 13:52:46 <abadger1999> because then you also have the social aspect of forcing those project decisions from ansible/ansible onto the new colection. 13:53:07 <felixfontein> what about the new features for 2.10 already merged? 13:53:38 <gregdek> 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 <shaps> abadger1999: which wouldn't really be different to how the releases go now, really 13:53:56 <abadger1999> shaps: No..... 13:54:12 <abadger1999> shaps: it's how releases are done now for the non-core modules. 13:54:32 <bcoca> ^ he is RM 13:54:50 <bcoca> just FYI in case you want to know how familiar he is with our release process 13:54:56 <abadger1999> 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 <resmo> I am concerned there will be many flavors of the same collection on galaxy... 13:55:30 <bcoca> resmo: nginx roles? 13:55:37 <resmo> bcoca: exactly 13:55:43 <shaps> abadger1999: yeah, i'd be +1 for that 13:55:46 <ptoal> Ansible Galaxy Verified Accounts... 13:55:50 <gregdek> resmo: that's a risk, yes. That risk is exacerbated by a poorly managed upstream. 13:55:50 <jtanner> 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 <abadger1999> 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 <jimi|ansible> 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 <bcoca> but its easy to copy existing colleciton and add a plugin or patch existing and republish 13:56:58 <bcoca> license permiting 13:57:05 <jtanner> 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 <gregdek> 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 <gundalow> now speaking is chouseknecht, who is the Ansible Galaxy Lead 13:57:38 <bcoca> gregdek: that is why some of us want some content to stay in core 13:57:41 <gregdek> #info chouseknecht is discussing galaxy 13:57:44 <abadger1999> gregdek: Yep. 13:58:12 <gregdek> abadger1999 bcoca it's a fair point. Something maybe to dig into during the next session. 13:59:12 <gundalow> Now speaking: geerlingguy 13:59:14 <gregdek> #info geerlingguy is asking questions about ui of galaxy 13:59:52 <gregdek> #info searchabilityt of collections will be key 14:00:27 <gregdek> #action gwmngilfen should have basic stats for collections in galaxy 14:00:30 <geerlingguy> Sorry I'm terrible about saying my name :P 14:00:35 <gregdek> :) 14:00:48 <gundalow> #action gregdek to think about stats on growth of collections and usage rate 14:01:32 <gundalow> #info maybe 10-30 people don't know what ansible-test is 14:02:11 <robertdebock> geerlingguy, I'm also horrible at saying your name. ;-) 14:02:22 <geerlingguy> lol 14:02:38 <fungi> anybody have a url for the ansible-test repo? 14:02:40 <gundalow> #info `ansible-test` is what does all the work when you push a PR to ansible/ansible 14:03:05 <fungi> curious to look into the source code 14:03:16 <dmsimard> https://github.com/ansible/ansible/tree/devel/test ? 14:03:17 <resmo> what about the integration tests in ansible/ansible for modules going out to collections? 14:03:26 <gundalow> #info ansible-test is in the github.com/ansible/ansible (ie main) repo 14:03:37 <bcoca> resmo: that is one thing the migration team is working on, moving those tests 14:03:48 <resmo> cool 14:03:51 <bcoca> they need to be rewritten to use the collection (wip) 14:03:53 <jimi|ansible> resmo: yeah tests will move when the corresponding module moves out 14:04:00 <bcoca> unit tests also 14:04:00 <jimi|ansible> which will make core tests soo much faster 14:04:04 <gundalow> DING DING DING 14:04:07 <gundalow> Back in 20 minutes 14:04:07 <fungi> 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 <shaps> ^ +1 14:05:00 <abadger1999> 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 <bcoca> geerlingguy: the way to run them faster is to disable them 14:05:15 <fungi> abadger1999: thanks! 14:05:25 <shaps> it's just to split the modules repo again 14:06:01 <bcoca> can someone stop the music? 14:06:01 <fungi> 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 <bcoca> shaps: not really, though similar pains 14:06:52 <bcoca> its also to enable core to have longer more stable releases, while making plugins relase at their own schedule 14:07:02 <bcoca> 1/2 the time people want a new release is for 'features' in their plugins 14:07:18 <abadger1999> 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 <bcoca> it also allows for more flexible maintainership 14:07:51 <abadger1999> fungi: The roadmap is largely done internally right now :-/ 14:07:54 <felixfontein> 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 <fungi> abadger1999: thanks again! dmsimard beat you to the url 14:08:30 <bcoca> felixfontein: i dont expect collections to need that much synchronicity 14:08:42 <fungi> 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 <bcoca> i do see a few cases (process plugins) .. but mostly we need a way to say 'collection ansible version compatiblity' 14:09:10 <resmo> bcoca: docs? 14:09:12 <chouseknecht> 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 <bcoca> resmo: one we figure out the mech ... 14:09:41 <bcoca> collections are WIP, so are collection docs (though you should have up2date ones on docs.ansible.com 14:09:52 <chouseknecht> felixfontein which is a case for amping-up the work on molecule 14:09:56 <resmo> fair enough. I am curious. 14:09:56 <bcoca> https://docs.ansible.com/ansible/devel/user_guide/collections_using.html 14:10:11 <abadger1999> 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 <bcoca> https://docs.ansible.com/ansible/devel/user_guide/collections_using.html 14:10:25 <bcoca> https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html 14:10:31 <fungi> abadger1999: okay, great. thanks for the explanation 14:10:46 <abadger1999> 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 <bcoca> 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 <fungi> business-controlled open source is a bit of a foreign concept to me, so trying to learn more about it 14:12:03 <fungi> coming from community-driven projects, the difference in dynamics is intruiging 14:12:35 <fungi> er, intriguing 14:12:40 <abadger1999> 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 <fungi> are there community governance documents which have any detailed explanations of that? 14:13:32 <abadger1999> The core irc meetings are the place to get decisions made but it does suffer from a lack of attendance. 14:13:42 <abadger1999> gundalow: ^ see fungi's last question. 14:14:09 <abadger1999> 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 <fungi> thanks again, that's all great info 14:14:59 <webknjaz> @fungi: you may find some answers to your questions around here: https://docs.ansible.com/ansible/devel/community/development_process.html 14:15:20 <fungi> awesome, thanks webknjaz! 14:15:40 <abadger1999> (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 <webknjaz> @fungi: also take a look at this wiki: https://github.com/ansible/community/wiki 14:16:58 <fungi> excellent, thanks again 14:17:43 <felixfontein> how many versions of ansible core should a collection support? the last 3 or 4, like core? 14:17:47 <cyberpear> usually there's enough RH folks lurking that they would outnumber any vote where RH had a strong option 14:18:40 <bcoca> cyberpear: most of the time RH employees are not a voting block 14:18:47 <gwmngilfen> geerlingguy gregdek sure I have a bunch of galaxy data, I'll ping later on and we can dig into it 14:18:51 <bcoca> rarely happens when we all agree ... and normally that is for a good reason 14:19:25 <bcoca> 'no we are not rewriting ansible in ruby!' 14:19:46 <jillr> I thought we had decided on rust? ;) 14:19:53 <misc> rustby 14:20:10 <bcoca> i used ruby as the one way to get unanimous core vote .. rust/haskell/golang will get disenters 14:21:38 <felixfontein> bcoca: use ruby as a way to get an unanimous yes, or an unanimous no? 14:22:31 <geerlingguy> rewrite in bash 14:23:02 <bcoca> felixfontein: try proposing for next meeting to find out 14:23:02 <felixfontein> why not in JVM bytecode? 14:23:09 <bcoca> geerlingguy: actually ... im 1/2 there 14:23:16 <cyberpear> ^would remove py dep! :P 14:23:19 <felixfontein> bcoca: no thanks, I don't really like ruby, to put it nicely :) 14:23:21 <bcoca> felixfontein: ironpython 14:24:19 <felixfontein> the music stopped 14:24:23 <felixfontein> so let's continue? :) 14:24:26 <felixfontein> ah 14:24:30 <felixfontein> or not 14:26:00 <abadger1999> I was hoping too, but just bluejeans being laggy.... ;-) 14:26:48 <bcoca> you fooled me to rejoin! 14:27:00 <felixfontein> the music went away, someone said a word, and then the music came back... 14:27:09 <felixfontein> now there's a voice again 14:27:13 <bcoca> its not just that i would prefer a diff track, tis that BJ is choppy making it really annoying 14:27:17 <felixfontein> announcing it will start again at 10:30 14:27:21 <felixfontein> i.e. in 3 minutes 14:27:30 <felixfontein> yep indeed 14:27:30 <misc> +1, the sound is choppy, I tought it was my side 14:28:34 <abadger1999> 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 <jhawkesworth> My guess is bluejeans is optimised for voices, so it mutes anything that doesn't sound like a voice 14:29:13 <bcoca> bj is optimized for maximum annoyance 14:29:31 <abadger1999> 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 <felixfontein> 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 <abadger1999> Yeah 14:30:07 <gundalow> DING DING DING 14:30:08 <felixfontein> so if we ever want to use new core features, we'll have fun with multiple branches like in core itself 14:30:13 <gundalow> #topic Collections 14:30:24 <gundalow> Please see screen 14:30:28 <felixfontein> I can see the screen 14:30:38 <gundalow> https://etherpad.openstack.org/p/ansible-summit-atlanta-2019-general-session line 69 14:32:17 <abadger1999> felixfontein: <nod> Either that or you'll have to choose. 14:32:28 <felixfontein> from when on will the "no longer merge new stuff" rule be active? 14:32:41 <gregdek> #info proposal: new collection format for community collections: one repo, many collections 14:33:03 <cyberpear> boo! 14:33:24 <gregdek> #info proposal: net new plugins will go into the new community collection 14:33:39 <gregdek> cyberpear: any detail on that "boo"? :) 14:33:46 <shaps> felixfontein: 2.10 14:33:49 <cyberpear> is everything in this new repo guaranteed to ship in the batteries included distro? 14:33:53 <abadger1999> 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 <felixfontein> shaps: once 2.10 is released, or like *now*? 14:34:00 <gundalow> #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 <cyberpear> he said "now", no grace period 14:34:21 <gregdek> cyberpear: part of this exercise is changing the definition of "batteries included". 14:34:32 <robertdebock> 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 <gregdek> There will still be a single command to install all of this content. 14:34:37 <felixfontein> if it is now "now", ansibot should maybe be stopped from merging, and people with commit rights should be told too 14:34:40 <abadger1999> (permissions to merge, release schedules, getting issues to the right people, etc) 14:34:41 <mnaser> abadger1999: yeah, i think there is a lot of noise right now with the multirepo stuff 14:34:46 <bcoca> meta collections are also possible: so ansible.community could just be a list of N collections 14:34:56 <jtanner> robertdebock: mattclay is giving a talk/demo on that this week with ansible-test 14:35:01 <gregdek> felixfontein: remember, this is a proposal, so "now" is for some value of "now" 14:35:03 <gundalow> #info For now the Ansible Community Collections will live under github.com/ansible/ 14:35:19 <robertdebock> jtanner cool! 14:35:19 <cyberpear> how will security issues be handled? 14:35:32 <felixfontein> gregdek: so now = not now, i.e. we can add new stuff until this is properly announced? 14:35:34 <bcoca> cyberpear: tbd 14:35:39 <gundalow> cyberpear: What specifically? 14:35:52 <gundalow> #chair cyberpear 14:35:52 <zodbot> 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 <gregdek> 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 <mnaser> 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 <cyberpear> what is the cve/reporting/patching process? 14:37:22 <mnaser> 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 <gregdek> cyberpear: we'll need answers to that, but those answers will be "the process that the community can bear". 14:38:18 <gregdek> mnaser: yes, that will be your option. 14:38:23 <gundalow> #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 <gundalow> mnaser: does that answer your Q? 14:38:32 <mnaser> neat 14:38:32 <mnaser> yeah 14:38:35 <fungi> 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 <gregdek> fungi: yes, that was a requirement. 14:38:57 <gundalow> now speaking dmsimard (Mr Ara) 14:39:22 <gregdek> 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 <fungi> theoretically people can check compiled binaries into a github repo too ;) 14:41:14 <jillr> 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 <gregdek> jillr: good one. :) wanna ask in the room? 14:41:40 <bcoca> he, iirc we have one in our repo (golang moduel test?) 14:41:58 <jtanner> it's in an integration test, but not available generally 14:42:00 <jillr> gregdek: sure, also wanted it noted in channel :) 14:42:04 <gregdek> +1 14:42:35 <cyberpear> "deprecated" or "removed"? 14:42:35 <gundalow> now speaking jillr 14:43:05 <felixfontein> I like that answer so far :D 14:43:14 <gregdek> WOW, that's a good question! :) 14:43:16 <geerlingguy> lots of dancing in here 14:43:25 <gundalow> felixfontein: aye, we are trying to be open and honest here 14:43:30 <gregdek> #info module_utils will be forked. 14:43:34 <cyberpear> downstream first development! 14:43:41 <pabelanger> :( 14:43:47 <cyberpear> (just like OpenShift 4.x) 14:43:53 <jimi|ansible> when we de-couple modules from our core release cycle, we're going to have to maintain some level of compatibility 14:43:54 <gregdek> #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 <bcoca> module_utils is not a 'block' there is very specialized/specific stuff 14:43:59 <felixfontein> gundalow: that's really good :) 14:44:01 <gundalow> 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 <geerlingguy> apropos to earlier question about source repo not necessarily being visible (https://github.com/ansible/galaxy/issues/2006) 14:44:16 <gregdek> This is definitely one of the Hard Problems. 14:44:35 <felixfontein> oooh, I know some more modules which need more maintenance :) 14:44:49 <bcoca> long list ... 14:44:52 <jimi|ansible> 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 <jimi|ansible> playbooks are not coupled to a core version, so we try to keep things flexible there 14:45:18 <shaps> jillr: i'd be glad to help in that 14:45:27 <jimi|ansible> if we deprecate things, we take a long time to actually remove it 14:45:35 <gregdek> abadger1999: it may be that we should more properly say "we will fork if we must" 14:45:39 <jillr> shaps: you're hired! you get paid in a backlog of PRs and Issues ;) 14:45:45 <abadger1999> gregdek: Yep. 14:45:52 <abadger1999> that would be best. 14:46:03 <shaps> jillr: lol thanks 14:46:26 <gregdek> #info we will not necessarily fork mod_utils, but we must have the ability to do so, and if we do, maintaining upstream/downstream relationship will be critical 14:46:48 <cyberpear> w/o docs, ansible is dead... good to hear that recognized 14:46:56 <abadger1999> gregdek: welll.... one thing about that.... I would see it as .... there becomes two upstreams. 14:46:56 <gregdek> Yeah. 14:46:58 <gundalow> now speaking acozine (Docs Lead for Ansible) 14:47:03 <felixfontein> will the *whole* of module_utils be forked, or only the module-specific part? 14:47:09 <abadger1999> libreoffice/openoffic. 14:47:10 <gregdek> abadger1999: yes, good point. 14:47:14 <bcoca> felixfontein: that is the debate 14:47:16 <abadger1999> gcc/egcs 14:47:19 <jimi|ansible> forking would be the nuclear option, if and only if we had zero other options and I would not expect it unless there was some huge rewrite of features involved 14:47:20 <abadger1999> etc. 14:47:20 <gundalow> #info FYI #ansible-docs https://github.com/ansible/community/wiki/Docs 14:47:23 <bcoca> <= really wants to keep 'common' in core 14:47:35 <gregdek> These are all still proposals :) 14:47:57 <dmellado> jillr: regarding AWS, at some point I might be able to lend a hand as well 14:48:03 <jimi|ansible> felixfontein: some things in module_utils (aws, for instance) would follow their modules 14:48:11 <jillr> dmellado: woot! 14:48:21 <jtanner> for any given supported collection's modules, all of it's module utils that don't stay in core will have to be forked from it's community counterpart so that will be functional without the community code 14:48:23 <felixfontein> jimi|ansible: that's what I understood in the beginning, but then I began to wonder if I got it right 14:48:53 <jimi|ansible> yeah there'd be no point in us maintaining it, it'd be best for those modules maintainers to ensure compatibility 14:48:58 <jimi|ansible> otherwise we'd still be a road block 14:49:33 <jillr> dmellado: shaps cloud breakout https://etherpad.openstack.org/p/ansible-summit-atlanta-2019-cloud at 13:00EDT (17:00UTC) 14:49:35 <gregdek> #info question in the room: will there an option to say "this collection is for x versions only"? 14:49:51 <felixfontein> hmm, can there be different versions of the collection for different versions of ansible? 14:50:08 <jtanner> not at the moment 14:50:17 <robertdebock> I've not heard if Ansible Tower/AWX will be ready for Ansible Collections... 14:50:25 <gregdek> #info answer: yes, creators can say "this collection version only works for these versions of ansible" -- tooling will eventually restrict, but does not work that way today 14:50:27 <dmellado> jillr: ack, I'll try to be there, let's see if it doesn't collide wit hthe networking one 14:50:28 <dmsimard> so it's expected that a collection supports all supported releases of ansible ? 14:50:33 <dmellado> worst case I'll sync with you afterwards 14:50:34 <dmsimard> (unless pinned in metadata) 14:50:44 <dmellado> dmsimard: actually that's a good question 14:50:44 <gregdek> dmsimard: unclear, I think 14:50:52 <dmellado> I was thinking about some kind of 'branchless' collections 14:51:01 <dmellado> otherwise, matrix compatibility would be really chaotic 14:51:02 <mnaser> ah, that might make it harder for using something where we have multiple major releases supporting a certain range of ansible versions 14:51:04 <bcoca> what about collections that depend on other collections? 14:51:13 <jtanner> with the relative imports feature coming in 2.9, we'll already have collections that won't function in 2.8 14:51:16 <bcoca> how will that be reflected in galaxy? 14:51:19 <jtanner> so we're already at this phase 14:51:19 <jillr> dmellado: it does not, it's the block of breaouts prior to networking 14:51:20 <dmellado> bcoca: pinning the version on requirements? 14:51:27 <pabelanger> how does a collection manage a python dependency? Like is ansible AWS collections needs to install boto3, is that done before the collection is installed vi ansible-galaxy client? 14:51:28 <dmellado> jillr: awesome then 14:51:32 <dmsimard> bcoca: there is a field for collection dependencies that, I'm not sure how it is displayed in galaxy 14:51:40 <jtanner> pabelanger: we're not handling python deps 14:51:41 <bcoca> dmellado: that is in galaxy.yml, but i dont see it reflected in galaxy ui 14:51:45 <jimi|ansible> this is a problem for roles today - for instance when we split import vs. include 14:51:52 <cyberpear> how will core infra changes propagate to community collections? 14:51:54 <shaps> jillr: ack 14:51:58 <jimi|ansible> anything written to do include_role or import_role wouldn't have worked in the version of ansible before 14:52:00 <dmellado> bcoca: would it mean for a ui? I mean 14:52:05 <dmellado> would a UI user need to specify that? 14:52:06 <robertdebock> Good suggestion; every module in it's own repo. Makes testing/developing easier. 14:52:08 <jtanner> cyberpear: core infra? 14:52:12 <gregdek> cyberpear: what do you mean "core infra"? 14:52:16 <gundalow> #info These are all proposals, we need your feedback to help work out what's the right way to move forward 14:52:17 <dmellado> if we assume that collection A needs B 14:52:24 <dmellado> a user would just install it and be happy with that 14:52:39 <cyberpear> something like the new way of accessing module params vs the old way? 14:52:43 <mnaser> i'd hate for there to be "community collections" and "vendor-specific collections" 14:52:48 <bcoca> unless collection C needs B1.0 and A needs B2.0 14:52:51 <mnaser> that would just lead to confusion, lack of code sync, et 14:52:52 <mnaser> etc 14:53:06 <dmellado> bcoca: then houston there's an issue and we should set up an exception 14:53:14 <dmellado> bcoca: also there might be circular dependencies 14:53:20 <cyberpear> (who talking?) 14:53:21 <dmellado> so that would need to be really well defined 14:53:26 <bcoca> no, those are resolved by ansible-galaxy cli 14:53:27 <jtanner> atm, gregdek 14:53:43 <pabelanger> mnaser: I suspect there is going to be an explosing of duplicate code; eg vendoring is going to be the new thing 14:54:01 <gregdek> (sorry, should have said) 14:54:27 <jborean93> circular deps should be ok with `ansible-galaxy collection install` 14:54:32 <mnaser> the transition argument makes sense i guess 14:54:40 <gregdek> mnaser: there will be "vendor-specific collections" in that those will be "officially certified and supported by partners", we need that designation 14:54:59 * geerlingguy does like the idea of modules and plugins being in their own individual repos (like roles) 14:55:13 <cyberpear> (how many raised hands?) 14:55:15 * geerlingguy then collections == collections of these modules plugins and roles :D 14:55:20 <jtanner> cyberpear: a few 14:55:20 <gundalow> #info about dozzen Terraform users in the room 14:55:22 <gregdek> About 20 14:55:22 <geerlingguy> cyberpear: maybe 10ish? 14:55:26 <gregdek> LOL 14:55:28 <robertdebock> cyberpear about 10 or so. 14:55:31 <dmsimard> geerlingguy: the overhead of managing >1 repo is non-null 14:55:31 <geerlingguy> 3-20 14:55:33 <jborean93> there are dozens or us, dozens! 14:55:34 <shaps> cyberpear: 6-7 14:55:39 <gregdek> 83 14:55:43 <mnaser> 42 tbh 14:55:44 <felixfontein> a positive integer 14:55:45 <dmellado> bcoca: just curious, how do you handle circular deps with ansible-galaxy cli? 14:55:46 <jimi|ansible> a lot less terraform users than i would have expected 14:55:48 <gregdek> ¯\_(ツ)_/¯ 14:55:55 <geerlingguy> dmsimard: I manage over 200 active repos (personally) ;) 14:56:05 <jborean93> dmellado: yes it should be ok 14:56:15 <mnaser> i think geerlingguy just volunteered to split all of those repos 14:56:17 <resmo> openshift 4 ansible collection installer ! 14:56:19 <dmsimard> geerlingguy: and you're doing an excellent job at it too 14:56:19 * cyberpear has heard great things about terraform, never actually used it 14:56:20 <jborean93> as long as the dep versions have no conflict 14:56:41 <dmellado> jborean93: but in such case of version conflict? 14:56:55 <jborean93> it will fail because how would it know what version to install 14:56:57 <gundalow> FYI we have 21 top level directories and ~180 sub directories 14:57:03 <gundalow> under lib/ansible/modules/ 14:57:29 <cyberpear> cascading ansible config? 14:57:36 <gundalow> now speaking nitzmahone (Matt Davis The (original) Windows Guy) 14:59:44 <felixfontein> I hope that most collections will have zero dependencies (except Ansible versions), otherwise there'll be a new dependency hell 14:59:52 <abadger1999> Is there a single namespace or can there be conflicting namespaces? 15:00:09 <cyberpear> is the extra `collections/ansible_collections` still a thing? 15:00:14 <cyberpear> YES! 15:00:15 <abadger1999> that's kind of... is there a "Internet Assigned Ansible Namespace Authority"? 15:00:16 <jimi|ansible> only one person can register a namespace on galaxy 15:00:22 <geerlingguy> cyberpear: yeah... 15:00:31 <geerlingguy> something about a python PEP standard 15:00:34 <abadger1999> jimi|ansible: but what if there's multiple galaxy servers..... 15:00:35 <gundalow> #info Only ~dozen people in the room knew what a collection looks like on disk (ie directory structure) 15:00:37 <robertdebock> Would be nice to point requirements.yml to collections. 15:00:40 * misc register nginx 15:00:44 <jimi|ansible> that wouldn't prevent someone from directly creating a conflicting namespace and aiming the cli tool at a git repo directly 15:00:54 <jimi|ansible> abadger1999: all we can say is "Don't do that" 15:01:07 <cyberpear> gundalow++ thanks for helping us remote folks! 15:01:07 <zodbot> cyberpear: Karma for gundalow changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:01:07 <jborean93> felixfontein: that's my hope as well, if you have circular deps then you really have a problem 15:01:10 <jimi|ansible> if you've got a private galaxy or git repo of some kind make sure your namespaces don't conflict 15:01:11 <akasurde> Just like galang does 15:01:15 <jimi|ansible> we can only control the public ones 15:01:16 <akasurde> Go get package name 15:01:37 <geerlingguy> it's something you figure out once and avoid in the future. Same issue exists in all software. 15:02:07 <cyberpear> I'd drop the `ansible_collections` part of the path 15:02:08 <samccann> collection structure - https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#developing-collections 15:02:14 <geerlingguy> cyberpear: PEP 420 I believe? 15:02:37 <geerlingguy> (I'm annoyed by the extra subdir because if you're just doing roles you don't have to care about Python in the least) 15:04:32 <cyberpear> `for i in collections/ansible_collections/*/ ; do ln -s $i . ; done` or something to make it more usable in the repo 15:05:19 <bcoca> you can actually get rid of '/collections/' insteaed 15:05:28 <abadger1999> cyberpear: you might possibly be able to drop the "collections" portion. But it would mean that (for example) putting ansible_collections in ~/ would also add any python pakages and modules in ~/ into the PYTHONPATH. that could be problematic. 15:05:30 <felixfontein> I'm nervous, a little more than before :) 15:05:35 <cyberpear> or better `for i in collections/ansible_collections/namespace/collection/*/ ; do ln -s $i . ; done` 15:05:43 <gundalow> now speaking robertdebock 15:06:05 <cyberpear> (w/in a "collection repo") 15:06:19 <mnaser> was there a reason why python dependencies are not mapped in? 15:06:28 <mnaser> it'd be nice to have things pre-included somehow 15:06:34 <jborean93> mnaser: MVP 15:06:42 <jtanner> pre-included where? 15:06:43 <geerlingguy> q: where do roles fit in here? A lot of discussion of plugins and modules and Python... but being able to use all the nice packaging features of Collections with roles seems like a double-edge sword right now. (I can ask over mic) 15:06:45 <cyberpear> (or do the reverse, but idea is to make the repos more accessible) 15:06:54 <abadger1999> mnaser: that is not simple. 15:06:58 <gundalow> #info there were some people in the room that are now more concerned that before 15:07:16 <gregdek> geerlingguy: you should do that 15:07:18 <abadger1999> Imagine that something has a dependency on libselinux. 15:07:18 <robertdebock> geerlingguy I'm wondering too. 15:07:19 <mnaser> right, something like requirements.txt 15:07:24 <mnaser> yeah, that's a nightmare, heh 15:07:28 <geerlingguy> I shall, give me the mic gregdek 15:07:31 <geerlingguy> :P 15:07:31 <pabelanger> bindep.txt :) 15:07:43 <jtanner> i think many people miss the fact that modules typically don't run on the controller host. if a collection comes pre-installed with it's deps on the controller, it doesn't help the module run on the remote hosts. 15:07:51 <abadger1999> There's no way for us to ship a portable version of that and no way for us to portably automatically install that. 15:07:57 <felixfontein> jtanner +1 15:08:07 <mnaser> in openstack-ansible, we actually run modules a lot on the host because many of those modules just talk to an API anyways 15:08:09 <gundalow> now speaking geerlingguy 15:08:30 <jimi|ansible> mnaser: a lot of modules are like that 15:08:47 <jtanner> mnaser: that may be the case, but it doesn't mean it fits everyone's usecase 15:08:50 <mnaser> i.e. openstack modules need openstacksdk but they almost rarely need to run on anything but the control host. we have a whole bnch of bootstrapping code and id love to eliminate that wiht a collcetion :) 15:08:53 <mnaser> valid 15:09:03 <gundalow> #info geerlingguy asks A lot of discussion is about Python and Collections. What about Roles? When are Roles getting new features? 15:09:04 <bcoca> same for most networking modules 15:09:06 <pabelanger> mnaser: for our testing of collections, we are using requirements.txt files. But ansible-galaxy doesn't do it out of box, we pip install first 15:09:27 <pabelanger> but we'll need to figure out some contraint system 15:09:33 <mnaser> yeah 15:09:34 <pabelanger> (network) 15:09:36 <bcoca> networking/cloud has a workflow that does more 'execute on controller' but that is not for all modules, so it has to be configurable 15:10:06 <bcoca> also, many people cannot use pip, require os specific package manager 15:10:08 <pabelanger> I really like what openstack did for global requirements, but is a lot of work / testing too 15:10:27 <mnaser> yeah i kinda forgot about the whole rpm-ized side of things 15:10:39 <mnaser> i guess y'all thought about this for a while :) 15:10:46 <jtanner> every day 15:10:54 <cyberpear> no dashes... 15:10:56 <gregdek> mnaser: yes. it burns, precious 15:11:19 <gundalow> now speaking nitzmahone 15:11:28 <robertdebock> From a role-first perspective; having control over the installed modules could be a strong benefit. 15:11:40 <jtanner> can you elaborate? 15:11:43 <dmsimard> mnaser: there is probably nothing preventing you from packaging a collection as a python package -- pip install openstack-collection -- which would take care of getting the deps and installing the collection files in the right path 15:12:00 <gundalow> now speaking geerlingguy 15:12:04 <mnaser> yeah, i think that might make sense 15:12:22 <bcoca> mnaser: 6yrs now i've been thinking this over 15:12:24 <robertdebock> When writing a role, it would be great to set the venv, and modules. That ensures the roll will run in a supported environment. 15:12:32 <felixfontein> how will ansible find a collection installed via pip? 15:12:49 <alikins> no reason a collection can't just include a single role 15:12:50 <felixfontein> or do you only mean modules/plugins, but not roles in there? 15:13:01 <dmsimard> felixfontein: by installing files in whatever paths ansible seeks things in 15:13:02 <gregdek> alikins: +1 15:13:11 <dmsimard> felixfontein: ~/.ansible ? /usr/share/ansible? other places 15:13:13 <jtanner> it can't use pip installed collections currently, unless you symlink from the collection root to the site-packages install location 15:13:15 <abadger1999> robertdebock: it doesn't.... see the selinux thing I mentioned earlier. 15:13:39 <felixfontein> dmsimard: can pip packages actually do that? sounds kind of scary, I thought they were restricted to the path where all installed modules land (except executables) 15:13:40 <gundalow> Now speaking Alex Stephens 15:13:47 <abadger1999> and you can sub libxml2, openssl, etc, for libselinux... 15:13:54 * geerlingguy also would like a migration path from role to collection (currently this is impossible) 15:14:25 <jtanner> what's making it impossible? 15:14:28 <mnaser> what if you make a big meta collection that gets preinstalled with the next release? 15:14:39 <gundalow> For those that are remote: we have ~130 people in the room here in Atlanta https://twitter.com/the_gundalow/status/1176128450974900224 15:15:06 <pabelanger> geerlingguy: 1 role into a collection? 15:15:10 * cyberpear missed the memo on 6mo release 15:15:22 <geerlingguy> pabelanger: yes 15:15:24 <jimi|ansible> we're approaching the second AnsibleFest (NYC) size... 15:15:29 <gregdek> :) 15:15:32 <jtanner> it varies here and there, but it has been 6 months on average 15:15:40 <pabelanger> geerlingguy: yah, I kinda want that too. But, haven't really tried 15:15:50 <geerlingguy> I tried and failed :P 15:15:53 <dmsimard> felixfontein: let me get back to you on that 15:16:02 <geerlingguy> I might be able to get a role deleted then create a collection in its place 15:16:17 <geerlingguy> Or I could build up a new namespace :D 15:16:32 <felixfontein> dmsimard: no hurry, I was just wondering how that could work :) 15:16:38 * geerlingguy reserves 'batteries' 15:16:41 <cyberpear> where is this community collection? 15:16:42 <jtanner> geerlingguy: oh, you are saying it's impossible to migrate in the galaxy api without delete+recreate? 15:16:46 <pabelanger> geerlingguy: what I did experiment, was keeping the collection, but a build time, create the collection (collection build / collection install). It seems to work okay 15:16:47 <robertdebock> geerlingguy if you "recycle" the name of the role into a collections, that would really confuse people I guess. 15:16:50 <pabelanger> err 15:16:50 <cyberpear> since we're supposed to merge stuff there starting today... 15:16:53 <pabelanger> keeping the role 15:16:53 <geerlingguy> jtanner: yes, exactly 15:16:59 <jtanner> geerlingguy: okay, gotcha 15:16:59 <resmo> "there are sooo many moving parts..." I am excited! :P 15:17:03 <felixfontein> I'm scared *and* excited :) 15:17:07 * geerlingguy is scared and excited 15:17:15 <robertdebock> felixfontein + 15:17:16 <felixfontein> (ok, not scared, more concerned) 15:17:17 <gundalow> #info ~2 two dozen people are excited for Collections 15:17:20 <gundalow> geerlingguy: :) 15:17:34 <gregdek> I'm encouraged that we're mostly scared about the same things. :) 15:17:42 <gundalow> now speaking dmsimard 15:18:02 <BobBoldin> I see job security in change, bring it on 15:18:07 <abadger1999> release schedule 15:18:08 <geerlingguy> robertdebock: true, but in some cases I have role names that I'd also like to move to a more broad collection 15:18:18 <felixfontein> about the current question: getting features earlier than waiting for the next ansible release :) 15:18:20 <mnaser> i think a huge value is "now i can use this role only, or library only or playbooks" 15:18:21 <bcoca> thaumos: if only that worked!!! 15:18:21 <abadger1999> Need a bugfix or new feature, you can get them quicker 15:18:26 <geerlingguy> e.g. `geerlingguy.php` could be the premiere collection of PHP resources for all of the content I produce 15:18:36 <bcoca> ^ not wiating for core cycle for new plugins/features 15:18:38 <geerlingguy> (vs right now I have like php, php-something, php-something-else (roles) 15:19:05 <mnaser> and shipping libraries in an easier form too 15:19:21 <mnaser> ansible-config_template struggles with this and i think ceph-ansible vendors it to use it 15:19:57 <BobBoldin> plugins have moved to top level out of roles, what about the library directory? 15:20:03 <felixfontein> will collection docs be hosted by ansible / redhat? 15:20:03 <gundalow> #info Requiring documentation for modules has been key to ensuring Ansible's success 15:20:39 <jimi|ansible> BobBoldin: one of the main goals of collections was to make modules and all other forms of plugins first-class content (whereas just roles were before) 15:21:02 <jimi|ansible> so it won't be library anymore, there's just a modules directory in the collection 15:21:06 <gundalow> now speaking nitzmahone 15:21:10 <resmo> gregdek: well said 15:21:17 <gregdek> resmo: thanks! 15:21:30 <jimi|ansible> (library was a left-over of the old way modules were imported from like 1.2...) 15:21:52 <alikins> most of the issue with reusing 'alikins.myrole' for migrating to collection 'alikins.myrole' are galaxy server/db constraints (which is being slowly addressed). Ansible itself doesn't care too much (bare 'alikins.myrole' references would be one case that would be odd) 15:22:12 <gregdek> felixfontein: yes, we will host documentation for anything that's published on galaxy. 15:22:45 <robertdebock> drive-by-contribution, cool word. 15:23:03 <gregdek> It may not be that *all* new content is documented on docs.ansible.com -- still some details to work out there, because there may be a lot of corner cases we don't know about yet. But the content that we have now, and the docs we have now, will all continue to be documented at docs.ansible.com. 15:23:07 <bcoca> dispells the illusion that 'core will maintain it' 15:23:13 <gregdek> ^^ 15:23:29 <felixfontein> gregdek: how will that work with different versions of one collcetion? (maybe aimed at different ansible core versions, once that's supported?) sounds like that will get somewhat complicated 15:24:18 <gregdek> felixfontein: yes. Will have to work that out. In the past we had backdated versions of "ansible documentation". Not sure how that's going to work. Possible: docs.ansible.com always has "latest" docs, collection has backlevel docs. 15:24:19 <mnaser> yeah i'm thinking you might end up with something like foobar 1.0 support ansible 2.5-2.7, foobar 2.0 supports 2.8-2.9 15:24:31 <mnaser> oh, about docs 15:24:42 <gundalow> #action gundalow for future Contributor Summits ensure we have a decent webcam/video camera showing the room 15:24:55 <felixfontein> mnaser: and then you have foobar 1.1 which fixes some bug, which also supports ansible 2.5-2.7, next to foobar 1.0 and foobar 2.0 :) 15:25:09 <bcoca> also, ansible-doc will always have the 'currently installed' documentation 15:25:25 <mnaser> felixfontein: yeah i think this would have to maintained by speciifc orgs, but what i would imagine is: merge change into master, backport tot stable/1.0 15:25:26 <felixfontein> ansible-doc is more tedious than nice HTML docs ;) 15:25:28 <gregdek> Good point! Local docs are always important. 15:25:45 <jborean93> felixfontein: blasphemy 15:26:05 <gundalow> erm, that was me speaking 15:26:11 <bcoca> felixfontein: that depends on user, i actually find the opposite to be true 15:26:44 <gregdek> to be fair, bcoca uses links instead of chrome or firefox 15:27:11 <jtanner> until firefox/chrome are ported to framebuffer 15:27:30 <jimi|ansible> bcoca writes all code in ed too 15:27:44 <gregdek> ed is fancy, bcoca uses cat 15:27:44 <jtanner> or bcoca is an ed script 15:27:46 <robertdebock> Ansible Docs to publish collection to something like: docs.ansible.com/collections//my_namespace/my_collection/version/modules/my_module 15:27:47 <mnaser> how does galaxy determine "latest version of a role" .. i.e. if we publish 1.3.1 (after 2.0) and we have 2.0 released already 15:27:58 <felixfontein> bcoca: true; I somehow miss colors :) 15:28:02 <mnaser> will "latest" correspond to 2.0 or "1.3.1" 15:28:05 <bcoca> semantic versioning 15:28:05 <felixfontein> (or other ANSI formatting) 15:28:11 <gundalow> DING DING Opening up question more generally now, not just Collections 15:28:12 <mnaser> bcoca: cool, perfect 15:28:17 <bcoca> felixfontein: .. we can support colors in ansible-doc, but i wont make it default 15:28:18 <gundalow> now speaking akasurde (Mr VMware) 15:28:32 <geerlingguy> What's the 2.9 release song name? We should play that over the speakers in here 15:28:45 <felixfontein> geerlingguy++ 15:28:47 <gundalow> now speaking nitzmahone 15:29:35 <jimi|ansible> 2.9.0 Immigrant Song 15:29:53 <gundalow> Remote people: Any more general questions. Ansible Team: Ask me Anything 15:29:59 * geerlingguy needs to watch Thor Ragnarok again now 15:30:15 <gundalow> now speaking robertdebock 15:31:10 <gundalow> now Speaking Alan (AWX team) 15:32:02 <felixfontein> interesting, `ansible-doc package_facts` is way more informative than the HTML page for package_facts: ansible-doc also shows "unsupported" keys (at least for return values) 15:32:22 <gundalow> felixfontein: oh, could you please raise a bug for that 15:32:51 <felixfontein> gundalow: I'm not sure whether it is a bug in ansible-doc or in the HTML docs :) 15:33:13 <robertdebock> roles/requirements.yml and collections/requirements.yml. Sounds good to me. 15:33:15 <gundalow> felixfontein: at least one of them :) 15:33:34 <gundalow> Now speaking mikewiebe (Cisco NXOS) 15:35:19 <abadger1999> felixfontein: gregdek : Re docs.ansible.com. "the docs we have now, will all continue to be documented at docs.ansible.com [for now]".... I think we're going to have a transition period of undetermined length but probably phase out to the docs hosted on galaxy sometime in the future. acozine will know for sure. 15:35:21 <alikins> collections can be any license. collections published to galaxy need to be open source compatible 15:35:22 <geerlingguy> #info thaumos "licensing sucks" 15:35:33 <bcoca> licencing is for lawyers 15:35:40 <robertdebock> 50% of the people here work at Red Hat... ;-) 15:35:42 <resmo> IBM paywall... 15:35:46 <bcoca> lol 15:35:59 <bcoca> ansible BU 15:36:23 <mnaser> would anyone be up to hack/triage/work with pull requests for openstack in the 212/213 working group channel? 15:36:30 <geerlingguy> in room: calisthenics 15:36:43 <mnaser> (openstack, as in the openstack ansible modules) 15:36:44 <bcoca> abu in RH in IBM 15:36:51 <felixfontein> an advantage of collections is that the whole collection (including module_utils) can be GLPv3; there will be no longer the "but module_utils must be BSD" dance :) 15:38:03 <geerlingguy> Downside is it could be DWTFYW licensed, which a lot of corporate lawyers hate 15:38:15 <felixfontein> definitely! 15:38:37 <dmsimard> felixfontein: re: pip packaged files -- the answer is yes, python packages can/could install things in, say, /usr/share/ansible. Just tested to double check. 15:38:40 <robertdebock> Creative Commons is pretty DWTFYW right? 15:39:05 <alikins> not really 15:39:09 <felixfontein> dmsimard: hmm, so using "sudo pip install" could also install a new /etc/passwd file? :) 15:39:12 <abadger1999> My phase out was unclear... For docs that are hosted on galaxy,phase out the equivalent docs which are hosted on docs.ansible.com 15:39:17 <alikins> almost always requires attribution 15:40:01 <dmsimard> felixfontein: don't shoot the messenger :p https://docs.python.org/3.7/distutils/setupscript.html#installing-additional-files 15:40:16 <felixfontein> dmsimard: don't worry, I won't shoot you ;) 15:40:31 * abadger1999 tries to scroll the agenda in bluejeans.... ;-) 15:40:45 <dmsimard> felixfontein: it looks like you would typically install to a relative path but it is possible to install to absolute paths 15:41:14 <alikins> dmsimard: yeah, in theory, collections can be installed via any mechanism that puts the files in the right place. Though handling deps would be responsibity of the other tool then. 15:41:48 <dmsimard> alikins: aye, we were discussing pip as a means to install a collection to take care of the python dependencies that might be required for the collection to work 15:41:55 <geerlingguy> It's all fun and games until someone brings up licensing 15:42:10 <bcoca> LOL 15:42:15 <dmsimard> licensing is hard 15:42:33 * geerlingguy has PTSD from being on Drupal's Licensing Working Group 15:43:15 <geerlingguy> nice. Immigrant song playing in room. 15:43:32 <bcoca> a law professor told me once, every lawyer's opinion is wrong .. unless he happens to be the judge in the case .. even then he can be appealed 15:43:40 <jimi|ansible> geerlingguy: I took care of it :) 15:43:52 <felixfontein> <- afk 15:43:58 <bcoca> <= afk2 15:44:06 <ptoal2> I can't hear this song without thinking of this: https://www.youtube.com/watch?v=TGUDM2LQ-3E 15:44:16 * resmo is afk 16:45:46 <gundalow> #endmeeting