Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-30
12:55:26 jangutter sean-k-mooney, leakypipes: Re: ( https://review.openstack.org/#/c/607610/ ), I left the option open to do the "duelling options" right till the runway engages... mainly to keep progress unblocked, with the idea to update the spec with the decision made.
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

Earlier   Later