18:00:00 <felixfontein> #startmeeting Ansible Community Meeting
18:00:00 <zodbot> Meeting started Wed Aug 16 18:00:00 2023 UTC.
18:00:00 <zodbot> This meeting is logged and archived in a public location.
18:00:00 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:00 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:01 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/679
18:00:05 <felixfontein> Landrash[m], Leo[m], acozine, andersson007_, anwesha, ascherbaum, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, ompragash, oranod, resmo, russoz, samccann, thaumos, wbentley15[m], zbr: The Ansible community
18:00:11 <felixfontein> meeting is starting now!
18:00:13 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:00:17 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:00:22 <felixfontein> #topic Updates
18:00:36 <ansible_relay> 12samccann> o/
18:01:22 <felixfontein> hmm, I'm not sure whether it makes sense to chair matrix users
18:01:52 <ansible_relay> 12samccann> nah no worries
18:02:37 <cybette> o/
18:03:02 <felixfontein> #info There is a community vote on removing community.azure from Ansible 10: https://github.com/ansible-community/community-topics/discussions/264
18:03:12 <ansible_relay> 13mariolenz> o/
18:03:25 <ansible_relay> 02acozine> o/
18:03:29 <felixfontein> #info There is a community vote on removing hpe.nimble from Ansible 10: https://github.com/ansible-community/community-topics/discussions/265
18:03:47 <felixfontein> #info There is a community vote on removing ngine_io.exoscale from Ansible 10: https://github.com/ansible-community/community-topics/discussions/266
18:03:51 <felixfontein> #chair cybette
18:03:51 <zodbot> Current chairs: cybette felixfontein
18:04:58 <cybette> #info Ansible Community Day in Berlin, Sept 20, see more details (including CFP) here: https://ansible-community-day-berlin-2023.eventbrite.com/
18:05:49 <felixfontein> #info Ansible 8.3.0 has been released: https://groups.google.com/g/ansible-project/c/wzWrUh0sNJ4/
18:05:57 <ansible_relay> 02acozine> hooray!
18:06:13 <ansible_relay> 02Don Naro> hello hello
18:06:15 <ansible_relay> 02Don Naro> o/
18:06:31 <felixfontein> #info ansible-core 2.14.9 (https://groups.google.com/g/ansible-project/c/xHowm-mvWNs/) and 2.15.3 (https://groups.google.com/g/ansible-project/c/eVSj3uILbNo/) have been released as well
18:06:39 <felixfontein> hello matrix :)
18:06:57 <felixfontein> this looks *really* ugly with elements...
18:07:08 <cybette> yeah
18:07:10 <felixfontein> #chair oranod
18:07:10 <zodbot> Current chairs: cybette felixfontein oranod
18:07:21 <felixfontein> I'm glad my text mode matrix client only has one single font size ;)
18:08:21 <ansible_relay> 14Felix Fontein> Gwmngilfen: do you have access to the sources of the relay bot? escaping the `#` (with `\`) should make the output less ugly
18:08:38 <ansible_relay> 12samccann> yeah we used the matrix meeting bot this week for the DaWGs meeting
18:08:58 <ansible_relay> 12samccann> looked okay on both sides but at the moment can't use meeting commands from the IRC side
18:09:08 <felixfontein> I'd like to discuss https://github.com/ansible-community/community-topics/issues/251, https://github.com/ansible-community/community-topics/issues/245, and https://github.com/ansible-community/community-topics/issues/267 today. are there any other topics folks want to discuss?
18:10:57 <felixfontein> #topic Update Python requirements for collections included in Ansible
18:11:01 <felixfontein> #link https://github.com/ansible-community/community-topics/issues/251
18:11:17 <felixfontein> I created a concrete proposal for this: https://github.com/ansible/ansible-documentation/pull/281
18:11:38 <felixfontein> gotmax improved the formulation, but so far nobody else commented.
18:12:04 <felixfontein> the idea is to make the requirements on supported Python versions for collections included in Ansible (the community package) as version agnostic as possible, so we don't have to update it
18:12:53 <felixfontein> right now for example it tells collections to support Python 2.7 on the controller side if no libraries prevent it from doing that - which only makes sense if the collection still supports ansible-core versions that are EOL
18:13:15 <felixfontein> (which collections *can* of course do, but forcing them is not good IMO)
18:13:37 <ansible_relay> 12samccann> am I the only one who gets confused by 'controller' and thinks it means awx/Ansible Controller?
18:13:50 <ansible_relay> 12samccann> could we wordsmith to control node?
18:14:03 <ansible_relay> 04Leo> Hello o/ sorry the delay, fighting the my irc client, joinin in matrix instead
18:15:01 <ansible_relay> 10remindbot> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:04 <felixfontein> samccann: I'm not sure how long 'Ansible Controller' exists as a product, but controller has been used for the controller side of ansible-core for a looong time (basically as long as I can remember)
18:15:32 <ansible_relay> 12samccann> this is what I'm used to - https://docs.ansible.com/ansible/latest/getting_started/index.html
18:15:40 <ansible_relay> 12samccann> maybe cuz I only look at docs, it's control node there
18:15:45 <bcoca> controller is just rename of tower (aka awx)  when AAP product was created
18:15:52 <bcoca> ^ and yes, i complained about the overload of the term
18:16:24 <ansible_relay> 12samccann> yeah I may just be in my own docs-land void thinking we always called it control node
18:16:26 <bcoca> controller term in core predates 'Controller' product by 8yrs .. giver or take
18:17:14 <bcoca> Controler has had many names ... 'AnsibleWorX commander'  was first
18:17:19 <bcoca> ^ where awx comes from
18:17:45 <bcoca> not like 'ansible' has not been overloaded to death ...
18:17:52 <felixfontein> :)
18:18:10 <bcoca> </endrant>
18:18:21 <ansible_relay> 04Leo> I also used to refer to the control node as the one where we run the automation from, before controller/tower rebranding
18:18:24 <felixfontein> samccann: the term 'controller' is also used in docs land, though probably control node is more common
18:19:07 <felixfontein> in any case, I don't mind changing it to control node, but I think that should be done in a separate PR, since so far the whole document talks about 'controller' and not 'control node' in other places as well
18:19:10 <bcoca> funny cause Tower used to be the controller, but when they renamed to Controller it stoppped being the controller, it just pushed everything into an EE which is the actual controller
18:19:16 <ansible_relay> 04Leo> I would have like Ansible Commander better :)
18:19:25 <ansible_relay> 12samccann> hehe
18:19:34 <felixfontein> ha, in one case it even says "controller node" :D
18:19:36 <bcoca> ^ use caps to reffer to product, its how i keep a sliver of a shadow of the reflection of my sanity
18:19:58 <ansible_relay> 12samccann> ok I'll open a docs issues to change all controller to control node across the docs. That's always a good easfix issue that someone will grab and grep
18:20:01 <bcoca> felixfontein: cause awx/tower/controller can also be 'federated' into nodes ...
18:20:06 <ansible_relay> 04Leo> samccann: this is from another conversation, but this is what I meant for the caps discussion :D
18:20:26 <felixfontein> bcoca: oh the fun... :)
18:20:31 <bcoca> so controller node is not free of ambiguity
18:20:38 <bcoca> felixfontein: #dontgetmestarted
18:21:04 <felixfontein> anyway, back to the topic, is there anything else than 'controller' that you all have comments on? :)
18:21:15 * bcoca controlls himself
18:23:09 <felixfontein> and is it OK if we defer the (possible) 'controller' -> 'control node' change to some later point (the PR uses the same language as the unchanged part of the section it is in)?
18:23:46 <ansible_relay> 12samccann> yeah I'll open a separate wordsmith issue for the whole docset to make it consistent
18:24:03 <ansible_relay> 12samccann> as for the PR - looks pretty good to me.
18:24:39 <felixfontein> if everyone is happy I can start a vote after the meeting is done
18:26:27 * gotmax quickly pops in to say they agree with that plan
18:26:29 <bcoca> glwt, if you come up with something good, let me konw, i'll start using it and nagging others to do same
18:26:35 <felixfontein> if nobody disagrees I'll switch to another topic in a minute and will create the vote afterwards :)
18:26:38 <felixfontein> #chair gotmax
18:26:38 <zodbot> Current chairs: cybette felixfontein gotmax oranod
18:26:40 <ansible_relay> 02acozine> +1 for fixing all the `controller` to `control node` changes as a separate PR
18:26:45 <felixfontein> gotmax: thanks!
18:27:14 <ansible_relay> 02acozine> so we can merge the PR, then fix the wordsmithing
18:27:31 <felixfontein> #action felixfontein create vote on https://github.com/ansible/ansible-documentation/pull/281
18:27:51 <felixfontein> #topic Which/how many versions of ansible(-base|-core) should a (community) collection support? Proposal for community.general
18:27:55 <felixfontein> #link https://github.com/ansible-community/community-topics/issues/245
18:28:08 <felixfontein> #info Proposal for community.general: https://github.com/ansible-community/community-topics/issues/245#issuecomment-1601585504
18:29:01 <felixfontein> I created this discussion with a concrete proposal for community.general some time ago so that folks can comment what they think about it, and that we have an example that other collections can use as a recommendation if they're not sure what to support
18:29:30 <felixfontein> I didn't hear much feedback so far, so I want to bring this topic to your all attention again :)
18:30:01 <ansible_relay> 10remindbot> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:07 <felixfontein> right now many collections support all Ansible versions from 2.9 on, and many (like most of the ones I'm maintaining) are wondering when to drop support for older Ansible versions (also to simplify the CI matrix)
18:30:52 <ansible_relay> 12samccann> from the RH certified collection perspective, 2.9 is still a 'thing'. That might be why some collections cling to it
18:31:34 <felixfontein> true. but others simply still support it because dropping support is a breaking change from their POV, and they didn't yet have a new major release after 1.0.0
18:32:06 <felixfontein> (also even if collections still want to support 2.9, they might want to drop support for 2.10, 2.11, and other EOL versions)
18:32:09 <ansible_relay> 04Leo> Also, not only from the certified collection perspective, also AAP 1.2 is supported until september (unless there are changes), and includes Ansible 2.9
18:33:13 <ansible_relay> 12samccann> so in the general sense - I like the idea of suggesting when is a good time to drop EOL from a collection
18:33:19 <felixfontein> on the community side, Ansible 2.9 is EOL since end of May this year
18:33:30 <ansible_relay> 12samccann> the x.y(x+5) math is harder to parse on a quick read
18:33:35 <felixfontein> (also community.general already dropped Ansible 2.9 and ansible-base 2.10 support, I think last year?)
18:34:01 <ansible_relay> 12samccann> I think community 2.9 EOL'd a lot earlier than May... or I dropped it too fast from the docs :-)
18:34:11 <ansible_relay> 12samccann> it's been DEAD TO ME for ..feels like pushing a year
18:34:19 <ansible_relay> 04Leo> ansible-core 2.13 and 2..14 are included in maintenance releases as well. (AAP 2.2 and 2.3)
18:34:34 <felixfontein> ah, lol, May 2022, not May 2023 :D
18:34:39 <felixfontein> so a year and some months...
18:34:54 <felixfontein> (https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix has all the dates, it helps if you can read...)
18:36:06 <ansible_relay> 12samccann> sorry I feel like we digressed on the original topic
18:36:10 <felixfontein> Leo: effectively most content will probably also work with older ansible-core releases, but there is no guarantee (how much community can guarantee such things anyway :) )
18:36:20 <felixfontein> samccann: true ;)
18:36:53 <ansible_relay> 12samccann> I did get lost in the math - is the suggestion to drop EOL shortly after the EOL happens (for core)?
18:37:00 <felixfontein> the general idea of the proposal is that a major c.g release supports all ansible-core versions that were not EOL 1-2 weeks before the major release
18:37:13 <ansible_relay> 12samccann> ok cool
18:37:35 <felixfontein> to avoid that c.g X.0.0 drops support for ansible-core 2.x just because ansible-core 2.x was EOL'ed two days before c.g X.0.0 has been released
18:37:45 <ansible_relay> 04Leo> felixfontein: i agree,  just wanted to mention that there will be people interested in using those community collections even with downstream versions that upstream considers out of date, and that *might* make it worth it. to those mantainers or developers
18:38:31 <felixfontein> Leo: if someone actively asks to support a specific version (and helps with it if it involves work), I don't think a collection will say no to it
18:38:49 <ansible_relay> 12samccann> Leo: so the impact would be that user couldn't got to the most recent version of c.g, but could keep using the older version of c.g .. right?
18:39:17 <felixfontein> (at least if there isn't something specific the collection needs that the old version cannot provide)
18:39:45 <felixfontein> samccann: yes. (though in many cases the latest version might still work, or at least most of it)
18:40:02 <ansible_relay> 12samccann> I guess the gotcha would be for bugfixes. If there's a bug in c.g.NEW that gets fixed... would it also be fixed in c.g.OLD (assuming it applies)..
18:40:12 <ansible_relay> 12samccann> aka when goes c.g itself go EOL?
18:40:35 <felixfontein> in any case, I'm thinking of keeping this proposal there for another week, and start a vote next week if nobody has objections until then
18:40:52 <ansible_relay> 12samccann> sounds good to me
18:41:11 <felixfontein> samccann: right now c.g has three active major releases (the latest with new features, the previous with bugfixes, and the previous before that with security and major bugfixes)
18:41:44 <ansible_relay> 12samccann> cool. thanks
18:42:01 <felixfontein> (or even four, if you count the main branch as a forth one)
18:42:25 <felixfontein> which is similar to ansible-core, which also has four activley maintained branches that aren't EOL
18:42:56 <ansible_relay> 12samccann> so an 18 month lifecyle (ignoring main)
18:43:09 <felixfontein> yes
18:43:51 <ansible_relay> 12samccann> random question - if I wanted to just find the changelogs/porting instructions  for each version of c.g, where would I find it?
18:44:25 <ansible_relay> 12samccann> I know it's all part of Ansible porting guide... just wondering about those collection users who just take the collectoins they want vs the full package
18:45:01 <ansible_relay> 10remindbot> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:07 <felixfontein> samccann: in the CHANGELOG.rst file in the corresponding stable-x branch in the git repo (which is also inluded in the Galaxy tarball)
18:45:19 <felixfontein> (there is no explicit porting guide)
18:45:25 <ansible_relay> 04Leo> perfect, I was mostly thinking on avoiding a suggestion to drop versions being in maintenance on downstream if possible (the should vs must)
18:45:58 <ansible_relay> 02acozine> +1 for voting on the proposal
18:46:21 <ansible_relay> 04Leo> or maybe: just a warning about that difference in EOL might be enough
18:46:27 <ansible_relay> 12samccann> Felix Fontein: when galaxyNG becomes galaxy, it'll have docs support. So might be worth adding a link to the changelogs in the readme if it's not there already
18:46:37 <ansible_relay> 12samccann> but once again... i digress the conversation
18:47:07 <felixfontein> Leo: this is a concrete proposal for c.g, collections don't have to follow it
18:47:27 <felixfontein> samccann: it's already there :)
18:47:46 <felixfontein> #action felixfontein create a vote for https://github.com/ansible-community/community-topics/issues/245 next week if there has been no further feedback
18:47:55 <felixfontein> #undo
18:47:55 <zodbot> Removing item from minutes: ACTION by felixfontein at 18:47:46 : felixfontein create a vote for https://github.com/ansible-community/community-topics/issues/245 next week if there has been no further feedback
18:48:01 <felixfontein> #action felixfontein create a vote for https://github.com/ansible-community/community-topics/issues/245#issuecomment-1601585504 next week if there has been no further feedback
18:48:05 <felixfontein> sorry :)
18:48:15 <felixfontein> #topic Community EE
18:48:18 <felixfontein> #link https://github.com/ansible-community/community-topics/issues/267
18:48:34 <felixfontein> anwesha_ isn't around for this meeting, but she asked that we should take a look at this
18:49:21 <felixfontein> I'm not really sure why this thing is called "Community EE" though, my hope would be that someone from the Ansible community team can explain that :)
18:49:37 <oranod> naming things is hard?
18:49:41 <felixfontein> :D
18:49:42 <felixfontein> true
18:50:37 <felixfontein> (the EE contains some ansible.* collections, but no community collection)
18:50:52 <ansible_relay> 12samccann> I'm not directly involved but I think the notion is to try to get more understanding and use of EEs on the community side
18:51:08 <ansible_relay> 12samccann> So one question would be - where does it live (which is that topic)
18:51:56 <ansible_relay> 12samccann> but since my boss isn't here to tell me to hush up (not that he would) - my other nickel would be it's a valid discussion to say what collections should be in a 'community ee'
18:52:23 <felixfontein> I did try building an EE with all collections included in Ansible in the past, and that spectacularly failed due to conflicting dependencies... so that's kind of out of question
18:52:27 <ansible_relay> 12samccann> or really - what should our batch of communit yees be
18:52:43 <ansible_relay> 12samccann> yeah but is a c.g ee a worthwhile thing to have?
18:52:53 <ansible_relay> 12samccann> or c.g and some other handful of collections?
18:52:58 <felixfontein> just c.g is probably too little
18:53:01 <ansible_relay> 04Leo> afaik, it's a starting point, the idea is to have a basic EE for community use, and take it from there
18:53:21 <ansible_relay> 12samccann> Part of this is a learning exercise - what makes a good EE, how do we get more people using EEs cuz they seem like a Good Thing (tm)? etc
18:53:37 <felixfontein> Leo: that seems to imply that other EEs aren't a good starting point for community use
18:53:40 <oranod> universal community image?
18:54:16 <ansible_relay> 12samccann> I'm an EE neophyte but seems like there could be multiple useful ones
18:54:34 <ansible_relay> 12samccann> this first one was a 'hey.. ee's are a thing! help us make a batch of useful ones!'
18:55:09 <ansible_relay> 02acozine> from my own (minimal) EE experience, I'd say the most useful ones are the smallest and the most targeted
18:55:10 <felixfontein> samccann: definitely... but I'm not sure whether we should call the first one "community EE", as that name implies different things for everyone :)
18:55:31 <felixfontein> acozine: I agree (without really having used EEs so far)
18:55:40 <ansible_relay> 04Leo> felixfontein: do you have a couple of examples? the only i can think of are creator and downstream
18:55:43 <ansible_relay> 02acozine> I've worked on building "an EE for network stuff", for example
18:55:45 <ansible_relay> 12samccann> felixfontein: good feedback to be in that community topic - let's call it something esle
18:56:24 <ansible_relay> 12samccann> acozine: see that would be a helpful one too - a network-focused ee.
18:56:25 <felixfontein> Leo: not really, but there are UBIs and it's very easy to create an EE with your own set of collections in it
18:56:25 <ansible_relay> 04Leo> as in, pre built EEs. I think a lot of ansible users are not at the stage to create their own right now, and the idea is to provide something that covers the basics, to allow them to migrate to EE instead of ansible-playbook
18:57:13 <ansible_relay> 04Leo> once they get the hang of it, you can start trimming and customizing with builder
18:57:17 <felixfontein> Leo: almost all of my playbooks (even simple ones) need something from community.*, so an EE only containing ansible-core and other ansible.* collections wouldn't be very helpful for me
18:57:18 <ansible_relay> 02acozine> I think "dividing c.g into smaller collections" and "building minimalist, useful EEs" kind of go together
18:57:40 <felixfontein> acozine: +1
18:57:48 <felixfontein> (and it again comes with the maintenance issue :D )
18:57:49 <ansible_relay> 02acozine> c.g is still large and has no real theme
18:57:54 <ansible_relay> 02acozine> yeah
18:57:58 <ansible_relay> 04Leo> the current selection afaik, is to have something working, I don't want to speak for the team working on it, but the idea afaik, is to take this to the community to see which collections would be useful
18:58:06 <ansible_relay> 07dmsimard> https://github.com/ansible-community/images/tree/main/execution-environments was a thing but it never really took off
18:58:23 <ansible_relay> 13mariolenz> I wouldn't call it "community EE2 because this somehow implies that it's an EE for the community package altough it isn't. Maybe community-base or community-example or something?
18:58:27 <ansible_relay> 12samccann> Felix Fontein: also very valid feedback on that topic. Seems if people see no use in this 'community ee' then we go back and create a different one. Maybe we should start with acozine network EE
18:58:41 <ansible_relay> 04Leo> i like acozine idea of multiple minimal community EEs as well.
18:59:25 <ansible_relay> 12samccann> what would a communit_network_minimal ee look like for example?
19:00:01 <ansible_relay> 04Leo> samccann: the collection selection on the community one could be discussed, i don't think a general EE is a bad idea, even if we have specialist ones
19:00:58 <felixfontein> we probably need some statistics on which collections are used how often in playbooks
19:01:04 <felixfontein> (and which combinations of collections)
19:01:28 <felixfontein> having such information would probably directly yield some EEs
19:01:58 <ansible_relay> 04Leo> we have some data on the top 10 galaxy downloaded for ex.
19:02:02 <ansible_relay> 12samccann> random ee question - if I'm using 'community_ee' of some variety, does that mean i'm NOT using the Ansible package?
19:02:07 <ansible_relay> 02acozine> I don't have my list of collections (the ones I was putting on my network EE), but I think the EE had a specific core version plus `ansible.netcommon` and a hardware-specific collection
19:02:39 <ansible_relay> 02acozine> samccann: you could put the Ansible package into an EE
19:02:42 <ansible_relay> 12samccann> Leo: are galaxy downloads accurate? I thought it was possibly biased by potential CI infrustructure downloading select collections for test
19:02:50 <ansible_relay> 02acozine> it would make it  . . . not minimal
19:03:02 <ansible_relay> 04Leo> quite biased samccann , but it's something
19:03:28 <ansible_relay> 04Leo> kind of matches "common" use if you look at it
19:03:35 <ansible_relay> 02acozine> the other strength of EEs is you can put other tools into them, like python packages and yum/apt packages
19:03:37 <ansible_relay> 12samccann> We also can look at doc statistics if folks think that's worthwhile... which collections get the most docs visits etc
19:04:05 <ansible_relay> 04Leo> this, was it fortinet the huge one? there was a network collection that was quite big. and if you are not using that vendor, you get the whole package
19:04:08 <ansible_relay> 02acozine> so it's not just core and collections, you can really tailor the toolset for the job at hand
19:04:41 <ansible_relay> 04Leo> but we are probably digressing a bit, the idea is to have a starting point
19:04:43 <felixfontein> samccann: I think Galaxy download stats aren't really helpful
19:04:48 <ansible_relay> 12samccann> well do folks think we could come up with a better 'first ee' to offer community than the one anwesha created?
19:04:48 <ansible_relay> 02acozine> Leo: that comment was in response to the idea of putting the Ansible package into an EE, not in response to the network one
19:05:10 <felixfontein> Leo: the fortinet colleciton is REALLY big
19:05:17 <felixfontein> (or one of them, I think there are multiple ones)
19:05:35 <ansible_relay> 02acozine> sorry, folks, i have to run
19:05:39 <ansible_relay> 02acozine> great to see y'all!
19:06:05 <felixfontein> bye acozine!
19:06:08 <ansible_relay> 12samccann> we're a bit beyond time. Other than putting feedback directly in https://github.com/ansible-community/community-topics/issues/267
19:06:11 <felixfontein> oh, it's already over an hour...
19:06:18 <felixfontein> thanks everyone!
19:06:25 <felixfontein> I hope nobody had another topic :)
19:06:28 <ansible_relay> 12samccann> what would be next steps? Do we open a topic to design our first community-provided EE?
19:06:28 <felixfontein> #endmeeting