Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
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
16:00:01 cfriesen_ ew
16:00:02 mriedem cfriesen_: well, how did they delete the compute node record? directly in the DB?
16:00:13 mriedem if you're monkeying with the db, then you are also going to need to deal with cleaning up placement as a result
16:00:20 mriedem at least for now, until we have some interface for this
16:00:34 cfriesen_ mriedem: I don't think they did delete the comptue node record, just the service
16:01:04 mriedem then i don't see how the compute node uuid would change unless the hostname changed or something
16:01:26 mriedem if the hostname changes, you have other problems
16:02:03 mriedem i think this also might tie into something tssurya was looking at which is having a way to delete host mappings and also make that recursive to delete compute nodes
16:02:08 mriedem and placement entries for those compute nodes
16:03:23 mriedem anyway, there is enough here that we should (1) have a way to cleanup compute nodes and their associated records and (2) that is complicated enough that it probably deserves at least a short spec
16:03:42 mriedem if it were easy it would have been done by now
16:03:59 tssurya I am cleaning up compute node and rp records in my patch
16:04:07 tssurya when we delete a cell or a host
16:04:26 dansmith tssurya: s/host/host mapping/ right?
16:04:55 tssurya yes
16:05:37 mriedem cfriesen_: in the meantime, they can use osc-placement 1.0 to delete the old compute node RP in placement
16:06:44 cfriesen_ okay, thanks for the info. tssurya, can you invite me to review that patch?
16:07:10 mriedem https://review.openstack.org/#/c/542964/ ?
16:07:19 cfriesen_ mriedem: I think that's basically what they were planning on doing for now
16:07:25 tssurya https://review.openstack.org/#/c/546660/
16:08:10 tssurya mriedem: its the one I posted, same one needing the functional test
16:08:13 tssurya for the placement side
16:08:32 tssurya for deleting the RP record
16:09:27 tssurya cfriesen_ : done, I hope I got the name right
16:09:31 tssurya for the review invite
16:10:18 cfriesen_ on a totally different issue, I opened https://bugs.launchpad.net/nova/+bug/1755981 Basically there seems to be a race due to the fact that we remove serial ports from ALLOCATED_PORTS but leave them in the guest definition.

Earlier   Later