18:00:21 <dmsimard> #startmeeting Ansible Community Meeting 18:00:21 <zodbot> Meeting started Wed Jul 21 18:00:21 2021 UTC. 18:00:21 <zodbot> This meeting is logged and archived in a public location. 18:00:21 <zodbot> The chair is dmsimard. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:21 <zodbot> The meeting name has been set to 'ansible_community_meeting' 18:00:25 <andersson007_> o/ 18:00:26 <dmsimard> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics 18:00:35 * dericcrago waves 18:00:45 <dmsimard> abadger1999 acozine andersson007_ baptistemm bcoca briantist cidrblock cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow ikhan_ misc nitzmahone resmo samccann tadeboro thaumos zbr: ping! 18:00:54 <tadeboro> o/ 18:01:00 <gundalow> o/ 18:01:00 <acozine> o/ 18:01:03 <cidrblock[m]> howdy! 18:01:09 <abadger1999> Bom día 18:01:25 <dmsimard> #chair andersson007_ dericcrago jillr tadeboro gundalow acozine abadger1999 cidrblock[m] 18:01:25 <zodbot> Current chairs: abadger1999 acozine andersson007_ cidrblock[m] dericcrago dmsimard gundalow jillr tadeboro 18:01:31 <dmsimard> hello everyone 18:01:35 <jtanner> lurking 18:01:51 <dmsimard> jtanner: you're welcome :) 18:02:00 <samccann> not really here today.. meeting overlap 18:02:08 <jillr> hola jtanner 18:02:12 <jtanner> hello 18:02:20 <dmsimard> #topic Updates 18:02:27 <dmsimard> Any updates before we move on to topics ? 18:02:40 <abadger1999> ansible-4.3.0 is out 18:02:58 <dmsimard> #info ansible 4.3.0 has been released to pypi 18:03:13 <gundalow> Nothing else from me 18:04:06 <dmsimard> #info community.rabbitmq looking for new maintainers: https://github.com/ansible-collections/community.rabbitmq/issues/81 18:04:19 * cyberpear arrives late 18:04:20 <dmsimard> #info community.libvirt looking for new maintainers: https://github.com/ansible-collections/community.libvirt/issues/78 18:04:25 <dmsimard> #chair cyberpear 18:04:25 <zodbot> Current chairs: abadger1999 acozine andersson007_ cidrblock[m] cyberpear dericcrago dmsimard gundalow jillr tadeboro 18:04:33 <andersson007_> dmsimard: thanks for mentioning 18:05:21 <dmsimard> tadeboro: shall we discuss inclusion candidates ? 18:05:47 <tadeboro> I am not sure if there is anything to discuss since not much is happening. 18:06:00 <dmsimard> ok, we can go over it briefly 18:06:03 <dmsimard> #topic Incusion candidates for Ansible 5 https://github.com/ansible-community/community-topics/issues/32 18:06:38 <andersson007_> tadeboro: thanks for the summary-issue! 18:06:42 <gundalow> Thank you tadeboro for the reviews and creating the summary 18:06:52 <dmsimard> yeah andersson007_ beat me to it, thank you for the reviews and the summary 18:07:22 <jillr> tadeboro: do you want to discuss vmware_rest? 18:08:00 <gundalow> jillr: could be good 18:08:15 <gundalow> do we need to get `cloud.common` added to the list (since vmware_rest depends on it) 18:08:25 <jillr> yeah we do, that's my fault 18:08:34 <gundalow> nps, easy to miss 18:08:39 <gundalow> I'll add it to #32 18:08:42 <jillr> ty 18:08:47 <tadeboro> jillr: Python compatibility I guess? I am just writing a reply to your comment in PR 230. 18:08:49 <gundalow> and we can update that once the request has been added 18:08:54 <jillr> tadeboro: yes 18:09:41 <dmsimard> there are other collections that only support python3 due to dependencies that they need 18:09:49 <jillr> tldr for everyone else; the vmware_rest collection does not support py2.7 18:09:53 <andersson007_> i believe we should close the discussions related to silent unresponsive things like inflobox and equinix not to distract ourselves and other possible reviewers. 18:10:21 <andersson007_> they should be intrested 18:10:29 <tadeboro> To be honest here, it feels like "cheating" when someone says we need aiohttp and thus we need Python 3 since there are other http libraries available (one directly in ansible itself). 18:10:53 <gundalow> andersson007_: I'll strikethrough them 18:10:55 <dmsimard> andersson007_: maybe there should be a duration after which we close it due to lack of response or motivation 18:11:05 <jillr> this decision was made long before the collection inclusion criteria 18:11:20 <jillr> and we needed aiohttp for performance reasons 18:11:48 <andersson007_> gundalow: would be nice. once they decide to finish their works, we could continue 18:11:56 <tadeboro> jillr: This changes things. This is the reason I was after. Some real WHY behind the aiohttp ;) 18:12:06 <abadger1999> tadeboro: it is true that when things are a part of ansible-core, we were saying that the reception shouldn't be used as a convenient excuse 18:12:14 <jillr> 6 of the 7 included cloud collections managed by us are 3-only, when we discussed this while designing the guidelines I dont recall us saying we would question design choices 18:12:25 <abadger1999> *the exception 18:12:30 <andersson007_> dmsimard: yes, probably it should be, though in those particular cases... 18:12:31 <jillr> tadeboro: ok we can add a why :) 18:12:37 <jillr> or, more of a why 18:13:09 <jillr> I'll ask akasurde to update the PR :) 18:13:14 <abadger1999> Jillr: the wording I'm referring to might have made it in to our criteria... Let me check 18:13:28 <tadeboro> If the design was done before the inclusion criteria were in place, you have a valid case and I will give it a checkmark. But I had a feeling that vmware collection was younger than that ;) 18:13:40 <andersson007_> dmsimard: i mean they have been hanging long enough 18:13:46 <jillr> we made this one last year, we just didn't get it included before this 18:13:49 <tadeboro> The wording is pretty strong: In the controller environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v3.5 if all required libraries support this version. 18:14:22 <jillr> aiohttp is required until core ansible can give us better connection reuse/async because the vmware API is... not good on this 18:14:23 <cyberpear> vmware_rest collection has been around since the original 2.10 split, hasn't it? (but never part of ansible itself) 18:14:33 <jillr> cyberpear: yeah 18:14:42 <abadger1999> jillr: looks like that wording did not make it into the criteria 18:14:50 <tadeboro> And I had a problem with a aiohttp as an excuse because I assumed people were aware of the crtiteria for inclusion at the design stage. 18:15:02 <jillr> this collection is almost unusable with base ansible 18:15:03 <jtanner> akasurde wrote vmware_rest a long time ago 18:15:12 <cyberpear> jillr: does this improve vmware_tools connection plugin performance? -- it's useful, but dreadfully slow 18:15:32 <gundalow> tadeboro: given the above, are you happy with aiohttp (performance, existed before criteria/split) 18:15:39 <jtanner> vmware tools uses the soap api 18:16:03 <jillr> cyberpear: this is all new that uses the REST API only in vSphere ... oh gosh... 6.7? and later (please don't quote me on that version number) 18:16:18 <tadeboro> gundalow: Yes. I just wanted a serious justification for it. 18:16:19 <jillr> http conn setup is still fairly dreadful though :( 18:16:23 * acozine changing seating . . . I might disconnect briefly 18:16:27 <gundalow> tadeboro: yup, likewise 18:16:38 <dmsimard> tadeboro: appreciate you being on the lookout 18:16:55 <gundalow> What other outstanding discussions are there for vmware? 18:17:02 <tadeboro> And to be fair, I was nagging a bit more so that other people cannot say that Red Hat's stuff has an easier time getting into Ansible. 18:17:03 <abadger1999> tadeboro: I think even if the guideline was new, it should still block a non-compliant collection. 18:17:35 <abadger1999> (But I don't see a conflict here, with the loose way we've written the python compat guideline) 18:18:20 <jillr> and we'll update the readme now that we know what's needed 18:18:24 <gundalow> Thanks 18:18:26 <jillr> np 18:18:32 <dmsimard> FWIW maintaining py2.7 will be increasingly harder as time goes on so we may want to reconsider the strong wording in the not-too-distant future, it's a significant maintenance burden 18:18:45 <jillr> dmsimard++ 18:18:45 <zodbot> jillr: Karma for dmsimard changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:19:32 <jtanner> https://github.com/ansible-collections/community.vmware/blob/main/plugins/connection/vmware_tools.py not sure if there's a new one somewhere else, but this is def using pyvmomi which is soap based 18:20:11 <dmsimard> Looking briefly into the other inclusion applications, there is community.dns and comunity.ciscosmb that appear almost good to go 18:21:25 <tadeboro> dmsimard: Do note that those are only my reviews and I am far from perfect, so yeah ;) 18:21:52 <tadeboro> But all in all, I think current submissions are in better shape compared to the last batch. 18:22:14 <dmsimard> indeed, if anyone has time to review as well, that'd be great -- I will try to do my part as well 18:22:47 <tadeboro> vmware_ret collection is also almost there - once the cloud.common is added or if that dependency is dropped like it was from the kubernetes collection 18:23:07 <andersson007_> i was thinking of reviewing seeing tadeboro 's activity there 18:23:14 <andersson007_> will try to make time soon 18:23:19 <dmsimard> andersson007_++ 18:24:39 <dmsimard> Looking at topics (https://github.com/ansible-community/community-topics/issues), I think they have been discussed in past meetings -- is there any particular topic someone would like to talk about ? 18:24:49 <andersson007_> btw, should we develop exclusion criteria and engrave the procedure somewhere? (to motivate individuals / companies to look after their stuff shipped with Ansible) 18:25:30 <andersson007_> i people find it interesting I could create a topic 18:25:41 <andersson007_> s/i/if/g 18:26:07 <dmsimard> andersson007_: I suppose the exclusion criteria is if the inclusion criteria is not maintained but there can be more to it than that, worth a discussion inclusive of the steering committee 18:26:43 <andersson007_> dmsimard: yeah, it can be more 18:26:55 <andersson007_> and we don't have the procedure 18:27:22 <andersson007_> terms, etc 18:27:34 * dmsimard nods 18:27:44 <abadger1999> Yeah, we need to have that at some point. 18:28:09 <acozine> yes, preferably before we need to use i 18:28:11 <acozine> it 18:28:16 <andersson007_> if we don't want to have Ansible pulling a bunch of unmaintained stuff 18:28:30 <andersson007_> broken 18:28:31 <tadeboro> andersson007_: DO you have a reason for asking this? Is there something that is not properly maintained? 18:28:37 <abadger1999> At the latest, the first time it comes up to the committee, we should write down what reasons we are deciding to remove or block a collection and be sure to apply it to other collcetions as well. 18:29:11 <tadeboro> andersson007_: Or just a as preventive measure so that things are in place once we need them. 18:29:19 <andersson007_> tadeboro: no, i don't have a reason 18:29:27 <andersson007_> preventive measure 18:29:36 <andersson007_> exactly 18:30:28 <dmsimard> cyb-clock says we're 30 minutes into the meeting and still looking for the next topic 18:30:42 <andersson007_> tadeboro: this came to mind when we were talking about equinix, etc 18:30:49 <abadger1999> Cool. It probably needs someone to propose a few rules and then we can vote on those and then people will fee free to propose more rules 18:31:00 <abadger1999> *feel free 18:31:24 <andersson007_> I'll create the topic (or if anyone personally wants, feel free) 18:32:06 <abadger1999> Thanks :-) 18:32:41 <dmsimard> If there are no other burning topics or issues, that's cool too and we can move to open floor 18:32:53 <abadger1999> Slightly tangential to the review topic:If anyone is interested in helping out but from a programming rather than review perspective, I have a dep-closure script for collections that needs to be integrated into the build process for ansible. 18:33:24 <abadger1999> You can ping me here if you want to work on it: https://github.com/ansible-community/antsibull/pull/270 18:33:25 <github-linkbot> https://github.com/ansible-community/antsibull/pull/270 | open, created 2021-03-30T19:44:55Z by abadger: [WIP] Add a Dep closure script. 18:33:28 <dmsimard> abadger1999: to determine whether all the required dependencies are included ? 18:33:41 <abadger1999> Yeah. Meaning collections depending on other collections. 18:33:57 <dmsimard> neat 18:34:09 <tadeboro> So that you do not need angry tadeboro yelling at people that cloud.common is not there yet ;) 18:35:09 <jillr> I opened the request! 18:35:17 <dmsimard> jillr: thanks :) 18:35:24 <dmsimard> #topic open floor 18:35:26 <jillr> I owe tadeboro cookies 18:36:31 <cidrblock[m]> One thing to discuss....... I got pinged by the author of the DNAC collection, they have been contracted to write a Cisco ISE collection 18:37:17 <cidrblock[m]> one issue identified with the DNAC collection was the use of the inventory to contain username/password etc vs. providing it to each task 18:38:09 <cidrblock[m]> If the suggestion to them is to write a new connection, simply for the purpose of documentation and storing credentials, do we think this will get pushback? 18:38:47 <cidrblock[m]> The credentials can be pulled from the connection from an action and used within it......... The connection here will never actually be used as a connection 18:39:24 <dmsimard> cidrblock[m]: could it use the new module defaults feature to pass credentials to each task automatically ? 18:39:32 * cidrblock[m] looks for some sample code brb 18:39:39 <jtanner> pushback on what? 18:40:03 <cidrblock[m]> dmsimard: the action group defaults stuff? 18:40:32 <cidrblock[m]> what I don't like about that is the credential are not specific to the host in play 18:40:38 <cidrblock[m]> * what I don't like about that is the credentials are not specific to the host in play 18:40:55 <tadeboro> jtanner: https://github.com/ansible-collections/ansible-inclusion/discussions/20#discussioncomment-555000 is where things started. 18:40:59 <cidrblock[m]> pushback on a connection that will never be used as a connection 18:41:29 <cidrblock[m]> sample: https://github.com/cidrblock/conn_shim_action_validation/blob/main/collections/ansible_collections/cidrblock/conn_test/plugins/connection/demo.py 18:41:44 <jtanner> yeah, but nobody comments on the structure/code of a collection unless it's being considered for inclusion right? 18:42:08 <jtanner> or it violates an ansible-lint/molecule rule 18:42:17 <cidrblock[m]> I wanted to get ahead of this one since the target is inclusion 18:42:44 <jtanner> okay, i would ask who gets the ball when the DNAC author's contract is over 18:42:48 <cidrblock[m]> example pulling the credentials from the connection into an action: https://github.com/cidrblock/conn_shim_action_validation/blob/main/collections/ansible_collections/cidrblock/conn_test/plugins/action/add.py#L41 18:42:51 <dmsimard> cidrblock[m]: https://docs.ansible.com/ansible/latest/user_guide/playbooks_module_defaults.html is what I had in mind, I can't find it right now but there is a relatively recent addition that allows collections to declare their own generic namespace (like 'aws', 'openstack') 18:43:11 <cidrblock[m]> @jtan 18:43:30 <cidrblock[m]> * @jtanner Cisco dev net & community, but I will confirm and report back 18:44:20 * jtanner feels inspired by infoblox 18:44:45 <cidrblock[m]> dmsimard: that's cool if the user doesn't need to use the same module with different credentials for multiple hosts in play 18:45:29 <abadger1999> Heh, comment-555000 seems to point at a different issue that would need to be resolved. 18:45:29 <bcoca> dmsimard: been suggesting that for a while now, have a 'declare var struct name' and then have collections/modules/plugins subscribe to it 18:45:31 <jillr> dmsimard: we've had module_defaults/action groups for a while, do you mean this fix? https://github.com/ansible/ansible/pull/75284 18:45:32 <github-linkbot> https://github.com/ansible/ansible/pull/75284 | closed, created 2021-07-19T14:51:00Z by s-hertel: Fix resolution of action/module names in module_defaults [affects_2.12,bug,core_review,support:community,support:core] 18:45:53 <gundalow> jillr: Thanks for inclusion request. I've added to https://github.com/ansible-community/community-topics/issues/32 18:45:59 <jillr> gundalow: ta 18:46:00 <cidrblock[m]> unless there isn't any glaring issues with that approach, I'll suggest a connection shim, or the persistent connection framework for the ISe collection 18:46:01 <cidrblock[m]> * unless there isn't any glaring issues with that approach, I'll suggest a connection shim, or the persistent connection framework for the ISE collection 18:46:22 <jtanner> cidrblock[m]: i personally don't see why it matters if nobody will ever use the plugin [in any form] ... "usefulness" was never part of the inclusion criteria afaik 18:46:31 * bcoca needs to fix 'persistent' and 'forced_local' connection paths 18:46:53 <dmsimard> jillr: nope, and now I need to go and search for it :p 18:46:53 <bcoca> jtanner: it used to be in core .. looong time ago ... 18:47:10 <jtanner> or course, but that was like a millennia ago 18:47:21 <tadeboro> I would advocate for the actual persistent connection since this allows reusing http session for example. 18:47:27 <bcoca> back when i had a boss with your same name! 18:47:35 <jtanner> sounds like a jerk 18:47:38 <dmsimard> jillr: https://github.com/ansible/ansible/pull/74039 is the one 18:47:39 <github-linkbot> https://github.com/ansible/ansible/pull/74039 | closed, created 2021-03-25T22:03:47Z by s-hertel: add action_groups support to collections [affects_2.11,core_review,docs,docsite,feature,has_issue,new_plugin,runtime,stale_ci,support:community,support:core,test] 18:47:42 <bcoca> had his moments 18:47:55 <jillr> dmsimard: ah gotcha 18:48:01 <cidrblock[m]> tadeboro: agree, there is a little more work to be done there to serialize everything across the socket, but agree 18:48:03 <bcoca> % dmsimard that also has a follow up with fix 18:48:18 <dmsimard> I thought that had merged a longer time ago, turns out it was just last week 18:48:29 <bcoca> dmsimard: its been worked on for a looong time 18:48:45 <bcoca> we even had previous incarnation in 2.10 almost merged 18:49:11 <cidrblock[m]> thx for letting me take the time to bring that one up 18:49:38 <dmsimard> cidrblock[m]: that last PR I linked was what I meant to link to btw 18:49:53 <dmsimard> I guess it's not usable yet since it merged just recently 18:50:00 <bcoca> for 2.12 18:50:04 <dmsimard> yup. 18:50:15 <cidrblock[m]> dmsimard: the collection action group def stuff? Yeah cool, but not host specific 18:50:18 <bcoca> so in a few months or for the YOLO crowd that usess devel in prod 18:50:38 <dmsimard> cidrblock[m]: I wasn't aware of the host-specific nature of the need before you brought it up, got it now :p 18:50:39 <bcoca> cidrblock[m]: use hostvars 18:50:55 <cidrblock[m]> bcoca: 18:51:23 <cidrblock[m]> * bcoca: hostvars for module defaults? 18:51:53 <cidrblock[m]> * bcoca: hostvars for module defaults? (didn't know module defaults could be host specific in hostvars) 18:52:12 <tadeboro> bcoca: And what is the opposite of the YOLO crowd? I need to know what my "I am stuck with 2.9 until Red Hat does not kill it" tribe is called ;) 18:52:30 <cidrblock[m]> or do you mean module default: {{ some hostvar }} 18:52:34 <bcoca> cidrblock[m]: assign hostvar to module default, then you get host specific defaults 18:52:41 <gundalow> 8 minutes left 18:52:56 <bcoca> tadeboro: 'enteprise' 18:53:17 <cidrblock[m]> bcoca: good idea, will mess w/ that 18:53:28 <dmsimard> Only thing I might have for open floor is just a FYI: fedora and centos have been somewhat stuck on ansible 2.9 due to the changes in packaging. There is now ansible-core 2.11.x package in fedora rawhide and we'd like to bump the ansible package to 4.x (or soon 5.x), details remain to be determined as to how the packaging will work out -- whether 18:53:28 <dmsimard> collections will be individually packaged and things like that. More on that in not-too-distant future 18:54:03 <gundalow> worth a `#info`? 18:54:17 <dmsimard> sure 18:55:07 <tadeboro> I found your yesterday (I think) that ansible-core-2.11 is called ansible-base-2.11 in Gentoo ... Packaging is fun. 18:55:16 <tadeboro> *out 18:55:19 <dmsimard> #info fedora and centos have been somewhat stuck on ansible 2.9 due to the changes in packaging. There's now an ansible-core 2.11.x package in fedora rawhide and we'd like to bump the ansible package to 4.x (or soon 5.x), details remain to be determined as to how the packaging will work out -- whether collections will be individually packaged and 18:55:19 <dmsimard> things like that. 18:55:28 <dmsimard> grr irc character limit 18:55:29 <dmsimard> #undo 18:55:29 <zodbot> Removing item from minutes: INFO by dmsimard at 18:55:19 : fedora and centos have been somewhat stuck on ansible 2.9 due to the changes in packaging. There's now an ansible-core 2.11.x package in fedora rawhide and we'd like to bump the ansible package to 4.x (or soon 5.x), details remain to be determined as to how the packaging will work out -- whether collections will be individually packaged and 18:55:37 <dmsimard> #info fedora and centos have been somewhat stuck on ansible 2.9 due to the changes in packaging. There's now an ansible-core 2.11.x package in fedora rawhide and we'd like to bump the ansible package to 4.x (or soon 5.x), details remain to be determined as to how the packaging will work out. 18:56:18 <dmsimard> tadeboro: I don't run gentoo, should we reach out to tell them ? 18:56:50 <dmsimard> https://packages.gentoo.org/packages/app-admin/ansible-base right ? 18:57:13 <tadeboro> dmsimard: They know that since they handle that rename in the ebuild. So this does not seem like a mistake but a deliberate choice. 18:57:13 <bcoca> its a simple rename of the ebuild 18:57:34 <bcoca> ^ what iwas going to say, they have abstained from renames in past 18:57:39 <dmsimard> turns out I've collaborated with one of the maintainers before, I can ask even if just out of personal curiosity :) 18:58:20 <abadger1999> cidrblock[m]: Having read the comments on the DNAC review now... I don't think I know enough about httpapi and networking plugins to know whether your approach is correct or not. I do think that it's better than using inventory (since it looks like the code all runs locally). But maybe a networking team person should say whether making the httpapi plugin just a holder of information is correct or should be done 18:58:20 <abadger1999> differently. 18:59:01 <cidrblock[m]> abadger1999: no use of the httpapi plugin here, just NetworkConnectionBase 18:59:35 <cidrblock[m]> * abadger1999: no use of the httpapi needed in the case of a new persistent connection plugin, just NetworkConnectionBase 18:59:53 <tadeboro> abadger1999: httpapi is only really an option if you interact with the web API directly. If you use python library, httpapi cannot help much. 19:00:21 <abadger1999> tadeboro: ah. so they're competing at the same level of abstraction? 19:01:02 <cidrblock[m]> but the python package can be loaded and used in a persistent connection, so it's connection will be sustained on the other side of the socket path 19:01:20 <tadeboro> abadger1999: Yes. This is why I suggested custom persistent connection. 19:02:22 <abadger1999> tadeboro: <nod> That SOUNDS LIKE IT'S MORE IN LINE WITH ANSIBLE'S STRUCTURE. 19:02:28 <abadger1999> Sorry, capslock got me 19:02:53 <tadeboro> I need to run. Thank you all and have a great <suitable part of the day>. 19:03:01 <cidrblock[m]> abadger1999: and if all that is needed is a credential store, a connection can be used for the sake of documenting it, without ever using it as a "connection" 19:03:07 <cidrblock[m]> tadeboro: 19:03:08 <gundalow> tadeboro: Thank you as always 19:03:08 <cidrblock[m]> * tadeboro:cu 19:03:08 <jillr> cya tadeboro o/ 19:03:14 <tadeboro> #unchair tadeboro 19:03:15 <zodbot> Current chairs: abadger1999 acozine andersson007_ cidrblock[m] cyberpear dericcrago dmsimard gundalow jillr 19:03:30 <dmsimard> I'm going to wrap up the open floor here, you can continue chatting after :) 19:03:34 <cidrblock[m]> crap, gotta run too, tty all later 19:03:35 <dmsimard> #endmeeting