| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-11 | |||
| 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) | |
| 17:32:00 | bauzas | dansmith: not sure you saw the long convo I had with mdbooth but before I leave for 2.5 hours (will be back later), just food for thoughts | |
| 17:32:07 | cdent | I can't remember why they get manipulated | |
| 17:32:20 | cdent | My ability to index this stuff for memory is broken | |
| 17:33:02 | dansmith | edleafe: not in the scheduler | |
| 17:33:12 | dansmith | edleafe: I'm not having any problems with the code that treats it as opaque | |
| 17:33:14 | bauzas | dansmith: since we create mediated devices on the fly (or allocate them) based on allocations, and generate the guest config with that, thanks to allocations, it means that when you power off and then power on again, you get a guest that no longer has VGPUs because we don't pass (yet) the allocations to power_on() | |
| 17:33:37 | dansmith | bauzas: okay | |
| 17:33:56 | bauzas | dansmith: everything works seamlessly when booting, so https://review.openstack.org/#/c/528832/ is ready for reviews, but I'll need to address that issue in a follow-up | |
| 17:34:31 | homeski | Question for anyone ... | |
| 17:34:45 | homeski | I have a instance booted from volume, where the volume gets attached using the IDE bus | |
| 17:34:50 | homeski | is there a way, using OSP CLI, to have the boot device remounted using virtio ? | |
| 17:34:57 | homeski | ight now I have to manually `virsh edit` the XML | |
| 17:35:04 | homeski | Also, if I attach any additional volumes, they always get attached using IDE, even if I have `disk_bus=virtio` set on the volume metadata | |
| 17:35:10 | homeski | I have to keep messing with the XML manually | |
| 17:35:44 | dansmith | edleafe: and we can't get rid of the doubling until rocky, AFAIK, because pike computes still depends on it | |
| 17:36:22 | dansmith | homeski: see topic please | |
| 17:36:40 | homeski | gotcha, thx | |
| 17:36:54 | edleafe | dansmith: sure, what I was asking was if that was a one-off thing, and that we aren't doing any more of it | |