Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
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
15:57:22 cfriesen_ yes
15:57:24 mriedem and no we don't have anything in place to clean that stuff up
15:57:33 mriedem we don't have any interfaces for deleting compute node records either
15:57:39 mriedem we've talked about adding that to nova-manage in the past
15:58:23 penick artom_ almost. Before becoming bros you have to go through the ceremony of course.
15:58:54 mriedem we have another issue with cleaning up stuff in placement mentioned here https://review.openstack.org/#/c/502306/17/specs/rocky/approved/bandwidth-resource-provider.rst@228
15:59:13 cfriesen_ mriedem: we've got a reported bug that deleting then re-adding a compute node with the same name results in not being able to schedule due to this placement issue
15:59:21 mriedem if you disable a compute or it's down, and delete instances from it and then purge them from the db, the allocations for those instances against that compute are never removed from placement

Earlier   Later