| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-18 | |||
| 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? | |
| 22:00:23 | mriedem | correct | |
| 22:00:32 | mriedem | admins control extra specs in the flavors, not users | |
| 22:00:38 | mriedem | by default policy rules anyway | |
| 22:00:55 | ozzzo | so we can only delegate to users by giving them a menu of flavors? | |
| 22:01:27 | ozzzo | or by setting specs in image? | |
| 22:01:31 | mriedem | correct | |
| 22:01:38 | ozzzo | ok that is very helpful, ty! | |
| 22:01:41 | mriedem | filtering by image properties is a different filter | |
| 22:01:50 | mriedem | https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateimagepropertiesisolation | |
| 22:02:24 | ozzzo | ok got it | |
| 22:03:28 | mriedem | you could of course write your own filter that processes server metadata linked to a host aggregate but that could be semi expensive since the RequestSpec object passed to the filter interface does not have the server metadata in it (you'd have to get that from the db per instance in the request) | |
| 22:03:40 | sean-k-mooney | ozzzo: you may be interested in a spec that is currently being proposed in this area | |