| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-14 | |||
| 14:18:13 | stephenfin | I change my mind | |
| 14:18:14 | dansmith | I'm going tp propose a spec soon to let you reserve a single byte of physical memory | |
| 14:18:20 | dansmith | hope that's cool | |
| 14:18:26 | jaypipes | dansmith: totes. go for it. | |
| 14:18:29 | dansmith | I've always been partial to memory location 0xdeadbeef | |
| 14:18:35 | mriedem | jaypipes: just abandoned that spec - it was still targeting pike | |
| 14:18:35 | jaypipes | dansmith: a single bit would be better, though. | |
| 14:18:38 | dansmith | and I desire my byte to be stored there | |
| 14:19:07 | ShilpaSD | stephenfin: Hi | |
| 14:19:14 | stephenfin | ShilpaSD: o/ | |
| 14:19:45 | ShilpaSD | stephenfin: Had one query on same topic what we discussed yesterday | |
| 14:19:58 | mnaser | so i was working with the ODL folks and it looks like https://review.openstack.org/#/c/542738/ has their vif plugging. i dug in deeper and it looks like the unplug operation in os_vif with ovs is noop (so odl never really sees the port unplugged to change state) and then when the server is started again, it expects a network-vif-plugged event which never comes because the port is already plugged based on odl's | |
| 14:19:58 | mnaser | logic | |
| 14:19:58 | ShilpaSD | stephenfin: Instead of doing changes in manager to update access URL, can we add the url in novncproxy_base_url | |
| 14:20:13 | mnaser | as this is being backported, it's breaking branch by branch unfortunately | |
| 14:20:24 | ShilpaSD | stephenfin: novncproxy_base_url=http:// |
|
| 14:21:06 | mnaser | unfortunately the port type is still 'ovs' when using ODL.. should the fix be making os_vif actually unplug things rather than noop? | |
| 14:21:40 | jaypipes | mnaser: I will take a look at it as soon as I'm done with the cyborg demo. | |
| 14:22:08 | mnaser | jaypipes: cool, thank you, i spent a lot of time digging around so i can point to a few things i've seen | |
| 14:22:54 | jaypipes | cool | |
| 14:26:20 | Kevin_Zheng | mriedem Hi saw you guys were talking about the quota issue yesterday, any conclusion? | |
| 14:26:42 | mriedem | Kevin_Zheng: no, just that it's still a problem | |
| 14:26:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 14:26:53 | gibi | mriedem: sorry | |
| 14:26:54 | mriedem | efried: is there a spec or talk about adding a generation to https://developer.openstack.org/api-ref/placement/#update-allocations ? | |
| 14:26:59 | mriedem | gibi: ! | |
| 14:27:00 | gibi | mriedem: I just saw your ping | |
| 14:27:25 | gibi | mriedem: I promise I will read your comments even if it is on older ps | |
| 14:27:33 | mriedem | well ok then | |
| 14:28:56 | mriedem | efried: oh i guess there is an optional generation in PUT /allocations/{consumer_id} in 1.12 | |
| 14:28:57 | mriedem | so nvm | |
| 14:29:00 | gibi | mriedem: sorry. I will not be available until Monday (national holiday in Hungary) and I have to leave soon | |
| 14:29:07 | Kevin_Zheng | mriedm OK, I will be intrested if we dicide to fix it | |
| 14:29:08 | mriedem | np | |
| 14:29:24 | mriedem | Kevin_Zheng: melwitt sounded semi interested in fixing it, so probably want to talk to her | |
| 14:29:50 | Kevin_Zheng | Cool, good to know | |
| 14:30:23 | efried | mriedem: No, there's nothing. | |
| 14:30:39 | mriedem | efried: so https://developer.openstack.org/api-ref/placement/#request-microversions-1-12 is wrong? | |
| 14:31:28 | Kevin_Zheng | gibi, I have a quick question about versioned notification | |
| 14:31:39 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/schemas/allocation.py#L85 | |
| 14:31:46 | efried | It's ignored | |
| 14:32:00 | efried | generation (Optional)bodyintegerA consistent view marker that assists with the management of concurrent resource provider updates. The value is ignored; it is present to preserve symmetry between read and write representations. | |
| 14:32:01 | mriedem | oh gdi | |
| 14:32:24 | mriedem | ok, well, probably going to be important when both nova and neutron are changing allocatoins for the same consumer | |
| 14:32:53 | Kevin_Zheng | gibi, I saw that InstanceActionPayload is a parent object of alot other payload objects, and seems some of the child object also got version bump when the parent object got bumped? | |
| 14:33:08 | efried | mriedem: Yes. We talked about it in Dublin. On Wednesday IIRC. And agreed to add a generation field to the allocations table. jaypipes probably has more of it in his head. Not sure who's on the hook to do the spec/work. | |
| 14:33:18 | mriedem | Kevin_Zheng: yes that's not new | |
| 14:33:23 | gibi | Kevin_Zheng: if you add something to the parent then that will appeare in the children payloads therefore you need the bump | |
| 14:33:24 | mriedem | you'll have to update all of the children | |
| 14:33:37 | Kevin_Zheng | OMG | |
| 14:33:43 | Kevin_Zheng | so many children | |
| 14:33:52 | mriedem | c'mon | |
| 14:33:56 | mriedem | climb that mountain | |
| 14:34:12 | gibi | Kevin_Zheng: the parent-child relationship is not visible in the serialized payload, as it only contains the child class name | |
| 14:34:38 | gibi | Kevin_Zheng: therefore the version of the child should reflect the overall structure | |
| 14:35:06 | Kevin_Zheng | gibi ack | |
| 14:35:30 | gibi | Kevin_Zheng: dont worry I think the unit test will catch if you miss some of those children | |
| 14:35:53 | Kevin_Zheng | mriedem you got trainning too, I thought it was just for us LOL | |
| 14:36:38 | gibi | Kevin_Zheng: as the signature of the children classes will change if you add a field to the parent | |
| 14:37:09 | Kevin_Zheng | gibi, yeah thats true | |
| 14:37:38 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098 | |
| 14:37:40 | edleafe | alex_xu_: ^^ now you can ignore efried | |
| 14:38:09 | stephenfin | ShilpaSD: and that works as expected, for both noVNC 0.6 and 1.0? | |
| 14:38:55 | ShilpaSD | yes, if we manage at configuration level, no need to do changes at nova-compute | |
| 14:39:10 | stephenfin | mriedem: Thoughts on that? ^ | |
| 14:39:23 | mriedem | stephenfin: huh? | |
| 14:39:49 | stephenfin | mriedem: This is for the breaking change in noVNC 1.0. Apparently we can set the config option to use 'vnc.html' with a parameter and this works with both noVNC 0.6 and 1.0 | |
| 14:40:13 | stephenfin | 'vnc.html' instead of 'vnc_auto.html' for 0.6 and 'vnc_lite.html' for 1.0 | |
| 14:40:32 | mriedem | oh | |
| 14:40:50 | mriedem | well that seems like the thing to do for the default then, but does that also work for 0.6? | |
| 14:41:07 | mriedem | if that doesn't work for 0.6, then you'd be regressing the default for anyone <1.0 | |
| 14:41:07 | stephenfin | mriedem: According to ShilpaSD, it does, yes | |
| 14:41:23 | stephenfin | Yup, same as changing the default to 'vnc_lite.html' | |
| 14:41:48 | mriedem | sure seems fine then, accompanied with a release note that the default is changing probably | |
| 14:41:57 | stephenfin | Sweet | |
| 14:42:30 | stephenfin | ShilpaSD: If you fancy making that change to the default, we can see if DevStack is happy. That will ensure we're OK with 0.6 | |
| 14:43:31 | stephenfin | ShilpaSD: I already have a DevStack change up to bump noVNC 1.0. I can make this change 'Depends-on' your one | |
| 14:48:53 | ShilpaSD | stephenfin: that will be great, but still one more query | |
| 14:49:01 | stephenfin | Shoot | |
| 14:49:03 | ShilpaSD | stephenfin: /opt/stack/nova/nova/tests/functional/api_sample_tests/api_samples/os-remote-consoles/get-vnc-console-post-resp.json.tpl....here also need to make that change? since functionaly TC using that | |
| 14:49:19 | ShilpaSD | /opt/stack/nova/doc/api_samples/os-remote-consoles/get-vnc-console-post-resp.json | |
| 14:49:38 | stephenfin | ShilpaSD: Already done https://review.openstack.org/#/c/550173/ | |
| 14:50:00 | stephenfin | Well, those are wrong. You can take that patch and fix it up, if you like | |
| 14:50:21 | stephenfin | Or I'll rebase it onto whatever you do. You just need to modify nova/conf/pci.py and add a release note | |
| 14:51:35 | stephenfin | lyarwood: Regarding https://review.openstack.org/#/c/552874/, I think that's a bug in oslo_config.sphinxext. The rST is correct. | |
| 14:51:46 | stephenfin | If I were to guess, we're not doing a nested parse | |
| 14:53:41 | ShilpaSD | stephenfin: thnak you for clarification, will get back to you on what action i am taking aginst this | |
| 14:54:15 | stephenfin | (y) | |
| 14:54:31 | sean-k-mooney | mriedem: stephenfin just looking at https://review.openstack.org/#/c/548525/1 the few runs of kuryr-kubernetes-tempest-daemon-octavia i have see so far against os-vif seam a little flaky. | |
| 14:55:03 | sean-k-mooney | mriedem: stephenfin we may want to consider makeing it non voting if it contiues. ill keep an eye on it | |
| 14:56:05 | cdent | efried: re [t 1LbC] wasn't it to the consumer table? | |
| 14:56:05 | purplerbot | <efried> mriedem: Yes. We talked about it in Dublin. On Wednesday IIRC. And agreed to add a generation field to the allocations table. jaypipes probably has more of it in his head. Not sure who's on the hook to do the spec/work. [2018-03-14 14:33:08.634568] [n 1LbC] | |
| 14:56:39 | efried | cdent: Could be, sure. I'm not very familiar with the tables related to allocations. | |
| 14:56:53 | efried | and don't remember the conversation exactly | |
| 14:56:56 | efried | but I bet it's in the etherpad. | |
| 14:57:36 | sean-k-mooney | stephenfin: mriedem for example it failed https://review.openstack.org/#/c/476612/ becase the tempest regex elminated all tests http://logs.openstack.org/12/476612/30/check/kuryr-kubernetes-tempest-daemon-octavia/576bfad/job-output.txt.gz#_2018-03-13_07_42_00_900216 and it did not publish results on https://review.openstack.org/#/c/482226/20 at all. | |
| 14:58:02 | stephenfin | sean-k-mooney: Indeed. There was a thing on openstack-dev about it earlier in the week. Apparently some neutron (?) change has broken it | |
| 14:58:17 | stephenfin | sean-k-mooney: Agreed though. Let's keep an eye on it | |
| 14:59:08 | sean-k-mooney | stephenfin: well those two need other work to be mergable first but i would prefer to make it non voteing instead of blocking other changes to os-vif that may be need in the future. | |
| 15:00:32 | sean-k-mooney | stephenfin: its not blocking anything currently hence lets wait and see. legacy-tempest-dsvm-nova-os-vif on the other had we might want to make voteing or rework for zuul v3 | |