| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-25 | |||
| 15:38:09 | stephenfin | Oops - fried_rice ^ | |
| 15:38:17 | mriedem | cdent is vmware | |
| 15:38:30 | fried_rice | oh, okay, cool. | |
| 15:38:35 | stephenfin | dansmith: Should I remove that deprecation warning entirely or simply soften the language? | |
| 15:38:50 | dansmith | stephenfin: I think you should remove the log statement entirely | |
| 15:39:00 | stephenfin | There's still some issues. A debug-level warning and pointer to the bug might be helpful | |
| 15:39:05 | stephenfin | K. I'll do that so | |
| 15:40:09 | mriedem | WOOT http://logs.openstack.org/44/497944/1/check/gate-tempest-dsvm-py35-ubuntu-xenial/ba85bc2/logs/etc/nova/nova_cell1.conf.txt.gz | |
| 15:40:14 | mriedem | log formatting ftw | |
| 15:40:38 | mriedem | clarkb: ^ | |
| 15:40:45 | mriedem | now to find a devstack core | |
| 15:41:01 | kashyap | dansmith: Reading your comment on the unset 'keymap' patch, where you refer to the feedback on this - https://review.openstack.org/#/c/483994/4 | |
| 15:41:30 | kashyap | dansmith: Did you also read my comment? Also, we don't know what version of noVNC did the tester try it with | |
| 15:41:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Allow users to unset 'keymap' options https://review.openstack.org/496605 | |
| 15:41:51 | stephenfin | dansmith: ^ | |
| 15:41:56 | kashyap | But I agree, we shouldn't hurry to deprecate it | |
| 15:42:30 | stephenfin | kashyap: Yeah, this is a good interim (and backportable) step. We can look into the issue in more detail over Queens | |
| 15:42:37 | dansmith | kashyap: I'm not sure what your comment has to do with my comment | |
| 15:42:52 | kashyap | "We probably should drop the warning here given the feedback on the following deprecation patch." | |
| 15:43:16 | kashyap | I think you were referring to the feedback by Tushar Patil? | |
| 15:44:08 | kashyap | Ah, I missed to note in _what_ scenario one can unset the '-k' option | |
| 15:44:47 | kashyap | *If* the noVNC client supports (from 0.6.1 & above it seems) the "QEMU RFB extension" (https://github.com/novnc/noVNC/pull/596), then the '-k' is not needed at all. | |
| 15:45:06 | edmondsw | claudiub: fried_rice: problem with spoofing vendor/product id would be that if they're not real how does the operator figure them out to put in the conf? Same issue as address | |
| 15:45:16 | edmondsw | sorry, finally got off my calls and catching up | |
| 15:45:27 | kashyap | Anyway, for now, stephenfin's allowing to unset the option is good. | |
| 15:46:27 | dansmith | stephenfin: see my comment just now.. I might be missing something | |
| 15:46:59 | fried_rice | edmondsw Yeah, I think that's why we want to be able to support alternative mechanisms for identifying the devices. | |
| 15:47:06 | edmondsw | +1 | |
| 15:47:09 | claudiub | edmondsw: yep, that's what i'm thinking about. although, there is a way, at least for my scenario. since i'm doing an md5 of the NIC's PCI device_id, a small script can be provided to "figure out" the vendor_id and product_id | |
| 15:47:21 | fried_rice | edmondsw See :08:13 | |
| 15:47:29 | clarkb | mriedem: is that content not the default out of nova/etc in the nova repo? | |
| 15:47:32 | claudiub | but ideally, we wouldn't have to rely on something like this | |
| 15:47:48 | fried_rice | claudiub You're only doing that for SR-IOV, so the user never sees it, right? | |
| 15:47:59 | claudiub | fried_rice: yep | |
| 15:48:03 | edmondsw | claudiub yeah... but it's a lot nicer to operators if they can just plug in something that makes sense, not have to go figure out how to turn what they know into something nova can understand | |
| 15:48:05 | fried_rice | I.e. the user doesn't have to figure out that MD5 spoofing and set up an alias with it. | |
| 15:48:12 | claudiub | fried_rice: it only has to be whitelisted | |
| 15:48:27 | fried_rice | claudiub And your setup allows you to whitelist by address :) | |
| 15:48:36 | clarkb | mriedem: I guess not reading the change it is an explicit step taken in devstack. Interesting | |
| 15:48:46 | fried_rice | After you've done all the mounting & dismounting gorp per https://blogs.technet.microsoft.com/heyscriptingguy/2016/07/14/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/ | |
| 15:50:09 | claudiub | fried_rice: that link is only for full PCI passthrough, not for SR-IOV. :) | |
| 15:50:28 | fried_rice | claudiub So how do you whitelist SR-IOV? | |
| 15:53:04 | claudiub | fried_rice: for hyper-v SR-IOV configuration, there are other steps to check if it's supported and enable it. For example, running the powershell command Get-VMHost, will also include SR-IOV support details: if it's supported or not on the host (must be enabled in BIOS). Afterwards, the NICs have to be checked if they support SR-IOV, which can be checked by Get-NetAdapterSriov, if i'm not mistaken | |
| 15:53:31 | fried_rice | claudiub But what do you put in the nova-cpu.conf's [pci]passthrough_whitelist ? | |
| 15:53:58 | fried_rice | Do the above commands produce some kind of output that the user can translate to the whitelist entry? | |
| 15:54:10 | mriedem | clarkb: yeah | |
| 15:54:14 | mriedem | devstack sets that up | |
| 15:54:16 | claudiub | fried_rice: at this moment, those spoofed vendor_id, product_id | |
| 15:54:31 | fried_rice | claudiub Oh, so your user *does* see the spoofed vendor/prod IDs. | |
| 15:54:33 | claudiub | but ideally I'd have a better option. | |
| 15:54:54 | fried_rice | okay, cool, that's a pretty good story. | |
| 15:55:04 | claudiub | fried_rice: only on the compute node's nova.conf file. | |
| 15:55:19 | fried_rice | claudiub Right, operator-facing. | |
| 15:55:29 | claudiub | fried_rice: yep | |
| 15:55:34 | fried_rice | Which is ick. | |
| 15:55:49 | claudiub | yep | |
| 16:03:28 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: WIP: SPEC: PCI passthrough by device ID https://review.openstack.org/497965 | |
| 16:03:31 | openstackgerrit | Dan Smith proposed openstack/nova master: Move hash ring initialization to init_host() for ironic https://review.openstack.org/497966 | |
| 16:04:23 | dansmith | edleafe: ^ | |
| 16:04:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Allow users to unset 'keymap' options https://review.openstack.org/496605 | |
| 16:04:57 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: De-duplicate some graphics tests https://review.openstack.org/497969 | |
| 16:05:19 | stephenfin | dansmith: ^ | |
| 16:05:25 | dansmith | aye | |
| 16:05:29 | stephenfin | ta | |
| 16:06:12 | dansmith | stephenfin: you're still not setting keymap to None... is there a reason? | |
| 16:06:16 | dansmith | in the test I mean | |
| 16:08:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: De-duplicate two delete_allocation_for_* methods https://review.openstack.org/496936 | |
| 16:09:45 | cdent | thanks for making that fix mrhillsman | |
| 16:09:45 | cdent | whoops mriedem | |
| 16:10:07 | mriedem | np | |
| 16:10:43 | fried_rice | cdent Rumor has it you're the VMWare guy. (mriedem threw you under the bus) | |
| 16:11:02 | mriedem | dansmith: first, superdan | |
| 16:11:04 | fried_rice | cdent Can you (refer me to someone who can) speak to how PCI is handled in VMWare? | |
| 16:11:11 | mriedem | second, notice the todo i added in here yesterday? https://review.openstack.org/#/c/497606/1/nova/compute/manager.py@3798 | |
| 16:11:23 | mriedem | superdan: am i just blind or does that error handling not make any sense? | |
| 16:12:15 | mriedem | it was added long ago https://review.openstack.org/#/c/73387/ and had quite a bit of review from different people, but i don't see how it made sense back then either | |
| 16:12:17 | cdent | fried_rice: if you mean being employed by vware makes me the vmware guy, then yes. I’ve pointed out the conversation from earlier to some people who were interested. | |
| 16:12:30 | mriedem | cdent: would that be radu? | |
| 16:12:41 | mriedem | radu is the only other person i know that was working on nova in recent times | |
| 16:13:01 | fried_rice | cdent Cool beans. And FYI for passing along to those folks: https://blueprints.launchpad.net/nova/+spec/pci-by-device-id (cc stephenfin claudiub) | |
| 16:13:45 | cdent | rgerganov and gjayavelu . I’ll let them know to look (and to come back to irc one in a while) | |
| 16:14:04 | cdent | there are a lot of people who apparently used to | |
| 16:14:09 | cdent | but not so much now | |
| 16:14:10 | mriedem | there was also of course no test for the compute manager piece of that | |
| 16:14:14 | mriedem | i think i'm just going to remove it | |
| 16:14:17 | superdan | mriedem: I bet that was intending to catch migrationerror, which can be raised by _prep_resize | |
| 16:14:39 | superdan | mriedem: well, the comment definitely talks about the call though | |
| 16:15:07 | superdan | mriedem: like I said yesterday I thought that was a call, so that person did too | |
| 16:15:26 | mriedem | ok, i was going to say, from the change itself, it's raising that here https://review.openstack.org/#/c/73387/13/nova/virt/libvirt/driver.py | |
| 16:15:34 | mriedem | which on the source after the rpc cast | |
| 16:15:48 | mriedem | the rpc all you mentioned yesterday i thought was about something in conductor, but maybe i'm confused | |
| 16:16:02 | mriedem | anyway, i'm going to remove this handling from prep_resize as it can't happen | |
| 16:16:32 | superdan | hang on | |
| 16:16:34 | superdan | I'm confused | |
| 16:17:16 | mriedem | the libvirt driver raises that error from migrate_disk_and_power_off which is called from ComputeManager.resize_instance, | |
| 16:17:25 | mriedem | _prep_resize does an rpc cast to resize_instance on the source host | |
| 16:17:31 | superdan | mriedem: so you see that we can raise a MigrationError in there, right? | |
| 16:17:34 | mriedem | since it's a cast, the error raised from migrate_disk_and_power_off on the source can't come back | |
| 16:17:40 | mriedem | in _prep_resize? | |
| 16:17:43 | superdan | yeah | |