| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 14:44:35 | stephenfin | Also, mriedem: that's what I did :) | |
| 14:44:53 | stephenfin | But I stripped the stuff from the main index page then as duplication | |
| 14:46:07 | mriedem | your proposed user index has a bunch of operator stuff in it | |
| 14:46:28 | mriedem | and nothing about the API version history or compute API reference | |
| 14:46:32 | gibi | cdent, mriedem: fyi, there is a resource allocation bug in resize same host when custom resources are involved: https://bugs.launchpad.net/nova/+bug/1713739 | |
| 14:46:32 | mriedem | which an end user would want | |
| 14:46:33 | openstack | Launchpad bug 1713739 in OpenStack Compute (nova) "VM resize and confirm on the same host fails with custom resources" [Undecided,New] | |
| 14:46:51 | gibi | cdent, mriedem: regression test is being created | |
| 14:46:52 | cdent | gibi: we were having _so_ much fun until you came back | |
| 14:47:27 | stephenfin | mriedem: Yeah, none of that is in the '/user' directory though. I was keeping only that stuff in there. A cross-reference wouldn't be any harm tho | |
| 14:48:02 | mriedem | i guess that is either external or in reference directory | |
| 14:48:35 | sdague | stephenfin: we don't strictly have to only list stuff in /user | |
| 14:48:38 | mriedem | guh, so...just have source/user/index.rst link back to the top level main index and be done with it | |
| 14:48:42 | gibi | cdent: It is not my finding :) I just suggested the certain test case to be created | |
| 14:49:11 | sdague | honestly, to avoid 404s, I'd say just write the user guide we think should be there, link whatever content is whereever, and it's fine | |
| 14:49:19 | sdague | links are not restricted about where they can go | |
| 14:49:36 | sdague | and the only people that will care that user isn't in the url are in this room | |
| 14:49:38 | cdent | the bug makes sense: the allocation creation routines are insufficiently custom resource class aware | |
| 14:49:43 | cdent | gibi: ^ | |
| 14:50:26 | openstackgerrit | Steve Noyes proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 14:51:12 | sean-k-mooney | stephenfin: did ye bottom out on how to handel pci devices on power yesterday? | |
| 14:51:37 | gibi | cdent: interestingly we only see problems in the resize same host case so far | |
| 14:51:52 | openstackgerrit | Ed Leafe proposed openstack/nova-specs master: Return Destination Objects https://review.openstack.org/498830 | |
| 14:52:42 | edleafe | mriedem: dansmith: cdent: jaypipes: ^^ wrote a quick spec on the object solution we discussed yesterday. Feedback appreciated! | |
| 14:53:13 | cdent | edleafe: thanks. probably won’t have a chance to look with any rigor until tomorrow afternoon | |
| 14:53:43 | openstackgerrit | Ed Leafe proposed openstack/nova-specs master: Return Destination Objects https://review.openstack.org/498830 | |
| 14:54:09 | jaypipes | edleafe: cool. will review this evening. | |
| 14:54:13 | jaypipes | edleafe: which is soon :) | |
| 14:54:17 | edleafe | jaypipes: thx | |
| 14:54:21 | stephenfin | sean-k-mooney: I think efried and claudiub|2 opened some blueprints | |
| 14:54:37 | stephenfin | https://blueprints.launchpad.net/nova/+spec/allow-pci-alias-choose-subset-of-devices and https://blueprints.launchpad.net/nova/+spec/devices-as-resources | |
| 14:54:59 | sean-k-mooney | edleafe: ovo for scheuler info from placement make sense or at least object instead of dictionaries. | |
| 14:55:46 | sean-k-mooney | stephenfin: there are two other spec that related to sriov bonding that would be good to group with those | |
| 14:56:05 | edleafe | sean-k-mooney: placement is http, so ovo isn't applicable. | |
| 14:56:26 | edleafe | sean-k-mooney: but yeah, from scheduler->conductor, ovo will help | |
| 14:56:48 | sean-k-mooney | edleafe: it is if you call object_to_primitive and then jsonutils.dump on it first | |
| 14:57:26 | sean-k-mooney | i would be really happy if we could start passing json serialised ovo across our apis in the future | |
| 14:57:33 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: Fix _delete_inventory log message in report client https://review.openstack.org/498833 | |
| 14:58:59 | mriedem | edleafe: jaypipes: dansmith: we should return compute node uuid back in the dict from select_destinations too, that would make lookups for providers on the client side quicker, so the client doesn't need to lookup a compute node by host/node just to get the uuid | |
| 14:59:23 | edleafe | mriedem: agreed. I already did that in my first crack at these objects | |
| 14:59:24 | mriedem | the dict that's returned isn't even versioned today | |
| 14:59:32 | dansmith | I wasn't really paying attention to that conversation so I'll have to catch up when I look at that | |
| 14:59:40 | mriedem | this is unrelated | |
| 14:59:51 | mriedem | but to fix a bug with cleaning up allocations during live migration, | |
| 14:59:57 | jaypipes | mriedem: yup, agreed. good idea. | |
| 15:00:07 | mriedem | i need the compute node uuid to remove the allocations and only have the dict from select_destinations which has the host/nodename | |
| 15:00:10 | edleafe | mriedem: we don't really need that dict per se, just the data in it | |
| 15:00:29 | edleafe | and the object will version that | |
| 15:00:36 | mriedem | so let's say i added a uuid key to the dict that's returned today, what would we change for the version? | |
| 15:00:39 | mriedem | the client rpc? | |
| 15:00:45 | mriedem | *scheduler client rpc? or manager? | |
| 15:01:21 | edleafe | probably the former | |
| 15:01:30 | mriedem | well it's 4.5 either way i think | |
| 15:01:47 | edleafe | but there's no point if we're gonna be changing the interface to use objects | |
| 15:02:24 | mriedem | plus i couldn't backport this, and we need to backport this fix... | |
| 15:02:26 | mriedem | TODO in the code it is | |
| 15:03:24 | beagles | sean-k-mooney, thanks for the info btw! | |
| 15:03:25 | edleafe | mriedem: you mean you don't have any reference to the compute node in the migration? | |
| 15:03:27 | sean-k-mooney | mriedem: well for now you would have to do a condtional check to see if the uuid is present in the dictionary and look it up if not | |
| 15:03:39 | mriedem | edleafe: not when we're still in the conductor task | |
| 15:03:45 | mriedem | i have the dict returned from select_destinations | |
| 15:03:55 | mriedem | which has the host/nodename, which i can use to lookup the ComputeNode to get the UUID | |
| 15:03:56 | sean-k-mooney | beagles: no worries i was off since thursday so just go back | |
| 15:03:57 | mriedem | it's just a hassle | |
| 15:04:05 | artom | claudiub|2, fips have always been associated to ports IIRC | |
| 15:04:19 | edleafe | mriedem: I see | |
| 15:04:22 | mriedem | sean-k-mooney: i'd rather not write in dead code | |
| 15:05:13 | sean-k-mooney | mriedem: agreed but it may be needed for the backport. if we go to ovo defintions and and a object based interfaces then we can do it correctly in that version for queens on | |
| 15:05:48 | claudiub|2 | artom: yeah, you're right. anyways. will let you know what i'll find out | |
| 15:06:32 | artom | claudiub|2, sure, thanks | |
| 15:06:36 | cdent | edleafe: i lied, apparently i had something to say now | |
| 15:07:32 | edleafe | cdent: typical | |
| 15:08:05 | mriedem | sean-k-mooney: i'm just going to lookup the compute node using the host and node strings that i already have | |
| 15:08:07 | mriedem | old school | |
| 15:08:18 | mriedem | we can clean it up in queens with a uuid we get back later if that happens | |
| 15:08:20 | mriedem | hence the TODO | |
| 15:08:53 | cdent | edleafe: well you know, I was taunted, I couldn’t help myself, I’m an easy target for bait | |
| 15:11:25 | sean-k-mooney | speaking of ptg does anyone have the link to nova etherpads? | |
| 15:12:00 | mriedem | sean-k-mooney: https://etherpad.openstack.org/p/nova-ptg-queens | |
| 15:12:15 | sean-k-mooney | mriedem: thanks :) | |
| 15:12:42 | sean-k-mooney | i just got approval at the weekend to travel so not i need to book all the things | |
| 15:13:08 | mriedem | sean-k-mooney: and start coming up with 10 different scheduler filters you want to talk about | |
| 15:13:10 | mriedem | like in ATL | |
| 15:14:22 | sean-k-mooney | haha well perhaps. honestly alot of what i want to talk about on that front will hopefully be covered in the existing scheduler and placement sessiosn | |
| 15:18:58 | sean-k-mooney | that said some topics i want to ensure we can model with placement and traists are, verifed boot(not the same as trusted boot), fpgas for tenants, power management of guests, and bandwith based scheduling(maily for sriov but maybe others in the future). | |
| 15:19:56 | mriedem | i think the huawei product team has a requirement for sriov bandwidth based scheduling | |
| 15:19:59 | mriedem | but i don't really have details yet | |
| 15:20:11 | sean-k-mooney | im also interested in the pci overhal topics and live migration both across vif types and with sriov | |
| 15:20:47 | sean-k-mooney | mriedem: cool we started working on that last year i think rodolfo had some patches up at one point | |
| 15:21:08 | sean-k-mooney | we should be able to model that with nested resource providers. | |
| 15:21:13 | gibi | sean-k-mooney, mriedem: ericsson also interested in the bandwith based scheduling, both for sriov and for ovs port as well | |
| 15:21:25 | sean-k-mooney | each pf would have a pool of bandwidth that could be consumed by the vf | |
| 15:21:45 | sean-k-mooney | gibi: ovs does not support enforcing the bandwidth | |
| 15:21:58 | sean-k-mooney | actully it has bandwidth limits | |
| 15:22:15 | sean-k-mooney | it just does not support mimium bandwidth guarentees | |
| 15:22:40 | gibi | sean-k-mooney: true, but as a first step we can trust the guest to only send/receive the requested bandwidth | |
| 15:22:50 | mriedem | sean-k-mooney: gibi: has anyone started a spec or etherpad for ideas or ML discussion, anything? | |
| 15:23:14 | gibi | mriedem: not from ericsson side | |
| 15:23:21 | sean-k-mooney | we had neutron or nova spec for this for pike | |
| 15:23:47 | gibi | sean-k-mooney: I think there was a neutron spec | |