18:00:12 <felixfontein> #startmeeting Ansible Community Meeting
18:00:12 <zodbot> Meeting started Wed Sep 16 18:00:12 2020 UTC.
18:00:12 <zodbot> This meeting is logged and archived in a public location.
18:00:12 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:12 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:36 <abadger1999> Hello :-)
18:00:50 <andersson007_> hi
18:00:55 <felixfontein> abadger1999: gundalow: samccann: andersson007_: cyberpear: geerlingguy: ping
18:01:00 <felixfontein> #chair abadger1999 andersson007_
18:01:00 <zodbot> Current chairs: abadger1999 andersson007_ felixfontein
18:01:00 <gundalow> Hi all
18:01:05 <felixfontein> hi abadger1999 and andersson007_ and gundalow!
18:01:07 <felixfontein> #chair gundalow
18:01:07 <zodbot> Current chairs: abadger1999 andersson007_ felixfontein gundalow
18:01:37 <felixfontein> #topic agenda https://github.com/ansible/community/issues/539#issuecomment-693350676
18:02:37 <felixfontein> aminvakil wanted to be back for the meeting, no idea if anyone else is around
18:03:29 <felixfontein> #chair aminvakil
18:03:29 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ felixfontein gundalow
18:03:32 <felixfontein> and there he is :)
18:03:51 <aminvakil> hi again
18:03:56 <gundalow> Welcome :)
18:04:00 <felixfontein> about today: I guess we cna start with some updates, and then talk about moving content between collections after 2.10. or is there anything else that people want to discuss today?
18:04:25 <abadger1999> Not from me
18:04:43 <felixfontein> #topic updates
18:04:48 <gundalow> sounds good
18:04:52 <felixfontein> abadger1999: do you want to summarize the latest 2.10.0 updates?
18:05:00 <felixfontein> (or should I?)
18:05:03 <tadeboro> I am here, but I am not sure how much smartness is left in me after attending a school meeting for the last hour and a half.
18:05:05 <gundalow> with #info
18:06:10 <felixfontein> #chair tadeboro
18:06:10 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ felixfontein gundalow tadeboro
18:06:10 <andersson007_> #chair tadeboro
18:06:10 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ felixfontein gundalow tadeboro
18:06:16 <felixfontein> jinx :)
18:06:17 <andersson007_> ops
18:06:22 <abadger1999> We have 2.10.0rc1
18:06:26 <abadger1999> :-)
18:06:44 <tadeboro> I guess I have 8 legs now? ;)
18:06:48 <abadger1999> Unless a blocker comes up, that's what will ship as final next week
18:07:04 <felixfontein> tadeboro: then you're a long couch, and no longer a chair :P
18:07:30 <felixfontein> #info 2.10.0rc1 has been released, and if no blocker comes up, the final 2.10.0 release will be next week
18:07:46 <abadger1999> The docs testing website has the latest version with redirects in place.  We'll want to get that up to production near release as well
18:08:26 <abadger1999> Basically, we're on track to release next week :-)
18:08:26 <felixfontein> #info The docs testing website has the latest version with redirects in place: http://docs.testing.ansible.com/ansible/2.10/collections/index.html test the redirects between 2.9 and 2.10 (you have to edit the URL manually)
18:08:48 <felixfontein> let's cross fingers that no nasty surprises come up!
18:08:57 <felixfontein> has there been any feedback about 2.10.0rc1 yet?
18:09:00 * abadger1999 knocks on wood ;-)
18:09:06 <abadger1999> I have heard nothing about it.
18:09:23 <abadger1999> No news is good news? (I hope)
18:09:24 <andersson007_> happy to hear that everything . ok with the doc
18:09:38 <andersson007_> is ok hopefully
18:10:17 <felixfontein> an update from gwmngilfen, who won't make it for today's meeting:
18:10:18 <felixfontein> #info gwmngilfen wanted to mention that https://stats.eng.ansible.com/ has a new look and he's starting to protoype the collections dash now
18:10:21 <felixfontein> #info code will be in https://github.com/ansible-community/stats-collections soon
18:10:30 <abadger1999> Cool
18:10:30 <tadeboro> We have been using beta releases in our CI for almost a week now and found no issues. The only modules that we use and were migrated to collections are a few docker ones and they work as expected. No playbook changes needed from our side.
18:10:44 <abadger1999> Yay!  thanks tadeboro  :-)
18:10:47 <gundalow> felixfontein: thanks for adding that stats update
18:10:54 <felixfontein> I'm also using the betas and now the rc1 in production, and so far it worked fine
18:11:44 <andersson007_> you are a risky man
18:11:52 <felixfontein> tadeboro: glad to hear that the docker modules work as expected :)
18:12:07 <tadeboro> Also, molecule works just fine with the latest beta releases. And once the final version is out, even installation woes will go away.
18:12:16 <felixfontein> andersson007_: when running stuff from my local machine I'm using devel, or something close to devel, pretty often
18:12:43 <felixfontein> andersson007_: though usually mostly for the stuff that I know works, or really should be working ;)
18:12:56 <andersson007_> ;)
18:13:11 <felixfontein> tadeboro: I think everyone looks forward to that! (and same for ansible-lint) in particular zbr :)
18:13:29 <abadger1999> :-)
18:14:02 <felixfontein> any more updates?
18:14:19 <tadeboro> Oh, we also use ansible-lint and that one also works just fine (again, if you ignore a bit of mess in the initial setup of python packages).
18:15:03 <abadger1999> None from me.
18:15:10 <felixfontein> tadeboro: good to hear!
18:15:24 <felixfontein> ok, then if nobody has other plans, let's talk about content moving :)
18:15:40 <felixfontein> #topic moving content between collections after 2.10 (https://github.com/ansible/community/issues/539#issuecomment-693350676)
18:16:15 <felixfontein> there's a first concrete case for this: https://github.com/ansible-collections/community.general/pull/866 which moves the oc module out of community.general to community.okd
18:16:44 <abadger1999> I would tentatively think that the content should live in both collections until the next major update to community.general.  at that time community.general can redirect to the new collection.
18:16:45 <felixfontein> we apparently already talked about moving a bit earlier (https://meetbot.fedoraproject.org/ansible-community/2020-08-12/ansible_community_meeting.2020-08-12-18.00.html), but I didn't manage to read up on that
18:17:09 <abadger1999> geerlingguy: Are you here, btw?  We're discussing how to move content from one collection to another.
18:17:10 <felixfontein> it was a bit specialized to the gluster collection, which we managed to partially move before 2.10
18:17:42 <felixfontein> earlier today when I mentioned that agenda, gundalow started asking some questions for this topic
18:17:47 <felixfontein> gundalow: do you mind if I paste them here?
18:18:03 <gundalow> felixfontein: go for t
18:18:05 <gundalow> it*
18:18:10 <felixfontein> <@gundalow> felixfontein: thanks for preparing us, so is that:
18:18:10 <felixfontein> <@gundalow> Q: I guess right now we remove it and add a redirect, 1-2 major version later add a deprecation warning, and then two major releases later remove it.
18:18:13 <felixfontein> <@gundalow> Q: Do we add the destination collections as dependencies while the direction is there?
18:18:16 <felixfontein> <@gundalow> Q: Moving content between collection - does it have to be aligned to a major release? carry "deprecated" copy in old location until next major release?
18:18:19 <felixfontein> <@gundalow> c.g -> gluster: https://github.com/ansible-collections/community.general/issues/761
18:18:23 <gundalow> #info Content moving out of community.general (and community.network) into dedicated collections is generally a good thing assuming there is a set of new maintainers
18:18:35 <felixfontein> +1 on the part with the new maintainers ;)
18:19:05 <felixfontein> abadger1999: I fully agree on the part with the major release, we should not remove content from a collection except in major releases
18:19:22 <felixfontein> adding new content (and also moved content) can be done in any minor release
18:20:06 <felixfontein> in fact I earlier today wrote about that:
18:20:07 <felixfontein> <felixfontein> I think the move (or more precisely: the removal from the old collection) needs to be aligned with a major release, since this is a breaking change - with Ansible 2.9, and also with later ansible-base versions if no dependency is added
18:20:14 <felixfontein> <felixfontein> about collection dependencies: I would really try to avoid them if somehow possible
18:21:01 <tadeboro> Is there are reason for treating content move between collections differently from other module deprecations?
18:21:39 <tadeboro> I would image that if the content needs to move, it gets deprecated in one collection with a link to a new location.
18:21:41 <felixfontein> tadeboro: depends on how transparent we want to make it
18:21:59 <tadeboro> Wait a year or two and then remove it.
18:22:03 <felixfontein> nitzmahone made a point that adding silent redirects and keeping them forever is best, and never to use tombstoning in this case (IIRC)
18:22:35 <abadger1999> Why four major versions until removal rather than deprecate and redirect immediately and then removing it two releases later?
18:22:52 <felixfontein> the reason is that otherwise you have fun when using `collections:` and specify the old collection before the new one - if the name is tombstoned, finding the module/plugin will fail
18:23:11 <nitzmahone> --^ that
18:23:37 <abadger1999> Why would we want to use tombstoning at all, then?
18:23:39 <nitzmahone> a tombstone is immediately fatal- we don't keep looking once we hit one
18:23:46 <nitzmahone> For things that are truly dead
18:23:47 <felixfontein> and if there's a redirect with a deprecation, you always get the deprecation message if you have the collections in the wrong order
18:24:03 <abadger1999> deprecate with removal, then after the deprecation period, remove.
18:24:20 <nitzmahone> (without a tombstone, that's fine)
18:24:28 <abadger1999> <nod> Cool.
18:24:53 <tadeboro> The `collections` keyword is evil. I hate that thing. Causes more problems than it solves ;)
18:25:02 <nitzmahone> tombstones only really make sense for things that didn't move, but just don't exist anymore (for whatever reason)
18:25:07 <felixfontein> tadeboro: I somewhat agree ;)
18:25:32 <nitzmahone> Heh- you should've heard the way people pissed and moaned at the collections prototypes without it :)
18:25:45 * abadger1999 waits for some collection to remove their "user" module and tombstone it....
18:25:48 <nitzmahone> "eww, you mean I have to type this big ugly name all the time?!"
18:26:24 <felixfontein> abadger1999: to be sure what's the correct order: (A) 1) deprecate module for c.g 1.2.0 for removal in 2.0.0, 2) remove and add redirect with deprecation message in 2.0.0, 3) remove redirect with deprecation in 4.0.0?
18:26:49 <nitzmahone> sounds right to me
18:27:04 <felixfontein> or (B) 1) don't deprecate module, 2) remove module in 2.0.0 and add silent redirect, 3) add deprecation to redirect in 3.0.0 or 4.0.0, 4) eventually remove redirect
18:27:11 <abadger1999> tangent: It almost sounds like when we get around to writing guidelines, we should make "Do not ever use tombstones" as one of the guidelines for collections in ansible.
18:27:32 <nitzmahone> They make sense for things that are truly dead (eg, clouds that don't exist anymore)
18:27:39 <felixfontein> that will suck more for 2.9 users, but for 2.10+ users this is somewhat more friendly, since they have a longer time to update their playbooks (though they only find out much later that they can/should if they don't read the porting guide / changelog)
18:27:52 <abadger1999> I don't think (b) will be good if we do not depend on the new collection.
18:28:08 * abadger1999 thinking through cornercases in (A)
18:28:30 <nitzmahone> You get a "nice"ish error message on most failed redirects
18:28:36 <felixfontein> abadger1999: for collections in Ansible, it is only a problem for ansible-base users which don't read the porting guide / changelog ;)
18:28:48 <nitzmahone> so everyone, then? ;)
18:28:56 <tadeboro> All of them then?
18:28:56 <felixfontein> and one easy to fix, it's not like you have to downgrade to get the old module back
18:29:17 <nitzmahone> Making c.g depend on all the other collections things got moved to is not a good plan IMO
18:29:19 <felixfontein> there's of course (C) which is similar to (B), except it adds a dependency
18:29:27 <felixfontein> but I'd really like to avoid adding any new dependency
18:29:40 <felixfontein> gundalow agreed with that earlier today :)
18:30:21 <abadger1999> If we're not adding dependencies, then I see how (A) makes sense and why there's so much time between intent to remove the module and actually removing it.
18:30:33 <tadeboro> What happens when the redirect is there and the "target" collection is not installed? An error indicating what is missing?
18:30:38 <nitzmahone> yes
18:31:16 <gundalow> Got to drop for another meeting
18:31:38 <tadeboro> Then I am fine with not having dependecies. As long as there is an error message that customer can paste into a bug report, things will work for my use cases.
18:32:20 <felixfontein> ok, one thing we have not mentioned yet is whether the redirects in ansible's ansible_builtin_runtime will get updated
18:32:27 <nitzmahone> they will not
18:32:32 <felixfontein> because if they are not, then removing the redirect will break things for users
18:32:52 <felixfontein> at least if it is a module that is used with its short name (without `collections:` keyword)
18:33:15 <tadeboro> This last thing is what I was thinking about: users that will not migrate their playbooks and rely on routing indefinitely.
18:33:39 <nitzmahone> the builtin runtime is generally assumed to be 2.9(ish) compatibility, and it's up to the initial collections listed to maintain the chain. If one of them goes away entirely, we might update it, but the point was not to have it be an endlessly-maintained "where are all the 2.9 plugins today?" map.
18:33:41 <tadeboro> For them, removing redirect in the "middle" breaks the redirect chain.
18:33:48 <felixfontein> tadeboro: eventually they will get disappointed, if the short name compatibility routing gets removed. though I don't think that'll happen in the near future
18:33:53 <abadger1999> felixfontein: I think that might be acceptable..... the old FQCN  will get broken then too.
18:34:00 <abadger1999> so it makes conceptual sense.
18:34:34 <felixfontein> abadger1999: but then for example `docker_container` gives a strange error (community.general.docker_container does not exist), except if you add the correct `collections:` - that would be a bit strange.
18:35:00 <nitzmahone> tis also (one) reason I implemented recursive redirect chaining- so we could do this *without* having to maintain future moves in that file
18:35:03 <abadger1999> That's true.... can the error message be made to make more sense?
18:35:23 <tadeboro> Maybe a bit off-topic, but anyway: is there a date set for when the "bare" names stop working?
18:35:34 <nitzmahone> There is no plan to remove that
18:35:42 <nitzmahone> Some people want to, but most of us do not
18:36:11 <tadeboro> Ugh, this means that there is no incentive to update the playbooks with FQCNs.
18:36:27 <nitzmahone> Tis not to say that won't change, but there is currently no plan to kill it
18:36:44 <felixfontein> #chair nitzmahone
18:36:44 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ felixfontein gundalow nitzmahone tadeboro
18:36:53 <felixfontein> since you're also talking... :)
18:37:09 <nitzmahone> We get a lot of sh*t for breaking playbooks, and we're trying to stop doing that
18:37:40 <felixfontein> I guess it will still happen, but it won't be ansible-base anymore - or at least not that often ;)
18:37:52 <nitzmahone> Sometimes there's just no way around it *cough* import stuff *cough* but in many cases we could've easily kept compatibility
18:38:05 <tadeboro> I would say that removing the intermediary redirect is only OK once the playbook authors are "forced" to use FQCNs (either directly or by means of `collections` keyword).
18:38:21 <geerlingguy> @abadger1999 ah, shoot, was at lunch, but here now
18:38:29 <geerlingguy> well, almost—I have to go turn off a sprinkler
18:38:50 <felixfontein> here it surprise rained today, no need for a sprinkler anymore ;)
18:39:06 <nitzmahone> tadeboro: that's the way I hoped things would work, but ultimately it's up to the maintainers of the collections to decide :)
18:39:07 <abadger1999> tadeboro: In a larger ecosystem sense, I don't think that's going to work out but we could decide not to make the problem worse.... although I'm not all that happy about that idea.
18:39:49 <abadger1999> tadeboro: We should propose a patch to ansible-base that adds a 0.25 second delay if you are using an old name ;-)
18:39:58 <nitzmahone> :P
18:40:24 <tadeboro> abadger1999: The best idea ever! I will kindly ask all of our userss to update this way from now on ;)
18:40:48 <felixfontein> if ansible_builtin_runtime.yml is frozen, it might be better to keep redirects without deprecation warnings indefinitely. then only anible 2.9 users will have to do actual work.
18:41:20 <felixfontein> at least for stuff that comes with Ansible; if you use ansible-base + collections you need to make sure you have the destination collection installed as well
18:41:27 <abadger1999> The drawbacks I can see would be....
18:41:32 <tadeboro> felixfontein: Or update Ansible to > 2.9
18:41:38 <felixfontein> (I'd really like to avoid collection dependencies, even though they'd fix this :) )
18:42:00 <felixfontein> tadeboro: they should do that anyway, but then there are people still using 2.4...
18:42:05 <nitzmahone> Yeah- esp on a collection of this size, I could see collection deps getting out of hand *fast* ;)
18:42:16 <felixfontein> (who just migrated to 2.9, and guess how long they will probably wait until the next migration...)
18:42:34 <nitzmahone> Esp since 2.9 is going to likely live a loooong time :(
18:42:44 <felixfontein> nitzmahone: yep. I don't want to see ansible-galaxy download half of the internet when I install community.general ;)
18:42:58 <nitzmahone> (well, at least any more than it already does ;) )
18:43:05 <abadger1999> (*) bug filing confusion (*) coordination between redirecting and redirected too collections (*) progressive slower usage for long redirect chains (*) more opportunities for unmaintained collections to cause problems.
18:43:07 <felixfontein> nitzmahone: maybe some more features should be backported to 2.9? :)
18:43:10 <tadeboro> felixfontein: Is there a way to stop that from happening? I think it already does ;)
18:43:46 <felixfontein> tadeboro: it's only 1/4, so don't complain ;)
18:44:27 * tadeboro stops complaining ;)
18:44:36 <nitzmahone> felixfontein: given its long life, there will almost certainly be other quality-of-life features that we'll have to backport, but we're definitely not opening the floodgates ;)
18:44:58 <felixfontein> nitzmahone: how about... routing? :D
18:45:02 <felixfontein> abadger1999: good points.
18:45:10 <nitzmahone> felixfontein: NO ;)
18:45:23 <abadger1999> (*) playbooks never get updated with the latest fqcn's.... (not sure if this is a problem in and of itself if the redirects never ever go away)
18:45:52 <nitzmahone> If someone told me I had to do that, I'd probably just `cp ansible/stable-2.10 ansible/stable-2.9` and call it a day ;)
18:45:59 <felixfontein> nitzmahone: it would be a breaking change though, so it's not a good idea anyway
18:46:22 <abadger1999> That was the strategy I proposed for python-2.8 ;-)
18:46:27 <nitzmahone> lol
18:46:32 <felixfontein> :D
18:47:53 <geerlingguy> To tadeboro's point—IMO it would be a good thing to make maybe Ansible 3.0 or 4.0 or something the "now you must use FQCNs" release, and at that point some of these issues go away.
18:48:08 <geerlingguy> Until then, IMHO, we should be incredibly careful to not break existing playbooks without very good reason.
18:48:09 <abadger1999> Maybe we should commit to a time span after which this could be revisited/approved for another timespan?
18:48:11 <felixfontein> hmm, I think we have two different groups of users to think of - the ones using the old short names (and not `collections:`), and then the ones who use FQCN and/or `collections:`.
18:48:27 <felixfontein> for the former, silent redirects would be best, for the latter, silent redirects would be bad
18:48:45 <abadger1999> yeah
18:48:50 <nitzmahone> It's been discussed ... but anytime you make a big change like that where people have to significantly touch old stuff to keep it working, it's also a chance to lose them to another technology.
18:49:12 <geerlingguy> Exactly, that's why it has to be a major release, and we should have all the little bugs ironed out first.
18:49:21 <felixfontein> see python 2 vs python 3...
18:49:25 <geerlingguy> And ideally we wouldn't have the case where a mid-chain redirect is removed until that day
18:49:37 <geerlingguy> (either that, or we merge PRs to update the redirection in ansible/ansible)
18:50:30 <felixfontein> updating ansible_builtin_runtime.yml would really solve a lot of problems :)
18:50:31 <nitzmahone> If the primary collection in ansible_builtin_routing goes away, of course we'll update it if there's a new canonical source, but the intent was that the collections listed there would keep the chain alive
18:51:40 <nitzmahone> Having it float in builtin routing just moves the problem around- it assumes that users are on the latest ansible, and that there are frequent enough releases to track it. What's the problem with leaving two lines in a collection's routing file to prevent all that?
18:51:44 <felixfontein> nitzmahone: unfortunately that doesn't work well with all use-cases, namely with users which use FQCNs
18:52:29 <felixfontein> if we keep silent redirects, users never know that the module/plugin actually moved somewhere else, will never update their roles/playbooks, and will report bugs in the wrong places
18:52:33 <nitzmahone> exactly- which is why I think it's an implied responsibility for the listed collections to preserve the chain
18:52:44 <felixfontein> essentially all the points abadger1999 listed
18:53:20 <nitzmahone> I have much less problem with the deprecation on redirects- people with collections: that don't want to see them can either reorder or use FQCN
18:53:35 <abadger1999> silent redirects make me think that there needs to be a builtin way to automatically update playbooks to the current canonical names.
18:53:57 <nitzmahone> *cough* 2to3 *cough* :(
18:54:22 <nitzmahone> People keep asking for those kinds of tools- they make great demoware, but rarely work well in the real world :(
18:54:36 <tadeboro> Deprecations are in my exe a good thing in this scenario since they nudge the playbook author in the right direction.
18:54:43 <tadeboro> exe -> eyes
18:54:48 <abadger1999> <nod> although ansible already has to be able to do that at runtime  whereas 2to3 isn't meant to be run without interaction
18:55:04 <felixfontein> nitzmahone: such tools have similar problems than 2to3, they can work in many cases, but they will always miss some corner cases
18:55:12 <nitzmahone> yep
18:55:29 <nitzmahone> and time spent building/maintaining those tools is time not spent making the underlying stuff better
18:55:37 <felixfontein> abadger1999: you can compose a tasks's module name with jinja2 expressions
18:56:04 <felixfontein> IIRC
18:56:04 <nitzmahone> anyway, y'all have my $0.02
18:56:15 * nitzmahone -> back to writing specs
18:56:16 <abadger1999> felixfontein: <nod>
18:56:22 <felixfontein> nitzmahone: US$ or CA$? :P
18:57:17 <felixfontein> hmm, so how about redirects, but with a deprecation with no expiry (i.e. no removal date/version)?
18:57:21 <tadeboro> What about having a deprecation with no expiry date?
18:57:27 <felixfontein> :)
18:57:53 <andersson007_> people will eventually get tired seeing warnings:)
18:58:17 <abadger1999> I'd like  a "revisit the question in 1 to 2 years" as well.
18:58:28 <felixfontein> (D) 1) deprecate module in 1.2.0 for removal in 2.0.0, 2) remove module and add redirect with deprecation warning in 2.0.0 with no removal date/version
18:58:29 <tadeboro> Yep. This is what I called earlier "a nugde in the right direction".
18:58:59 <felixfontein> abadger1999: we can decide to add a removal date to existing deprecated redirects in 1-2 years, and then to eventually remove them
18:59:00 <tadeboro> abadger1999: I fully agree. This should be a temporary solution.
18:59:23 <abadger1999> felixfontein: yep, that's what I was thinking too.
18:59:41 <tadeboro> So redirects that are temporary without an expiry date.
18:59:42 <felixfontein> and (E) 1) not deprecate module, 2) remove module and add redirect with deprecation warning in 2.0.0 with no removal date/version
19:00:06 <geerlingguy> community.general will someday just be a repo with one massive file that's 7 MB with all the redirects :D
19:00:20 <abadger1999> Or we'll find there's only a handful of these chained redirects then and so we can punt the decision date further down the road.
19:00:22 <felixfontein> geerlingguy: fortunately it will be much shorter, since redirects are not that huge ;)
19:00:33 <tadeboro> geerlingguy: And in Ansible 4.0 it can all go away ;)
19:01:24 <tadeboro> But I guess I will not live long enough to see Ansible 2.9 die, let alone see Ansible 4.0 be born ;)
19:01:31 <nitzmahone> I can't remember if the schema validation that required date/version got merged or not, but if so, you'll probably have to bypass that :)
19:01:51 <felixfontein> what do you think about (E)? that will be a bit mean to 2.9 users, since they get no deprecation warning before things break, but for 2.10+ users its nicer. (except if they use ansible-base and don't install the target collection.)
19:02:03 <felixfontein> nitzmahone: it got merged
19:02:06 <nitzmahone> Yeah, the heat death of the universe will probably occur before 2.9 dies :(
19:02:31 <felixfontein> nitzmahone: btw, some improvements: https://github.com/ansible/ansible/pull/71679 https://github.com/ansible/ansible/pull/71735
19:03:02 <felixfontein> I don't tihnk it will last *that* long
19:04:23 <felixfontein> maybe we should adjust the validation schema in https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/sanity/code-smell/runtime-metadata.py to allow redirects which have a deprecation that does not expire
19:05:04 <nitzmahone> `removal_date: 9999-12-31`
19:05:12 <nitzmahone> close enough
19:05:20 <geerlingguy> some future generation curses that removal date
19:05:47 <tadeboro> Or just 2038 maybe?
19:05:52 <felixfontein> geerlingguy: they can also move it. except that right now years are required to be four digits ;)
19:05:56 <nitzmahone> Some future generation makes December only have 30 days
19:06:06 <nitzmahone> *boom*
19:06:28 <felixfontein> let's remove Jan 1st instead, and let the year start on Jan 2nd
19:06:33 <abadger1999> It should be a non-date-like string.
19:06:50 <felixfontein> ok, we're already in overtime
19:07:11 <abadger1999> Because naive parsing of a date-like string will leave the wrong impression.
19:07:17 <felixfontein> so how (D) from above? or (E)?
19:07:28 <felixfontein> or is any other solution preferred?
19:07:42 <felixfontein> (D) 1) deprecate module in 1.2.0 for removal in 2.0.0, 2) remove module and add redirect with deprecation warning in 2.0.0 with no removal date/version
19:07:44 <tadeboro> I would vote for D
19:07:47 <felixfontein> (E) 1) not deprecate module, 2) remove module and add redirect with deprecation warning in 2.0.0 with no removal date/version
19:07:55 <felixfontein> or (F): do not remove content :P
19:07:59 <abadger1999> I think I like D better, but if everyone else like E, that's fine for me.  I do want us to discuss this in a year.
19:08:17 <tadeboro> +1 ^
19:08:19 <abadger1999> Could be a short discussion, though, if there are only a few instances where this comes into play.
19:08:25 <felixfontein> I'm somewhat torn between the two of them
19:08:43 <felixfontein> VOTE: (D) or (E) or something else?
19:08:50 <felixfontein> I see two votes for (D)
19:08:53 <felixfontein> #chair
19:08:53 <zodbot> Current chairs: abadger1999 aminvakil andersson007_ felixfontein gundalow nitzmahone tadeboro
19:09:32 <tadeboro> D (I prefer to see deprecations as early as possible)
19:10:04 <felixfontein> we should only deprecate though after a version of the target collection is released which actually contains the content
19:10:07 <nitzmahone> Can you take action to resolve the deprecation in 1.2.0?
19:10:11 <nitzmahone> --^ that
19:10:29 <felixfontein> nitzmahone: what do you mean by resolve the deprecation in 1.2.0?
19:10:31 <nitzmahone> You shouldn't show the warning until you can actually resolve it
19:10:38 <felixfontein> aah
19:10:40 <nitzmahone> what you said
19:10:44 <felixfontein> ok :)
19:10:54 <felixfontein> yeah, that's something we already did in the pre-1.0.0 phase
19:11:04 <nitzmahone> Showing a deprecation warning that can't be corrected is ... not good.
19:11:09 <felixfontein> yep
19:11:38 <tadeboro> Heh, I just found a DigitalOcean module that does that an hour ago ...
19:11:57 <nitzmahone> 🤦‍♂️
19:12:15 <felixfontein> nitzmahone: andersson007_: geerlingguy: gundalow: (D) or (E)? or something else? :)
19:12:24 <andersson007_> i'll abstain
19:12:30 <nitzmahone> +1 for E
19:13:39 <felixfontein> so 2.5 for (D) and 1.5 for (E), if I split my vote up :D
19:13:49 <abadger1999> :-)
19:14:06 <andersson007_> throw up a coin
19:14:23 <tadeboro> They are both decent suggestions, so there is nut much on the line here as far as I am concerned.
19:14:24 <nitzmahone> If you show the warning before anyone can correct it, they're either going to ignore it or suppress it.
19:14:30 <felixfontein> no, I think I'll change to (D) then, I don't want a draw or a too close result :)
19:14:45 <felixfontein> nitzmahone: (D) does not mean the warning will be shown before it can be prevented
19:14:46 <nitzmahone> (which in this case means suppress all)
19:15:07 <felixfontein> nitzmahone: that's another topic, allowing to suppress only *SOME* warnings :)
19:15:14 <nitzmahone> Ah, so long as the module is available in its new home when the deprecation occurs, I'm fine with D then
19:15:46 <tadeboro> I also expect that as soon as the deprecation warning pops up, I can fix my stuff without any waiting.
19:15:54 <felixfontein> so 4 x (D) then?
19:16:00 <nitzmahone> sounds like it
19:16:04 <felixfontein> :) good
19:16:13 <abadger1999> There is one thing about that.
19:16:18 <nitzmahone> Yeah, showing a dep warning without a way to fix it is maddening
19:16:29 <abadger1999> You might have to update outside of the ansible package.
19:17:12 <felixfontein> #agreed 1) deprecate module/plugin once it has been added to the target collection and that has been released, with removal scheduled for the next major version; 2) in next major version, remove module/plugin and add redirect with deprecation that has no removal date/version; 3) in 1-2 years, revisit these redirects
19:17:19 <nitzmahone> That seems to be a better argument for (E) then
19:17:26 <abadger1999> say, community.general 1.1.0 => 1.2.0 introduces the deprecation  and at the same time community.kubernetes  1.0 => 2.0 takes in the new module.
19:17:53 <abadger1999> the ansible-2.10.1 would get comm.gen-1.2.0 but it would not get comm.kube-2.0
19:17:54 <felixfontein> abadger1999: if the target collection is released first (and not a new major version, but a minor version), that should not be the case
19:17:55 <nitzmahone> or at least delaying adding the dep warning on the source for a release or two
19:18:05 <felixfontein> #undo
19:18:05 <zodbot> Removing item from minutes: AGREED by felixfontein at 19:17:12 : 1) deprecate module/plugin once it has been added to the target collection and that has been released, with removal scheduled for the next major version; 2) in next major version, remove module/plugin and add redirect with deprecation that has no removal date/version; 3) in 1-2 years, revisit these redirects
19:18:19 <felixfontein> I'll add a part which says "with a new *minor* version"
19:18:27 <felixfontein> is that ok for everyone?
19:18:32 <nitzmahone> wfm
19:18:38 <abadger1999> but a user can use ansible-galaxy colllection install to get the newer version of community.kubernetes.
19:18:54 <abadger1999> <nod> wfm
19:19:10 <tadeboro> wfm
19:19:10 <nitzmahone> It'd be "nice" if it all worked within the distribution, but it's a relatively minor nit
19:19:10 <felixfontein> #agreed 1) deprecate module/plugin once it has been added to the target collection and that has been released (as a minor release that will also get included in the next Ansible version), with removal scheduled for the next major version; 2) in next major version, remove module/plugin and add redirect with deprecation that has no removal date/version; 3) in 1-2 years, revisit these
19:19:16 <felixfontein> redirects
19:20:21 <tadeboro> I would also expect that collection maintainers will communicate things enough that the thing can be added in a minor version that will get pulled in along with the c.g.
19:21:34 <felixfontein> there's a big of a special case: if content is moved into a **new** collection, that one won't get included in Ansible, at least not in 2.10.x
19:21:48 <felixfontein> (in this case: moving community.general.oc to community.okd)
19:22:16 <felixfontein> what should we do in this case? or should we continue with that next week, since it's already pretty late?
19:23:07 <felixfontein> #info to discuss: what happens when the target collection is (not yet) contained in Ansible?
19:23:18 <abadger1999> oh.... question: is moving the module out of community.general going to happen in a new y-stream or a new x-stream?
19:23:41 <felixfontein> abadger1999: I would not do removals in minor versions, since that are breaking changes
19:23:44 <felixfontein> (though mostly for 2.9 users)
19:23:55 <felixfontein> (and for ansible-base 2.10 users which do not install the target collection)
19:24:12 <tadeboro> I vote for the current meeting to end ;)
19:24:36 <abadger1999> maybe I was worrying about nothing because we would not get the removal + deprecation in the comm.gen package in my example.
19:24:39 <felixfontein> tadeboro: I agree, let's discuss this next week. it's not *that* urgent yet :)
19:24:45 <abadger1999> Cool :-)
19:24:52 <tadeboro> Maybe we can tweak the deprecation rule a bit and say that thing gets deprecated once we know it can be replaced?
19:25:00 <felixfontein> #info discussion will be continued next time :)
19:25:04 <felixfontein> #topic open floor
19:25:25 <felixfontein> tadeboro: I think what I wrote up above already says that :)
19:25:51 <felixfontein> anyone has something for the open floor?
19:26:19 <tadeboro> felixfontein: Please ignore me if you did. I went half-braindead into this meeting. And now I am full-braindead.
19:27:00 <abadger1999> not i
19:27:04 <felixfontein> tadeboro: no problem :D if you think what I wrote didn't say that, I could have summed it up incorrectly, so it's always good to double-check
19:27:16 <felixfontein> in that case, thanks everyone!
19:27:30 <felixfontein> tomorrow at 18:00 UTC we have a (hopefully very short) meeting on potential blockers for the 2.10.0 release
19:27:59 <felixfontein> if you think you found something that could block that release, please write that into the meeting agenda ASAP (https://github.com/ansible/community/issues/539)
19:28:23 <felixfontein> if nothing is on the agenda, we will close the meeting very early :)
19:28:31 <felixfontein> #endmeeting