| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-30 | |||
| 12:41:38 | sean-k-mooney | artom you could have just said the new code would only work if both the source and dest node supported it | |
| 12:42:41 | sean-k-mooney | for the other 3 cases the old workflow will be used so you dont really need the table but i could follow it in its redered from much easier then in the raw rst doc | |
| 12:43:18 | sean-k-mooney | i only read the raw rst doc normally so its a little annoying to have to read the rendered version | |
| 12:45:41 | sean-k-mooney | leakypipes: im going to send an email to the list regrading the serialisation of os-vif objects | |
| 12:46:29 | sean-k-mooney | leakypipes: so that kuryr-kubernetes are aware that this will break in the future https://github.com/openstack/kuryr-kubernetes/commit/7cc187806b42fee5ea660f86d33ad2f59b009754 | |
| 12:47:31 | sean-k-mooney | leakypipes: and that everything they are doing in this file is using os-vif out of contract https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/objects/vif.py | |
| 12:48:24 | sean-k-mooney | i have told them we do not allow external plugins to define there own vif object 3 releases ago but we definetly do support serialising and prestingign between potically differed versions of os-vif | |
| 12:49:07 | artom | sean-k-mooney, yeah, the rst doc is unreadable for the table | |
| 12:50:48 | sean-k-mooney | artom: anyway the spec is merged and it was more of a nit i think then anything else so i would not worry about it | |
| 12:51:23 | leakypipes | sean-k-mooney: ack, thanks for getting that conversation started. if you need a spellcheck before sending out, lemme know :P | |
| 12:51:47 | sean-k-mooney | people keep telling me that specs are appreently not documentation so as long as we understand what you ment its all good | |
| 12:52:39 | leakypipes | sean-k-mooney: I actually don't understand why kuryr-kubernetes is defining os-vif objects at all (versus just defining the things in os-vif itself) | |
| 12:53:17 | sean-k-mooney | leakypipes: they did not know that they were not ment too so they did it really early on | |
| 12:53:47 | leakypipes | sean-k-mooney: ok | |
| 12:53:55 | leakypipes | sean-k-mooney: can we undo that? :) | |
| 12:53:59 | sean-k-mooney | more recently the have added it to os-vif when i pointed out that it would break going forward if tehy didnt | |
| 12:54:11 | sean-k-mooney | get rid of there objects yes | |
| 12:54:39 | sean-k-mooney | i ment to do it in rocky but move from intel to redhat and didnt get around to it | |
| 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 | |