| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-05-01 | |||
| 15:37:11 | gmann | lyarwood: seems rescue from BFV servers failing on ceph backend. https://bugs.launchpad.net/devstack-plugin-ceph/+bug/1876330 | |
| 15:37:11 | openstack | Launchpad bug 1876330 in devstack-plugin-ceph "Rescue BFV instances feature not supported in ceph, Tempest new test failing" [Undecided,New] | |
| 15:37:37 | gmann | I am going to skip the new tests to unblock the ceph job for now. | |
| 15:37:54 | lyarwood | gmann: looking | |
| 15:39:40 | lyarwood | gmann: that's unrelated to the feature at first glance and more a general rbd import failure of the import of the rescue image, ./me digs more. | |
| 15:42:24 | gmann | lyarwood: pushed the skip patch to unblock the gate where ceph job is voting. - https://review.opendev.org/#/c/724866/ | |
| 15:45:08 | melwitt | gmann: extra space on L3! -1! | |
| 15:51:53 | lyarwood | sigh, what's with the weird encoding of the logs with this job? | |
| 15:52:00 | lyarwood | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_32a/723645/15/check/devstack-plugin-ceph-tempest-py3/32ae221/controller/logs/screen-n-cpu.txt for example | |
| 15:52:13 | lyarwood | I can't pull it down to review quickly | |
| 15:59:59 | gmann | melwitt: updated. thanks | |
| 16:01:42 | lyarwood | yeah this really looks like an issue either with the snapshot we've downloaded from glance *or* with the deployed ceph env that we are trying to import it into | |
| 18:20:33 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Follow-up for NUMA live migration functional tests https://review.opendev.org/724903 | |
| 18:24:25 | artom | I wonder if I can backport that at least to U... stephenfin churned the func tests too much in after T | |
| 18:24:29 | artom | s/churned/improved/ :) | |
| 19:56:20 | markguz_ | Hi Nova folks. I'm scratching my head just now over soft-anti-affinity. I have 4 compute nodes, and I want to be able to deploy servers with anti-afinity policy | |
| 19:57:01 | markguz_ | hard anti-affinity works perfectly. 4 vms 1 on each compute node and then fail on a 5th. | |
| 19:57:42 | markguz_ | soft-anti-affinity i thought meant that like hard anti-affinity it would put an instance on each node, but not fail on the 5th and just put on the next available one | |
| 19:58:24 | markguz_ | not so. it seems that when using soft-aa the system will stack instances on 1 node. i'm stumped. | |
| 19:59:06 | markguz_ | i have the default schedulers enabled. and i have modified any of the weight stuff from the defaults either. what's going on? | |
| 21:05:40 | melwitt | markguz_: I'm not an expert on this, but from what I see in these docs https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/soft-affinity-for-server-group.html and https://docs.openstack.org/nova/latest/user/filter-scheduler.html#weights soft-anti-affinity is implemented via weights only, so you might have to tweak the weight multiplier to get a better result? | |
| 21:06:04 | melwitt | https://docs.openstack.org/nova/latest/configuration/config.html#filter_scheduler.soft_anti_affinity_weight_multiplier | |
| 21:07:10 | melwitt | and finally this might helpful https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/complex-anti-affinity-policies.html | |
| 23:38:17 | markguz_ | melwitt: yeah i've been looking at the weights. was beginning to come to that conclusion too. Thanks for the pointers! | |
| #openstack-nova - 2020-05-02 | |||
| 01:08:29 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add nested resource providers limit for multi create https://review.opendev.org/723884 | |
| 01:10:35 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add nested resource providers limit for multi create https://review.opendev.org/723884 | |
| 03:44:16 | openstackgerrit | Merged openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645 | |
| 04:08:54 | openstackgerrit | Jie Li proposed openstack/nova master: replace the "hide_hypervisor_id" to "hw:hide_hypervisor_id" https://review.opendev.org/722187 | |
| 05:26:00 | openstackgerrit | Takashi Natsume proposed openstack/python-novaclient master: Remove mock in lower-constraints.txt https://review.opendev.org/724956 | |
| 06:24:18 | openstackgerrit | Takashi Natsume proposed openstack/nova master: doc: Fix list rendering in cli/nova-status.rst https://review.opendev.org/724958 | |
| 08:02:54 | openstackgerrit | Takashi Natsume proposed openstack/os-vif master: Use unittest.mock instead of third party mock https://review.opendev.org/724965 | |
| 09:29:12 | openstackgerrit | Takashi Natsume proposed openstack/os-vif master: Remove six https://review.opendev.org/724966 | |
| 12:11:51 | openstackgerrit | Takashi Natsume proposed openstack/os-vif master: Remove Babel requirement https://review.opendev.org/724974 | |
| 12:50:37 | openstackgerrit | Sean McGinnis proposed openstack/nova master: Add py38 package metadata https://review.opendev.org/724990 | |
| 17:32:36 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Validate a BDMs disk_bus when provided https://review.opendev.org/724842 | |
| 23:28:21 | openstackgerrit | Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684 | |
| #openstack-nova - 2020-05-04 | |||
| 00:27:23 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/ussuri: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/725146 | |
| 00:57:10 | openstackgerrit | Ghanshyam Mann proposed openstack/nova stable/train: DNM: testing what all grenade jobs running https://review.opendev.org/725147 | |
| 02:33:07 | alex_xu | sean-k-mooney: gibi fyi, we will have someone working on provider config xml. | |
| 05:08:03 | openstackgerrit | Takashi Natsume proposed openstack/python-novaclient master: [WIP] Switch legacy Zuul jobs to native Zuul v3 jobs https://review.opendev.org/725163 | |
| 06:55:55 | gibi | alex_xu: ack, thanks | |
| 08:33:14 | gibi | stephenfin: hi! Do you have an idea why the reno job fails on this backport to stable/ussuri? https://review.opendev.org/#/c/725146/1 It is green for me locally but locally the releasenotes tox target does not try to generate stable/ussuri notes | |
| 08:56:25 | bauzas | gibi: me looks | |
| 08:59:31 | bauzas | gibi: I don't see any problems with the reno file itself, just testing it locally | |
| 08:59:59 | bauzas | Warning, treated as error: <reno.sphinxext stable/ussuri>:115:Duplicate target name, cannot be used as a unique reference: "upgrade notes". | |
| 09:00:07 | bauzas | that's why we get -1 ^ | |
| 09:03:11 | bauzas | ahah I think we probably have something missing https://docs.openstack.org/reno/latest/user/usage.html#updating-stable-branch-release-notes | |
| 09:03:53 | bauzas | "Occasionally it is necessary to update release notes for past releases due to URLs changing or errors not being noticed until after they have been released. In cases like these, it is important to note that any updates to these release notes should be proposed directly to the stable branch where they were introduced." | |
| 09:11:20 | bauzas | ok, so, relnotes are correctly written against master, but cherry-picking the change to my local stable/ussuri branch and retesting | |
| 09:11:43 | bauzas | I think I found the problem | |
| 09:12:31 | bauzas | gibi: we don't have *yet* ussuri release notes so reno writes the patch note against master twice | |
| 09:12:34 | bauzas | hence the duplicate | |
| 09:12:48 | bauzas | against 'unreleased' rather | |
| 09:13:03 | bauzas | lemme see if creating a ussuri.rst file would help | |
| 09:14:21 | gibi | bauzas: thanks for helping, I'm sitting on a meeting | |
| 09:14:31 | bauzas | ok, we have https://github.com/openstack/nova/blob/master/releasenotes/source/ussuri.rst | |
| 09:14:34 | bauzas | in master | |
| 09:14:43 | bauzas | which is normal | |
| 09:14:53 | bauzas | gibi: np | |
| 09:15:09 | bauzas | gibi: i think I have some potential findings but I need to test | |
| 09:15:25 | bauzas | and it takes a while to generate the relnotes locally as it scans all my branches | |
| 09:16:10 | gibi | yeah it is slow | |
| 09:16:46 | bauzas | interesting | |
| 09:16:53 | bauzas | it did worked fine on my box | |
| 09:18:05 | bauzas | interestingly, my current branch is ussuri when i'm testing on a local stable/ussuro | |
| 09:18:19 | bauzas | which is not the case with the job https://zuul.opendev.org/t/openstack/build/9c4f698044dc4af2b5bcb326b6a3e823/log/job-output.txt | |
| 09:20:12 | gibi | yeah, I also cannot reproduce the problem locally | |
| 09:35:16 | bauzas | gibi: maybe a job issue | |
| 09:36:55 | gibi | bauzas: interestingly the job tries to generate reno for stable/ussuri the local tox target does not try that for me | |
| 09:38:51 | gibi | locally I get | |
| 09:38:51 | gibi | scanning /home/gibizer/upstream/git/nova/releasenotes/notes for current branch release notes | |
| 09:38:54 | gibi | got versions [] | |
| 09:39:06 | gibi | in the job | |
| 09:39:07 | gibi | 2020-05-04 07:58:23.877287 | ubuntu-bionic | scanning /home/zuul/src/opendev.org/openstack/nova/releasenotes/notes for current branch release notes | |
| 09:39:11 | gibi | 2020-05-04 07:59:02.632023 | ubuntu-bionic | got versions ['21.0.0.0rc1-16'] | |
| 09:39:14 | gibi | 2020-05-04 07:59:02.664924 | ubuntu-bionic | reading sources... [100%] ussuri | |
| 09:39:17 | gibi | 2020-05-04 07:59:02.670555 | ubuntu-bionic | scanning /home/zuul/src/opendev.org/openstack/nova/releasenotes/notes for stable/ussuri release notes | |
| 09:39:20 | gibi | 2020-05-04 08:00:13.350874 | ubuntu-bionic | got versions ['21.0.0.0rc1-5', '21.0.0.0rc1'] | |
| 09:41:22 | bauzas | lemme doublecheck mine | |
| 09:41:42 | gibi | are these versions '21.0.0.0rc1-5' are git tags? | |
| 09:41:46 | gibi | I only have 21.0.0.0rc1 tag | |
| 09:42:13 | bauzas | gibi: that's my env http://paste.openstack.org/show/793033/ | |
| 09:42:34 | bauzas | gibi: I branched stable/ussuri and cherry-picked the change into it | |
| 09:43:10 | bauzas | gibi: yup, AFAIR, reno works with git commits and tags | |
| 09:43:12 | gibi | it is pretty similar to mine except you have got versions ['21.0.0.0rc1-5'] | |
| 09:43:47 | bauzas | which is expected | |
| 09:44:04 | bauzas | gibi: if I tag my branch as 21.0.1 per se | |
| 09:44:10 | bauzas | gibi: then you'll be seeing it | |
| 09:44:40 | bauzas | gibi: see https://docs.openstack.org/project-team-guide/release-management.html#how-to-preview-release-notes-at-rc-time | |
| 09:45:10 | bauzas | gibi: remember that reno tries to see which tags are related to which releasenotes | |
| 09:45:40 | bauzas | once you tag a .z version, then you'll see it | |
| 09:46:57 | gibi | bauzas: does it mean that the gate job temporarly tag the repo and then generate the notes? | |
| 09:47:09 | bauzas | I don't think so | |
| 09:47:27 | gibi | OK. I'm lost :) | |
| 09:48:03 | bauzas | and see whether reno finds it | |
| 09:48:08 | gibi | ok | |
| 09:48:44 | bauzas | we need dhellmann or someone else from the reno team IMHO | |
| 09:49:37 | bauzas | gibi: what's not normal is that we scan both the current branch and the stable/ussuri one | |
| 09:50:01 | bauzas | (against a stable/ussuri change) | |
| 09:50:07 | bauzas | because both are identical | |