Posted	Nick	Remark
#openstack-nova - 2017-11-14
20:41:09	mriedem	*again
20:41:39	dansmith	or we start disabling jobs that don't work, per the discussion :)
20:41:40	mordred	whatdididonow?
20:41:53	mriedem	in this case it's easier probably to just disable the job
20:42:12	mriedem	mordred: we have a cve fix for newton that can't pass the gate b/c dsvm jobs fail trying to install neutron,
20:42:15	mriedem	because neutron newton is eol
20:42:19	dansmith	mordred: we're trying to backport a cve fix to nova's newton branch and can't because neutron has eol'd theirs
20:42:39	mordred	ah. yah.
20:43:26	tonyb	mriedem: s/features/fixes/ on that backport is fine by me.
20:43:33	mriedem	um, cinder newton must be eol too
20:43:37	mriedem	http://logs.openstack.org/19/516119/1/gate/legacy-tempest-dsvm-cells/9e11a37/logs/devstacklog.txt.gz#_2017-11-14_17_21_45_400
20:43:45	tonyb	Oh rats :(
20:43:51	mriedem	it is
20:43:53	smcginnis	mriedem: Everyone is EOL on Newton I thought.
20:43:56	mriedem	so yeah, dsvm just won't work on netwon
20:44:00	mriedem	smcginnis: except nova
20:44:13	smcginnis	mriedem: You snooze you lose.
20:44:15	tonyb	Yeah everyone except nova, ironic and cycle-trainling
20:44:28	mriedem	tonyb: ok so looking at https://review.openstack.org/#/c/516119/
20:44:33	dansmith	mriedem: the question comes up if we should even release newton if we never ran a devstack job against it
20:44:49	mriedem	tonyb: i'd have to skip these jobs
20:44:51	mriedem	legacy-tempest-dsvm-cellsFAILURE in 19m 44slegacy-tempest-dsvm-multinode-live-migrationFAILURE in 19m 43slegacy-tempest-dsvm-neutron-fullFAILURE in 18m 41s
20:44:53	openstackgerrit	Merged openstack/nova stable/ocata: Correct log message when removing a security group https://review.openstack.org/519585
20:45:15	mriedem	dansmith: well this patch passed dsvm on 10/30 https://review.openstack.org/#/c/516119/
20:45:56	dansmith	mriedem: but you can't get a dsvm job run on the actual cve fix anymore right?
20:45:59	mriedem	somehow https://review.openstack.org/#/c/519684/ did run legacy-tempest-dsvm-neutron-full earlier today
20:46:04	mriedem	^ did
20:46:44	tonyb	mriedem: Yeah we only have 2 options patch devstack to work with eol-tags or accept the risk and drop the dsvm tests
20:47:14	mriedem	i could try patching devstack, but it might be awhile
20:48:04	dansmith	mriedem: hmm, how did that work?
20:48:07	mriedem	dansmith: no idea
20:48:12	mriedem	not sure if there are mirrors involved
20:48:25	tonyb	I can also try to see how bad it is but not until after I've dropped the kids at school
20:48:32	mriedem	ok, so i'm goign to get the reno backported for pike and ocata, then get the release requests up for those branches and will deal with newton
20:48:39	mriedem	s/school/pool/
20:48:56	tonyb	;P
20:50:11	openstackgerrit	Matt Riedemann proposed openstack/nova stable/pike: Add security release note for OSSA-2017-005 https://review.openstack.org/519752
20:50:15	tonyb	newton is xenial right?
20:50:45	mriedem	yes
20:50:58	tonyb	cool
20:51:41	openstackgerrit	Matt Riedemann proposed openstack/nova stable/ocata: Add security release note for OSSA-2017-005 https://review.openstack.org/519753
20:55:07	dansmith	mriedem: tonyb: +2 on the reno backports
20:55:12	openstackgerrit	Matt Riedemann proposed openstack/nova stable/newton: Validate new image via scheduler during rebuild https://review.openstack.org/519684
20:55:12	openstackgerrit	Matt Riedemann proposed openstack/nova stable/newton: Pass requested_destination in filter_properties https://review.openstack.org/516119
20:55:13	openstackgerrit	Matt Riedemann proposed openstack/nova stable/newton: Add security release note for OSSA-2017-005 https://review.openstack.org/519755
21:00:10	tonyb	looks like they're good to go on > newton
21:00:19	mriedem	yes
21:00:31	mriedem	i'll propose releases for pike and ocata once the reno is merged
21:00:34	openstackgerrit	Eric Fried proposed openstack/nova master: build ProviderSummary objects in sep function https://review.openstack.org/516779
21:00:34	openstackgerrit	Eric Fried proposed openstack/nova master: begin refactor AllocCandidates._get_by_filters() https://review.openstack.org/516778
21:00:35	openstackgerrit	Eric Fried proposed openstack/nova master: create allocation request for single provider https://review.openstack.org/516781
21:00:35	openstackgerrit	Eric Fried proposed openstack/nova master: build alloc request resources for shared resources https://review.openstack.org/516780
21:00:36	openstackgerrit	Eric Fried proposed openstack/nova master: required traits for no sharing providers https://review.openstack.org/517027
21:00:36	openstackgerrit	Eric Fried proposed openstack/nova master: finish refactor AllocCandidates._get_by_filters() https://review.openstack.org/516782
21:00:37	openstackgerrit	Eric Fried proposed openstack/nova master: handle traits with sharing providers https://review.openstack.org/517119
21:00:37	openstackgerrit	Eric Fried proposed openstack/nova master: Add ProviderSummary.resource_class_names @property https://review.openstack.org/517646
21:00:38	openstackgerrit	Eric Fried proposed openstack/nova master: Test alloc_cands with one RP shared between two RPs https://review.openstack.org/519617
21:00:38	openstackgerrit	Eric Fried proposed openstack/nova master: Test alloc_cands with non overlapping sharing RPs https://review.openstack.org/519380
21:00:39	openstackgerrit	Eric Fried proposed openstack/nova master: Test helper: validate provider summaries https://review.openstack.org/518982
21:00:39	openstackgerrit	Eric Fried proposed openstack/nova master: Test allocation candidates: multiple aggregates https://review.openstack.org/518633
21:00:59	efried	jaypipes ^ Addressed most of the comments in this series.
21:01:12	efried	jaypipes There are still bugs; but I think alex_xu might be willing to +2 the bottom one at this point.
21:03:56	tonyb	mriedem: cool, I'll keep an eye out
21:04:47	openstackgerrit	OpenStack Proposal Bot proposed openstack/os-vif stable/pike: Updated from global requirements https://review.openstack.org/493146
21:15:58	efried	dansmith stephenfin When you get a chance, would you please put eyeballs back on https://review.openstack.org/#/c/377138/ -- at this point it's just in a sisyphean rebase cycle.
21:20:08	moshele	stephenfin: hi
21:22:50	oomichi	mriedem: scheduler-hints is one of gross API designs. Do we have more related patches except https://review.openstack.org/#/c/519717 ?
21:24:25	moshele	ramishra: hi
21:25:50	mriedem	oomichi: nope
21:26:05	mriedem	dansmith: here is my devstack newton-eol trickery https://review.openstack.org/519758
21:26:18	mriedem	thanks to google for providing bash substring tips
21:26:39	dansmith	mriedem: wow that's... special
21:26:44	mriedem	heh
21:27:23	mriedem	eol_tag=$(echo ${git_ref:7:${#git_ref}})-eol
21:27:27	mriedem	is the best piece of coding i've done in ages
21:27:30	dansmith	mriedem: heh
21:27:56	efried	mriedem What's the 7-char prefix there?
21:28:03	mriedem	stable/
21:28:04	dansmith	stable/
21:28:05	mriedem	strip that off
21:28:35	efried	Then eol_tag=${git_ref#stable/}-eol would work too
21:28:59	efried	You know, if you're a shell guy rather than a python guy.
21:29:21	mriedem	so it doies
21:29:27	mriedem	i am not a shell guy
21:29:36	efried	Furthermore, that syntax will work all the way back to ksh88
21:29:43	efried	Which is important.
21:29:50	efried	In case you're running this script on AIX
21:29:56	mriedem	fuck i wish
21:32:06	mriedem	updated, thanks for the tip
21:32:11	cburgess	mriedem OK sorry... things got.. crazy here. I'm reading what your wrote hours ago now.
21:33:43	efried	mriedem Sure thing. But also x=foo is the same as x=$(echo foo)
21:34:22	cburgess	mriedem OK so... back to the live migration cancel thing, I think its probably reasonable to be able to cancel queued or running.
21:45:58	mriedem	cburgess: ack
21:45:59	mriedem	good to know
21:46:10	cburgess	I agree there is a bit of race condition though.
21:46:17	mriedem	apparently our operators are annoyed that they queue up a bunch of live migrations and can't abort some of them before they hit the hypervisor
21:46:33	mriedem	tonyb: ok redoing this newton series with the depends-on
21:46:35	cburgess	As in you want the API to fast fail if the state is wrong, but that state can change by the time you hit the compute node.
21:46:43	mriedem	and had to slip another funtional test backport in the mix
21:47:04	mriedem	cburgess: yeah i think we'd just have to ignore it if we got to the compute and something changed,

Earlier   Later