Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-04
11:30:21 kashyap stephenfin: That's the bit I was looking for.
11:31:39 kashyap I was wondering if we (wrongly) set an explict controller model like: <model name='ioh3420'/>
11:41:11 sean-k-mooney kashyap: ya perhaps.
12:10:06 efried Good morning nova
12:19:15 kashyap sean-k-mooney: Nova is not; so we're good there.
12:25:15 mnaser fwiw: rocky has been stable in sjc1 with a bunch of new clients coming on and being part of nodepool at ~50 vms (+ all bfv)
12:25:25 mnaser so congrats :)
12:29:57 openstackgerrit Surya Seetharaman proposed openstack/nova master: Merge security groups extension response into server view builder https://review.openstack.org/585475
12:29:58 openstackgerrit Surya Seetharaman proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092
12:29:59 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add scatter-gather-single-cell utility https://review.openstack.org/594947
12:30:00 openstackgerrit Surya Seetharaman proposed openstack/nova master: Merge extended_volumes extension response into server view builder https://review.openstack.org/596285
12:30:01 openstackgerrit Surya Seetharaman proposed openstack/nova master: Making instance/migration listing skipping down cells configurable https://review.openstack.org/592428
12:30:02 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList https://review.openstack.org/591656
12:30:03 openstackgerrit Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785
12:33:40 efried mnaser: ++ !
12:35:18 kashyap sean-k-mooney: Hey, when you're about: from yesterday's XML snippet from stephenfin, when _not_ setting any 'num_pcie_ports', why do we get 4 root ports: http://paste.openstack.org/show/729350/
12:36:43 gibi mnaser: thanks for the good news
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

Earlier   Later