| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-18 | |||
| 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 | |
| 22:04:40 | sean-k-mooney | https://review.opendev.org/#/c/663563/ | |
| 22:05:22 | sean-k-mooney | this is still changing alot and is not that popular but if you have usecase that would requrie something other then what flaovrs or images provide today | |
| 22:05:31 | ozzzo | that does look interesting, ty! | |
| 22:05:32 | sean-k-mooney | it would be good to read that and provide feedback | |
| 22:06:54 | sean-k-mooney | changing how this works is problematic as alot of the code and external tooling assumes flavor and image are the way resouce requests and qualitive aspects of an instance are defiened | |
| 22:07:52 | sean-k-mooney | that does not mean we cant discuss changing it its just hard not to break things in this if we do | |
| 23:39:19 | openstackgerrit | Merged openstack/nova master: Move rng device checks to the appropriate method https://review.opendev.org/693210 | |
| #openstack-nova - 2019-11-19 | |||
| 02:11:42 | openstackgerrit | Huachang Wang proposed openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | |
| 02:15:51 | ianw | with the drop python2 change @ https://review.opendev.org/#/c/687954/ ... it get that you got to switch at some point. but devstack doesn't default to python3, so this basically breaks the default case | |
| 02:16:07 | ianw | i feel like it has been done in the wrong order | |
| 02:19:23 | ianw | for example, https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/install-devstack doesn't work any more | |
| 02:28:43 | openstackgerrit | Ian Wienand proposed openstack/nova master: Revert "Stop testing Python 2" https://review.opendev.org/694891 | |
| 02:38:31 | brinzhang_ | ianw: I met the same issue with you, an run many times, the devstack cannot up easily ... | |
| 02:52:09 | sean-k-mooney | there are patches to change the default in devstack but we have to wait untill after m1 to change it | |
| 02:52:26 | sean-k-mooney | devstack also has had support for python3 for years | |
| 02:52:55 | sean-k-mooney | its trivial to set USE_PYTHON3=true | |
| 02:53:41 | ianw | personally i don't see that as a good argument for breaking the defaults | |
| 02:54:45 | sean-k-mooney | we have untill december to drop python 2 testing for non lib projects | |
| 02:55:41 | sean-k-mooney | the only functional change in that patch is the lack of installing contextlib2 | |
| 02:56:09 | sean-k-mooney | i guess the requirement for py36+ as well | |
| 02:56:30 | ianw | yes, and that's the sticking point for mine | |
| 02:57:03 | sean-k-mooney | leaving it work until december 12th? | |
| 02:57:49 | sean-k-mooney | the Ussuri release is not expected to have python 2 support in general | |
| 02:57:59 | brinzhang_ | Other project can do this until december 12th? it's not only exist in nova | |