Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-14
10:30:08 cdent ah, I hadnt understood you were using a custom resource class, that's an important bit of data. Do you have a log of the requests made to the placement service, it would be useful to see what the GET /allocation_candidartes query is
10:31:23 cdent pooja_jadhav: this bug may be related: https://bugs.launchpad.net/nova/+bug/1705231
10:31:24 openstack Launchpad bug 1705231 in OpenStack Compute (nova) "Placement returns no allocation candidate for request that needs both compute resources and custom shared resources" [High,Fix released] - Assigned to Chris Dent (cdent)
10:43:25 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Correct documentation for '[pci] passthrough_whitelist' https://review.openstack.org/552874
10:43:27 stephenfin lyarwood, sean-k-mooney: ^
10:43:36 stephenfin I'll probably look for that to be backported if all is ok
10:46:11 lyarwood stephenfin: cool yeah that would be great, will need a bug if you have time, happy to quickly write one if not, I did mean to do this yesterday :|
10:47:19 stephenfin lyarwood: I'm working on the NUMA-aware vSwitch spec this morning, so if you're happy to write up said bug I'd appreciate it :)
11:39:05 gibi afternoon nova
11:39:48 gibi cdent: thanks for the placement doc update, I +2d it
11:57:05 openstackgerrit Merged openstack/nova master: Update contributor/placement.rst to contemporary reality https://review.openstack.org/552860
12:27:35 artom bauzas, sahid, could you take a look at https://review.openstack.org/#/c/552722/ when you get a chance? It's the infamouse live migration with CPU pinning spec
12:27:56 artom sahid, you weren't at PTG, but we basically agreed to start over, with a spec, since Nikola's patch is too hard to review/merge at this point
12:28:21 artom jaypipes, ^^ dunno if you're around this early, but your input would be appreciated as well
12:36:07 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Enhance nova-specs webpage and clean up repo https://review.openstack.org/551802
12:46:05 jaypipes artom: yep, will look shortly.
12:46:11 jaypipes thx for the heads up
12:47:14 artom jaypipes, cheers :)
13:11:09 openstackgerrit Eric Fried proposed openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249
13:11:10 openstackgerrit Eric Fried proposed openstack/nova master: Stop assuming initial provider generation is 0 https://review.openstack.org/548975
13:11:10 openstackgerrit Eric Fried proposed openstack/nova master: placement: Return new provider from POST /rps https://review.openstack.org/548934
13:12:01 jaypipes efried: ^ that ready to go now?
13:12:09 efried jaypipes: First two, yes.
13:12:17 efried jaypipes: Quick, before edleafe's!
13:22:12 edleafe efried: no rush, working on alex_xu_'s comments
13:44:55 alex_xu_ edleafe: the only help I can give is to review efried's patch :)
13:45:04 efried hah!
13:49:18 sar Shouldn't there be a line such as this? : new_cinfo['volume_id'] = save_volume_id
13:49:18 sar So I had an issue where i couldn't delete an instance attached to a previously migrated volume. I get an error where it says it can't find the volume id. Turns out it doesn't update the volume_id in the json stored in block_device_mapping during volume migration. Can someone help me verify if this can be considered a bug? See around line 5656 here: https://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py
14:01:49 edleafe alex_xu_: should have an update soon. Until then, have at efried!
14:04:01 mriedem gibi: i'm going through https://review.openstack.org/#/c/502306/ if you want to hold off on updating it
14:04:56 cdent thanks jaypipes for saying what you did on the low-level cache spec
14:05:41 jaypipes cdent: yw
14:06:16 cdent I tried to read that whitepaper that's reference before I made a judgement and dissolved in a sea of acronyms
14:06:38 cdent but my gut reaction was "oh, you've got to be kidding me"
14:10:21 openstackgerrit Dan Smith proposed openstack/nova master: Add --by-service to discover_hosts https://review.openstack.org/552691
14:15:46 stephenfin jaypipes: Low-level cache spec?
14:17:23 jaypipes stephenfin: https://review.openstack.org/#/c/502575/1/specs/pike/approved/cache-as-a-resource-with-rdt.rst@101
14:18:09 stephenfin eew
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 jaypipes dansmith: a single bit would be better, though.
14:18:35 mriedem jaypipes: just abandoned that spec - it was still targeting pike
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 ShilpaSD stephenfin: Instead of doing changes in manager to update access URL, can we add the url in novncproxy_base_url
14:19:58 mnaser logic
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:20:13 mnaser as this is being backported, it's breaking branch by branch unfortunately
14:20:24 ShilpaSD stephenfin: novncproxy_base_url=http:// address>/vnc.html?path=websocikfy
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

Earlier   Later