15:03:09 <bcoca> #startmeeting ansible core public irc meeting 15:03:09 <zodbot> Meeting started Thu Mar 26 15:03:09 2020 UTC. 15:03:09 <zodbot> This meeting is logged and archived in a public location. 15:03:09 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:09 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting' 15:03:33 <bcoca> #open floor 15:03:42 <bcoca> #topic open floor 15:03:49 * bcoca has forgotten all the commands 15:04:08 <jtanner> one topic from me today 15:04:27 <jtanner> happy to announce Shrews will be switching over from zuul development to ansible-core development 15:04:36 <Shrews> ohai 15:04:49 <bcoca> gratz! 15:04:56 <bcoca> and condolences 15:05:16 <Shrews> lol 15:05:33 <relrod> \o/ 15:05:59 <cyberpear> o/ 15:07:09 <felixfontein> :) 15:07:23 <felixfontein> welcome Shrews! 15:07:32 <Shrews> ty ty 15:07:59 <shertel> \o/ 15:09:55 <bcoca> k, if nothing else, will close in 5 mins 15:10:03 <cyberpear> #idea make a minimal-sized collection to hold very useful module_utils and tests/filters, such as the `ipaddr` filter without having to depend on community.general 15:10:55 <felixfontein> you mean ansible.netcommons? 15:10:58 <felixfontein> or both? 15:11:52 <cyberpear> I guess the idea is to avoid duplicating the "very useful" stuff without having to bring in all of community.general into the dep chain 15:11:53 <felixfontein> right now ipaddr is in ansible.netcommons (next to module_utils/compat/ipaddress ;) ), and there are non-network usages of both 15:12:25 <cyberpear> but maybe netcommons is such a minimal collection? 15:12:32 <cyberpear> (I haven't actually looked at netcommons) 15:12:39 <felixfontein> it contains a lot of network specific stuff 15:12:54 <felixfontein> (i.e. for network modules) 15:13:22 <bcoca> cyberpear: w/o duplicating code .. really hard to create a 'subset collection' 15:13:35 <bcoca> we would need smaller collections to begin with and then 'meta collections' that include those 15:13:48 <bcoca> ^ which was one avenue we looked at .. but ended with community.general 15:16:32 <cyberpear> yeah, I think generally, smaller collections would be better, with 'community.general' being a superset that includes those others 15:16:57 <bcoca> but that is not under 'core' control, community team is handling those 15:17:27 <cyberpear> I also hate to see code live in multiple places, where fixes made in one place aren't automatically copied around to the others. 15:17:34 <bcoca> <= choir 15:17:35 <cyberpear> is there a community team meeting? 15:17:55 <cyberpear> or do those folks happen to be here now? 15:18:11 <bcoca> i beileve there is even new community channel 15:18:29 <bcoca> #ansible-community 15:18:55 <cyberpear> it's existed for a long time, but mostly for the "big community PR review days" 15:19:20 <bcoca> same team 15:20:56 <bcoca> they'll also be in charge of ACD: Ansible Community Distribution, while core team now is 'ansible-base' .. basically core engine + minimal set of plugins to do basic functions 15:22:47 <cyberpear> fair enough 15:23:17 <cyberpear> May I suggest holding "Ansible Community Public Meetings"? 15:24:03 <bcoca> yes, you may, probably @gundalow already has something in mind 15:24:16 <bcoca> but not something core team manages 15:24:48 * gundalow waves 15:24:50 <cyberpear> those of us who are not RH/ansible have no insight into the various teams/meetings/etc 15:25:19 <cyberpear> especially w/ all the collections changes 15:25:21 <bcoca> for those of us i RH/ansible .. not very diff 15:25:33 * bcoca forgot its now IBM/RH/Ansible 15:25:33 <gundalow> cyberpear: Thank your for making us accountable 15:25:43 <gundalow> I've been working on https://github.com/ansible-collections/overview/pull/33 today which is a status on Collections 15:26:12 <gundalow> I'm moving various proposals out of secret internal Google Docs and putting them in https://github.com/ansible-collections/overview/issues 15:26:24 <cyberpear> that's helpful 15:26:30 <gundalow> ie versioning and deprecation proposal https://github.com/ansible-collections/overview/issues/37 15:27:24 <gundalow> From this point forward the community team will be operating in GitHub for everything unless it business confidential, which should be very rare 15:27:43 <gundalow> cyberpear: I hope you will keep holding us accountable 15:27:48 <cyberpear> perhaps the wrong meeting, but for deprecations, I think it'd still be useful to (optionally) tie collection deprecations to the underlying ansible version 15:28:06 <cyberpear> I know there was discussion of doing it by date 15:28:10 <gundalow> cyberpear: feel free to add comments to #37 15:28:13 <bcoca> cyberpear: just found out that there is firm decition to do by date now 15:28:49 <felixfontein> I have a question for that, I asked it in #68177 15:29:13 <felixfontein> https://github.com/ansible/ansible/pull/68177#issuecomment-604488280 15:29:31 <gundalow> cyberpear: I generally talk about collection stuff in #ansible-devel 15:29:38 <cyberpear> especially for modules that existed and had a pre-announced ansible-version-based deprecation 15:29:43 <gundalow> Though when we have announcement stuff I'll pingit in more channels 15:29:58 <bcoca> felixfontein: also, distinguish between certified, ACD, ansible managed and 'completely 3rd party' collections 15:30:10 <felixfontein> cyberpear: pre-existing deprecations could be converted to dates by using an approximage 'one release every 6 months' ansible release cycle 15:30:17 <cyberpear> I watch for #startmeeting in all channels, but sometimes it's hard to keep up w/ the #ansible-devel chatter 15:30:22 <felixfontein> bcoca: yes... 15:30:26 <gundalow> It's contributor Summit at 11UTC on Sunday which will be taking place on IRC and video, so if you are around, that's a good place to be 15:30:44 <gundalow> ^ will be recorded (#startmeeting and video) 15:30:56 <felixfontein> video of whom? 15:31:12 <cyberpear> Sunday is very unfortunate, especially since we're all now remote 15:31:13 <felixfontein> everyone sitting at home in front of their computers? :) 15:31:16 <gundalow> felixfontein: video and audio for BlueJeans 15:31:22 <gundalow> yup 15:31:27 <cyberpear> (originally it was a good idea) 15:31:54 <felixfontein> cyberpear: there was a vote (on doodle), and sunday won 15:32:26 <gundalow> World has changed a bit 15:32:53 <cyberpear> what are the criteria for things being in ansible-base? 15:32:56 <bcoca> yep, dont know if i'll make it since i had already commited to family at that time 15:32:56 <cyberpear> has it been codified? 15:33:22 <gundalow> cyberpear: I'll find teh doc in a minute, though basically "not much chance for stuff to be added" 15:33:55 <felixfontein> I think everything the core team thinks is so essentialy that it should be there 15:33:55 <gundalow> cyberpear: https://github.com/ansible-collections/overview/blob/master/README.rst#q-what-exactly-is-ansible-base-for-and-what-will-it-contain 15:34:12 <bcoca> felixfontein: no, not just core team .. many teams invovled in that 15:34:20 <cyberpear> is the recommendation going forward for all roles to use `community.general.my_module` in `tasks/main.yml` or can you say "use community.general"? 15:34:44 <cyberpear> on a role-level? 15:34:48 <felixfontein> bcoca: core = this mysterious collections of people who make non-public decisions ;) 15:34:55 <bcoca> @cyberpear @geerlingguy is lobbying for actually making collections: inheritable by roles 15:35:21 <bcoca> felixfontein: core == people that implement decisions by a collection of people making them non/semi public 15:35:30 <cyberpear> I'd like to be able to say in my meta/main.yml (or similar) that I want to use unqualified names from XYZ.ABC collection 15:35:41 <cyberpear> but in the role, not in the playbook 15:35:44 <bcoca> cyberpear: i would like that too 15:35:49 <cyberpear> when I'd tried it out, it didn't seem to work that way 15:35:49 <bcoca> both should work imho 15:35:57 <felixfontein> bcoca: for people outside core / that other groups of people, there's no practical difference 15:36:00 <cyberpear> but maybe I was doing it wrong 15:36:03 <bcoca> collections: inheritable, but meta/main.yml:collecitons overrides 15:36:16 <bcoca> felixfontein: i understand that 15:36:41 <bcoca> felixfontein: just informing you that the 'core' you see here are not the ones making all the decisions 15:36:47 <cyberpear> Is there a way to say "whitelist all colleciotns in my COLLECITONS_PATH" so I can use everything unqualified? 15:37:03 <bcoca> cyberpear: no, but you are also not the first to ask for it 15:37:12 <bcoca> again @geerlingguy has issue open about that 15:37:45 <bcoca> right now there is no way to 'list all plugins' in all collections ( i hvae ansible-doc pr that just implements that) 15:37:47 <cyberpear> because it's going to be a pain to `ansible localhost -m community.general.my_module ...` every time 15:37:57 <bcoca> yes, yes it is 15:38:10 <cyberpear> much easier to keep the existing `ansible localhost -m my_module ...` 15:38:18 <bcoca> i would also advoctae for colleciotns to not be as redundant 15:38:30 <gundalow> cyberpear: well if you are using ACD for 2.10 then any module that was in devel before the migration you will be able to continue to use the short form 15:38:35 <cyberpear> (did we ever fix the `collections/ansible_collections` thing?) 15:38:55 <gundalow> cyberpear: fix what exactly? 15:38:56 <cyberpear> gundalow: yes, I know that existing modules have been "whitelisted" 15:39:02 <gundalow> cyberpear: cool 15:39:08 <bcoca> f5networks.f5_modules.f5_bigip_stuff ... vs f5.bigip.stuff 15:39:11 * gundalow has to drop off, though I'll review stuff later 15:39:25 <bcoca> cyberpear: no, also something i find annoying, we really shoudl only need 1 dir 15:39:40 <cyberpear> why is "collecitons" there twice, and why 2 directories deep? 15:40:09 <bcoca> design decision 15:40:22 * cyberpear needs to send PR to make ANSIBLE_COLLECTIONS_PATHS also work as ANSIBLE_COLLECTIONS_PATH like all the other PATH options 15:40:48 <cyberpear> ANSIBLE_PLUGINS_PATH, ANSIBLE_ROLES_PATH, etc 15:41:17 <bcoca> i also want to add option to allow 'appending' config optoins vs overwriting, make them all consistent 15:41:41 <felixfontein> sounds like lots of stuff to do for ansible 3.0 :) 15:41:41 <bcoca> .. PATH: /new:{{EXISTING}} 15:41:53 <bcoca> more like 23.5.4 15:42:39 <bcoca> actually need 2 .. PATH: /x:{{SELF}} and ..PATH: /x:{{DEFAULT}} 15:44:02 <bcoca> default is easy, self is harder since you need to recursively go down precedence until SELF is not in result 15:44:44 <cyberpear> if you use environment vars to do it, you can handle it just like system $PATH 15:44:59 <bcoca> cyberpear: but env vars are only ONE part of config 15:45:05 <cyberpear> right 15:45:16 <bcoca> vars > cli > env vars > .cfg file 15:45:20 <cyberpear> so I the sysadmin can set site-wide $ANSIBLE_COLLECTIONS_PATH, and the user can append/prepend in their own .bash_profile 15:45:45 <bcoca> yeah, but people keep asking to be able to do that from env var and still use .cfg file values 15:45:45 <cyberpear> I'm just saying that w/in the realm of env, you can do your own cascading 15:45:47 <bcoca> or cli 15:45:59 <cyberpear> I agree it'd be great to have the cascading config 15:46:28 <bcoca> yeah, poitned out the env stuff, but most dont want to deal wth that and just want 'appendable no matter the sources' 15:47:58 <cyberpear> (was annoying when RHEL was carrying a config patch for ROLES_PATH that didn't include anything in ~, so users would get errors when doing `ansible-galaxy install` because no writable path... thankfully they dropped that) 15:48:30 <bcoca> package managers are hard! 15:48:56 <cyberpear> (I think I don't have anything else for today.) 15:51:43 <bcoca> k, i'll end it at that then 15:51:48 <bcoca> #endmeeting