Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-14
14:15:07 mriedem sdague: well, it's also fodder for why nova/openstack is no good
14:15:17 mriedem i'd rather drop things that don't work
14:16:01 sdague mriedem: I agree on the drop front
14:16:33 mriedem i think fixing the volume terminate_connection thing is simple, but that only fixes some backends, because of how cinder works
14:16:42 mriedem which is unfortunate, and what stalled fixing it over a year ago
14:17:05 mriedem because what really needs to be called is this internal remove_export function which only os-detach calls, but that's exactly what we don't want to use for shelve becaues we want the volume to stay attached
14:17:17 sdague mriedem: it would be nice if there was a way we could actually get some real data on whether anyone actually uses this bit
14:17:44 smcginnis +1
14:17:47 mriedem so cinder exposes a new api, or changes terminate_connection to also call remove_export, of nova calls detach but then immediately also calls reserve_volume so the instance doesn't lose the volume, all of which aren't great
14:18:00 mriedem option 2 there is probably my favorite
14:18:04 mriedem since it abstracts everything within cinder
14:18:14 mriedem sdague: yeah but i don't really know how to get that
14:18:31 sdague mriedem: yeh, me either
14:18:32 mriedem polling the operators, i could ask if they disable it via policy
14:18:48 mriedem can't really ask users though
14:19:20 mriedem i also don't know if operators track incoming request metrics and could figure out how many calls are made to that api in a week/month
14:19:22 cdent turn if off and wait for someone to complain :D
14:19:22 sdague mriedem: so... an idea I was thinking about the other day was to actually build something into nova that builds API stats in a format that's easy to annonymously dump back out
14:19:40 sdague cdent: if the feedback cycle wasn't 1.5 years, that would work :)
14:20:07 mriedem we send an instance.shelve notification, which i'd think telemetry is consuming, but i'm not sure,
14:20:09 cdent we've all become quite patient for other reasons...this one more thing, no problem
14:20:19 mriedem but that also assumes people are using telemetry, which is a bad assumption
14:20:28 cdent yes it is a bad assumption
14:20:39 cdent it's also a bad assumption that even if they were, that they were recording that particular event
14:20:48 cdent s/recording/persisting/
14:20:51 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for flavor endpoint instead of stevedore[1] https://review.openstack.org/456549
14:20:51 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for flavors-access endpoint instead of stevedore https://review.openstack.org/456589
14:20:52 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for flavors-extraspecs endpoint instead of stevedore https://review.openstack.org/456585
14:20:52 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for '/os-aggregates' endpoint instead of stevedore https://review.openstack.org/456825
14:20:53 openstackgerrit Alex Xu proposed openstack/nova master: Use plain routes list for '/os-keypairs' endpoint instead of stevedore https://review.openstack.org/456478
14:21:21 sdague mriedem: so, just based on past interactions with folks, I honestly just wonder if marking shelve/unshelve as experimental in the API docs, say there are a number of issues with it, and move on might be best
14:21:31 sdague because it really really seems far on the edge
14:21:52 sdague and it gets a disproportunate amount of debugging time relative to use
14:23:08 mriedem i was hoping we could just pull from INFO logs in n-api for when a POST request to shelve comes in, but because it's an 'action' API and the bit we care about is in the body, we don't have that info...
14:24:09 mriedem i'm fine with noting limitations in the api, we do that for some other things as well, or should: https://review.openstack.org/#/c/452970/
14:24:19 mriedem https://review.openstack.org/#/c/452970/2/api-ref/source/servers-admin-action.inc
14:24:31 sdague mriedem: yep, that's one of those issues. I do think it's elsewhere though. Anyway, need to afk for a bit.
14:26:00 feeblepipes mriedem: happen to know Jan Gutter's IRC nick?
14:26:07 mriedem jangutter
14:26:14 feeblepipes mriedem: k, thx.
14:26:30 mriedem sdague: on "an idea I was thinking about the other day was to actually build something into nova that builds API stats in a format that's easy to annonymously dump back out" - thinking about that, i think we already have that, it's instance actions
14:27:15 mriedem so compute_shelve_instance is an action event
14:27:15 feeblepipes mriedem: pls see my -1 and comments from that netronome spec. I'm cool with it, but have concerns about the PCI device allocation code proposed for neutronv2/api.py module.
14:31:03 mriedem feeblepipes: they just mean this i think https://review.openstack.org/#/c/456481/1/nova/network/neutronv2/api.py
14:31:14 mriedem in addition to handling direct-physical, handle this other vnic type
14:31:30 mriedem that would need to be cleaned up a bit and non-vendorized,
14:31:34 mriedem but i think the spec notes that
14:35:44 feeblepipes mriedem: yeah, not really a fan of that approach as it embeds way too much vendor/product specific stuff into the model. It shouldn't matter what vendor/product_id is used underneath the covers. all that should matter is what *functionality* the end user can derive from the particular vNIC. so the things that should be passed from the neutronv2 api should really only be feature requests/capabilities, not vendor/product information.
14:35:49 feeblepipes mriedem: make sense?
14:36:59 cdent feeblepipes++
14:37:38 mriedem feeblepipes: so you're also saying you're not a fan of the existing direct-physical thing we already have in that code?
14:37:42 mriedem which i'm pretty sure doesn't work...
14:37:53 mriedem because a week after it landed, nikola created 2 bugs about it not working
14:38:10 feeblepipes mriedem: correct, I wasn't a fan of it when it entered the code and I'm still not a fan of it. you can check the review on that if you'd like :)
14:38:11 mriedem either way i'll totally defer here
14:38:49 mriedem i don't really know what the alternative implementation is, they are going to need some help there
14:38:58 feeblepipes mriedem: again, I'm not opposed to the netronome stuff at all. just have reservations (pun intended) about this particular part of th eproposal.
14:39:18 feeblepipes mriedem: yeah, I'll wait for Jan to answer and think about alternatives to recommedn.
14:40:23 feeblepipes mriedem: also note that the direct-physical thing is *only* passing through a network tag (the physnet tag) from Neutron's port profile. It isn't passing a vendor-specific piece of information.
14:41:30 feeblepipes mriedem: or perhaps you were referring to a different part of the codebase w.r.t. the direct-physical thing?
14:42:46 mriedem no i was just pointing at that thing
14:43:06 mriedem this part dev_type = pci_request.DEVICE_TYPE_FOR_VNIC_TYPE.get(vnic_type)
14:43:11 feeblepipes right
14:43:19 mriedem pci_request.DEVICE_TYPE_FOR_VNIC_TYPE is only mapped to direct-physical
14:43:25 feeblepipes yes, understood.
14:44:06 jangutter Oh hey, thanks for taking the time to review!
14:44:14 feeblepipes jangutter: hi :)
14:44:26 feeblepipes jangutter: sorry for the delay. been quite ill last few days :(
14:45:16 jangutter feeblepipes: not a problem, it took waaay too long on our side to jump the necessary hurdles. No-one to blame but me.
14:46:33 jangutter feeblepipes: yeah, regarding that allocation, the idea is not to put in a new place for it, but to allow port profiles that are "non-SR-IOV" to also request pci devices.
14:49:18 jangutter feeblepipes: and you're absolutely right, it is the crux of the spec. I had looked at other places, but most of them would happen after scheduling had already occurred.
14:49:30 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Add Cinder v3 detach call to _terminate_volume_connections https://review.openstack.org/456896
14:49:33 feeblepipes jangutter: see what I wrote to mriedem above about being pretty firm about keeping the information that we pass about the vNIC as vendor-agnostic as possible (and focusing instead on the *features* or functionality that the underlying technology supports)
14:49:38 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Idempotent PUT /resource_classes/{name} https://review.openstack.org/448791
14:49:39 openstackgerrit Chris Dent proposed openstack/nova master: Update resource tracker to PUT custom resource classes https://review.openstack.org/456915
14:50:10 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386
14:50:33 feeblepipes jangutter: what I'd like to see is a description of those features of the virtual switch technology that we could use instead of specific PCI vendor_id/product_id information.
14:52:00 jangutter Yep, so after a discussion yesterday with sean-k-mooney, it looks like it should be possible to push that check out to the OS-VIF side.
14:52:34 feeblepipes jangutter: another way to think about things... what is the difference between network_model.VNIC_TYPE_AGILIO_PASSTHROUGH and network_model.VNIC_TYPE_DIRECT or, frankly, network_model.VNIC_TYPE_DIRECT_PHYSICAL?
14:54:22 jangutter feeblepipes: Those two AGILIO VNIC types were added to in an effort not to re-use internal OpenStack code: they should go completely away.
14:56:00 jangutter feeblepipes: The idea is to have all the necessary whitelist info sent down via the os-vif port profile, so that the API will do matching.
14:57:24 feeblepipes jangutter: ok. that's cool with me. How exactly, however, do you plan to keep vendor_id/product_id information out of the os-vif modeling? In other words, what I'm looking for is an indication that you've thought of how to communicate the *functionality* that Agilio SmartNICs provide to the end user instead of passing a PCI vendor_id/product_id :)
14:58:59 jangutter feeblepipes: That's done in a couple of ways: a deployer runs a script that generates a nova.conf fragment, this adds the VF's to the compute node with in a full pci-whitelist format.
14:59:37 feeblepipes jangutter: sure, understood. that merely lets nova-compute "use" the Agilio NICs for tenants.
15:00:08 jangutter feeblepipes: Secondly, the OS-VIF object for the external plugin gets a set of fields. Likely this would be vendor/productids, we'll definitely have to coordinate with Mellanox on that.
15:00:47 jangutter feeblepipes: so when the API code at that place hits, the port profile is available, and the pci devices has been registered.
15:01:06 feeblepipes jangutter: right, so that's the thing I'd be -1 on :) we should definitely work with Moshe and others from Mellanox to ensure vendor_id/product_id information isn't needed to be passed via os-vif models.
15:03:45 feeblepipes jangutter: what I'm looking for is an object model that says "hey, I need a VIF plug that supports feature X, Y, and Z", not an object model that says "hey, I need a VIF plug that is specific to Mellanox Indigo NPS"
15:03:52 feeblepipes jangutter: that make sense?
15:03:53 jangutter feeblepipes: hmmm... that's interesting... you just made me think quite a lot...
15:04:34 jangutter feeblepipes: that would basically mean a "capability set" sort-of?
15:04:40 feeblepipes jangutter: BINGO :)
15:05:36 feeblepipes jangutter: ala the traits/capabilities that have begun to emerge here: https://review.openstack.org/#/c/448283/4
15:06:17 jangutter feeblepipes: I can understand the appeal, but WOW, the parameter space is _big_.
15:06:29 feeblepipes jangutter: so, as an example, the Neutron port profile and os-vif object model would, say, have a list of these acceleration traits: https://review.openstack.org/#/c/448283/4/os_traits/hw/nic/accel.py
15:06:42 feeblepipes that would be required to match to an available PCI device on the target host.
15:07:52 feeblepipes jangutter: and Netronome and Mellanox would add a set of traits/features that their NICs supported to https://review.openstack.org/#/c/448283/4/os_traits/hw/nic/sriov.py
15:07:58 jangutter feeblepipes: I'm just worried that the acceleration traits would not dovetail much. For example, our NIC's got an insane amount of flexibility. The same HW can support many different features.
15:09:49 jangutter feeblepipes: our internal lingo for the firmware running on the chip is "application" - the image I get when l think of negotiating capabilities is some insane duel.
15:10:11 feeblepipes jangutter: an end user, though, only wants to launch a VM on a host that has a NIC with certain features. an end user doesn't say "hey, I want a VM with a Netronome Agilio SmartNIC" (because, frankly, the end user doesn't *know* that the underlying hardware has Agilio NICs). Instead, the end user says "hey, give me a VM that has access to an SR-IOV virtual function that has a particular set of features"

Earlier   Later