Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
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 cfriesen_ https://bugs.launchpad.net/nova/+bug/1708958 is that the one you were thinking of?
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: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.
16:10:19 openstack Launchpad bug 1755981 in OpenStack Compute (nova) "powering off and on an instance can result in instance boot failure due to serial port handling race" [Undecided,New]
16:10:22 cfriesen_ tssurya: yes, thanks
16:10:51 mriedem cfriesen_: probably ask sahid_ about that bug
16:10:59 mriedem markus_z would have been good too but he's no longer around
16:14:11 cfriesen sahid_: (or anyone else) regarding the above bug, why do we remove the port from ALLOCATED_PORTS when powering off? wouldn't it make more sense to remove them when undefining or changing the libvirt domain? The alternative seems to be to detach the serial ports from the libvirt domain when doing a power off, which is kind of icky.
16:17:03 sahid_ cfriesen: no comment or todo to explain why? I can't really remember
16:18:00 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: Resource provider examples https://review.openstack.org/553461
16:18:46 sahid_ cfriesen: i just looked at the code, furing power_on we are doing a hard-reboot (don't ask me why)
16:19:03 sahid_ it seems that during hard reboot we redefine the domain xml
16:34:35 artom_ jaypipes, wanna talk about https://review.openstack.org/#/c/552722/1/specs/rocky/approved/live-migration-with-cpu-pinning.rst@16?
16:37:06 openstackgerrit Chris Dent proposed openstack/nova-specs master: Spec for isolating configuration of placement database https://review.openstack.org/552927

Earlier   Later