Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-14
13:56:30 mriedem like i came across this today https://bugs.launchpad.net/nova/+bug/1682060
13:56:30 openstack Launchpad bug 1682060 in kolla-ansible "empty nova service and hypervisor list" [Undecided,New]
13:56:42 mriedem ^ is a thing that just landed which broke how kolla does cell setup
13:56:53 mriedem yay
13:56:57 efried mriedem Okay, looking. (And will have to find out wtf kolla is...)
13:57:14 mriedem kolla is openstack on top of k8s
13:57:20 mriedem deploy openstack with k8s
13:57:34 efried And k8s is...?
13:57:38 mriedem kubernetes
13:58:15 mriedem dude, i'm still reeling from the shelve/unshelve stuff i was digging into for a few hours yesterday
13:58:26 mriedem i find new and terrible things every day it seems
13:58:54 mriedem well, "find" as in new to me, and then i find out someone else found the same thing out over a year ago
13:58:57 mriedem and it's not fixed yet
14:01:12 mriedem cdent: back to your point about dropping code,
14:01:15 mriedem i think we can do that after a release
14:01:28 mriedem cdent: so you request the new microversion and if it's there, great, else fallback,
14:01:47 mriedem cdent: and then in queens, we require the higher microversion - we've been signalling that in nova-status
14:01:57 cdent mriedem: okay, no problem, that's what I'm doing now: trying the new way. kablooie? okay do the old way
14:02:08 mriedem e.g. filter scheduler requires placement>=1.4 in pike, and nova-status checks that too
14:02:31 mriedem yeah https://github.com/openstack/nova/blob/ae637e70a72166067e09f3bbc3acb54e5d92771e/nova/cmd/status.py#L208
14:02:33 mriedem cool
14:02:53 mriedem huh, never realized we were using pkg_resources there
14:03:44 cdent mriedem: that's a relatively recent bugfix
14:03:48 cdent it was doing floats initially
14:03:53 cdent which would have broken relatively soon
14:04:31 mriedem i remember seeing something about that
14:06:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Clarify wording in compute API _delete method https://review.openstack.org/456910
14:13:23 sdague mriedem: you know, shelve/unshelve being terrible might be a feature and not a bug, to convince no one to ever use it
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 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:22 cdent turn if off and wait for someone to complain :D
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 flavors-access endpoint instead of stevedore https://review.openstack.org/456589
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: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: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: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 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:27:15 mriedem so compute_shelve_instance is an action event
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

Earlier   Later