| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-18 | |||
| 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 | |
| 02:58:21 | ianw | brinzhang_: well, yes, but nova is probably the biggest target :) | |
| 02:58:43 | ianw | sean-k-mooney: my suggestion would be to have devstacking using USE_PYTHON3 by default, then switch it | |
| 02:58:47 | sean-k-mooney | nova is proably the most visable | |
| 02:59:26 | ianw | switching to USE_PYTHON3 by default and waiting, say, a week, should probably give any issues time to shake out | |
| 02:59:42 | sean-k-mooney | you mean merge https://review.opendev.org/#/c/649097/ | |
| 03:00:25 | ianw | sean-k-mooney: yes, well work out the issues related to that and get it in | |
| 03:00:39 | ianw | as you say, many (most) people won't even notice the default changing, probably | |
| 03:00:44 | brinzhang_ | I agree | |
| 03:01:56 | sean-k-mooney | i know most deveolpoer i have talked to moved there default a release or two ago | |
| 03:02:27 | sean-k-mooney | not all but alot of devstack user have been using python3 since rocky or stien | |
| 03:03:21 | brinzhang_ | I think there are problem need to consider, about the base environment. In older centos/ubuntu it's dafault python is py27 | |
| 03:03:51 | ianw | sean-k-mooney: i think there's probably a long tail of gate jobs that people haven't converted | |
| 03:04:11 | sean-k-mooney | yep proably | |
| 03:04:21 | sean-k-mooney | we will find out shortly if they start exploding. | |
| 03:05:04 | sean-k-mooney | i think there was a seperate patch up to swap the defualt in devstack gate and anoutther in zuul devstack base job but i dont know what the state of those are | |
| 03:05:26 | brinzhang_ | at least, because of this change I have not build the devstack env now, it's terrible .. | |
| 03:05:52 | sean-k-mooney | brinzhang_: unstack and stack with python3 enabled | |