| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-30 | |||
| 14:12:56 | sean-k-mooney | yes i saw the follow up patch | |
| 14:13:26 | sean-k-mooney | i only tested the first one because it was a single node deployment and i did not have to worry about updgrades | |
| 14:14:32 | maciejjozefczyk | Ok | |
| 14:14:55 | sean-k-mooney | so just looking at https://review.openstack.org/#/c/591607/9/nova/network/neutronv2/api.py@2914 | |
| 14:15:29 | sean-k-mooney | the value of the port id will be a neutron port uuid not an int right | |
| 14:16:18 | sean-k-mooney | or is it a nova port id form the nova virtural interface table | |
| 14:17:17 | maciejjozefczyk | this 'id' is a sequence from table | |
| 14:17:37 | maciejjozefczyk | so it will always be int | |
| 14:18:00 | sean-k-mooney | ok what i was concerned about really was trying to maintian the order of interface withing the guest if possible | |
| 14:18:42 | sean-k-mooney | but to be honest i dont think there is a good way to do that so the code as written is proably fine | |
| 14:18:43 | maciejjozefczyk | https://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L36 | |
| 14:19:23 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Deprecate the unversioned notifications https://review.openstack.org/603079 | |
| 14:19:26 | sean-k-mooney | ya i assume it was this object | |
| 14:19:36 | maciejjozefczyk | For me its not a ideal solution also, but its only one source of real order of interfaces, that I know in nova | |
| 14:20:09 | maciejjozefczyk | It was like first idea how to make it after Vlad comment | |
| 14:20:52 | s10 | mnaser: Same thing with Queens. In Pike volumes are stuck in attaching state, in Queens - in reserved. | |
| 14:21:08 | mnaser | s10: indeed sounds like a bug | |
| 14:21:16 | sean-k-mooney | maciejjozefczyk: ya if you are sorting by that id and not the uuid i think the code makes sense | |
| 14:21:27 | mnaser | unfortunately i dont run this setting on and i'm a bit out of cycles to dig in deeper :X | |
| 14:21:36 | sean-k-mooney | i can leve that feedback on the reivew | |
| 14:22:11 | s10 | mnaser: and easy to reproduce. Just set CPU quota for the project to 1 and then create 2 instances with 1vcpu each in parallel. | |
| 14:22:36 | mnaser | s10: oh i can see it but digging into solution and all, but out of time for that :) | |
| 14:23:02 | maciejjozefczyk | sean-k-mooney: thanks | |
| 14:23:29 | maciejjozefczyk | s10: If you have a minute PTAL https://review.openstack.org/#/c/591607/ | |
| 14:24:05 | sean-k-mooney | maciejjozefczyk: part of my confustion was we also have this object to model vifs in nova https://github.com/openstack/nova/blob/master/nova/network/model.py#L378 and the id field there is the neutron port uuid | |
| 14:24:19 | gibi | jackding: ping | |
| 14:26:28 | maciejjozefczyk | sean-k-mooney: hmm, idk whats that, but anyway this model is not used there | |
| 14:27:25 | sean-k-mooney | its how we model neutron port when talking to the virt dirivers. | |
| 14:29:04 | sean-k-mooney | maciejjozefczyk: it is also the object that is contained in the networkinfo object https://github.com/openstack/nova/blob/master/nova/network/model.py#L485 and i had assuemd in the netwrok info cache | |
| 14:30:29 | maciejjozefczyk | ok, so its clearly some duplication of data :) | |
| 14:30:57 | mriedem | is mdbooth around today? | |
| 14:31:11 | sean-k-mooney | maciejjozefczyk: VirtualInterface i think is a legacy object we have for nova networks and it is what we persit in the db | |
| 14:31:39 | mriedem | sean-k-mooney: we also create virtualinterfaces in the db for neutron ports since newton | |
| 14:31:42 | sean-k-mooney | maciejjozefczyk: the other object are the ones we construct form neutron and use for port binding and creating the os-vif objects | |
| 14:31:49 | maciejjozefczyk | sean-k-mooney: mriedem said that its about storing 'tag' | |
| 14:31:55 | mriedem | it is | |
| 14:31:55 | sean-k-mooney | mriedem: we do yes | |
| 14:32:24 | sean-k-mooney | maciejjozefczyk: right for the device role tagging spec | |
| 14:33:29 | sean-k-mooney | mriedem: does the netwrok info cache contain the VIF form here https://github.com/openstack/nova/blob/master/nova/network/model.py#L378 or the virtualInterface objecst from here https://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L28 | |
| 14:33:37 | maciejjozefczyk | I used this field, btw, to store the last port I verified during online_data_migrations, same way as bauzas did for other migrations | |
| 14:33:53 | bauzas | mmm ? | |
| 14:34:09 | mriedem | the vif | |
| 14:34:30 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/model.py#L488 | |
| 14:34:37 | sean-k-mooney | thats what i had understood too | |
| 14:34:48 | mriedem | https://github.com/openstack/nova/blob/master/nova/objects/instance_info_cache.py#L40 | |
| 14:35:21 | sean-k-mooney | so the id filed that is being sorted on here https://review.openstack.org/#/c/591607/9/nova/network/neutronv2/api.py@2914 is the neutron port uuid that is stored in the VIF objects id field | |
| 14:36:02 | bauzas | shit, anyone knows why my nova-specs dashboard doesn't work ? | |
| 14:36:59 | bauzas | my own dashboard goo.gl/MgN7mp | |
| 14:37:00 | sean-k-mooney | maciejjozefczyk so that code is sorting on the uuid in the VIF.id field not the id of the VirtualInterface id field | |
| 14:37:01 | maciejjozefczyk | bauzas: I took your logic from https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py to have a marker, thanks btw | |
| 14:37:07 | bauzas | ah ok | |
| 14:37:17 | bauzas | http://goo.gl/MgN7mp is my own dashboard | |
| 14:38:23 | maciejjozefczyk | sean-k-mooney: so how to preserve the order after attaching new interface? if it sorts by VIF.id (that is uuid?)? | |
| 14:39:03 | sean-k-mooney | maciejjozefczyk: actully no you are ok you are build it from the db https://review.openstack.org/#/c/591607/9/nova/network/neutronv2/api.py@2356 | |
| 14:39:29 | maciejjozefczyk | sean-k-mooney: about get_vifs_by_instance: ok | |
| 14:43:37 | sean-k-mooney | maciejjozefczyk: so yes _get_ordered_port_list is constuting an orderd port list from the VirtualInterface objects retruned form get_vifs_by_instance and then in _build_network_info_model you are construting a NetworkInfo object containing VIF objects | |
| 14:44:00 | sean-k-mooney | maciejjozefczyk: so ya the logic is correct | |
| 14:53:08 | maciejjozefczyk | thats right :) | |
| 14:54:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 14:54:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 14:54:48 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 14:56:27 | kashyap | If someone has time, a refactor that makes your brain less warpy: https://review.openstack.org/#/c/620327/ ("libvirt: Refactor handling of PCIe root ports") | |
| 15:07:26 | gibi | kashyap: +2, thanks! | |
| 15:07:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Mention size limit on user data in docs https://review.openstack.org/620700 | |
| 15:07:39 | kashyap | gibi: Sweet, thank you, sir. | |
| 15:08:14 | kashyap | That means, then I _really_ need to workout the fix to address the more complex TODO item in the comment. | |
| 15:08:54 | openstack | Launchpad bug 1404867 in OpenStack Compute (nova) queens "Volume remains in-use status, if instance booted from volume is deleted in error state" [Medium,Fix committed] - Assigned to Mohammed Naser (mnaser) | |
| 15:08:54 | s10 | mriedem: We've faced a bug, which is related to https://bugs.launchpad.net/nova/+bug/1404867 . I've written about it in last comment, but I'm not sure, if I should open a new bug about this issue. We can't set quota.recheck_quota=False in our deployments, and some users sometimes ends up with volumes in incorrect status. | |
| 15:10:17 | mriedem | s10: which release? because i'm pretty sure mnaser already fixed that | |
| 15:10:33 | s10 | mriedem: Pike and Queens. | |
| 15:11:35 | mriedem | oh i'm thinking of I64074923fb741fbf5459f66b8ab1a23c16f3303f | |
| 15:11:50 | mriedem | https://review.openstack.org/#/c/544748/ | |
| 15:12:02 | s10 | mriedem: this issue is almost fixed, but still can happen, if this exception happens https://github.com/openstack/nova/blob/stable/rocky/nova/conductor/manager.py#L1308 | |
| 15:12:05 | mriedem | s10: open a new bug, you can refer to ^ as being related but a different failure | |
| 15:12:44 | s10 | mriedem: because after this exception instance is not being buried in cell0 | |
| 15:13:06 | mriedem | lyarwood: bauzas: this upgrade-impacting backport needs review https://review.openstack.org/#/c/610974/ | |
| 15:13:12 | mriedem | s10: yeah i get it | |
| 15:13:16 | mriedem | just report a new bug | |
| 15:13:22 | bauzas | mriedem: on a meeting but looking | |
| 15:14:18 | mriedem | bauzas: while you're on the call, you want to ask mdbooth if he'll be around the next two weeks to respond to review comments on https://blueprints.launchpad.net/nova/+spec/local-disk-serial-numbers if it's in a runway? | |
| 15:14:22 | s10 | mriedem: ok, I will report. | |
| 15:14:30 | mriedem | because it's next in the queue | |
| 15:14:32 | bauzas | mriedem: I can try to ask :) | |
| 15:14:49 | mriedem | i know you can do this! | |
| 15:14:53 | mriedem | be strong! | |
| 15:15:16 | bauzas | I'm a weak guy | |
| 15:15:32 | mriedem | you're a bear | |
| 15:15:37 | mriedem | big ol papa bear | |
| 15:15:50 | bauzas | maybe more a Winnie the Bear one | |
| 15:16:24 | bauzas | on another point, I finally found how to fix my specs dashboard :) | |
| 15:16:45 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove placement perf check https://review.openstack.org/621180 | |
| 15:18:59 | mdbooth | mriedem bauzas: I'm not working Mondays for the next few weeks, but Tuesday->Friday I can prioritise responding to reviews. | |
| 15:19:43 | bauzas | so, #1 I fixed my dashboard, #2 I have less downstream tasks to do, #3 there are a huge number of specs left to review | |
| 15:19:52 | bauzas | good news, I'll sharpen my pen | |
| 15:21:59 | mriedem | mdbooth: ok. i had some comments at one point on one of the changes in that blueprint which was merged in rocky (i think) and i don't think i ever heard back. i'll try to dig that up. | |
| 15:22:09 | mriedem | i may or may not be grinding an axe because of it | |
| 15:22:47 | mriedem | anyway, your bp is in the runways queue now | |
| 15:22:48 | mriedem | good luck | |
| 15:23:25 | mdbooth | mriedem: I rebased and addressed all prior feedback a few weeks back, so hopefully all good. | |
| 15:23:55 | mriedem | i meant this i think https://review.openstack.org/#/c/528362/ | |