| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-15 | |||
| 14:45:18 | dansmith | which I will | |
| 14:45:22 | dansmith | but yeah | |
| 14:45:25 | Spaz-Home | Ahh that's unfortunate | |
| 14:45:27 | Spaz-Home | It's hard on our hours | |
| 14:47:32 | mriedem | bhagyashri_s: i've abandoned your spec since it looks, well, abandoned https://review.openstack.org/#/c/511825/ | |
| 14:47:51 | mriedem | needs to be moved to the rocky directory structure and incorporate the direction from the PTG | |
| 14:51:45 | mriedem | simondodsley: are you going to move this to rocky? https://review.openstack.org/#/c/340168/ it's proposed against pike | |
| 14:54:06 | mriedem | sean-k-mooney: does anyone care about this anymore? https://review.openstack.org/#/c/471815/ | |
| 14:54:20 | mriedem | i don't know if baoli is around anymore re: cisco | |
| 14:54:40 | mriedem | mgagne: ^ seems like something that would be up your alley | |
| 14:56:03 | mriedem | or vdrok ^ i.e. vlan trunk port metadata bliss | |
| 14:56:44 | openstackgerrit | Nguyen Hai proposed openstack/python-novaclient master: Fix local test fails with pypy https://review.openstack.org/553426 | |
| 14:57:24 | openstackgerrit | Nguyen Hai proposed openstack/python-novaclient master: Fix local test fails with pypy https://review.openstack.org/553426 | |
| 15:00:00 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add disabled field to CellMapping object https://review.openstack.org/550090 | |
| 15:00:20 | mgagne | mriedem: thanks for the heads-up | |
| 15:00:22 | dansmith | mriedem: comments in that rebuild-bfv spec | |
| 15:00:27 | mriedem | mgagne: do you still plan on pushing this spec? https://review.openstack.org/#/c/312626/ it's targeted at pike and would need to be moved to rocky and address reviewer feedback | |
| 15:00:49 | dansmith | mriedem: I might be the only one, but doing a create, delete and re-pointing at a new volume seems like not a great experience to me | |
| 15:01:58 | efried | I assume (because I've not seen it done) that it's Wrong to point to specs from comments/docstrings. | |
| 15:03:26 | efried | Reason I ask: http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/update-provider-tree.html#computedriver-update-provider-tree contains a lot more information than I want to put into https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L833 | |
| 15:03:40 | efried | But that information sure would be useful for people implementing that method. | |
| 15:03:59 | mriedem | efried: just say "see the update_provider_tree spec for more details" | |
| 15:04:01 | mriedem | or something | |
| 15:04:21 | efried | Can I say "rocky" too? | |
| 15:04:33 | efried | That'd give them enough info to find it in one shot. | |
| 15:04:36 | mriedem | sure | |
| 15:04:46 | mriedem | or, move the dev details of that spec into devref | |
| 15:05:16 | mriedem | https://docs.openstack.org/nova/latest/reference/index.html | |
| 15:06:57 | dansmith | mriedem: tested by a real live person: https://review.openstack.org/#/c/552691 | |
| 15:06:59 | dansmith | per your ask | |
| 15:08:04 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add disabled field to CellMapping object https://review.openstack.org/550090 | |
| 15:08:51 | openstackgerrit | Claudiu Belu proposed openstack/nova-specs master: Adds spec for instance live resize https://review.openstack.org/141219 | |
| 15:08:51 | efried | mriedem: And then can I link to the devref, or do I still have to say, "See the [name] section of the devref for details" ? | |
| 15:12:23 | mriedem | efried: idk, choose your own adventure | |
| 15:12:48 | mriedem | linking to a devref is probably ok, the spec URL is long as hell | |
| 15:16:15 | mriedem | dansmith: agree the create/delete volume thing sucks | |
| 15:16:27 | mriedem | don't know how easy it would be for cinder to add an api to re-image a volume | |
| 15:16:30 | mriedem | smcginnis: ^? | |
| 15:17:23 | smcginnis | So detach, re-lay down an image on the vol, reattach? | |
| 15:17:27 | openstackgerrit | Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/553255 | |
| 15:17:46 | mriedem | not sure if we'd need the detach/re-attach part | |
| 15:17:50 | dansmith | smcginnis: yeah | |
| 15:17:51 | mriedem | but that's what happens during rebuild anyway yeah | |
| 15:17:54 | dansmith | mriedem: I assume we would for some backends | |
| 15:17:55 | mdbooth | mriedem: Would you mind taking a look at https://review.openstack.org/#/c/551302/ ? I think it's your bailiwick. | |
| 15:18:34 | mriedem | is a bailiwick related to a throat sweet? | |
| 15:18:51 | smcginnis | mriedem: I think we would need the detach reattach. | |
| 15:19:03 | smcginnis | We need to attach it to a cinder node to reimage it. | |
| 15:19:04 | mriedem | smcginnis: that's fine probably b/c we do it anyway for rebuild | |
| 15:19:14 | smcginnis | Unless nova wants to take care of that part and leave cinder out of it. | |
| 15:19:19 | hrw | morning | |
| 15:19:22 | smcginnis | Basically just duplicate what we do in cinder. | |
| 15:19:41 | smcginnis | Pull the image to the compute node, write it over the volume, then start up the instance again. | |
| 15:19:43 | mriedem | it seems like nova doing things with the internals of the volume is a bad idea | |
| 15:19:49 | mdbooth | mriedem: Not especially :) I think there's still a literal bailiwick in the channel islands. | |
| 15:20:04 | dansmith | mriedem: I dunno, it's no different than a regular disk image, | |
| 15:20:04 | hrw | can someone help me with understanding how nova compares cpus on live migration? | |
| 15:20:08 | openstackgerrit | Mathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information https://review.openstack.org/312626 | |
| 15:20:13 | smcginnis | mriedem: I agree, but it would be an "optimization" to not have to tear things down and start over. | |
| 15:20:19 | dansmith | mriedem: the thing is I would expect cinder to maybe be able to do it more efficiently in some cases (i.e. ceph) | |
| 15:20:29 | smcginnis | Especially as I'm not sure how that would work with a boot volume. We can't detach those normally, right. | |
| 15:20:42 | dansmith | smcginnis: we're talking about bfv here | |
| 15:20:50 | dansmith | smcginnis: we're doing a rebuild, so we'd detach | |
| 15:20:52 | smcginnis | dansmith: Yeah, so that would be an extra complication. | |
| 15:20:59 | smcginnis | dansmith: Oh, right! | |
| 15:21:00 | openstackgerrit | Mathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information https://review.openstack.org/312626 | |
| 15:21:29 | mriedem | the volume would remain in-use during all of this from a state pov | |
| 15:21:30 | smcginnis | So delete instance, detach volume, cinder rewrites it, reattach, create new "rebuilt" instance using it. | |
| 15:21:56 | mdbooth | dansmith: Could also be a multi-attach volume, btw. | |
| 15:22:01 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Add CellMappingList.get_all_enabled() query method https://review.openstack.org/550188 | |
| 15:22:18 | mriedem | this is the code that detaches the volume today for rebuild https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3072 | |
| 15:22:20 | dansmith | mdbooth: if people are multi-attaching bfv then I give up | |
| 15:22:33 | mriedem | we create a 2nd attachment to keep the volume 'in-use' and then delete the first attachment | |
| 15:22:40 | dansmith | well, unless it's read only I guess | |
| 15:22:45 | mdbooth | dansmith: It's a thing with real hardware. | |
| 15:23:03 | dansmith | but yeah, if we can't undo all the attachments, we'd have to fail I think | |
| 15:23:38 | mriedem | before we spawn the guest again, we 'attach' again https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3103 | |
| 15:23:47 | hrw | https://bugs.launchpad.net/nova/+bug/1756118 reported | |
| 15:23:48 | openstack | Launchpad bug 1756118 in OpenStack Compute (nova) "No live migration on aarch64" [Undecided,New] | |
| 15:23:55 | mdbooth | ... unless the volume was attached RO | |
| 15:24:00 | openstackgerrit | Jianghua Wang proposed openstack/os-traits master: GPU: define traits for maximum display heads https://review.openstack.org/553277 | |
| 15:24:44 | mriedem | hrw: "nova doesn't support operation x for an architecture that no one started caring about nova supporting until recently" isn't a bug :) | |
| 15:25:01 | hrw | mriedem: it works in newton. | |
| 15:25:03 | mdbooth | That's a good point. Can you rebuild a server whose root disk is read-only? | |
| 15:25:28 | hrw | mriedem: on newton we have libvirt 2.2.10 and live migration from nova level on aarch64 works. | |
| 15:25:52 | hrw | mriedem: on queens we have libvirt 3.8/3.10 and it does not on nova level but does on libvirt level | |
| 15:26:11 | mriedem | hrw: ok that's info that should be pointed out in the bug report then | |
| 15:26:16 | hrw | will do | |
| 15:27:08 | hrw | added | |
| 15:27:29 | hrw | mriedem: bug raport is more to signal issue as I will dig into it to find out what is going on | |
| 15:28:25 | openstackgerrit | Merged openstack/os-traits master: Add HW_NIC_SRIOV_TRUSTED trait https://review.openstack.org/550873 | |
| 15:28:42 | hrw | mriedem: have to find out where get_connection().CompareCPU() is defined | |
| 15:29:03 | hrw | mriedem: as it looks like suspicious place ;d | |
| 15:29:23 | mriedem | my guess would be nova.virt.libvirt.host | |
| 15:31:03 | hrw | mriedem: nova.virt.libvirt.host.compare_cpu() calls self.get_connection.compareCPU() | |
| 15:32:09 | mriedem | mdbooth: dansmith: i think we'd just say you can't rebuild a volume-backed server with a new image using a multiattach volume if that volume has >1 attachment | |
| 15:32:19 | dansmith | right, | |
| 15:32:22 | dansmith | at least for the moment | |
| 15:32:43 | mriedem | and if it's a leap year because that's a lot of conditionals | |
| 15:42:02 | mriedem | would like to see another core review the flavor extra specs in GET /flavors/detail spec https://review.openstack.org/#/c/544158/ - discussed at the ptg and it's pretty straight forward | |