Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-30
12:56:23 sean-k-mooney jangutter: i personally hate updateing spec retroactivly. so im happy to conceed just to avoid that
12:56:41 sean-k-mooney well almost
12:57:47 jangutter sean-k-mooney, leakypipes: I have been selling tickets, but I'm pretty sure I can track down the people and refund them with only a limited loss of kneecaps.
12:58:30 sean-k-mooney jangutter: if you want to continue the discussion over code review then we can
12:59:41 sean-k-mooney i would like to see if we can merge the spec soon however and move on to th code as we only have until midle of febuary to release os-vif and i would prefer to have this mered earlier then later.
12:59:46 sean-k-mooney e.g. the code
12:59:58 jangutter sean-k-mooney, leakypipes: on that note, do you think the spec is in a good enough shape for a wider review?
13:00:21 jangutter sean-k-mooney: agreed on that, want to fixup the code early next week to match the spec in any case.
13:01:58 sean-k-mooney jangutter: i would like to see if we can get an os-vif release in the next 2 weeks and alost another one at the end of january to give some time to test it with nova, so sound good.
13:02:20 sean-k-mooney jangutter: i think the spec i fine for wider review
13:05:22 leakypipes jangutter: I do, which is what I said in the review last night :)
13:09:20 jangutter leakypipes, sean-k-mooney: thanks! Any idea who would be sufficiently interested and ... I want to say "still haven't lost hope in all that is good"?
13:15:45 leakypipes jangutter: give it a few hours. you'll have lost all faith in humanity by that point.
13:17:31 jangutter leakypipes: you're describing what I call "Monday".
13:17:52 leakypipes happy Friday.
13:17:58 sean-k-mooney jangutter: well i woudl recommend starting with the nova specs core team since they are the only people that can give you the remaining +2 and +w
13:20:59 sean-k-mooney jangutter: dansmith might have some input on ovo versionng and the inheritance/compostion element of the rest https://review.openstack.org/#/admin/groups/302,members it does not jump out at me as an area the rest are stongly invovled in
13:21:00 jangutter sean-k-mooney: (facepalm, didn't notice that nova-specs and nova have different ACLs)
13:21:21 sean-k-mooney ya nova specs is much smaller
13:48:05 s10 Hello. We've faced a bug, that is claimed to be fixed by in https://bugs.launchpad.net/nova/+bug/1404867 . I added a comment about conditions, in which it can happen during the bulk instances creation by Heat.
13:48:05 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)
13:48:11 s10 When instances are created in parallel, they can fail to build because of the quota.recheck_quota=True in nova.conf, and then it's impossible to remove volumes without admin intervention, because volumes are stuck in 'attaching' state.
13:48:12 s10 What will be the right approach to fix this bug?
14:06:11 s10 I can reproduce this bug even without Heat, with small terraform config...
14:08:46 mnaser s10: what release?
14:09:51 s10 mnaser: I tried it with the Pike. I can try it with the Queens, if those fixes weren't backported to Pike.
14:10:56 maciejjozefczyk sean-k-mooney: Hey, I finally took time to check https://review.openstack.org/#/c/591607
14:12:00 maciejjozefczyk sean-k-mooney: If you have a minute please look also at: https://review.openstack.org/#/c/614167
14:12:06 maciejjozefczyk Its related
14:12:43 sean-k-mooney maciejjozefczyk: hi
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 sean-k-mooney mriedem: we do yes
14:31:55 mriedem it is
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: Send RP uuid in the port binding https://review.openstack.org/569459
14:54:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
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 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: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:10:17 mriedem s10: which release? because i'm pretty sure mnaser already fixed that
15:10:33 s10 mriedem: Pike and Queens.

Earlier   Later