| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-05 | |||
| 16:32:34 | gundalow | sshnaidm: ++ KEEP THINGS SINGLE | |
| 16:32:38 | gundalow | SIMPLE | |
| 16:32:43 | gtema | I think: import, github freeze, collection release, github rm | |
| 16:32:48 | sshnaidm | single and simple :) | |
| 16:33:09 | gtema | github = ansible upstream | |
| 16:33:14 | sshnaidm | so no need to have sync jobs as well? | |
| 16:33:37 | sshnaidm | pabelanger, ^ | |
| 16:33:38 | gtema | if we handle import and first release in few days - I would say no | |
| 16:33:56 | pabelanger | well, need some import process to gerrit | |
| 16:34:00 | pabelanger | which, usually isn't manual | |
| 16:34:04 | pabelanger | so we need something automated | |
| 16:34:11 | pabelanger | or ask infra what they want to do | |
| 16:34:17 | dtantsur | well, we did a manual import for ironic-tempest-plugin | |
| 16:34:21 | dtantsur | it was a bit.. interesting | |
| 16:34:28 | gundalow | For grafana (own repe & collection). | |
| 16:34:28 | gtema | well, we have already changes in gerrit, so just more-or-less merge and release it | |
| 16:34:29 | gundalow | Then do $something with open grafana issues & PRs | |
| 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 | |