18:05:15 <gundalow> #startmeeting Ansible Community Meeting
18:05:15 <zodbot> Meeting started Wed Oct  7 18:05:15 2020 UTC.
18:05:15 <zodbot> This meeting is logged and archived in a public location.
18:05:15 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:05:15 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:05:22 <gundalow> #chair samccann lmodemal abadger1999
18:05:22 <zodbot> Current chairs: abadger1999 gundalow lmodemal samccann
18:05:32 <abadger1999> Howdy
18:05:53 <cybette> hei
18:06:07 <gundalow> #topic Ansible Fest and Contributors Summit
18:06:10 <gundalow> #chair cybette
18:06:10 <zodbot> Current chairs: abadger1999 cybette gundalow lmodemal samccann
18:07:14 <gundalow> #info Ansible Fest and Contributors Summit are taking place next week
18:08:52 <felixfontein> hey!
18:08:58 <felixfontein> just managed it :)
18:09:09 <gundalow> #info Main Contributors Summit is Thursday 15th starting at 10am Eastern Agenda https://etherpad.opendev.org/p/virtual-ansible-contributor-summit-october-2020
18:09:12 <gundalow> #chair felixfontein
18:09:12 <zodbot> Current chairs: abadger1999 cybette felixfontein gundalow lmodemal samccann
18:09:13 <gundalow> hey :)
18:09:42 <cybette> hi felixfontein !
18:09:47 <gundalow> lmodemal: Are you registered for AnsibleFest and Contributors Summit?
18:10:19 <felixfontein> hi gundalow and cybette! and of course everyone else :)
18:10:55 <lmodemal> I am doing that right now. samccann was explaining it to me earlier :)
18:11:03 <samccann> do you have the contributor summit link handy?
18:11:07 <samccann> (to register)
18:11:28 <lmodemal> Yes. These are workshops?
18:11:42 <samccann> sorry meant that for gundalow ^^
18:11:47 <lmodemal> Oh lol
18:12:12 <samccann> #link https://www.eventbrowse.com/city/london/event/ansible-contributor-summit-october-2020/
18:12:16 <samccann> there ya go!
18:15:12 <gundalow> Thanks
18:16:12 <gundalow> #topic General updates
18:16:55 <felixfontein> no updates from my side
18:17:28 <samccann> the only tidbit of interest in docs is that discussion about pulling the rst files out of the tarball(s)
18:17:37 <gundalow> I've put "2.11 inclusion criteria" on the Contributor Summit agenda
18:17:45 <felixfontein> I guess next week is time for Ansible 2.10.1, if we want to release every three weeks?
18:19:20 <felixfontein> there's also the discussion about including new collections in 2.10.x: https://github.com/ansible-collections/overview/issues/117
18:19:54 <felixfontein> and the related discussion about how to move stuff to collections that aren't contained in Ansible yet, but probably will be in 2.11.0
18:19:57 <felixfontein> (same issue)
18:22:40 <gundalow> If we were to do that, do we know what the proposed workflow would be?
18:24:01 <felixfontein> do you mean the technical aspects, or the non-technical (policy) aspects?
18:24:05 <gundalow> yes :)
18:24:22 <gundalow> lets start with technical, hopefully that's easier
18:25:24 <felixfontein> for adding new collections? just add them to `ansible.in`, and do a release, that should do the job. the changelog generator should announce the new collection.
18:26:03 <felixfontein> for moving content, I guess adding the collection (with the moved content), then (or in the same ansible release) deprecate the old content, and in 2.11.0 remove the content from the old collection and adding redirects to the new one
18:28:13 <samccann> hmm so does that mean adding a new collection is allowed in 2.10.x?
18:28:17 <gundalow> would ansible-base's runtime.yml still point to c.g? Could we even update it due to dependencies between ansible-base and version of c.g
18:28:31 <felixfontein> in case we don't want to add new collections to 2.10.x, I'm not sure how to do the move correctly - at least not if the move should be completed for 2.11.0
18:28:42 <felixfontein> samccann: that's a policy question :)
18:29:05 <samccann> heh sorry :-)
18:29:05 <felixfontein> gundalow: it would still point to c.g I guess, since we can't update it anymore
18:30:16 <felixfontein> I'm really wondering whether there should be an exception for updating ansible_buildin_runtime.yml once more, to finalize a lot of moving. otherwise people *must* install community.general even if they don't want to use it, because the redirects for modules/plugins moved out of it do not work without it
18:31:20 <felixfontein> (well, of course they can always use the new FQCN to work around that.)
18:31:45 <gundalow> I'd love to continue update `ansible_buildin_runtime.yml` when things move out of community.(general,network)
18:32:39 <felixfontein> me too, just to avoid the redirect mess and indirect dependence on c.g that this results in
18:32:50 <felixfontein> but I can also understand that core wants to keep that file frozen
18:32:55 <gundalow> nitzmahone: I know we agreed no new entries to `ansible_buildin_runtime.yml`, though is it OK to update as we move content out of community.general to (say) community.postgres collection
18:34:06 <felixfontein> maybe we could agree on allowing one more time to update ansible_builtin_runtime.yml, maybe for ansible-base 2.12.0? by then, I'd expect that most material that wants to move out of c.g/c.n has been moved out
18:34:14 <felixfontein> (or I hope :) )
18:34:48 <nitzmahone> The bigger issue is that if you don't keep the redirection around, there's an implied dependency on a newer dot release of core
18:35:34 <felixfontein> nitzmahone: I think we'll keep the redirect in c.g/c.n, but if ansible_builtin_runtime.yml isn't adjusted as well, people must install c.g/c.n for the redirects to work
18:35:41 <gundalow> c.g runtime would still redirect to c.postgres
18:35:41 <gundalow> ansible-base ansible_buildin_runtime.yml would point directly to c.postgres
18:35:57 <gundalow> ^ is what I'm assumed
18:36:24 <nitzmahone> You can argue it's a bugfix, but the original intent was that the target collections would be responsible for keeping the chain alive as things moved out of them. There really isn't a dependency on the target collection; someone that tries to use that redirect without having the other one installed will get an appropriate error, and you can still add a deprecation warning to the redirect to tell people
18:36:51 <nitzmahone> Ah, I see
18:37:22 <nitzmahone> If you're willing to keep the redirection around, I'm willing to take *limited* changes to the runtime file for sanity purposes like that
18:37:59 <felixfontein> :+1:
18:38:10 <gundalow> I think we have to keep c.g's runtime.yml correct as their will no doubt be people that have already updated to use `community.general.postgres_user`
18:38:16 <felixfontein> I think users of the new collections will thank you in the future for not having to install c.g ;)
18:38:27 <gundalow> c.g is a big ugly thing :)
18:38:36 <felixfontein> it is...
18:38:37 <nitzmahone> Heh, yeah- I think that's a reasonable compromise
18:39:17 <nitzmahone> It's just a slippery slope to `ansible_builtin_runtime.yml` becoming a living "where are they now?" document, which was absolutely not the intent.
18:39:46 <felixfontein> true
18:41:19 <nitzmahone> For the majority of folks that are using the `ansible` with all that stuff already included, it's probably not an issue, and that's what the builtin runtime was designed around.
18:42:22 <gundalow> Continual updates to `ansible_builtin_runtime.yml` might speed up the release of Ansible 3.0 :)
18:46:22 <gundalow> #agreed nitzmahone has said it's OK for us to continue to update `ansible_builtin_runtime.yml` for when content moves out of community.general (or community.network) into new dedicated collections as long as c.g continues to update it's `runtime.yml` to point to the new collection
18:46:30 <gundalow> Hopefully I captured that correctly
18:46:32 <gundalow> #chair nitzmahone
18:46:32 <zodbot> Current chairs: abadger1999 cybette felixfontein gundalow lmodemal nitzmahone samccann
18:46:36 <gundalow> Anything else?
18:47:09 <nitzmahone> Yep, so long as the collections will preserve the chain for existing `ansible-base` that points at the old location
18:49:16 <gundalow> Yup :0
18:49:17 <gundalow> :)
18:49:20 <gundalow> Thank you
18:49:33 <gundalow> I don't have anything else, apart from hunger
18:49:38 <gundalow> #chair
18:49:38 <zodbot> Current chairs: abadger1999 cybette felixfontein gundalow lmodemal nitzmahone samccann
18:49:46 <gundalow> Anyone got anything else to share?
18:50:20 <felixfontein> should we prepare something for the contributor summit for the 'new collections in 2.11 requirements'?
18:50:31 <gundalow> #info We will move away from Shippable (for all repos) before the end of the year. I might start looking at this shortly after Fest
18:50:32 <felixfontein> and more input on https://github.com/ansible-collections/overview/issues/117 would be nice :)
18:50:53 <felixfontein> gundalow: do you know when ansible/ansible will make the move?
18:50:55 <gundalow> prepare something for the contributor summit for the 'new collections in 2.11 requirements'? sounds good
18:51:13 <gundalow> felixfontein: I expect in the next month or two
18:51:44 <samccann> gundalow as in ansible/ansible will stop using shippable in a month or two?
18:51:49 <gundalow> I believe it technically works, some some procurement fun between Red Hat and Microsoft
18:52:01 <gundalow> samccann: We will be moving to Azure Pipelines
18:53:37 <samccann> yeah I remember that and created an issue to s/shippable/azure for the docs (it's mentioned a few times). I just forgot the timeframe
18:53:38 <felixfontein> does anyone know of a collection / repo that's already using Azure pipelines?
18:53:46 <felixfontein> would be interesting to see how it looks like
18:54:21 <gundalow> mattclay: ^
18:54:33 <gundalow> (or maybe nitzmahone knows)
18:54:34 <nitzmahone> mattclay has a sample repo- I can give you a job from yesterday
18:54:39 <gundalow> Thanks
18:54:51 <nitzmahone> https://dev.azure.com/ansible/ansible-azp/_build/results?buildId=1274&view=results
18:55:09 <nitzmahone> Here's the PR: https://github.com/ansible/ansible-azp/pull/1
18:55:10 <github-linkbot> https://github.com/ansible/ansible-azp/pull/1 | open, created 2020-09-18T21:36:05Z by mattclay: [devel] Test full matrix on Azure Pipelines.
18:55:45 <nitzmahone> He's still playing with the stages and nesting/naming stuff, but this is roughly what they'll look like
18:57:18 <tadeboro> I have collection tests running on CircleCI, GitHub Actions, and Gitlab CI, and they all look pretty much the same if you ignore the configuration file specifics.
18:57:51 <tadeboro> I guess testing Ansible is a bit trickier, but collections are not that problematic from my experience.
18:58:31 <felixfontein> nitzmahone: thanks!
18:59:35 <tadeboro> So I would imagine running tests on AZP works roughly the same.
18:59:44 <nitzmahone> You can see some of the nasty bits there, eg the AZP status checks are much more verbose since they surface the individual job detail onto the PR- bug or feature, depending on how you look at it ;)
19:02:05 <tadeboro> nitzmahone: CircleCI does the same thing. For example https://github.com/sensu/sensu-go-ansible/pull/222
19:02:40 <gundalow> tadeboro: By design all the logic is in `ansible-test` so contributors have the same experience if running on their laptops or $random_CI_provider
19:02:46 <nitzmahone> Matt C has an open feature request to Microsoft to allow pipeline/stage/job level granularity on status checks, but no idea if/when they'll get to tit
19:02:48 <nitzmahone> *it
19:06:16 <tadeboro> gundalow: We added a small abstraction layer over ansible-test in our case: a Makefile. And yes, if the docker is functional, running ansible test is really easy.
19:06:29 <gundalow> Glad to know it's working
19:06:45 <felixfontein> github actions is pretty annoying to use on my laptop, by default I can only see ~three lines of console output. I need to put my browser in fullscreen mode (or the console log view into fullscreen mode). Azure seems to look better though
19:06:54 <gundalow> and to be fair, I have a bit of logic to install the other needed dependent collections
19:07:24 <felixfontein> ansible-test with --docker is really easy to run. without it, I don't have much experience :)
19:07:24 <gundalow> sorry for the distraction about Shippable vs Azure Pipeline. Though I wanted to share it as it got confirmed this week
19:08:18 <nitzmahone> same with `--venv`; even `--local` is ok if you're willing to "pollute" your current Python env by adding `--requirements`
19:08:38 <tadeboro> We do not use docker for sanity and unit tests, but molecule does need it.
19:08:40 <nitzmahone> (eg letting ansible-test set up all the pip-installable requirements for you)
19:09:47 <tadeboro> nitzmahone: This is what we have in our Makefile. + we instruct andone who would like to hack on our collection to use venv and that is it.
19:10:07 <gundalow> Back to Ansible 2.11 collection inclusion critera
19:10:20 <gundalow> I think there are technical and no technical bits
19:11:51 <gundalow> 1) Testing (ansible-tets sanity) against $FIXME versions of Ansible
19:11:51 <gundalow> 2) License of code
19:11:51 <gundalow> 3) Q: Anything that meets checlist, or is there some voting
19:11:51 <gundalow> 4) Q: Minimum numbers of maintainers
19:11:51 <gundalow> 5) Q: When could/MUST collections be removed
19:11:52 <gundalow> 6) Always FQCN
19:13:49 <felixfontein> 2) is something we haven't really talked about yet, I think
19:14:26 <felixfontein> and 4) can be tricky
19:15:32 <gundalow> I'm just throwing random stuff out, that we may/maynot care about
19:17:23 <felixfontein> for 2), I think requiring GPL for modules/plugins and BSD or GPL for module_utils (i.e. as in ansible) isn't a bad thing
19:17:39 <felixfontein> would also make it easier to declare a license for the Ansible package
19:18:06 <felixfontein> no idea whether all collections currently in Ansible satisfy that though
19:19:23 <gundalow> I've thrown 1-6 in https://etherpad.opendev.org/p/virtual-ansible-contributor-summit-october-2020 Line 82
19:20:32 <abadger1999> At minimum, I think plugins do have to be licensed GPLv3 compatible.
19:21:09 <felixfontein> abadger1999: yep, that's enforced by GPLv3 itself
19:22:28 <gundalow> oh, and should tick https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
19:26:43 <gundalow> I need to drop off in a minute
19:26:50 <gundalow> and I notice we are at 90 minutes
19:26:52 <abadger1999> gregdek's vision of the ansible package was kind of like Fedora or Debian.... any collections that wanted to be a part of ansible and met the guidelines.  So I don't think (3) should be voting unless there's some cornercase.  Like "Rule: Has sufficient CI testing"  and then a reviewer doesn't agree that there is enough testing yet.
19:27:15 <gundalow> abadger1999: I'm OK with that as long as we document it
19:30:54 <abadger1999> Okay.... So being at ninety minutes+, do we want to end the meeting now?
19:32:50 <felixfontein> sounds good to me
19:33:19 <gundalow> Thanks everybody
19:33:23 <gundalow> #endmeeting