Posted	Nick	Remark
#openstack-nova - 2018-09-04
12:37:32	kashyap	sean-k-mooney: Ah, never mind, saw this: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5114-L5119
12:39:30	mnaser	the next fun step is going to be upgrading our mtl region
12:39:32	mnaser	that will be the fun one
12:47:41	openstackgerrit	Stephen Finucane proposed openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587
12:52:29	openstackgerrit	Brin Zhang proposed openstack/nova master: Need further updates, no need to review https://review.openstack.org/599276
13:26:10	openstackgerrit	Jay Pipes proposed openstack/nova-specs master: allow transferring ownership of instance https://review.openstack.org/599598
13:27:05	jaypipes	melwitt: ^^ example of needed coordination between nova and placement. /me hopes the extraction won't be too much of a distraction
13:44:13	openstackgerrit	Jay Pipes proposed openstack/nova-specs master: allow transferring ownership of instance https://review.openstack.org/599598
13:54:48	mriedem	jaypipes: can you push the spec and such against the old existing bp for the same thing? https://blueprints.launchpad.net/nova/+spec/transfer-instance-ownership
13:56:24	sean-k-mooney	jaypipes: i have been asked how to do that in the past. mainly for teaching cases where we wanted to be able to prepare a buncn of vms for people then give them the vm.
13:57:04	mriedem	this is more than just placement coordination,
13:57:14	mriedem	it's also cinder, neutron, glance, castellan/barbican right?
13:58:11	openstackgerrit	Jay Pipes proposed openstack/nova-specs master: allow transferring ownership of instance https://review.openstack.org/599598
13:58:12	mriedem	plus maybe whatever is managing the vm? trove/heat?
13:58:20	jaypipes	mriedem: done.
13:59:08	sean-k-mooney	trove/heat should really only need to expose an api to initate the transfer the rest should be handeld in nova right?
13:59:16	jaypipes	mriedem: I'm not trying to coordinate between cinder, neutron or glance in the spec. only placement and nova. I note the other integration points and why I'm not trying to add orchestration functionality to nova.
14:00:08	jaypipes	mriedem: I'm afraid absolutely nothing would get done at all if we try to boil the ocean like previous attempts have done.
14:00:19	mriedem	that would effectively break us
14:00:28	mriedem	if you create a vm which creates a volume and a port,
14:00:29	jaypipes	mriedem: what would effectively break us?
14:00:36	mriedem	and then change the owner of the vm, we'll fail to delete the volume/port
14:00:52	jaypipes	mriedem: why would you delete the volume/port?
14:00:57	mriedem	b/c that's what we do
14:01:03	mriedem	delete_on_termination=true for bfv,
14:01:04	sean-k-mooney	jaypipes: from a placement perspecitive did we settle on the idea that neutron and cinder resouces would be conumed by the instance e.g. the instance uuid is used as the consumer rather then neutorn port uuid ecta.
14:01:07	mriedem	and nova cleans up the ports it creates
14:01:14	jaypipes	mriedem: who said anything about terminating anything?
14:01:37	mriedem	we can assume that someone would eventually try to delete these resources
14:01:57	mriedem	if this is stricly baremetal instances b/c oath, then let's be clear about that
14:02:04	jaypipes	mriedem: let's discuss this on the review, eh
14:02:04	mriedem	but even baremetal instances can boot from volume now
14:02:24	jaypipes	mriedem: this is not strictly bm instances for oath, no...
14:02:25	mriedem	sure
14:02:41	jaypipes	I'm really not sure why you think that.
14:02:56	jaypipes	I'm not sure what about the spec as written gave you that impression.
14:08:42	tobias-urdin	hm is there any easy way to figure out if an instance is volume backed using novaclient?
14:09:27	mriedem	yes
14:09:32	mriedem	image_ref is ''
14:10:29	mriedem	*image
14:10:37	mriedem	normally it's a dict with an id and link,
14:10:40	mriedem	but for volume-backed, it's just ''
14:11:12	mriedem	https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/views/servers.py#L332
14:15:50	mriedem	comments inline
14:15:55	mriedem	jaypipes:
14:18:41	tobias-urdin	mriedem: thanks!
14:23:43	tobias-urdin	mriedem: and if you need to get a list of all attached volume and know which one is the root volume?
14:25:05	tobias-urdin	sorry got it get_server_volumes()
14:25:57	tobias-urdin	if it's one volume that easy, otherwise should you rely that device=/dev/vda always is the first that is booting
14:26:02	tobias-urdin	?
14:27:24	mriedem	device name doesn't really mean anything,
14:27:28	mriedem	nova ignores it if supplied
14:27:46	mriedem	boot_index is what you'd want, but i don't think we expose that out of the api
14:28:20	mriedem	we certainly could, and probably should if we ever want to get device_name out of the API for volumes
14:30:05	tobias-urdin	hm ouch so the boot index cant be access through any api calls listing server info or block device mappings or similar
14:31:12	tobias-urdin	can the boot_index be changed from nova's perspective? because the only way I could work around that would be relying on the creation date of the volumes
14:31:20	sean-k-mooney	tobias-urdin: if you need a reliable way to assicate volumes with devices in the guest you need to use tags
14:33:52	tobias-urdin	sean-k-mooney: ok, don't think that helps what i'm trying to do. i need to get the root volume if its a volume backed instance
14:34:27	tobias-urdin	i guess other than creation date i could check if the volume was created from an image with the cinder api, but that could fail as well if somebody attaches a volume for recovery
14:34:58	sean-k-mooney	tobias-urdin: e.g. novas boot form volume form image or boot with a precreated volume
14:36:01	tobias-urdin	after checking i can't see nova populating the image field even when booting from a volume + image during creation
14:36:35	sean-k-mooney	mdbooth: wasn't someone working on ^^
14:37:10	mriedem	which image field?
14:37:36	mriedem	i forgot about tags - yes you could use tags to say which is the root volume during boot from volume, but we don't expose the bdm tags out of the API either :)
14:37:42	tobias-urdin	whichever Server.image from novaclient provides
14:37:50	mriedem	i have related specs for both of those things i think
14:38:04	mriedem	yes that's on purpose - the server.image is '' if volume-backed
14:38:14	mriedem	the image backing the root volume is in the volume metadata
14:38:41	mriedem	in "volume_image_metadata"
14:39:23	mriedem	https://review.openstack.org/#/c/452546/ is related to getting device_name out of the API,
14:39:27	tobias-urdin	is that exposed out of the api and novaclient?
14:39:36	sean-k-mooney	volume_image_metadata is a copy of the glance metadata for an image pluse i think an image ref of some kind i think ?
14:39:53	mriedem	tobias-urdin: which? volume_image_metadata?
14:40:03	mriedem	tobias-urdin: that's on the volume, so nova doesn't expose it, cinder does,
14:40:04	mriedem	but yes
14:41:25	mriedem	https://review.openstack.org/#/c/393930/ also related to exposing bdm tags out of the compute api
14:41:28	mdbooth	volume_image_metadata doesn't need to have a corresponding glance image, btw.
14:41:36	mriedem	which overlaps with https://review.openstack.org/#/c/452546/
14:41:51	mdbooth	But it's used in the same way and has the same semantics.
14:43:43	mdbooth	mriedem: Yeah, it's weird we don't expose that.
14:44:14	mdbooth	tags via the rest api, that is.
14:44:36	mriedem	just hasn't been done - i've had the specs, been defeated, then found new agreement but haven't found new motivation for doing the work
14:46:45	tobias-urdin	found what i needed in volume_image_metadata atleast, just have to do some ugly assumptions for now based on volume_image_metadata and creation date since i cant access boot_index or block device mappings info
14:46:55	tobias-urdin	thanks for helping out :)
14:49:27	sean-k-mooney	tobias-urdin: this kind of think is something that could be a feature request to the openstacksdk/shade teams as getting the root volume for boot from volume is likely one of thoes things that will change alot depending on your env and could be handeld in a shade proxy api
14:49:46	mdbooth	tobias-urdin: In practise, it's probably going to be the one with volume_image_metadata.
14:50:28	mdbooth	Although I was reviewing a v2v tool the other day which added volume_image_metadata to multiple volumes, which would have broken that assumption, but I can't imagine that's common.
14:51:20	mdbooth	Creation data is less reliable, especially if you have persistent data on volume X, and created a root volume to contain an app to manipulate it some time later.
14:51:47	mdbooth	Unlike the first case, I'd expect that to be likely to happen in the wild.
14:52:39	tobias-urdin	sean-k-mooney: sort of pressing to get this stuff done (as always...) otherwise it would've been optimal to check the sdk first
14:53:04	tobias-urdin	mdbooth: yeah, i was thinking about combining if there is multiple volume_image_metadata just assume the first created.. atleast i would always get something
14:56:03	prometheanfire	stephenfin: hi :D
14:56:09	stephenfin	prometheanfire: o/
14:57:16	mdbooth	Not strictly related, but afaict we attach volumes in a non-deterministic order on restart, except for the root volume. And that's ok. We should probably deliberately randomise it :)
14:58:39	tobias-urdin	while I'm at it... here's a sad question, can I somehow block the creation of image backed instances? (i.e images_type backed instances)
14:59:29	tobias-urdin	policy, super simple api hack or similar, everything's allowed but the best would be to not really touch anything critical
14:59:38	prometheanfire	stephenfin: maybe my deployment is just broken, gimme a few to get out of this meeting and I'll update you
14:59:59	tobias-urdin	I was hoping on setting images_type to None but that errors out upon initialization
15:01:25	mdbooth	tobias-urdin: Don't deploy glance?
15:01:33	tobias-urdin	(oh how I wish there was a cinder backend for images_type right now, wish i familar enough with the codebase to drive such a work)

Earlier   Later