| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-02-09 | |||
| 15:49:09 | dansmith | oh yeah I see the fails | |
| 15:50:10 | dansmith | the version I uploaded yesterday was +1 from zuul, so maybe her changes in the set after that had a problem | |
| 15:50:31 | dansmith | I'll check with her when she's around | |
| 16:02:40 | gibi | sean-k-mooney: I'm also +2 on the remote managed port series. Just to double check we don't have any open neutron dependency as the vnic type definition is merged. Am I correct? | |
| 16:04:04 | sean-k-mooney | yes and no | |
| 16:04:16 | sean-k-mooney | technially neutorn-lib has not been released with that change yet | |
| 16:04:21 | sean-k-mooney | but nova does not use it | |
| 16:04:31 | sean-k-mooney | im not sure if the neutron patches have merged dmitriis? | |
| 16:04:53 | sean-k-mooney | gibi: nova wont break without them but obviously it wont work until nueton merge the ml2/ovn change | |
| 16:05:13 | gibi | sean-k-mooney: OK then we have the same understanding | |
| 16:05:16 | melwitt | bauzas: thanks for the heads up, I haven't gotten a chance to look at the CI results yet. I uploaded that late last night | |
| 16:05:33 | bauzas | np | |
| 16:05:34 | dmitriis | sean-k-mooney: https://review.opendev.org/c/openstack/neutron-lib/+/828174 the lib patch is in | |
| 16:05:42 | gibi | the name of the new vnci type is fixed now so we can merge the nova side of that and at max neutron will not allow creating such port yet but that does not break nova | |
| 16:06:01 | sean-k-mooney | dmitriis: right but neutron uses neutron-lib form pypi | |
| 16:06:15 | sean-k-mooney | dmitriis: so until the release happens they cant use it in there unit tests | |
| 16:06:18 | dmitriis | sean-k-mooney: also waiting for this to land https://review.opendev.org/c/openstack/releases/+/828452 | |
| 16:06:24 | sean-k-mooney | yep | |
| 16:06:42 | sean-k-mooney | gibi: correct | |
| 16:06:49 | gibi | sean-k-mooney: cool | |
| 16:06:59 | sean-k-mooney | until the neutron change land there api validation will reject the vnic type | |
| 16:06:59 | gibi | then I pull the trigger on the series up until the doc | |
| 16:07:11 | sean-k-mooney | ack works for me | |
| 16:07:34 | sean-k-mooney | ok going to join donstream meeting | |
| 16:40:30 | opendevreview | melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139 | |
| 16:40:31 | opendevreview | melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | |
| 16:40:31 | opendevreview | melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | |
| 16:40:32 | opendevreview | melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | |
| 16:40:32 | opendevreview | melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | |
| 16:40:33 | opendevreview | melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301 | |
| 16:40:33 | opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | |
| 16:40:34 | opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | |
| 16:40:34 | opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | |
| 16:40:36 | opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | |
| 16:40:36 | opendevreview | melanie witt proposed openstack/nova master: Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963 | |
| 16:54:15 | opendevreview | Balazs Gibizer proposed openstack/osc-placement master: Support microversion 1.39 https://review.opendev.org/c/openstack/osc-placement/+/828545 | |
| 17:10:18 | gmann | gibi: replied - https://review.opendev.org/c/openstack/placement/+/826491/7/placement/util.py#426 | |
| 17:10:32 | gmann | it is same API behavior change that you also mentioned. !!!FOO is accepted as valid trait in code and there was no error at the down layer too so it is bad interface but success case for user. Now we are changing it to failure so break user. we should do this change in microversion only. any reason not to do as part of 1.39 ? | |
| 17:10:55 | gmann | we have lot of such cases in APIs in past and currently too | |
| 17:11:29 | gmann | main purpose of microversion was to improve the interface "not to be used incorrectly" without breaking the success case. | |
| 17:11:42 | gmann | * one of the purpose | |
| 17:33:23 | opendevreview | melanie witt proposed openstack/placement master: Make perfload jobs fail if write allocation fails https://review.opendev.org/c/openstack/placement/+/828438 | |
| 17:39:20 | bauzas | gmann: about the gate failure you mentioned yesterday at the nova meeting, do we have an open bug report against it ? | |
| 17:39:33 | bauzas | context : | |
| 17:39:35 | bauzas | https://meetings.opendev.org/meetings/nova/2022/nova.2022-02-08-16.00.log.html#l-112 | |
| 17:44:52 | gmann | bauzas: yes, this one https://bugs.launchpad.net/devstack/+bug/1960346 | |
| 17:46:42 | bauzas | gmann: thanks | |
| 18:00:07 | opendevreview | sean mooney proposed openstack/nova master: docs: Document virtio-net multiqueue https://review.opendev.org/c/openstack/nova/+/792362 | |
| 18:09:59 | opendevreview | Stephen Finucane proposed openstack/nova master: doc: Split up notifications document https://review.opendev.org/c/openstack/nova/+/828598 | |
| 18:09:59 | opendevreview | Stephen Finucane proposed openstack/nova master: doc: Remove useless contributor/api-2 doc https://review.opendev.org/c/openstack/nova/+/828599 | |
| 18:13:37 | opendevreview | Stephen Finucane proposed openstack/nova master: doc: Correct version for virtio-net multiqueue https://review.opendev.org/c/openstack/nova/+/828601 | |
| 18:13:39 | stephenfin | sean-k-mooney: Want to +2+W that ^ | |
| 18:13:49 | stephenfin | Rather than respin the base patch | |
| 18:14:09 | stephenfin | I'd do it myself but good to sanity check | |
| 18:15:49 | sean-k-mooney | sure i can take a look | |
| 18:15:56 | sean-k-mooney | so you restacked teh chain | |
| 18:16:12 | sean-k-mooney | did you read my comment as to why this was needed | |
| 18:16:44 | sean-k-mooney | discussing it with fungi and other one suggestion was to modify zuul or to comment when submit failes in this case | |
| 18:17:04 | sean-k-mooney | basically "this patch is in merge confclit please rebase" | |
| 18:18:45 | fungi | it's not technically in "merge conflict" so much as that it has an outdated parent change, and so gerrit will refuse to create a merge commit for it when asked | |
| 18:19:16 | sean-k-mooney | fungi: ya you are right the imporant bit though is "you need to do something" before this can merge | |
| 18:19:19 | fungi | its parent got a new revision and then was merged, but this change did not get rebased when its parent was updated | |
| 18:19:28 | fungi | so that's what needs to be done, yeah | |
| 18:20:19 | sean-k-mooney | fungi: is that technially a job failure fomment or an actul zuul change. e.g. is the submit implemented as a job or part of zuul when using the gerrit driver | |
| 18:21:19 | fungi | zuul would need to get a new feature in its gerrit source connection driver to report that error to the change | |
| 18:21:19 | sean-k-mooney | basically im wondering is this a chagne to the project-config repo for the job/pipline definition or a change in zuul | |
| 18:21:29 | sean-k-mooney | ack | |
| 18:21:34 | fungi | you can actually see it indicated in the gerrit webui if you're not colorblind (no joke), the way they decide to show it is by making the "(merged)" next to the parent change red instead of grey | |
| 18:21:44 | fungi | they couldn't make that more subtle if they tried | |
| 18:22:23 | sean-k-mooney | is it? | |
| 18:22:49 | sean-k-mooney | i dont see that on https://review.opendev.org/c/openstack/nova/+/792362/8 | |
| 18:23:41 | sean-k-mooney | we might not be able to see this now since i have rebased | |
| 18:23:56 | sean-k-mooney | also im using dark mode so that might also be a thing | |
| 18:24:09 | sean-k-mooney | was that in the relation changed section | |
| 18:25:16 | sean-k-mooney | fungi: oh ok so its grey for me normally and its orange for me in this case | |
| 18:25:24 | sean-k-mooney | ya that is really not clear | |
| 18:25:52 | sean-k-mooney | like if i hover over it the alt text is just relation chain | |
| 18:25:56 | fungi | indeed. you have to be looking for it, and able to see that orange/red color distinct from grey | |
| 18:26:09 | fungi | and know what it means | |
| 18:26:20 | sean-k-mooney | right the last bit is the gap | |
| 18:26:33 | sean-k-mooney | ther is nothing in the ui that tells you what that means | |
| 18:26:42 | sean-k-mooney | ux bug i guess | |
| 18:26:53 | fungi | though if you click the parent change in the relation list, then you'll be taken to the outdated patchset which you can see in its patchset drop-down once there | |
| 18:27:05 | sean-k-mooney | right | |
| 18:27:22 | sean-k-mooney | but since zuul does not enforece the same restrcions | |
| 18:27:27 | sean-k-mooney | and the test pass | |
| 18:27:34 | sean-k-mooney | there is a disconenct | |
| 18:31:09 | sean-k-mooney | stephenfin: i proably dont have the brain capasity today to review https://review.opendev.org/q/topic:notifications-docs properly so ill leave the tab open and try to review them tomorrow | |
| 18:31:35 | stephenfin | sean-k-mooney: oh yeah, I just meant https://review.opendev.org/c/openstack/nova/+/828601 | |
| 18:31:43 | stephenfin | the others can wait, for sure :) | |
| 18:32:06 | sean-k-mooney | by the way im off friday and monday so if i dont get to it tomrrow ping me on tuesday and ill review them then | |
| 18:35:20 | chateaulav | sean-k-mooney: I seperated the patch into 3. As clarification on submitting them for review, do i follow this process? https://docs.opendev.org/opendev/infra-manual/latest/developers.html#adding-a-dependency | |
| 18:36:39 | sean-k-mooney | you can normally i just do "git review -t <gerrit topic>" from the top patch | |
| 18:36:51 | sean-k-mooney | so if you have the 3 commits locally | |
| 18:36:59 | sean-k-mooney | i rebase againt master | |
| 18:37:18 | sean-k-mooney | then git review -t <bp/<blueprint name> | |
| 18:37:37 | sean-k-mooney | that will submit all patches not on the target branch and update the relevent reviews | |
| 18:38:10 | sean-k-mooney | you only need to do git review -d $PARENT_CHANGE_NUMBER and git review -x $CHILD_CHANGE_NUMBER | |
| 18:38:31 | sean-k-mooney | if you are changing the base and dont want to do an rebase | |
| 18:38:40 | sean-k-mooney | or interactive rebase | |