Earlier  
Posted Nick Remark
#openstack-nova - 2019-11-18
16:53:36 mgoddard 1. I didn't hit "Skipping removal of allocations for deleted instances"
16:54:18 mgoddard 2. Part of my change prevents the orphan deletion happening in that case, so I rolled that part back for testing
16:54:29 mgoddard https://review.opendev.org/#/c/694802/1/nova/db/sqlalchemy/api.py
16:54:56 mgoddard ^ that prevents host2 from deleting a compute node after host1 has taken ownership of it
16:55:14 mgoddard which should prevent us from hitting this issue
16:55:29 mgoddard the rest of the change is to help clean up if we have hit it previously
16:59:24 mriedem mgoddard: ok i guess it's up to king solomon then to figure out which patch to go with
16:59:48 mriedem or just -1 my change if you want
17:00:25 mriedem either way i think the functional test needs to stay b/c unit tests aren't really sufficient for this kind of multi-service and db interaction
17:01:06 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle NoSuchOptError in nova-manage gracefully https://review.opendev.org/694806
17:02:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Print help if nova-manage subcommand is not specified https://review.opendev.org/694806
17:41:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Use admin neutron client to see if instance has qos ports https://review.opendev.org/694668
17:44:02 artom sean-k-mooney, left you things on https://review.opendev.org/#/c/687957/5
17:50:37 sean-k-mooney just a couple :)
17:51:33 sean-k-mooney ill adress them tomorrow. over all are you ok with the patch
17:56:36 artom Yeah, once we've taken image difference out of the picture, I don't see issues with not running the NUMATopologyFilter on rebuilds
17:56:40 artom (Famous last words)
17:57:04 artom Might be good to get jparker to look at it
17:57:24 artom He came up with interesting test cases for NUMA LM, he might find a way to break it :)
17:57:36 artom Not necessarily the code itself, just the idea of it
17:58:31 sean-k-mooney well the idea is if we assert no numa toplogy constraits change in the api we dont need to use the filter to assert that again since rebuilds cant change host
17:58:41 sean-k-mooney so the existing claim should be valid
17:59:00 artom Yep :) I'm just paranoid
17:59:23 sean-k-mooney you could break the rebuild in other ways
17:59:31 artom Right, that's out of scope
17:59:36 sean-k-mooney e.g. adding a trait that is not present on the host
17:59:55 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: [RFC] Pick NEXT_MIN libvirt/QEMU versions for "V" release https://review.opendev.org/694821
17:59:59 sean-k-mooney ya im not trying to adress that although i hope we already do
18:00:05 artom ... do we check placement for rebuild?
18:00:36 sean-k-mooney i hope so but im not sure. its on my todo list to look at in general
18:01:01 artom Your ocean-spanning todo list :D
18:01:28 sean-k-mooney yes well when i fix things i keep findind other thngs that need to be fixed
18:02:24 artom https://xkcd.com/1739/
18:02:24 sean-k-mooney like i found out that apparently we allow you to attach port that violate numa toplogy and you will only find out if you rebuild or otherwise have to go back to the schduler
18:02:41 artom Oh are those your comments on the second patch in that stack?
18:02:55 sean-k-mooney they are on a different patch one sec
18:03:58 sean-k-mooney artom: https://review.opendev.org/#/c/674072/7/nova/tests/unit/virt/test_hardware.py@4240
18:04:09 sean-k-mooney no wrong one
18:04:18 sean-k-mooney also found that issue...
18:05:35 sean-k-mooney https://review.opendev.org/#/c/689861/3/nova/tests/functional/libvirt/test_numa_servers.py@1106
18:06:42 sean-k-mooney i need to make that less wordy but ya that existing test was wrong
18:10:55 artom Or make it into its own patch? I haven't dug in yet, is what related to NUMA rebuilds?
18:11:02 artom (That last bit)
18:12:05 sean-k-mooney fixing the attachment api to reject interace if it would volate the numa aware vstichs feature is a spereate thing
18:12:25 sean-k-mooney at present it does not check and then a rebuild or resize to the same host woudl fail
18:13:48 sean-k-mooney i need to file a seperate bug and address it seperately
18:17:37 artom sean-k-mooney, I mean just putting the comments in a separate patch :)
18:17:43 artom Anyways, lemme review that properly
18:18:08 sean-k-mooney i needed to chagne the test so i added the comment to explain why
18:18:18 artom Ack
18:18:24 artom As I said, I hadn't dug in yet
18:18:55 sean-k-mooney i proably should change teh NOTE to a FIXME
18:21:59 openstackgerrit Archit Modi proposed openstack/nova stable/pike: doc: fix and clarify --block-device usage in user docs https://review.opendev.org/694450
18:50:53 mriedem this is a good pike-only fix for something that was regressed with a backport https://review.opendev.org/#/q/topic:bug/1852207+(status:open+OR+status:merged)
19:01:36 artom sean-k-mooney, grah, forgot the backporting thing - might have left comments that make no sense in that context
19:24:42 openstackgerrit Matt Riedemann proposed openstack/nova master: FUP to Ie1a0cbd82a617dbcc15729647218ac3e9cd0e5a9 https://review.opendev.org/694787
19:24:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Drop neutron-grenade-multinode job https://review.opendev.org/694789
19:44:09 rafaelweingartne Hey guys, we are found on Nova that might be a bug
19:44:46 rafaelweingartne when a user is updating something in the VM (e.g. its name), this information is not updated in the KVM XML that is used to describe the VM in the compute host
19:44:52 rafaelweingartne is that expected? Or, is it a bug?
19:47:02 dansmith rafaelweingartne: generally only something like a volume attach will change the libvirt xml at runtime
19:47:09 rafaelweingartne hmm
19:47:15 rafaelweingartne so, that is by design?
19:47:29 dansmith rafaelweingartne: if we store the display name in the xml (do we?) we wouldn't update that until a migration or hard reboot type event
19:47:44 rafaelweingartne yes, we do store some data there
19:47:51 rafaelweingartne not just the display name, but also project for instance
19:48:03 rafaelweingartne and this is troublesome for Ceilometer, as it was trusting that data
19:48:22 dansmith I see, in metadata. No, we don't change that on the fly
19:48:28 rafaelweingartne hmm
19:48:38 rafaelweingartne should we fix it in Ceilometer or in Nova?
19:48:39 dansmith not even sure the compute gets notified when that changes.. I suspect not
19:48:57 rafaelweingartne I opened a bug report: https://bugs.launchpad.net/ceilometer/+bug/1853048
19:48:57 openstack Launchpad bug 1853048 in OpenStack Compute (nova) "Nova not updating VM's XML in KVM" [Undecided,New]
19:49:32 dansmith rafaelweingartne: ceilometer scraping anything out of the xml underneath nova would be at its own peril for sure
19:50:22 rafaelweingartne hmm
19:50:51 dansmith yeah, confirmed, the compute node won't even be notified that such things have changed via the api,
19:51:05 rafaelweingartne So, this is by design in Nova? If someone were to fix it, you guys would prefer to fix on Ceilometer side, right?
19:51:12 dansmith it would just re-read that info from the db the next time it needs to generate the XML, which like I say would be some significant livecycle event
19:51:17 dansmith rafaelweingartne: yes, by design
19:51:59 dansmith rafaelweingartne: if you mean ceilometer update the xml itself, then no, but if you mean change ceilometer to get that info from somewhere else, then yes
19:52:32 rafaelweingartne and, what about changing Nova to update the data when the user is updating something (e.g. display name of a VM)?
19:54:00 dansmith rafaelweingartne: I would be -2 on that without some really really strong use-case, and ceilometer scraping that info and expecting it to be reliable is not good enough
19:54:25 rafaelweingartne ok
19:54:26 rafaelweingartne got it
21:01:46 openstackgerrit Merged openstack/nova master: Remove service_uuids_online_data_migration https://review.opendev.org/693421
21:01:53 openstackgerrit Merged openstack/nova master: functional: Change order of two classes https://review.opendev.org/689178
21:02:00 openstackgerrit Merged openstack/nova master: functional: Rework '_delete_server' https://review.opendev.org/689179
21:08:19 ozzzo I created an aggregate with property "allflavors='0'"
21:08:34 ozzzo https://paste.fedoraproject.org/paste/X8lzKsU474FD1Ffj2x29uQ
21:08:44 ozzzo Then I created VMs and specified "allflavors='1'"
21:08:52 ozzzo openstack server create --flavor s1.1cx4g --image NOT-QSC-CentOS7.6-19P1-v4 --network it-network --property allflavors='1' --max 20 alberttest
21:09:12 ozzzo but some of the VMs I created went to hv005 which should be restricted by "allflavors"
21:09:21 ozzzo https://paste.fedoraproject.org/paste/AhxIfQnQjeWPgMw33xmbKQ
21:09:28 ozzzo what am I doing wrong?
21:09:42 ozzzo I tried asking in #openstack but nobody is answering questions there
21:38:49 openstackgerrit Merged openstack/nova master: Stop testing Python 2 https://review.opendev.org/687954
21:51:24 mriedem that's an exclusion problem with the aggregates filters
21:52:10 mriedem and --property is server metadata, not part of the flavor extra spec
21:52:26 mriedem see https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateinstanceextraspecsfilter
21:59:46 ozzzo mriedem: does that mean that we can't specify extra-specs on the command line? Does it have to be in a flavor?

Earlier   Later