Posted	Nick	Remark
#openstack-nova - 2017-10-27
22:00:24	openstackgerrit	OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/511035
22:01:35	openstackgerrit	OpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements https://review.openstack.org/511035
22:12:38	openstackgerrit	Merged openstack/nova master: rt: Implement XenAPI get_inventory() method https://review.openstack.org/339204
22:32:30	rm_work	Do you guys have a feel for how commonly deployments use the AZ extension?
22:32:45	rm_work	I'm curious if it's close to 100%, or much less
22:33:38	mriedem	i'd say pretty common
22:33:46	openstackgerrit	Eric Fried proposed openstack/nova master: Granularize resources_from_{flavor|request_spec} https://review.openstack.org/515223
22:33:46	openstackgerrit	Eric Fried proposed openstack/nova master: Parse granular resources/traits from extra_specs https://review.openstack.org/515151
22:33:47	openstackgerrit	Eric Fried proposed openstack/nova master: ResourceRequest.to_querystring() https://review.openstack.org/515811
22:33:49	mriedem	but probably better input if you ask in #openstack-operators
22:33:56	rm_work	hmm, k
22:41:25	bfife	kashyap / melwitt; thanks for https://review.openstack.org/#/c/514339/. what i came here to sort out :-)
22:45:50	fried_rice	mriedem Okay, so here's how those deprecations work with ksa...
22:46:28	fried_rice	If you were to access the deprecated opt directly (e.g. CONF.placement.os_region_name), you would get the deprecation message from the deprecated_reason.
22:46:32	fried_rice	But you would never do that.
22:47:01	fried_rice	What actually happens is you call utils.get_ksa_adapter, which references that var from within ksa, where it keys off of the fact that we passed that guy as a deprecated opt.
22:47:28	fried_rice	whereupon it emits the warning that looks like: WARNING:oslo_config.cfg:Option "os_region_name" from group "placement" is deprecated. Use option "region-name" from group "placement".
22:48:31	fried_rice	So... it's only useful for me to even put the deprecated_reason into the conf for developers' eyeballs to look at. (Unless the deprecation shows up in the config sample - but it doesn't, does it?)
22:48:43	mriedem	it does show up in the conf sample
22:48:47	mriedem	which is why i asked for it
22:48:51	mriedem	otherwise you have to look at the others to see the link
22:49:27	fried_rice	mriedem Okay, cool. Will fix.
23:09:53	openstackgerrit	Eric Fried proposed openstack/nova master: Use ksa adapter for placement conf & requests https://review.openstack.org/492247
23:10:00	fried_rice	mriedem Done, I think ^
23:10:18	fried_rice	mriedem Though I built the conf sample, and I couldn't get that stuff to show up in it...
23:10:31	fried_rice	I think the deprecation from ksa is doing some funkiness that overrides.
23:10:51	fried_rice	but at least it's visible to the guy looking at the file.
23:11:09	fried_rice	I want to say I looked at all of this when I first started slinging this blueprint around, but clearly I've slept since then.
23:11:21	mriedem	ok
23:13:01	bauwser	mriedem: heh, related kaboom https://bugs.launchpad.net/nova/+bug/1721522
23:13:02	openstack	Launchpad bug 1721522 in OpenStack Compute (nova) "encrypted volumes: Cannot format device /dev/sdb which is still in use" [Undecided,Incomplete]
23:13:44	bauwser	mriedem: looks like the folk asked for sdb
23:14:06	bauwser	oh even better https://docs.openstack.org/cinder/pike/configuration/block-storage/volume-encryption.html
23:14:26	mriedem	because we pass the user-supplied device to the cryptsetup command rather than taking what we calculated as the device ourselves?
23:14:43	bauwser	openstack server add volume --device /dev/vdc TESTVM 'encrypted volume'
23:14:48	mriedem	openstack server add volume --device /dev/vdc TESTVM 'encrypted volume'
23:14:50	mriedem	heh
23:14:51	mriedem	yeah
23:15:03	bauwser	mriedem: looks like
23:15:12	mriedem	probably need a .. note:: that says "don't pass device"
23:15:20	bauwser	:)
23:15:28	bauwser	I'll wait for the reply
23:16:00	bauwser	mriedem: also FYI https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L621
23:16:23	bauwser	even if the user doesn't specify it, OSC forces it
23:16:28	mriedem	yeah you already showed me that
23:16:45	mriedem	i'd say that should all be deprecated in osc
23:16:48	bauwser	ah yeah
23:17:24	mriedem	looks like chenrui added a bunch of that
23:17:26	mriedem	he's at huawei
23:17:37	bauwser	cool
23:18:05	mriedem	although it also looks like that predated his changes https://github.com/openstack/python-openstackclient/commit/95c8661f86e74c9d5217869a740da11350f1f0eb
23:20:17	mriedem	https://github.com/openstack/python-openstackclient/commit/2c9d263611190996d64e35bc74a8575aeb25ed3e
23:20:20	mriedem	anyway, deprecate it
23:20:26	mriedem	Kevin_Zheng: ^ :)
23:20:28	bauwser	mriedem: indeed
23:20:51	bauwser	that change trampled your colleague
23:21:40	bauwser	wait, it's Saturday now here
23:22:13	bauzas	mriedem: before going to bed, I'd love your thoughts on https://bugs.launchpad.net/nova/+bug/1723165
23:22:14	openstack	Launchpad bug 1723165 in OpenStack Compute (nova) "Volume is not detached when deleted VM was in error state" [Undecided,New]
23:22:52	bauzas	that's not a quota problem, just the fact we don't unattach the volumz
23:23:28	bauzas	I tend to think it's legit
23:23:39	Kevin_Zheng	mriedem: will check latter, 4th Saturday of the month... still have to work
23:29:00	mriedem	bauzas: sounds like a bug
23:29:08	mriedem	we don't test image-defined bdms very well
23:29:15	mriedem	error scenarios anyway
23:29:23	bauzas	triaging it
23:29:40	bauzas	if it's something else, then meh
23:31:21	mriedem	bauzas: oh i see,
23:31:27	mriedem	so it goes to error state in the compute service,
23:31:37	mriedem	because that's going to create some new volumes in cinder from the snapshot bdms
23:31:42	mriedem	cinder fails on the volume create because overquota
23:31:47	bauzas	right
23:31:59	mriedem	and we probably don't "detach" the volumes because we never attached them in the first place - because of overquota
23:32:41	mriedem	or maybe we attached 2 but didn't finish one of them in time, idk
23:33:08	bauzas	looks like it's the instance which fails, not the volume creation
23:33:11	mriedem	would probably be helpful for them to give us the information about the volumes after the failure
23:33:17	mriedem	like their status and if they show an instance id
23:33:20	bauzas	because the volume is there
23:33:33	mriedem	but the instance failure would be due to _prep_block_devices failing to create the last volume
23:33:41	mriedem	because cinder returns overquota
23:33:45	mriedem	they started with 3 volumes,
23:33:48	mriedem	snapshot
23:33:53	mriedem	set vol quota to 5
23:34:04	mriedem	create new instance from the image snapshot which has 3 image-defined bdms in it,
23:34:09	mriedem	so nova is going to create 3 more volumes from the snapshot bdms,
23:34:17	mriedem	2 will get created, 1 will fail with overquota from cinder
23:34:26	mriedem	which makes _prep_block_devices fail and the instance goes to ERROR state on the compute
23:34:43	bauzas	right
23:55:46	bauzas	mriedem: last point, are we unquoting a shelved instance or not ?
23:56:09	bauzas	of course, an offloaded instance
23:56:23	bauzas	I think we shouldn't
23:57:11	mriedem	can't talk about bugs anymore
23:57:22	mriedem	go to be you crazy frenchman
23:57:26	mriedem	*bed
23:58:16	bauzas	:p
23:58:44	bauzas	we have 18 open bugs and next week, I'll have a talk about bug triaging :p
23:59:45	mriedem	yeah i know why you've been on top of it,
23:59:53	mriedem	you should have to give a talk about bug triaging every quarter
#openstack-nova - 2017-10-28
00:00:10	mriedem	we reserve quota for an unshelved instance,
00:00:14	mriedem	*shelved offloaded

Earlier   Later