Earlier  
Posted Nick Remark
#openstack-sdks - 2019-12-05
16:34:29 gundalow then gitrm & add `migrated_to` in BOTMETA.yml
16:34:29 gundalow Once we've got publishing to Galaxy done and a final check we will see if there have been any other changes to grafana code in ansible/ansible, copy those across
16:34:29 gundalow I've create a new repo and the maintainers are doing there work there (CI is up, they are merging stuff)
16:34:32 pabelanger right, not out of the question but we can ask infra
16:34:37 dtantsur we extracted a git subtree from ironic, then asked infra adminds to push it :)
16:34:44 pabelanger right
16:35:06 dtantsur gundalow: sounds right and simple
16:35:22 gundalow I'd avoid having to keep too many things in progres, and even fewer things in sync
16:35:48 gundalow So maybe create a test collection, play with it, check it works. then do the move for real
16:36:07 sshnaidm (and I think we have some job that testing modules, it runs on github changes)
16:36:07 gtema therefore if we here (mostly the only ones approving changes in ansible) agree not to review anything else during releasing collection - we are fine
16:36:36 sshnaidm gtema, I think we can agree here
16:36:44 gundalow There is an OpenStack specific Zuul job that runs against OpenStack PRs in ansible/ansible
16:37:08 sshnaidm gundalow, yeah, exactly, we can import it for collections repo
16:37:15 gtema now with tests: from what I have experienced as of now with collections - you MUST modify plybooks
16:37:15 gundalow +1
16:37:15 sshnaidm as a start
16:37:31 dtantsur #agreed No periodic sync, just one-time migration with temporary freezes on both sides (ending with `git rm` on the ansible side)
16:37:32 dtantsur right?
16:37:44 gundalow gtema: ansible-test (in 2.9) has been updated so it should work without FQCN (Fully Qualified Collection Name)
16:37:46 sshnaidm dtantsur++
16:38:01 gtema gundalow, ah ok. Nice to know
16:38:13 gundalow dtantsur: Please add + add `migrated_to: openstack.FOO` in `.github/BOTMETA.yml`
16:38:18 gundalow In the same PR
16:38:20 dtantsur #undo
16:38:21 openstack Removing item from minutes: #agreed No periodic sync, just one-time migration with temporary freezes on both sides (ending with `git rm` on the ansible side)
16:38:35 gtema but then we need to change our jobs to use "ansible-test" instead of "ansible-playbook". Right?
16:38:40 dtantsur #agreed No periodic sync, just one-time migration with temporary freezes on both sides (ending with `git rm` and `migrated_to: openstack.FOO` on the ansible side)
16:38:49 dtantsur gundalow: like ^^?
16:39:06 sshnaidm gtema, ansible-test is just a different tool afaiu
16:39:16 sshnaidm with sanity checks etc
16:39:39 gtema yeah, looks like that
16:39:43 sshnaidm maybe let's set a time for the moving?
16:39:50 sshnaidm when can we do it?
16:40:01 sshnaidm gundalow, any restrictions..?
16:40:11 gundalow dtantsur: perfect, thank you
16:40:21 gtema gundalow, what do I need to do not to use FQCN?
16:40:30 dtantsur probably not right before winter holidays :)
16:40:36 dtantsur or are we in time pressure?
16:40:44 sshnaidm dtantsur, yeah, before xmass of after :)
16:40:52 gundalow I'd suggest you continue to use `ansible-test sanity` that will help spot functional problems
16:41:00 dtantsur I'm here next week, then out till January
16:41:27 gundalow realistically I'd say play now (do a trial move, get CI working, define merging/+1, etc), move in Jan
16:41:33 gtema gundalow, our tests run "ansible-playbook ..."
16:41:38 sshnaidm if no time pressure, let's do after holidays
16:41:45 gundalow Jan is fine for me
16:42:11 dtantsur any specific dates?
16:42:16 dtantsur right the week of 6th or?
16:42:41 sshnaidm dtantsur, we'll need to sync maybe
16:42:45 gundalow I'm back on the 13th Jan
16:43:08 sshnaidm pabelanger, are you available in Jan?
16:43:49 sshnaidm dtantsur, I think we can start at 13 then
16:44:00 dtantsur let's put it this way
16:44:07 sshnaidm dtantsur, or at least to decide to postpone it then
16:44:10 dtantsur #agreed Do the migration in the middle of January 2020
16:44:35 gtema gundalow, any change to "survive" with "ansible-playbook our_tests.yml"?
16:44:49 gundalow gtema: So continue to use `ansible-playbook` directly for integration tests if that's how you currently do things 2) Please look at using `ansible-test sanity` in your new repo (currently this is run via Shippable on ansible/ansible PRs), this *will* catch valid issues that your integration tests may not
16:45:10 sshnaidm ok, let's get back to agenda then
16:45:19 sshnaidm are we keeping them GPL?
16:45:29 gundalow gtema: unsure, if you speak to mattclay in #ansible-devel he might be able to give some ideas
16:45:30 dtantsur can we practically re-license them?
16:45:30 gtema but I mean ansible-playbook will fail when there is "git rm"
16:45:37 sshnaidm or we start develop new in Apache2?
16:45:57 dtantsur then we'll need clean-room development (without looking at old ones)
16:46:07 gtema gundalow, ok, will ask in #ansible-devel, but this is important to verify the whole migration
16:46:36 gtema dtantsur: without looking will be very hard
16:46:52 dtantsur exactly, but that's the condition of re-licensing via rewriting
16:46:55 gtema and we repeat all the issues we were fixing for ages
16:47:12 dtantsur otherwise we need an agreement from every contributor whose code is still there
16:47:13 sshnaidm https://bit.ly/2OUz1Xa
16:47:16 gtema I know, and this is not what I would like to do
16:47:46 dtantsur I'd keep shared bits permissive if possible, but the modules themselves probably have to be GPL
16:47:50 gtema this is terrible, even if one has changed a typo
16:48:00 sshnaidm are there licenses experts here? :)
16:48:17 pabelanger sshnaidm: yes
16:48:34 sshnaidm can we write new modules in different licenses?
16:48:41 sshnaidm I mean not in GPL
16:48:54 sshnaidm the goal is to deprecate old ones
16:49:06 gundalow git log --pretty=format:"%an%x09" lib/ansible/modules/cloud/openstack | sort | uniq | wc -l ----> 157
16:49:25 gundalow (may be some duplicates, though that's a lot of people to get sign off from)
16:50:05 sshnaidm wow
16:50:17 sshnaidm should we ask all 155 people to agree?
16:50:41 gundalow IANAL, though I if one person doesn't respond you can't do it
16:50:42 sshnaidm I don't think it's doable at all
16:51:02 sshnaidm gundalow, but it's for re-licensing, I'm talking about new modules develop
16:51:20 sshnaidm I think it's kinda gray area here..
16:51:43 dtantsur it's grey indeed. how to distinguish new development from copy-pasting in case of very similar code?
16:51:59 sshnaidm no idea, need license experts opinion :)
16:52:24 sshnaidm although I hope it won't be copy paste
16:52:48 dtantsur IANAL, only relaying what I've previously heard
16:52:50 sshnaidm we don't need to copy paste, we just have them available..
16:53:26 sshnaidm mnaser mentioned some license-... maillist, maybe worth to ask there
16:53:38 mnaser legal-discuss :)
16:53:42 dtantsur ^^^
16:53:44 sshnaidm mnaser, yes! :)
16:54:04 mnaser and yes i think you need to get all 155 people to agree AFAIK. but im not a license expert
16:54:21 dtantsur the problem as I understand it, if you're familiar with old code, you won't be able to claim you wrote the new code without taking from it.
16:54:28 sshnaidm ok, but modules that don't have a parallel I think we can start with Apache2
16:54:29 dtantsur I mean, legally claim, we all here believe you :)
16:54:49 dtantsur probably? I'd really bring it to legal-discuss

Earlier   Later