Earlier  
Posted Nick Remark
#openstack-sdks - 2019-12-05
16:31:18 gundalow Unless I see a critical bug, I'm not going to be backporting anything to stable-2.9 after we've gitrm'd from devel
16:31:21 gtema dasp - wrong channel. We are deciding to drop that at all ;-)
16:31:29 sshnaidm pabelanger, I think we agree it should be something exceptional
16:31:36 pabelanger +1
16:31:46 dtantsur okay, so do we even need a constant sync then?
16:31:52 sshnaidm gtema, :D
16:32:01 gundalow and "critical bug" is subjective, maybe you'd use that to your advantage :P
16:32:04 dtantsur or just copy everything once and apply some policies by humans?
16:32:20 sshnaidm dtantsur, I'd go for that for simplifying things
16:32:26 gundalow Maybe I could give an example of what I'm doing with Grafana
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 gtema well, we have already changes in gerrit, so just more-or-less merge and release it
16:34:28 gundalow For grafana (own repe & collection).
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: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 then gitrm & add `migrated_to` in BOTMETA.yml
16:34:29 gundalow Then do $something with open grafana issues & PRs
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 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:07 sshnaidm (and I think we have some job that testing modules, it runs on github changes)
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 sshnaidm as a start
16:37:15 gundalow +1
16:37:15 gtema now with tests: from what I have experienced as of now with collections - you MUST modify plybooks
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 gtema but I mean ansible-playbook will fail when there is "git rm"
16:45:30 dtantsur can we practically re-license them?
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

Earlier   Later