| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-04 | |||
| 10:13:54 | openstackgerrit | Chen proposed openstack/nova master: doc: update info for hypervisors https://review.openstack.org/599554 | |
| 10:14:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: WIP: Use placement from separate repo in functional test https://review.openstack.org/599556 | |
| 10:16:37 | openstackgerrit | fupingxie proposed openstack/nova master: Delete allocations for instances that have been moved to another node https://review.openstack.org/582899 | |
| 10:56:04 | stephenfin | prometheanfire: Oh, yeah, I'm around now (and for the next 6 hours or so - I'm GMT) | |
| 11:29:42 | kashyap | stephenfin: Most excellent: | |
| 11:30:13 | kashyap | <controller type='pci' index='1' model='pcie-root-port'> | |
| 11:30:13 | kashyap | <model name='pcie-root-port'/> | |
| 11:30:13 | kashyap | ... | |
| 11:30:14 | kashyap | </controller> | |
| 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, | |