Posted	Nick	Remark
#openstack-sdks - 2019-12-05
16:24:55	sshnaidm	gtema, to keep old modules you mean?
16:24:58	dtantsur	sshnaidm: #actions requires <who>
16:25:07	sshnaidm	#action sshnaidm to collaborate with pabelanger to create sync zuul jobs
16:25:20	pabelanger	gtema: freeze should be as long as we all agree, final sync looks good and we can rm -rf ansible/ansible
16:25:32	pabelanger	we should be able to drive delete date
16:25:36	dtantsur	gtema: until they are removed from ansible/ansible. then it's bugfix-only mode.
16:25:52	pabelanger	that means, getting content uploaded into galaxy and some sort of pre-release versioning
16:26:00	gtema	ok then. I just wanted to avoid freeze, which will keep us ourselves with tied hands
16:26:33	gundalow	FYI for bug fixes for ansible/ansible:stable-2.9, once you've gitrm'd from devel you can create a PR directly against that branch, rather than `git cherry-pick -x` from devel into stable-2.9
16:26:43	sshnaidm	and these bugfixes should be done in openstack repos since moving, right?
16:26:46	gundalow	Which may mean one fewer things to keep moving
16:27:36	gundalow	Once the collection is done, I'd expect bug fixes do be done in the collection first. Then optionally made to ansible/ansible:stable-2.9. Realistically I expect fewer backports to ansible/ansible once Collections are up and running
16:27:56	sshnaidm	gundalow, lemme understand, 2.9 backports via ansible github, all new - via our repos, right?
16:28:00	dtantsur	hmm, that's the opposite direction
16:28:25	pabelanger	backwards?
16:28:40	gtema	"main dev on our side"
16:28:54	gtema	and "port" fixes back to ansible-2.9
16:29:06	pabelanger	that seem correct to me
16:29:23	sshnaidm	gtema, I think we shouldn't port there, maybe only some critical fixes
16:29:43	gtema	that's exactly about critical things, but I do not expect those honestly
16:29:56	pabelanger	it raises the question of maybe stable backports team?
16:30:15	pabelanger	which can handle sync to github
16:30:30	gtema	I don't think that just for 2.9 it make sense to have this overhead
16:30:35	gundalow	Current backport docs: https://docs.ansible.com/ansible/latest/community/development_process.html#backporting-merged-prs
16:30:35	gundalow	Before Collections: 1) PR to `devel`, 2) wait for that to be merged. 3) For bug fixes only Create backport PR to `stable-2.x`
16:30:37	sshnaidm	I don't think we should backport anything to 2.9 at all, it looks working as is, and no much activity was there
16:30:46	dasp	Can I get some reviews on https://github.com/ansible/ansible/pull/65339 and https://github.com/ansible/ansible/pull/65292 ? (new qos_policy modules for Ansible)
16:31:07	pabelanger	sshnaidm: we can't say that however, as ansible/ansible still maintans that
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

Earlier   Later