Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-25
15:28:51 fried_rice I want the RP to be able to say "I can supply this many VFs" (or VNICs, or whatever) - just like it says "I can supply this many VCPUs".
15:29:04 fried_rice And when I do a claim, it decrements by one and lets my compute driver do the rest.
15:29:39 claudiub fried_rice: that sounds ideal, IMO.
15:29:55 fried_rice claudiub Okay, so same question about blueprint collaboration there.
15:30:55 claudiub fried_rice: I'd help in any shape / form I could, but I am a bit swamped at the moment, so I can't make any promises. :)
15:32:06 fried_rice claudiub Really all I'm asking for is a hearty "me too" if I propose this stuff. If this is just for PowerVM, it's a tough sell. But if there's more than one driver that cares, it carries a lot more weight.
15:33:02 claudiub fried_rice: then yes, that would help me as well. :)
15:33:06 fried_rice claudiub You going to the PTG?
15:35:34 claudiub fried_rice: unfortunately, no
15:36:31 fried_rice Okay. There's a topic queued up (see https://etherpad.openstack.org/p/nova-ptg-queens ~L66). If you want to add a note in there, at least, that'll help when I take the floor with it.
15:37:25 fried_rice I would like to have this same discussion with someone from VMWare - see if this direction is also of interest there. Any idea who would be a good touchpoint there? stephenfin
15:38:03 stephenfin dansmith: I've no idea, unfortunately. mriedem might know though?
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

Earlier   Later