| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-18 | |||
| 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 | |
| 03:06:52 | sean-k-mooney | we proably could have watied to merge it for another week or too | |
| 03:07:17 | sean-k-mooney | but we do need to complete this this cycle | |
| 03:07:48 | sean-k-mooney | and as far as i am aware this is inline with the tc plan for the dropping of python 2 support | |
| 03:08:58 | ianw | not going to argue about the overall dropping of it at all. just it seems a gentler approach to have devstack defaulting to python3, then switch projects to stop supporting python2 | |
| 03:09:25 | ianw | i mean, realistically, with nova refusing to install on py2 it's not even a configuration option in devstack after that point | |
| 03:10:41 | sean-k-mooney | that is fair. althoguh all project were ment to have gate jobs running on python 3 last cycle so all project shoudl be able to at least run on python 3 | |
| 03:10:49 | sean-k-mooney | also not all porject or jobs deploy nova | |
| 03:10:57 | sean-k-mooney | alot do but not all | |
| 03:12:47 | sean-k-mooney | projects like keysone, swift and glance wont need nova in ther gate jobs in many cases. although i suspect in many cases they get it by default | |
| 03:13:19 | sean-k-mooney | anyway night o/ we proably coudl revert it temporailly but i would personally prefer to fix the broken jobs | |
| 03:20:02 | brinzhang_ | sean-k-mooney: can you provide some guide how to "unstack and stack with python3 enabled"? | |
| 03:27:12 | brinzhang_ | sean-k-mooney: I have encountered this problem several times, excute "python -m pip install --upgrade pip" and also raised the same issue. http://paste.openstack.org/show/786318/ | |
| 03:44:37 | ianw | brinzhang_: you want to set USE_PYTHON3 in your devstack localrc | |
| 04:05:08 | openstackgerrit | Dong Ma proposed openstack/nova master: ZVM: Implement update_provider_tree https://review.opendev.org/694897 | |
| 04:41:32 | openstackgerrit | Merged openstack/nova stable/pike: Functional reproduce for bug 1852207 https://review.opendev.org/693817 | |
| 04:41:32 | openstack | bug 1852207 in OpenStack Compute (nova) pike "reschedule ignores requested availability zone" [Medium,In progress] https://launchpad.net/bugs/1852207 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 05:37:07 | brinzhang | ianw: thanks, I will try :) | |