ansible_core_public_irc_meeting
LOGS
15:31:28 <gundalow> #startmeeting ansible core public irc meeting
15:31:28 <zodbot> Meeting started Thu May 28 15:31:28 2020 UTC.
15:31:28 <zodbot> This meeting is logged and archived in a public location.
15:31:28 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:31:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:31:28 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:31:32 <shertel> \o
15:31:39 <jimi|ansible> o/
15:31:52 <gundalow> #chair felixfontein cyberpear sdoran jtanner acozine shertel abadger1999
15:31:52 <zodbot> Current chairs: abadger1999 acozine cyberpear felixfontein gundalow jtanner sdoran shertel
15:32:14 <gundalow> (I'm going to have to drop offline in 10 minutes
15:32:15 <gundalow> )
15:32:21 <relrod> o/
15:32:32 <gundalow> #topic ansible-base 2.10 beta 1
15:32:45 <jtanner> we're cutting beta on monday
15:33:01 <jtanner> i decided i didn't want us making a major change on a friday
15:33:18 <gundalow> #info ansible-base beta 1 will be released on 2020-06-01
15:33:32 <felixfontein> so all major changes have to happen today?
15:33:33 <gundalow> +1 to not Friday :)
15:34:19 <gundalow> It's great that nitzmahone life work (Routing^Wruntime PR has been merged)
15:34:26 <dmellado> o/
15:34:34 <gundalow> #chair jimi|ansible relrod dmellado
15:34:34 <zodbot> Current chairs: abadger1999 acozine cyberpear dmellado felixfontein gundalow jimi|ansible jtanner relrod sdoran shertel
15:35:18 <felixfontein> I guess the most pressing problem is that right now, module deprecation in collection cannot be done properly.
15:35:40 <abadger1999> felixfontein: So earlier, when you talked about the PRs you have... it sounded like they might be blockers to the 2.10.beta ?
15:36:02 <felixfontein> abadger1999: IMO they are, but people might not see them as important as me :)
15:36:10 <acozine> they are blockers in my book
15:36:45 <felixfontein> I have three PRs: https://github.com/ansible/ansible/pull/69313 - update changelog generator to antsibull-changelog - this will make compiling the ACD changelog a lot easier, since the new changelog.yaml format will be used
15:36:57 <acozine> releasing without usable documentation would be a problem
15:37:00 <abadger1999> jtanner: ^ Okay... sooo it sounds like at least you need to be involved in that... and like you say, if nitz and mattclay are the ones to evaluate, then they probably need to be participating too?
15:37:19 <jtanner> i'm not sure i understand what "that" is
15:37:29 <felixfontein> https://github.com/ansible/ansible/pull/69727 - fixes deprecation of modules in collections: right now ansible-test will scream at you if you don't want to remove a module for a ansible-base version
15:37:45 <felixfontein> (PR allows both to specify date, and to specify other versions in collections)
15:38:32 <felixfontein> https://github.com/ansible/proposals/issues/178 and https://github.com/ansible/ansible/pull/69680 make sure that people know *WHAT* exactly is deprecating something (or *WHERE* a new feature was added) - no matter whether it's about versions or dates
15:38:37 <samccann> allowing date base deprecation 'feels' like a blocker to me as the network team uses that, amongst other ansible-maintained collections (with eventual S*upport)
15:38:42 <jtanner> nitz just showed on an internal demo how plugins can be deprecated by version or by date
15:38:51 <jtanner> i'm not sure 69727 is an issue anymore
15:38:58 <felixfontein> jtanner: did you try running `ansible-test sanity` on these plugins?
15:39:04 <felixfontein> modules I mean
15:39:17 <samccann> dmellado maxamillion ikhan may know better on date-based deprecation being a blocker
15:39:18 <jtanner> ansible-test wasn't part of the demo, so i don't know
15:39:35 <felixfontein> validate-modules *INSISTS* that for depreacated modules you have a removed_in version number, which is one of 2.2, 2.3, 2.4, ..., 2.14
15:39:45 <gundalow> This also needs to go in to beta1 https://github.com/ansible/ansible/pull/69742 validate ansible-base's and collections runtime.yml
15:40:57 <gundalow> https://github.com/ansible/ansible/projects/39 also appears to have a fair bit of open stuff in
15:41:30 <felixfontein> btw, did anyone test whether module_defaults that worked in 2.9 still work in 2.10? (especially with shertel's PR not being merged?)
15:41:41 <shertel> didn't we decide that some things on the board (such as flatmapping) are not blockers after all?
15:42:03 <shertel> felixfontein: that PR is still in progress on the board
15:42:15 <shertel> I think it's done but I'm waiting for nitz to have time to take another look
15:42:31 <felixfontein> shertel: I know, I get emails about it all the time, but it's still marked as WIP :)
15:42:35 <nitzmahone> Yeah, I'm reviewing the module_defaults/action_groups stuff today
15:42:37 <shertel> if you have time/interest in testing it, please do (I think it's fully functional)
15:42:48 <shertel> felixfontein: I'm just uncertain about a couple things. It works.
15:42:56 <felixfontein> I didn't really have time yet to look at it more closely
15:43:00 <gundalow> jtanner: Who's on the hook for reviewing https://github.com/ansible/ansible/projects/39 ?
15:43:01 <felixfontein> there are so many other things :)
15:43:26 <jtanner> we reviewed 39 a  week or 2 ago as a team.
15:44:21 <gundalow> jtanner: mkay, what of that still has to be done? before beta1?
15:44:25 <nitzmahone> flatmapping got nuked a few weeks ago
15:45:04 <nitzmahone> It's only a few lines of code now, but the consensus seemed to be that it wasn't necessary, so I removed it
15:45:37 <felixfontein> it's not necessary if we either use symlinks, or have to mention every single module in meta/runtime.yml in community.general and community.network
15:45:40 <gundalow> nitzmahone: So, just to clarify, how will modules in community.general and community.network (which both have subdirectories) be accessed?
15:46:00 <nitzmahone> what felixfontein said
15:46:17 <felixfontein> both are quite a PITA for people who submit a new module
15:46:36 <jtanner> but it's not a blocker.
15:46:56 <nitzmahone> The (new) flatmapping code basically made the root routing entries at runtime when the collection loads
15:46:56 <felixfontein> true. and symlinks are a good workaround which even works with ansible 2.9
15:47:14 <felixfontein> "good"
15:47:15 <jtanner> creating a symlink isn't rocket science and if it's so painful, the community [team] can make a script to autogenerate them
15:48:25 <felixfontein> I'm more concerned with cross-collection deprecation versions and dates, and version_added. that's a major UX PITA for users.
15:48:54 <abadger1999> felixfontein: yeah... when I talked with gundalow about it (last week I think) we were going to remove all symlinks and enter them into routing.yml via a script.  But of course, that was waiting on routing to be merged.  I'll probably get to writing that script next week.
15:49:14 <felixfontein> abadger1999: so definitely no 2.9 support?
15:49:16 <acozine> +1, especially since deprecation handling relates to testing
15:49:35 <abadger1999> felixfontein: that was what gundalow was in favor of last week.... but we can revisit.
15:50:15 <acozine> (that's +1 to collection deprecation versions and dates/version_added)
15:50:30 <gundalow> My team doesn't have the resources to do anything to support community collections on ansible 2.9. If they happen to work cool
15:50:31 <abadger1999> felixfontein: maybe next week, after ansible-2.10-alpha1 is out, you gundalow, and aI can sit down and see if we've changed our minds about that.
15:51:13 <gundalow> Yup, lets revisit that in Wednesday's community meeting
15:51:23 <gundalow> felixfontein: which other blockers do you have
15:51:28 <felixfontein> the main problem with deprecation version/dates is that most of it needs manual tagging by collection maintainers, and if we don't require it for 2.10 (or at least allow it without ansible-test complaining, and having basic support for it), it's next to impossible to add later
15:51:35 <gundalow> I need to drop off now. I'll read scrollback in a few hours
15:51:41 <gundalow> Thanks all
15:51:42 <acozine> thanks gundalow
15:51:42 <felixfontein> gundalow: see you later!
15:51:46 <felixfontein> and thanks!
15:52:39 <felixfontein> I have three blockers, the PRs/proposal from above
15:52:46 <acozine> what is preventing the merge of the deprecation version/dates PR? needs more reviews/testing?
15:52:52 <shertel> felixfontein: I'll try to make some time to review the validate-modules PR today
15:52:59 <felixfontein> I can go through all of them again, in any level of details, but it would be really helpful if someone tells me which ones are not clear
15:53:01 <nitzmahone> felixfontein: I don't disagree, but IMO it's not a blocker for Monday
15:53:04 <abadger1999> Okay, so it sounds like we need confirmation of blocker status for those PRs.  jtanner nitzmahone shertel , should we go through those one by one?
15:53:28 <felixfontein> nitzmahone: if it's not merged by then, it has to wait for 2.11, right?
15:53:42 <cyberpear> ^ that's how freeze has always worked
15:53:54 <abadger1999> felixfontein: You're chaired, so could you do #topic <desc> <PR> and then we can decide on them?
15:54:09 <felixfontein> ok
15:54:21 <nitzmahone> Those things are always a little slushy- this isn't really a "feature", it's just a necessary docs metadata thing with some code support that needs to be filled in before the real release
15:54:25 <felixfontein> #action https://github.com/ansible/ansible/pull/69313 use antsibull-changelog for ansible/ansible
15:54:42 <nitzmahone> I say "just" like I'm minimizing the importance- that's not it ;)
15:54:58 <acozine> nitzmahone: so it's not a blocker for Monday's alpha/beta, but it is a blocker for 2.10 release?
15:55:00 <felixfontein> (instead of the currently included changelog generator in packaging)
15:55:16 <nitzmahone> acozine: that's the way I'd handle that one
15:55:26 <abadger1999> cyberpear: (note: not always... there used to be two separate freeze dates.  Although, even though we called it the core and community freeze dates, it was more about the core engine vs modules)
15:55:31 <felixfontein> this one really needs to get in before monday, because it uses a different metadata format (changelog.yaml instead of .changes.yaml, with slightly different format)
15:56:00 <jtanner> so all collections will need to change their files?
15:56:07 <felixfontein> it's needed to be able to compile ACD changelogs in a sane way (i.e. without lots of legacy code for handling ansible-base changelog differently than collection changelogs)
15:56:19 <jtanner> how many have the wrong filenames/schemas right now if that gets merged?
15:56:35 <felixfontein> jtanner: about what are you talking now?
15:56:47 <jtanner> the changelog change
15:56:55 <felixfontein> ah. that's ansible-base specific
15:57:05 <felixfontein> it doesn't affect any collection, it only affects ACD
15:57:15 <jtanner> but base doesn't have any issues with it's own changelogs
15:57:34 <felixfontein> for "users", everything stays the same: the changelog fragments, the automatic linting in CI, and generated .rst file
15:57:43 <jtanner> it sounds like ACD went with it's own format and is expecting base to go along with it, rather than doing it's own conversion
15:58:01 <felixfontein> it's just that there will be changelogs/changelog.yaml instead of changelogs/.changes.yaml which is a machine-readable version of the .rst file
15:58:22 <mattclay> Why did ACD go with its own format?
15:58:23 <felixfontein> and opposed to .changes.yaml it is self-contained, and doesn't require the fragment files separately, and also not a separate library of version_added for all modules/plugins included in ansible-base
15:58:35 <felixfontein> mattclay: because .chances.yaml is not self-contained
15:58:49 <mattclay> Requiring the separate fragment files is actually a feature -- they can be edited later to correct mistakes in the changelog.
15:58:57 <abadger1999> @jtanner my understanding is that docs would like to have a unified changelog.  One that they can display on the website.  To achieve that, they need to be able to pull in information from -base and from all of the collections.
15:59:35 <felixfontein> mattclay: true, and they can also stay. (I can adjust the generator to update the changelog.yaml if the fragments are changed)
16:00:23 <mattclay> felixfontein: That sounds like it should work. What was the reason for wanting to store them twice instead of reading them as needed?
16:00:23 <felixfontein> mattclay: it's mainly that extra data about plugins isn't included. that fragments should be included was voted for in ... don't remember where. docs meeting maybe?
16:00:45 <mattclay> What extra data?
16:01:01 <mattclay> Everything that goes into the changelog (except the actual text) was in `.changes.yaml`.
16:01:06 <felixfontein> the current .changes.yaml only contains the name of the plugin (with its type) / module
16:01:18 <felixfontein> but the .rst file also needs the short_description
16:01:38 <felixfontein> so that's also included in the changelog.yaml
16:02:35 <mattclay> So basically the text is written to the yaml file to avoid having to load/read the collection files to extract the text for the changelog?
16:02:43 <felixfontein> and the 'namespace' value (mostly relevant for community.general and community.network now)
16:03:06 <felixfontein> mostly, yes
16:03:22 <felixfontein> (and because people voted for that, among a list of alternatives, which included not including the fragments into that file)
16:03:38 <mattclay> That makes sense, as long as the tool can automatically refresh any extracted text when the original source of that text has changed (fragment updated, module short description edited, etc.)
16:03:54 <mattclay> Otherwise fixes to the original source won't be reflected in the changelog when a release is created.
16:04:04 <felixfontein> it might not do that right now, but I can adjust it to do that
16:04:07 <mattclay> The original files were intended to be the one source of truth.
16:04:13 <abadger1999> #topic https://github.com/ansible/ansible/pull/69313 use antsibull-changelog for ansible/ansible
16:04:19 <nitzmahone> "source of truthiness"
16:04:23 <abadger1999> (Sorry, just noticed it wasn't topic that got set)
16:04:25 <felixfontein> heh :)
16:04:30 <felixfontein> abadger1999: thanks!
16:05:15 <felixfontein> the combined changelog.yaml format is also useful for people who want to use another changelog tool, and have a single file they can convert their data to (if they want their changelog to be included in the ACD changelog)
16:05:46 <felixfontein> if you would have to artificially write a bunch of fragment files and include them in the released collection, that becomes somewhat annoying
16:07:25 <mattclay> Yeah, I can see that being useful. As long as the changelog tool automatically refreshes the text in the yaml that was extracted from the fragments/plugins/etc. when regenerating the yaml, I think that should be OK.
16:07:28 <acozine> this gives collection owners flexibility while still letting us pull all (okay, most, I won't say "all") changes together so we have one place to look for "why did my playbook break?"
16:07:43 <mattclay> Then we keep the single source of truth, while still being able to have all the released changelog data in one place.
16:08:25 <mattclay> Otherwise people have to remember to edit both the original and the yaml file -- and the yaml file shouldn't ever need manual edits.
16:08:40 <felixfontein> sounds good to me
16:08:52 <acozine> +1
16:09:34 <nitzmahone> So are there further changes needed for 69313 or good to merge now?
16:09:47 <jtanner> i have to run. bbl
16:10:08 <mattclay> I haven't reviewed the PR yet, I'd like to take a look at it today.
16:10:20 <felixfontein> from my POV it's ready. the changelog generator can be adjusted in the antsibull repo and released, to fix these things
16:10:43 <felixfontein> mattclay: thanks!
16:10:53 <abadger1999> So it sounds like there's agreement this is a blocker...  is it a 2.10 final blocker or a 2.10beta1 blocker?
16:10:53 <nitzmahone> cool, I'll add to my (quickly growing) queue for a glance as well today ;)
16:11:08 <felixfontein> abadger1999: if it's not merged before the beta is released, it has to wait for 2.11
16:11:24 <felixfontein> except if someone wants to convert .changes.yaml to changelog.yaml by hand
16:11:45 <abadger1999> #action mattclay and nitzmahone to review 69313 to get it merged before 2.10beta1.
16:11:47 <abadger1999> Gotcha.
16:11:50 <felixfontein> (ok, it can be done halfway automatically, but it's still more work after the release than before)
16:12:03 <mattclay> How is the changelog tool being versioned?
16:12:09 <nitzmahone> felixfontein: yeah, not a blocker per se, but definitely much more convenient to merge pre beta than post ;)
16:12:17 <mattclay> We're likely to end up pinning the tool version (and deps) in ansible-test.
16:12:21 <felixfontein> nitzmahone: indeed :)
16:12:32 <felixfontein> mattclay: good idea.
16:13:09 <felixfontein> I'll start working on a refresh feature soon
16:13:17 <abadger1999> #info if not merged before 2.10beta1, ansible-base RMs can get it working before 2.10 final but there will be a lot of additional work to make that happen.
16:13:53 <mattclay> Oh, what's the cause of the 3.6 requirement for the tool?
16:14:10 <mattclay> That limitation results in the only 3.6+ requirement for sanity tests (others are all 3.5+)
16:14:17 <felixfontein> mattclay: mainly because we're using type hinting in antsibull
16:14:21 <abadger1999> @mattclay @felixfontein Hmmmm..... one thing to think about with that is that the changelog tool is currently being shipped with other build tools (the website build tool in particular).... so we might end up with a need to make changes.
16:14:49 <mattclay> felixfontein: Why not use the comment version for backwards compat like we do in ansible-test?
16:14:59 <nitzmahone> What a tangled web we weave, when in deps we do believe ;)
16:15:07 <abadger1999> @mattclay @felixfontein Maybe we solve that by pinning a "major" version and then we only push changes needed for ansible to patch releases to that.
16:15:10 <mattclay> abadger1999: If we need changes we can always bump the pinned version.
16:15:22 <felixfontein> mattclay: IMO that form is ugly, and abadger1999 started using proper type hintings, so I decided to use that as well :)
16:15:32 <abadger1999> @nitzmahone My favorite non-shakespeare, shakespeare quote ;-)
16:15:32 <mattclay> We effectively already pin due to generation of the default-test-container -- pinning in the requirements file just makes it more explicit.
16:15:33 <felixfontein> (as it was moved into the ansibulled -> antsibull project)
16:16:05 <mattclay> I'd be less concerned about the 3.6+ limitation if ansible-base didn't support 3.5.
16:16:15 <felixfontein> wasn't the docs build tool in antsibull supposed to also be used for ansible-base module/plugin docs?
16:16:29 <mattclay> We ran into another issue where there's a 3.5 regression since we don't run integration tests against it -- but that's a separate discussion for 2.11 perhaps.
16:16:53 <felixfontein> mattclay: that changelog sanity test is only used in ansible-base, not in collections, so it should not affect anyone but ansible-base itself
16:17:00 <samccann> as I recall felixfontein that is the ultimate goal, yes. but not required for 2.10
16:17:05 <abadger1999> mattclay: <nod> Yeah, felixfontein and I should probably just be careful because it could be easy to get in a situation where we want new changes from the docs-build but not from the changelog generator.
16:17:25 <mattclay> felixfontein: Oh... why isn't there sanity testing for collections using that?
16:17:27 <samccann> (the docs build coming from the same tool in both ansible-base and ansible and anywhere else folks want to generate docs)
16:17:36 <felixfontein> abadger1999: the changelog generator is hopefully soon "feature complete" (it mostly was before I forked it)
16:18:08 <felixfontein> mattclay: because changelog fragment validation was moved into ansible-base specific code-smell tests by you :) I guess the main reason is that collections generally don't use changelog fragments
16:18:16 <abadger1999> Yeah, docs build will be used for the plugins in ansible-base too (it's harder to separate those than to code them together).
16:18:38 <mattclay> abadger1999 felixfontein: Is the changelog generator standalone enough that it could be separate from the rest of that project (perhaps also reducing deps needed in ansible-test)?
16:18:45 <samccann> felixfontein: wouldn't individual collections use the changelog generator to generate their own per-collection changelog.rst?
16:18:57 <felixfontein> mattclay: it is, it was in fact a separate project before we moved it into antsibull
16:19:03 <felixfontein> (was called ansibulled "back then")
16:19:05 <mattclay> felixfontein: If the collections aren't using changelog fragments, how are they generating their changelog yaml?
16:19:13 <felixfontein> samccann: some will, but not all
16:19:27 <mattclay> felixfontein: Why not keep the changelog generator as a separate project then?
16:19:39 <samccann> felixfontein so the ones that do would/should eventually want the sanity test to go with it, right?
16:19:40 <felixfontein> mattclay: some collections (such as community.general and community.network) use changelog fragments, but other collections want to use reno, and some others maybe something completely different
16:20:04 <felixfontein> samccann: yes. as soon as sanity tests become pluggable that should be easy to do
16:20:11 <samccann> kewl thanks
16:20:14 <mattclay> felixfontein: So ACD has to special case those collections that don't use the changelog tool then?
16:20:42 <felixfontein> mattclay: I have no good answer to that (question about separate project)
16:21:04 <felixfontein> I somewhat like the idea of bundling different tools useful for collection maintainers and ansible-base in one project
16:21:25 <mattclay> felixfontein: So couldn't the changelog fragment linting be enabled for collections? If there's no fragments there's nothing to lint. If there are fragments it makes sense to run the test doesn't it?
16:21:28 <felixfontein> both the docs and the changelog tool will be potentially useful for all collection maintainers / authors
16:21:33 <abadger1999> mattclay: docs team decided that the path would be that other tools would be responsible for adding output in the common format... my understanding is that felixfontein and dmellado  are working on an output for reno now.
16:21:57 <felixfontein> abadger1999: I think dmellado is working on that, I unfortunately don't have time right now for that
16:22:04 <dmellado> abadger1999: nope, we gave up on reno, as it implied having a sphinx config on that
16:22:13 <abadger1999> <nod> okay.
16:22:17 <felixfontein> oh. ok.
16:22:25 <felixfontein> dmellado: what are you planning to use now?
16:22:31 <dmellado> felixfontein: just your tool
16:22:44 <felixfontein> ok. sounds good :) makes life easier ;)
16:22:54 <acozine> mattclay: we were working toward a "collection developer tools" suite, so we bundled those tools together
16:22:57 <dmellado> felixfontein: exactly, didn't want to spend more time on duplicating work
16:23:39 <acozine> and hoped that the same toolset could be used across the ecosystem (ansible-base, collections) to reduce the maintenance burden
16:23:39 <dmellado> sphinx config per collection repo, I meant ;)
16:23:57 <abadger1999> felixfontein, mattclay: I think there was a piece of shared code but I can't remember what it was and I haven't been participating in the changelog code so I'm not sure what it was.... maybe downloading collections?  Maybe parsing the versions of collections that ansible-2.10 is using?
16:24:37 <felixfontein> abadger1999: that will be shared code for building ACD changelogs; it's not used by the changelog generator itself
16:24:42 <abadger1999> Those would both be about the unified changelog, though, so perhaps the per-collection functionality could be split out and the unified functionality could stay in?
16:24:47 <abadger1999> <nod> Yeah.
16:24:48 <felixfontein> but the ACD changelog generator will use the changelog generator's internals
16:25:01 <felixfontein> yep, that would work
16:25:18 <abadger1999> So we could have antsibull-changlog(unified) depend on the changelog-per-collection package
16:25:20 <felixfontein> then collection maintainers don't have to install the ACD build tool as well
16:25:26 <abadger1999> <nod> Yep.
16:25:32 <abadger1999> that sounds good to me.
16:25:36 <felixfontein> to me too!
16:25:54 <mattclay> I'm concerned that we're going to cause problems for users wanting to use the latest version of the collection tools and also run ansible-test in the same environment, but they're going to be different versions.
16:26:18 <mattclay> We'd basically be forcing users to always use separate environments (manually maintained, or using `--docker` or `--venv` with `ansible-test`).
16:27:34 <abadger1999> #action felixfontein to look at splitting the per-collection-changelog functionality into its own package.
16:28:04 <felixfontein> mattclay: changelog validation isn't likely to change, so the chance that this actually causes a problem in the future is very low
16:28:36 <mattclay> felixfontein: All the more reason to have changelog generation be a separate tool/package we can install.
16:29:07 <mattclay> That way ansible-base's sanity tests don't have to depend on antsibull.
16:29:37 <felixfontein> they would depend on it anyway once the rst doc generation is done by antsibull
16:30:51 <abadger1999> yeah.
16:31:19 <mattclay> felixfontein: Why would the tests care about that?
16:31:46 <felixfontein> isn't doc .rst building part of the code-smell tests?
16:31:54 <felixfontein> (also currently restricted to ansible/ansible IIRC)
16:31:59 <abadger1999> Okay, so this is a blocker.... we have a path to getting it in before 2.10beta1.  Do we need to move on to the next one?
16:32:42 <acozine> we need to test the docs
16:32:59 <samccann> +1
16:33:09 * samccann states the obvious considering... :-)
16:34:08 <abadger1999> @mattclay @acozine For testing docs... should we discuss the rest of felixfontein's PRs first?
16:34:11 <felixfontein> it's best if `ansible-test sanity` already tests doc build (i.e. generate rst, maybe validates rst) before we notice that the docsite build breaks
16:34:26 <acozine> abadger1999: sounds good
16:34:46 <mattclay> Sure
16:35:09 <abadger1999> #agreed https://github.com/ansible/ansible/pull/69313  is a 2.10 blocker... will attempt to get it in before 2.10beta1
16:35:17 <abadger1999> felixfontein: go ahead and #topic the next one
16:35:18 <felixfontein> #topic 18:11 <@abadger1999> #action mattclay and nitzmahone to review 69313 to get it merged before 2.10beta1.
16:35:21 <felixfontein> oops
16:35:21 <felixfontein> sorry
16:35:26 <felixfontein> #topic https://github.com/ansible/ansible/pull/69727
16:35:31 <felixfontein> wrong copy'n'paste :(
16:35:45 <felixfontein> this is about deprecation, so ping nitzmahone
16:36:03 <felixfontein> it tries to fix as many "simple" problems with deprecations I'm aware of :)
16:36:20 <felixfontein> it a) allows both date-based and collection-version-based deprecation of modules in documentation
16:36:37 <felixfontein> b) allows to deprecate *plugin* options (not module options) by date
16:37:01 <felixfontein> c) it adds a sanity check which makes sure that module docs say the same thing on deprecation as meta/runtime.yml (regarding to date/version)
16:37:55 <felixfontein> (and it adds a changelog entry for the 'deprecate module options by date' PR, which I apprently completely forgot about)
16:38:38 <felixfontein> right now, plugin options cannot be deprecated by date (module options can), and module deprecation causes problems as validate-module *only* accepts deprecation by Ansible-base version
16:38:44 <felixfontein> (in module docs)
16:38:59 <nitzmahone> Yep, conceptually that's all fine, and at a glance LGTM
16:39:05 <nitzmahone> but I'll do a real review today
16:39:14 <nitzmahone> I don't anticipate any big issues there though
16:39:40 <abadger1999> Okay, so 2.10beta1 blocker?
16:39:40 <felixfontein> nitzmahone: if you find an issue and I'm already asleep, feel free to push directly to the branch
16:39:55 <felixfontein> I think this is the most obvious blocker, at least from my POV :)
16:40:06 <nitzmahone> felixfontein: will do
16:40:10 <mattclay> I'll review today as well.
16:40:27 <abadger1999> #agreed https://github.com/ansible/ansible/pull/69727 is a 2.10beta1 blocker.
16:40:31 <felixfontein> and should definitely be able to get it done until tomorrow
16:40:37 <abadger1999> #action nitzmahone and mattclay to review today.
16:40:39 <felixfontein> nitzmahone: mattclay: thanks!
16:40:56 <abadger1999> #info in broad overview, this looks good.
16:41:16 <abadger1999> Okay, felixfontein, next one :-)
16:41:18 <felixfontein> ok
16:41:28 <felixfontein> #topic https://github.com/ansible/ansible/pull/69680 and https://github.com/ansible/proposals/issues/178
16:41:49 <felixfontein> this one resulted from a discussion by mattclay and abadger1999 and me almost two weeks ago (on a saturday evening - in my time zone)
16:42:28 <felixfontein> the problem is that version_added, deprecation versions and deprecation dates can come from ansible-base, other collections, and the collection the current module/plugin is from
16:42:56 <felixfontein> so if the user is presented with "this feature will be removed in 4.0.0", she has no clue which version 4.0.0 is referred to
16:42:59 <felixfontein> (or might assume the wrong one)
16:43:34 <felixfontein> it could be the collection the module/plugin is from, it could be the collection a module_util or doc_fragment the plugin/module uses is from, or it could be from ansible-base
16:43:35 <cyberpear> ^ this is essential for deprecations in ACD to be usable
16:43:44 <felixfontein> (ansible-base can be identified by version numbers right now)
16:43:51 <felixfontein> cyberpear: I think so too
16:43:57 <acozine> agreed
16:44:03 <shertel> seems like it to me too
16:44:07 <cyberpear> (related note, can a module/plugin be deprecated in one collection and added to a new collection in a non-deprecated status)
16:44:11 <samccann> Yep
16:44:18 <felixfontein> for some version numbers/dates, tooling can automatically tag the version name into it so it can be shown to the user
16:44:39 <felixfontein> but for everything done in code (module.deprecate / Display.deprecated calls, or module argument_spec entries), Ansible doens't know where it comes from
16:45:02 <felixfontein> so I'm proposing to automatically tag as much as possible, and force people to manually tag the rest as well
16:45:20 <nitzmahone> cyberpear: yes
16:45:24 <felixfontein> the proposal describes this in more detail, and the PR implements this, including code in the validate-modules and pylint sanity checks which enforces this
16:45:47 <felixfontein> cyberpear: that can be mentioned in the message, and if people don't write a bad one, it should be understandable to the user
16:45:59 <nitzmahone> cyberpear: the plugin deprecation is tied to the routing entry/name within a given collection, not the plugin itself
16:46:24 <felixfontein> the PR also updates the collection finder code to mention the collection name in the deprecation messages :)
16:46:49 <felixfontein> also it will still work with untagged version numbers or dates, except that `ansible-test sanity` will start screaming
16:47:06 <felixfontein> (but then, at least for the big community collections, deprecation version numbers are still all wrong, so they have to be updated anyway)
16:47:17 <cyberpear> nitzmahone: is routing supported inter-collection? such as if ACME.cloud has some useful stuff that could be factored out into ACME.common for use also by ACME.metal?
16:47:49 <nitzmahone> yep
16:48:06 <cyberpear> (or more real-world, factoring `ipaddr` and similar useful stuff that's currently duplicated between community.general and community.network)
16:48:17 <cyberpear> cool
16:48:40 <nitzmahone> Yep, obviously it stops at the plugin level, but yeah, that kind of thing was one of the primary use cases I had in mind
16:49:14 <cyberpear> then there is some hope left! :P
16:49:50 <felixfontein> anyway. I know this is quite a big change, and very close to the freeze, but I think it's really important.
16:49:56 <abadger1999> @nitzmahone So this PR sounds like something that you would need to look at.
16:50:03 <nitzmahone> felixfontein: yeah, there's some overlap with that one and some of my in-flight stuff, but we'll sort it
16:50:10 <abadger1999> I think that acozine and samccann think that this should be a blocker?
16:50:13 <nitzmahone> yep, on my queue for today as well
16:50:22 <acozine> yes, it's a blocker in my book
16:50:40 <acozine> and it sounds like it should get in under the wire
16:50:46 <mattclay> Also on my queue for today. :)
16:50:48 <acozine> which is a huge relief and makes me really happy
16:50:51 <abadger1999> Cool, okay
16:51:04 <felixfontein> nitzmahone: mattclay: thanks again!
16:51:08 <abadger1999> #agreed https://github.com/ansible/ansible/pull/69680 is a 2.10beta1 blocker
16:51:20 <abadger1999> #action nitzmahone and mattclay to review https://github.com/ansible/ansible/pull/69680 today
16:51:29 <felixfontein> I mean, it would already be good if a subset of it would make it, that would allow people to use tagged versions + dates (and stop ansible-test to complain about them)
16:51:29 <abadger1999> felixfontein: any others from you?
16:51:39 <nitzmahone> NP, thank *you* for running with all this stuff and shedding blood on the bleeding edge ;)
16:51:46 <felixfontein> though I'd prefer the full tagging :)
16:52:00 <felixfontein> abadger1999: no, I think not. at least nothing that is important enough that it comes to my mind ;)
16:52:20 <felixfontein> I'm looking forward to some more PRs from other people to be merged, like shertel's install collections from git and module_defaults :)
16:52:36 <nitzmahone> I think the former is 2.11, but the latter needs to be in 2.10
16:52:38 <felixfontein> nitzmahone: thanks!
16:53:01 <felixfontein> yeah, I think module_defaults should definitely be in 2.10, to avoid breaking backwards compatibility
16:53:11 <felixfontein> installing from git is more nice-to-have, though I'd also like to see it :)
16:53:27 <nitzmahone> We've been collaborating on the module_defaults stuff for awhile now, it's just been blocked (like so many other things) on routing getting merged
16:53:35 <shertel> I'm going to merge the PR to install collections from git as soon as tests are passing, I think. Unless there are objections (I haven't heard any, yet)
16:53:40 <shertel> quay is having issues again
16:53:43 <felixfontein> cool! \o/
16:53:45 <shertel> so shippable is all red
16:54:01 <mattclay> quay.io is having issues again
16:54:02 <felixfontein> it already had problems a couple of hours ago
16:54:06 <shertel> (I'm also waiting to run ci_complete on the action groups PR)
16:54:17 <nitzmahone> shertel: Oh nice- last I heard that was targeted as a 2.11 feature, but if you think it's ready for 2.10, I'm sure the world will love you for it ;)
16:54:19 <abadger1999> Okay, so those are both on the project page.
16:54:38 <abadger1999> What would be nice (but maybe too late this cycle) is if blockers were all clearly marked on that page.
16:54:40 <mattclay> If quay.io continues having issues we may have to delay beta.
16:54:54 <abadger1999> Could be the columns a thing is in are all marked as blockers or something.
16:54:58 <mattclay> Since it's difficult to test/merge PRs or perform a release when our containers aren't available.
16:55:01 <shertel> nitzmahone: Dylan commented on the issue saying we'd try to get it into 2.10 if the stars aligned. I think it's good to go.
16:55:10 <nitzmahone> woot
16:55:43 <cyberpear> wondering if someone might have a moment to review this (non-blocker but nice-to-have) groupdict feature for regex_search: https://github.com/ansible/ansible/pull/64474
16:55:45 <abadger1999> Does anyone here really really want to have the project board fixed up and in an understandable state before beta1?
16:55:59 <felixfontein> nitzmahone: the world will definitely love shertel for that! :)
16:56:04 <shertel> abadger1999: that project board was *only* supposed to contain blockers
16:56:06 <cyberpear> (bcoca had asked for tests and changelog, which are there now)
16:56:36 <shertel> felixfontein: heh :-)
16:56:36 <abadger1999> @shertel heh, okay, then what would be nice is if someone pruned all the cards that are not blockers off of it ;-)
16:56:55 <nitzmahone> I nuked flatmapping already just a bit ago
16:56:57 <felixfontein> I think geerlingguy has also been very keen on having that feature
16:57:03 <abadger1999> @nitzmahone Excellent.  thanks
16:57:36 <abadger1999> #topic open floor
16:57:50 <abadger1999> Anyone from the community have any other potential blockers for 2.10 to talk about?
16:58:18 <cyberpear> (sorry for stepping on the previous topic)
16:58:20 <abadger1999> I know that the testing of docs needs to be discussed... I want to make sure no one else in the community has something to nominate before we sink our teeth into that.
16:58:59 <nitzmahone> cyberpear: https://github.com/ansible/ansible/pull/64474/ LGTM at a glance- mixed feelings about polymorphic return types on a filter, but I think it probably makes a lot more sense than duplicating the entirety of the filter functionality for groupdict-returning versions
16:59:13 <mattclay> abadger1999: Unless that's a blocker for 2.10, can we postpone that discussion until after beta so there's more time to review blockers?
16:59:36 <abadger1999> nitzmahone: cyberpear Maybe better to implement it in a common function but have two separate filters as front ends
16:59:38 <cyberpear> yeah, seems too much code duplication to make it separate
17:00:00 <abadger1999> @acozine @samccann is website testing a blocker for 2.10?  From previous discussions, I think you would like it to be.
17:00:26 <acozine> @abadger1999 yes, testing for any docs headed for the website is a blocker for us
17:00:27 <nitzmahone> abadger1999: that was my first thought as well, though docs and whatever ... it's definitely borderline
17:00:48 <acozine> every day we leave the module docs untested, errors creep in
17:00:51 <abadger1999> @mattclay Okay, so it needs to be discussed today.
17:01:19 <geerlingguy> docs is definitely a blocker imo—I can't imagine launching 2.10 and having docs mess all over the place
17:01:57 <abadger1999> #topic testing of website build for ansible-2.10
17:01:58 <geerlingguy> especially since 99% of the time the answer should be "look at this docs page"—if docs are broken all support lands in IRC or yelling into the wind
17:02:16 <abadger1999> So... I guess question (1) what can we still do after beta1?
17:02:20 <acozine> it's going to be hard enough for people to adapt with good docs; if the docs disappear it will be chaos
17:02:36 <felixfontein> devel module docs are mostly already gone :)
17:03:39 <abadger1999> Like, I'm sure that mattclay would tell us that tests that run separately from commits don't block 2.10beta1.
17:03:45 <nitzmahone> abadger1999: seems like almost anything, since docs can release updates as often as needed
17:04:02 <abadger1999> @nitzmahone These are tests, though.
17:04:13 <abadger1999> @nitzmahone and ansible-test freezes along with the rest of ansible-base.
17:04:20 <mattclay> What's the current state of docs testing in ansible-base?
17:04:33 <abadger1999> So that means there are limits but we need to establish what those are.
17:04:44 <acozine> we're still testing the rst docs
17:04:49 <acozine> in ansible-base
17:05:10 <abadger1999> <nod> So those would be the static site and the modules which are hosted in ansible-base's repo, correct?
17:05:46 <acozine> yes, the static site for sure gets tested (I've broken it myself recently . . . thank you for saving me, ansible-test)
17:05:47 <abadger1999> and the test is... run makesinglehtmldoc as part of the sanity test?
17:06:00 <acozine> yes, I believe so - it hasn't changed
17:06:14 <abadger1999> Oh... and that is only run for ansible/ansible.... it's not run as part of sanity for collections.
17:06:23 <acozine> true
17:06:36 <acozine> so it runs on `ansible.builtin`
17:06:44 <acozine> but not on anything else
17:07:52 <abadger1999> Is there also an ansible-doc --json sanity test which is run for collections?  (So that would check that documentation is parsable.... not necessarily that documentation is well-formed as ansible-doc doesn't validate.)
17:08:03 <mattclay> Do we have a list of specific docs testing blocker issue(s) for 2.10 then? I'm not clear on what (if anything) needs to change at this point.
17:08:32 <acozine> when collections break module docs that we're publishing to the docsite, we can post a special 404 page (in theory, the work to do this hasn't been done), but we need a way for collection owners to test their docs
17:09:32 <abadger1999> okay, so we can decide that we don't have to have a test in ansible-test for 2.10 that collection owners run to see if their docs will format correctly?
17:09:48 <abadger1999> (sorry, my grammar sucks)
17:10:00 <acozine> where do the rest of the collections tests live?
17:10:13 <abadger1999> in ansible-test.
17:10:15 <acozine> are collections generally using `ansible-test`out of ansible/ansible?
17:10:17 <acozine> okay
17:10:27 <abadger1999> there's a set of tests which ansible-test sanity runs on collections.
17:10:42 <abadger1999> and a (superset?) of that which ansible-test sanity runs on -base.
17:11:16 <abadger1999> mattclay: ^ I don't know the answer to that.. you might.... but you might not as well.
17:11:53 <acozine> the best solution would be to run the docs build on collections, but that introduced dependences mattclay had concerns about IIRC
17:12:41 <mattclay> ansible-test has two sets of sanity tests -- those which run on everything (collections and ansible-base) and those that only run on ansible-base.
17:12:47 <abadger1999> mattclay: (For the answer to your question, I think we're trying to figure that out now... pushing down the road questions like testing because we didn't have the rest of the code in place yet.)
17:14:01 <abadger1999> acozine: "are collections generally using `ansible-test`out of ansible/ansible?" are you asking what version of  ansible-test they're running?
17:14:33 <acozine> in other cases, we are providing separate tools for collections, like the changelogs
17:14:55 <abadger1999> yeah, for building the website... if we want to build the whole website, there will be more deps.
17:15:15 <acozine> but we don't and won't do that with testing - that's what I wanted to confirm
17:15:25 <acozine> one tool for everything, and it lives in the ansible/ansible repo
17:15:38 <acozine> * for testing everything
17:16:14 <samccann> One tool to rule them all....
17:16:16 <acozine> I'm not opposed, just making sure I udnerstand
17:17:18 <abadger1999> @acozine Do you mean, "You want to confirm that ansible-test sanity will or will not do a whole website build"?
17:17:38 <abadger1999> (and then we have to define what whole website means)
17:18:22 <nitzmahone> it seems like ansible-test should be doing *less* with docsite build sanity as things become more distributed
17:18:22 <acozine> I wanted to confirm that 1. ansible-test sanity will not try to build docs from collections and 2. we do not plan to create something like antsibull-collections-test
17:18:48 <abadger1999> (2) I do not want to do that.
17:19:13 <abadger1999> But there probably needs to be a sanity test which does the equivalent of that.
17:19:19 <acozine> nitzmahone: that's fine, as long as we have some way to test or at least provide feedback for broken docs in collections
17:19:26 <mattclay> ansible-test should be testing plugins to make sure they follow all the necessary rules (docs provided, schema valid, embedded docs rst correct, etc.) -- but it shouldn't care about docs site generation. Either the plugins are correct or they're not -- docs site generation shouldn't be related to that.
17:19:27 <abadger1999> (when it gets added to ansible-test becomes a question)
17:20:01 <nitzmahone> Otherwise we get to intractable circular dependencies
17:20:02 <mattclay> The only reason ansible-test should need to care about docs site generation is because the docs site currently lives in ansible/ansible.
17:20:19 <abadger1999> (1) That seems reasonable... but there's a few other nuances from me.... what about building the docs for ansible-builtin?
17:20:36 <nitzmahone> Why should that be any different?
17:20:37 <acozine> mattclay: are we currently testing collection-based plugins to prove that docs are provided, the schema is valid, and the embedded docs are rst correct?
17:20:45 <mattclay> acozine: Yes
17:20:52 <acozine> okay, then we are good, I think
17:21:05 <abadger1999> nitzmahone: So.... it seems like tests should run on a repo when the releavnt files are checked into that repo, correct?
17:21:22 <mattclay> acozine: Although there's less testing of non-module plugins (validate-modules only tests modules currently), but the embedded rst checking is for all plugin types.
17:22:42 <mattclay> Basically we should be able to assert that docs in plugins from a collection won't break a docs site build without having to do the docs site build, since we know what the docs embedded in plugins should look like.
17:23:02 <abadger1999> nitzmahone: If the answer is yes... these are things I think follow from that goal:   (1)  The tests are hosted in ansible-test... so they have to be present there before it is "frozen".  (2) When a change to an ansible-builtin is PR'd/merged... we would want that test to run on the ansible/ansible repo.
17:23:16 <mattclay> If there are gaps in those tests, we should fill them in rather than trying to use a full docs site build as a substitute for proper validation.
17:23:32 <abadger1999> mattclay: We don't test the schema.  (We have a partial schema for modules.  We have no schema for non-module plugins)
17:23:43 <mattclay> abadger1999: That's a gap we should be fixing
17:23:46 <nitzmahone> abadger1999: tests that the proposed changes in that repo are semantically correct, yes, but tests that a huge external beast of a process runs successfully on those inputs beyond the semantically-correct validation? Probably not...
17:24:01 <abadger1999> mattclay: <nod>  I have a way to fill that for you.... but I need to talk to you about it.
17:24:17 <acozine> so if we're seeing docs decay in collections-based modules, our problem is "people aren't running the docs tests on collections" rather than "there are no tests for docs in collections"
17:24:32 <acozine> still a problem, but a very different solution
17:25:24 <abadger1999> @nitzmahone Not sure.... Like I say, I do have a way to provide a schema which could be run to validate things.  That would be light weight.  but there is an ask right now that since the website is hosted in ansible/ansible.... changes to the portions of the website in ansible/ansible need to be tested.
17:26:03 <abadger1999> which seems like it's probably reasonable.... the website is a deliverable and ansible/ansible is hosting a portion of its source code, yes?
17:26:09 <nitzmahone> ... and I'd say that's probably moving the wrong direction- I've historically been an advocate for keeping docsite in ansible/ansible, but I think we're at a point now where that's more a liability than a benefit
17:26:59 <mattclay> We should try to maintain a clear distinction between the two parts of docs testing: 1) testing docs content extracted from plugins (ansible-base or collections) and 2) the docs site itself, including static content, generation tools, etc. -- which should only be a concern for the docs site and not collections
17:27:04 <nitzmahone> The primary benefit in the past was that feature PRs could include the relevant docs changes all at once. That almost never happens now that we have a full-time docs team that generates content separately from their impls
17:27:49 <samccann> Hmm feels to me like that still happens
17:27:52 <abadger1999> I don't think the docs team agrees that they're writing docs separately....
17:28:33 <nitzmahone> Really? I can't think of the last time I saw a feature PR that shipped with all its docs in the same PR
17:28:36 <samccann> We do author some of it but most of the collections info for example has come from feature prs
17:28:43 <abadger1999> #info one issue we have is that the non-website-build ansible-test tests do not check the whole schema
17:28:54 <mattclay> separately as in a separate PR -- yes, separately as in different project -- no
17:29:04 <nitzmahone> It made sense when we didn't have a docs team, so the dev responsible for the feature also wrote the docs
17:29:09 <abadger1999> #action abadger1999 to talk to mattclay about some possibilities he has for rectifying the schema.
17:29:18 <acozine> since the docs team is two people for all of core and collections, we can't write all docs separately, I certainly hope developers will continue to provide at least basic docs for code changes
17:29:41 <samccann> We want to keep that developer writing docs with their features
17:30:07 <abadger1999> #agreed we do not have to do anything in ansible/ansible to solver people are not running the docs tests against their collections.
17:30:18 <cyberpear> docsite in ansible/ansible has been very helpful for adding docs in the same PR as a change
17:30:30 <samccann> If the features are in ansible/ansible the docs should be
17:30:54 <acozine> nitzmahone: what is the liability of continuing to do it that way?
17:31:37 <nitzmahone> As the codebase is split into smaller parts, that we end up having circular dependencies on things like testing/validation
17:31:57 <nitzmahone> ansible-test shouldn't have deps on things like Sphinx
17:31:59 <mattclay> I understand wanting docs in ansible/ansible. If it was just a collection of unstyled rst files that would be one thing, but it's also evertything else needed to build the full docs site.
17:32:32 <cyberpear> w/ circular deps, comes a need for a "bootstrap" mode of building stuff to break the circle
17:32:44 <abadger1999> nitzmahone: it feels like ansible-test should be split out from ansible-base... because for ansible-test to be the one-stop testing framework for collections... it does need to depend on things like sphinx.
17:33:09 <mattclay> I think sphinx is a bad example.
17:33:14 <mattclay> Collections shouldn't need that to test.
17:33:28 <mattclay> Unless we're going to start supporting static docs in collections (not plugin docs).
17:33:37 <samccann> Yes
17:33:44 <mattclay> samccann: Yes to what?
17:33:46 <abadger1999> yes, that's a plan.
17:33:55 <samccann> Scenario guides for example should be in their collection
17:34:01 <acozine> eventually collections will need/want static docs as well as module docs
17:34:47 <acozine> however, I think this discussion is drifting
17:35:11 <acozine> we started with "what are the blockers for 2.10 beta" and I think we've answered that
17:35:11 <mattclay> OK, circling back to what we need this week for freeze. Do we have any concerns/action items to address before end of day Friday?
17:35:12 <cyberpear> ansible-doc is very helpful for when there's no internet
17:35:19 <samccann> As in we should move scenario guides out of ansible/ansible when we have support for this in collections. They would be pulled in to the docs build fro there
17:36:08 <mattclay> While the rest of this discussion has been good, we should defer the non-blocker parts until after beta.
17:36:13 <acozine> mattclay: I agree
17:36:32 <abadger1999> To try and refocus... I think there's a few testing threads here... (1) What tests do we need in ansible-test so that people can test their collections will build as part of dociste correctly? (2) What tests do we need to run as part of anible-test on the ansible-base repo (3) Which of these things can go in after freeze?
17:37:20 <felixfontein> sorry for being quiet... was busy cooking
17:37:28 <acozine> abadger1999: yes, and if I've followed this, the answer to (1) is: tests for this already exist in `ansible-test`
17:37:56 <acozine> at least for now, with only docs from python being built from collections
17:38:06 <abadger1999> (1) is somewhat...
17:38:23 <felixfontein> abadger1999: there's a `ansible-doc --json` test here: https://github.com/ansible/ansible/pull/69288
17:38:49 <abadger1999> website build doesn't run collections.  So we depend on the schema, right?  And the schema validates modules (probably 90%) but it doesn't operate on plugins.
17:40:01 <abadger1999> Would a new test that completes the schema be allowable after freeze?  Would it , even if it is a complete reimplementation?
17:40:38 <abadger1999> Do we care for 2.10 (since modules are the majority of the plugins people are building?)
17:41:17 <mattclay> As much as I'd like to see complete schema validation, I don't think we should be landing that after freeze (or even trying to rush to get it in before freeze, given that's less than 2 days).
17:41:46 <abadger1999> For (2) + (3).. we have a website-build test for everything in ansible/ansible right now.  The build is going to change.  So can we fix the build test to use the new stuff after 2.10 freeze?
17:42:19 <acozine> I think building docs for non-module plugins would be great, but I'm willing to let it slide to 2.11, given the crunch we're under
17:42:20 <felixfontein> I think having that in devel soon will already be good enough, since at least the big collections use devel's ansible-test
17:42:23 <abadger1999> mattclay: <nod>  I tend to agree with you abut not going in after freeze as it will mean that collections would suddenly start failing to validate.
17:42:25 <mattclay> We should be able to, since the docs site build is not shipped with the product.
17:42:53 <mattclay> Anything in `test/sanity/` is ansible-base specific and we don't ship it with ansible-base, so we have more flexibility to change it after freeze.
17:43:57 <abadger1999> Okay, so I'm going to put #1 as, we're going to rely on whatever the current ansible-test ansible-doc extraction and the validate-modules schema catches.... plugins and other things will not be checks.
17:44:56 <abadger1999> mattclay: Cool, and that's separable in a way that whatever new deps get added to make that work are okay... at least for 2.10?
17:46:27 <mattclay> abadger1999: Since the docs site build isn't shipped as part of 2.10 we do have the flexibility to change those tests after freeze, add new deps, etc.
17:46:37 <abadger1999> mattclay: Cool.
17:47:11 <mattclay> Speaking of freeze, we'll be branching for stable-2.10. Which brings up the question, what are we doing to recommend for collection testing?
17:47:38 <acozine> meaning, `stable-2.10` vs. `devel`?
17:47:44 <mattclay> If collections are testing against devel, they're going to be soon testing against in-development 2.11 features, sanity tests, etc. instead of 2.10.
17:48:03 <mattclay> Which is probably not what we want, leading up to the 2.10 release.
17:48:16 <abadger1999> #agreed we can rely on the current tests in ansible-test (ansible-doc parsing for everything and avlidate-modules does a 90% shcema validation for modules) to cover the most problematic test cases for 2.10.
17:49:04 <mattclay> We probably want to communicate to collection maintainers that they should switch their testing to use stable-2.10 instead of devel once we've branched.
17:49:06 <abadger1999> #agreed ansible/ansible will continue to test all parts of the docsite that ship within the ansible/ansible repo
17:49:28 <abadger1999> #agreed updates to the website build test which only runs against ansible/ansible can be put in after freeze.
17:49:48 <abadger1999> #action abadger1999 to update the website build and website build test
17:50:12 <abadger1999> @acozine @mattclay  Take one moment to make sure my agreeds above were good and covered everything
17:50:28 <acozine> +1 looks good
17:51:02 <samccann> +1
17:51:07 <mattclay> +1
17:51:32 <abadger1999> Thanks :-)
17:51:43 <mattclay> Any thoughts on my concerns around using stable-2.10 vs devel for testing collections after freeze?
17:52:05 <acozine> mattclay: we can add a note to https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#testing-collections to say "please test against the stable ansible-base version you are targeting"
17:52:12 <abadger1999> mattclay: that sounds like a good plan.... When would we want to recommend that collection owners start testing with devel again?
17:52:47 <nitzmahone> At some point we'll need to figure out a way for people to test against all the Ansible versions they claim to work with :)
17:53:00 <abadger1999> or is our recommendation actu^Wnitzmahone, you beat me to it ;-)
17:53:17 <acozine> heh
17:53:33 * nitzmahone had my morning Dew ;)
17:54:12 <mattclay> I suppose it's going to depend on the individual collection maintainer when it comes to how soon they want to start testing against a new version.
17:54:16 <abadger1999> So maybe we want an announcement (part of the ansible-base-2.10beta1 release announcement?) that collection owners should now be testing their collection with both branches?
17:54:47 <mattclay> Some may want to test against devel always, but that's more than many probably can handle.
17:54:52 <mattclay> Some will want to start at beta.
17:54:58 <mattclay> Others may want to wait for RC or even GA.
17:55:16 <abadger1999> and some will be testing against stable-2.10  five years from now ;-)
17:55:32 <abadger1999> Oh, what is galaxy going to do when it starts running ansible-test sanity on import?
17:55:45 <abadger1999> Maybe that's another set of people to talk to about this.
17:55:47 <samccann> Hmmm but collections in ansible have to test against that before release right?
17:55:51 <mattclay> abadger1999: Ideally it will run it for each ansible version the collection claims to support.
17:55:57 <mattclay> Otherwise the tests are incomplete.
17:56:00 <felixfontein> samccann: they better should!
17:56:01 <abadger1999> <nod> yeah.
17:56:07 <samccann> (Acd)
17:56:41 <abadger1999> samccann: No-ish.... we don't have a way to track that or enforce it at the moment.
17:56:53 <samccann> Since we own the quality of ansible seems that’s a hard requirement
17:56:59 <abadger1999> When galaxy does start runnin ansible-test sanity on import, we will be able to get that information from there.
17:57:05 <mattclay> I hope most collections won't test against devel once 2.10 is released, unless they really want to be trying out features in development. I think for most collections beta or RC is more reasonable. 2.10 is a special case due to all the changes we're making around collections support.
17:58:11 <samccann> So at the least there is metadata in the collection that has to say 2.11 for example in order to be in 2.11 ansible?
17:58:53 <abadger1999> samccann: I don't believe so... but there was talk about an ansibl-base compatibility field being added.... I can look and see if it's there now.
17:59:53 <samccann> Yeah not a 2.10 blocker for sure but should be for the next ansible release that depends on ansible-base 2.11
18:00:23 <abadger1999> samccann: Not in the metadata for any of the collecitons I just checked
18:00:26 <abadger1999> :-(
18:02:02 <acozine> is that a conversation for 2.11?
18:02:06 <nitzmahone> Yeah, there's an optional `requires_ansible_version` key in meta/runtime.yml where collections can specify a range
18:02:30 <abadger1999> @nitzmahone Okay... how does that become available for others to use?
18:02:31 <mattclay> Are we done with the 2.10 blocker discussions then?
18:02:35 <acozine> aka next week?
18:02:46 <nitzmahone> @abadger1999: not sure what you mean?
18:02:46 * acozine could use some lunch . . .
18:02:56 * mattclay could use some breakfast
18:03:14 <samccann> Me could use some whiskey
18:03:14 <abadger1999> yeah, if samccann doesn't think this latest thing is a blocker and mattclay  is find with the text to be added to developing_collections.html#testing-collections  I think we're done
18:03:17 <nitzmahone> we can take this part offline, go eat, ppl!
18:03:19 <samccann> Heh
18:03:32 <abadger1999> mattclay: Oooh, breakfast sounds good.  I'll be able to get that in an hour (after my *next* meeting)
18:03:35 <samccann> No not a blocker
18:03:39 <abadger1999> Cool.
18:03:45 * abadger1999 writes the final actions
18:03:45 <mattclay> Thanks everyone.
18:03:48 <acozine> thanks for running the meeting abadger1999
18:03:49 <abadger1999> and will close
18:04:22 <abadger1999> No problem.. Thanks to gundalow for getting it started and mattclay nitzmahone acozine samccann  and felixfontein for getting all the blockers discused
18:05:20 <abadger1999> #action acozine to add  "please test against the stable ansible-base version you are targeting" to https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#testing-collections
18:05:53 <abadger1999> #agreed need to figure out a way to start using requires_ansible_version for building ansible for 2.11
18:06:09 <abadger1999> #action abadger1999 to open a bug to look into requires_ansible_version for building ansible for 2.11
18:06:14 <abadger1999> Thanks evreyone
18:06:16 <abadger1999> #endmeeting