Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
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
16:37:39 cdent stephenfin: addressed your suggestions on ^
16:41:07 openstackgerrit Matt Riedemann proposed openstack/nova master: Unmap compute nodes when deleting host mappings in delete cell operation https://review.openstack.org/542964
16:42:08 mriedem tssurya: would you like to propose a backport to stable/queens for ^ ?
16:43:14 tssurya mriedem: yes I will do it
16:45:24 openstackgerrit Alvaro Lopez Garcia proposed openstack/nova master: Ensure that periodic reclaim cleans DB deleted instances https://review.openstack.org/323250
16:46:13 cfriesen sahid_: I'm back. So on power_off() we _destroy() the instance (but leave it defined) and remove the serial ports from ALLOCATED_PORTS. Then on power_on() we hard reboot the instance, which calls _destroy() again, which removes the ports from ALLOCATED_PORTS again, which might result in removing ports currently in use by another instance.
16:46:42 jaypipes artom_: sure, what's up?
16:47:16 openstackgerrit sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457
16:47:24 cfriesen sahid: I assume we call _hard_reboot() to clean up as many things as possible about the instance (given the comment by mdbooth in _hard_reboot())
16:47:27 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.{add|remove}_{traits|aggregates} https://review.openstack.org/553475
16:48:05 efried dansmith, jaypipes, cdent, edleafe: One half of the result of the "need to be able to merge traits/aggs" discussion ^
16:48:55 cfriesen sahid_: I'm wondering whether we should do the serial port removal from ALLOCATED_PORTS in _undefine_domain() instead.
16:49:16 openstackgerrit Eric Fried proposed openstack/nova master: update_provider_tree devref and docstring updates https://review.openstack.org/553476
16:49:31 efried dansmith, jaypipes, cdent, edleafe, mriedem: The other half ^
16:49:52 efried ...and now to send out that dev ML note, so I don't get in trouble with mriedem...
16:51:15 tssurya mriedem: there is a small problem with the backport, I guess the above patch sits on this one -> https://review.openstack.org/#/c/540073/ , so will backport both

Earlier   Later