| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-15 | |||
| 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 | |
| 15:42:54 | dansmith | oooh | |
| 15:43:01 | dansmith | I found a typo I could use to crush your stats | |
| 15:46:39 | dansmith | penick: all while making this face: https://cheappopculture.files.wordpress.com/2015/02/revolting-blob.png?w=825 | |
| 15:46:52 | artom_ | As a non-core observer, I feel like singing Sweet Dreams, but with Sweet changed to Crushed, would be appropriate | |
| 15:46:54 | openstackgerrit | Mathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information https://review.openstack.org/312626 | |
| 15:47:08 | penick | hahaha, that got a real laugh outta me | |
| 15:47:49 | mriedem | we changed to "extra_spces" in a microversion in queens | |
| 15:47:54 | mriedem | you must have missed that | |
| 15:48:16 | dansmith | oh mah bad | |
| 15:48:21 | penick | Crushed dreams are made of theeeese, who am I to disagree?, travel the world, to the p-t-g, everybody's like minus two | |
| 15:48:54 | artom_ | penick, noice | |
| 15:49:12 | penick | *fistpump* | |
| 15:49:49 | artom_ | Are... are we bros now? Is this what being a bro is like? | |
| 15:51:31 | openstackgerrit | Merged openstack/nova-specs master: Add extra-specs to the flavor show and detail API calls https://review.openstack.org/544158 | |
| 15:53:24 | cfriesen_ | I've got a question about service delete and placement...currently when we delete a service we don't delete the resource provider(s) for that compute node. If someone adds that compute node back later, this causes accounting issues because it has the same name but a different UUID. | |
| 15:53:45 | cfriesen_ | Should we be calling delete_resource_provider() when deleting the service? | |
| 15:54:32 | cdent | cfriesen_: I _think_ there's a bug for that. | |
| 15:56:23 | openstack | Launchpad bug 1708958 in OpenStack Compute (nova) "disabling a compute service does not disable the resource provider" [Wishlist,Confirmed] | |
| 15:56:23 | cfriesen_ | https://bugs.launchpad.net/nova/+bug/1708958 is that the one you were thinking of? | |
| 15:56:52 | mriedem | disable != delete | |
| 15:57:00 | cfriesen_ | yeah | |
| 15:57:07 | mriedem | you can delete a service record via the api, | |
| 15:57:13 | mriedem | but not the compute node record | |
| 15:57:17 | mriedem | deleting the compute node record is the issue | |