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