| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-11 | |||
| 16:28:18 | mdbooth | bauzas: Hey, can you try a couple of things on your mdev box and document the results: create more mdevs than permitted, and create an mdev with an invalid name. | |
| 16:28:41 | bauzas | mdbooth: I'm just trying the former :) | |
| 16:29:55 | mdbooth | bauzas: The BFL around that function is fine by me. How do you plan to address all the other places which call _get_guest_xml? | |
| 16:31:30 | ildikov | mriedem: sadness :( | |
| 16:36:19 | mnaser | from what i understand, once an instance is scheduled in a cell, it will forever remain in that cell (rebuilds, live migrations, etc?) | |
| 16:36:27 | openstackgerrit | Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539 | |
| 16:36:27 | openstackgerrit | Eric Fried proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686 | |
| 16:36:28 | openstackgerrit | Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756 | |
| 16:36:28 | openstackgerrit | Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540 | |
| 16:36:29 | openstackgerrit | Eric Fried proposed openstack/nova master: Raise conflict exception on RP create 409 https://review.openstack.org/532563 | |
| 16:36:29 | openstackgerrit | Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541 | |
| 16:36:30 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098 | |
| 16:36:30 | openstackgerrit | Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564 | |
| 16:36:31 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 16:36:31 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187 | |
| 16:36:32 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 16:36:59 | bauzas | mdbooth: yup, in separate change | |
| 16:37:08 | efried | gibi If you're still around, would you please re+W https://review.openstack.org/521686 (just rebased) | |
| 16:37:17 | bauzas | mdbooth: oh shit, I forgot to amend the relnote telling that limitation | |
| 16:37:35 | bauzas | (basically, don't touch your instance for the moment once it's up) | |
| 16:37:53 | mdbooth | bauzas: Commented. | |
| 16:37:55 | efried | mgoddard Un-WIP'd SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564 -- see how ya like it. | |
| 16:38:07 | efried | mgoddard And maybe let's talk about peeling it out of that series so you can make use of it. | |
| 16:38:09 | mriedem | need a couple of cores to review the 2.57 novaclient change https://review.openstack.org/#/c/528128/ | |
| 16:38:14 | mriedem | and 2.58 above it | |
| 16:38:17 | mriedem | and 2.59 is approved | |
| 16:38:24 | mriedem | client freeze is in 2 weeks | |
| 16:38:40 | maciejjozefczyk | mriedem: about https://review.openstack.org/#/c/520024/ | |
| 16:38:44 | maciejjozefczyk | mriedem: found :) | |
| 16:39:35 | mdbooth | bauzas: Is it really useful to land in that state? The code is pretty cleanly separated. It's kinda annoying that the libvirt folks half-landed mdev for eg, and now we can't tell which version we're supposed to required. | |
| 16:39:52 | maciejjozefczyk | mriedem: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py?utf8=✓#L613 | |
| 16:40:07 | bauzas | mriedem: ack, top prio list of reviews, starred | |
| 16:40:42 | bauzas | API microversion client side changes are like more important than feature prios to me | |
| 16:41:03 | mriedem | maciejjozefczyk: so it overwrites the ComputeNode allocation ratios which are set in code, to the self allocation ratios set in the RT via the config options? | |
| 16:41:47 | mriedem | maciejjozefczyk: i'm guessing that's in there in case the operator changed the configs and restarted the service | |
| 16:42:00 | maciejjozefczyk | mriedem: yes | |
| 16:42:13 | maciejjozefczyk | mriedem: if not 0; then rewrite ;P ? | |
| 16:42:13 | mriedem | but maybe https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py?utf8=%E2%9C%93#L148 should match what's in the compute node object... | |
| 16:42:19 | mriedem | CONF.cpu_allocation_ratio or 16.0 | |
| 16:42:21 | mriedem | something like that | |
| 16:42:32 | mriedem | maciejjozefczyk: or that | |
| 16:42:56 | mriedem | it's definitely shitty that we have multiple places writing this value into the ocmpute node record | |
| 16:43:04 | maciejjozefczyk | mriedem: so.. should i create other bug and then fix it? | |
| 16:43:07 | mriedem | as evidenced by the fact it took 3 of us 3 hours yesterday to figure this out | |
| 16:43:11 | mriedem | maciejjozefczyk: sure | |
| 16:43:11 | maciejjozefczyk | mriedem: maybe move it to common | |
| 16:43:30 | mriedem | i think we have to leave what's in the compute node object | |
| 16:43:37 | mriedem | but the RT stuff definitely isn't obvious | |
| 16:44:55 | mriedem | fyi to anyone that's interested in what's going on with the gate http://grafana.openstack.org/dashboard/db/zuul-status | |
| 16:45:02 | mriedem | executors are maxed out so throughput is down | |
| 16:45:14 | mriedem | recheck grind is also killing things | |
| 16:45:31 | mriedem | so if you have a patch queued up in zuul, no need to recheck it | |
| 16:45:52 | mriedem | add the change number to http://status.openstack.org/zuul/ if you want to see if it's queue | |
| 16:45:54 | mriedem | *queued | |
| 16:46:12 | mriedem | or use https://github.com/openstack/gerrit-dash-creator | |
| 16:47:35 | bauzas | mdbooth: very interesting, I'm trying to allocate 2 vGPUs on a single VM | |
| 16:47:45 | bauzas | libvirt fails miserably | |
| 16:48:02 | bauzas | I guess because of the nvidia driver | |
| 16:48:36 | mdbooth | bauzas: Other fun things: allocate 1 vgpu to 2 vms. Create an mdev of each of 2 different types. | |
| 16:49:01 | bauzas | mdbooth: my code prevents that | |
| 16:49:01 | mdbooth | bauzas: It would be awesome to document all these failure modes somewhere in a code comment. Maybe the privsep function? | |
| 16:49:12 | bauzas | mdbooth: we only support one type | |
| 16:49:13 | mdbooth | Yeah, I know. | |
| 16:49:22 | bauzas | and that's documented in the relnote | |
| 16:49:46 | mdbooth | bauzas: Right, but I'm just thinking it's interesting to understand our failure modes, and most people don't have the hardware to hand to test it. | |
| 16:49:58 | bauzas | for the multi-assignment of the same mediated device, that should also be in theory avoided by my code, except if bugs | |
| 16:50:02 | mdbooth | Will help reviewers/maintainers, for eg | |
| 16:50:21 | bauzas | mdbooth: I mean, what would you like to see ? | |
| 16:50:43 | bauzas | mdbooth: I can try to change the conf opt | |
| 16:50:45 | mdbooth | So do we see a failure on creating the mdev? | |
| 16:50:54 | mdbooth | Or subsequently when we try to use it? | |
| 16:50:57 | bauzas | you mean the privsep call ? | |
| 16:51:02 | mdbooth | And in either case, what form does the failure take? | |
| 16:51:06 | mdbooth | Yeah | |
| 16:51:27 | bauzas | what I haven't checked is what happens if I modify the conf opt and ask for another type | |
| 16:51:45 | mdbooth | bauzas: That's an extremely nice to have, btw. | |
| 16:51:49 | bauzas | in theory, it should say 0 available resources | |
| 16:52:13 | bauzas | because some mediated devices are already created for the existing guests, so the other resources are 0 | |
| 16:52:28 | mdbooth | If you're testing this stuff anyway, if you could squirrel away what real failures look like it would be really useful. | |
| 16:52:30 | bauzas | well, for that physical GPU | |
| 16:53:00 | bauzas | mdbooth: well, an instance leading to an ERROR state is okay to me, if that's documented why | |
| 16:53:17 | bauzas | like, if you make a flavor that asks for 2 VGPUs, it won't work | |
| 16:53:32 | bauzas | that's the caveats I mentioned in my note | |
| 17:07:50 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 17:12:32 | dansmith | mriedem: cdent: I just want to say that us passing around dicts of placement api goo in our scheduler paths is really not ideal | |
| 17:12:46 | dansmith | I'm changing the microversion I make a call at, which changes that format, | |
| 17:12:59 | dansmith | and thus a bunch of obscure dict manipulation code paths have to change in weird ways | |
| 17:13:13 | cdent | yeah, I made a similar comment on a recent bug report | |
| 17:13:14 | dansmith | if we had a proper client-side model of this it would be a lot easier to maintain | |
| 17:13:49 | cdent | of the 'when we bump to the new microversion this stuff gonna go funkity' | |
| 17:13:50 | mriedem | client side model like an object? | |
| 17:13:57 | dansmith | mriedem: yes | |
| 17:14:08 | mriedem | leave a todo in the patch? | |
| 17:14:55 | dansmith | if I ever get it working | |
| 17:29:01 | efried | dansmith An object like ProviderTree? Though also presumably an equivalent for allocation candidates. | |
| 17:29:27 | dansmith | efried: well, kinda yeah | |
| 17:31:10 | edleafe | dansmith: aren't we treating them as opaque blobs, as originally designed? I know there was the doubking up hack, but that should no longer be necessary | |
| 17:31:21 | cdent | edleafe: they've changed shape | |
| 17:31:27 | cdent | and they get manipulated | |
| 17:31:34 | cdent | so not really opaque (last I checked) | |