| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 16:58:18 | dansmith | so that seems okay then | |
| 16:58:35 | dansmith | I was reading this as "a new microversion to return the must-be-empty extra specs from POST" | |
| 16:58:37 | bauzas | well, then it's impossible to get extra specs from a POST | |
| 16:58:42 | bauzas | sorry, it's late here | |
| 16:58:45 | dansmith | but if it's just done with everything else, then it's not such a big deal | |
| 16:58:55 | dansmith | bauzas: right, like I said, it's good for consistency, | |
| 16:59:05 | mriedem | you can't create a flavor today with extra specs in a single call | |
| 16:59:09 | dansmith | just not worth its own microversion IMHO, but if this is in with the useful GET changes then not a big deal | |
| 16:59:27 | dansmith | mriedem: right and this isn't aiming to change that | |
| 16:59:35 | mriedem | so if this is just saying, return extra_specs in the POST response, but it will be empty, fine | |
| 16:59:38 | dansmith | just make the return of POST consistent | |
| 16:59:53 | dansmith | I just didn't see a point in doing a whole new microversion for that because.. always empty, | |
| 16:59:56 | bauzas | dansmith: yeah that's what I understood when reviewing first the change | |
| 16:59:57 | dansmith | but if it's just alongside the GET changes | |
| 16:59:59 | dansmith | then that's cool | |
| 17:01:02 | bauzas | dansmith: yeah, sorry, I got confused tonight | |
| 17:01:31 | bauzas | I didn't remember it was just the returned fields | |
| 17:01:32 | mriedem | https://review.openstack.org/#/c/554134/3/specs/rocky/approved/add-extra-specs-to-flavor-list.rst@177 | |
| 17:01:36 | mriedem | exactly ^ | |
| 17:02:06 | bauzas | honestly, passing the extra specs on both POST/PUT and GET with the same microversion seems harmless to me | |
| 17:02:29 | mriedem | passing in the request or the response? | |
| 17:02:35 | mriedem | this is just the response | |
| 17:02:36 | bauzas | no, in the response | |
| 17:02:51 | mriedem | yes, it is fine | |
| 17:03:00 | bauzas | hence my original +2 | |
| 17:03:03 | mriedem | presumably yikun hit this during implementation | |
| 17:03:12 | bauzas | but I was trampled by POST tonight | |
| 17:03:26 | bauzas | and me thinking I was misunderstanding the spec | |
| 17:03:46 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Amend the "add extra-specs to flavor" for create and update API https://review.openstack.org/554134 | |
| 17:04:12 | mriedem | http://trampledbyturtles.com/ ? | |
| 17:04:19 | dansmith | mriedem: I was +W before you hit that so you send it when you're ready | |
| 17:04:26 | mriedem | already did | |
| 17:04:49 | bauzas | nice band name | |
| 17:06:10 | efried | jaypipes: Here's one for ya. I sent in separate granular resource requests for the same resource class, e.g. resources1=VF:1,BW:200&resources2=VF:1,BW:300. Per design, it's possible to get back candidates where all of that comes from one RP. So in that candidate you'll get back a *single* RP { VF: 2, BW: 500 }. Now the virt driver (or neutron, or whatever) needs to go grab/create the actual resources... | |
| 17:06:15 | mriedem | where are the john hopkins people when you need them? | |
| 17:06:22 | dansmith | man I really should have reserved my +1 on efried until the end of the waiting period, just to keep him worry'n | |
| 17:06:30 | efried | jaypipes: I guess it has to look at the flavor to figure out that the BW should be split up 200 for one and 300 for the other? | |
| 17:09:39 | efried | dansmith: I would have totally seen through that. | |
| 17:10:59 | mriedem | there is a 1 week period right? | |
| 17:11:10 | mriedem | because efried has been nit pickin the shit out of my patches lately | |
| 17:11:37 | efried | mriedem: You like the abuse. | |
| 17:11:53 | mriedem | that reminds me, | |
| 17:11:53 | efried | mriedem: I'm nitpicking your patches so dansmith will +1 me. | |
| 17:11:55 | mriedem | you bastard, | |
| 17:12:00 | mriedem | i have to switch back to KSA | |
| 17:12:16 | efried | Well, we should be getting rid of neutronclient eventually anyway. | |
| 17:12:21 | mriedem | ha | |
| 17:12:22 | efried | and using raw ksa. | |
| 17:12:28 | mriedem | i will be dead and buried before that happens | |
| 17:12:29 | efried | like we're doing with ironic | |
| 17:12:37 | cfriesen | efried: why does placement combine the two requests? | |
| 17:12:41 | efried | But you don't have to do that. You can catch exceptions for error paths instead. | |
| 17:13:02 | mriedem | efried: i'd rather just say don't raise errors and check the response status code | |
| 17:13:19 | efried | mriedem: You could shim the neutronclient... | |
| 17:13:25 | efried | kidding | |
| 17:13:59 | efried | cfriesen: This is code not yet written. But if nothing else, it's because (I think) the syntax of the response has a dict keyed by resource class. So there would be no way to split them up even if we wanted to (without some new syntax). | |
| 17:14:37 | efried | cfriesen: But you raise a good point: since it's not written yet, we could still consider new syntax in the new microversion that introduces granular. | |
| 17:14:51 | efried | cfriesen: But that spec is already approved, so sorry, too late :P | |
| 17:15:12 | jaypipes | efried: yes | |
| 17:15:46 | mriedem | anyone know what is up with this sriov bond thing https://review.openstack.org/#/c/463526/ ? | |
| 17:15:52 | mriedem | sahid might but he's gone now | |
| 17:17:10 | openstackgerrit | Merged openstack/nova-specs master: Few correction in the server filter/sort spec https://review.openstack.org/527019 | |
| 17:17:18 | mriedem | dansmith: on the volume-backed rebuild + new image spec, i think i want to just say, add an api to cinder to re-image the volume and once that is in place, nova will use it | |
| 17:17:30 | mriedem | because cinder also has things it needs to update about the image in the volume, i.e. some image metadata stuff | |
| 17:17:45 | dansmith | mriedem: that would certainly be the nicest way yeah | |
| 17:17:47 | mriedem | because i don't think we want to do the volume create / delete swap thing, it's too messy | |
| 17:17:57 | mriedem | quotas, types, etc | |
| 17:18:23 | dansmith | I don't think create/swap/delete would be the way anyway, | |
| 17:18:34 | dansmith | we'd just lay the image down on the volume ourselves I think, | |
| 17:18:40 | dansmith | but that's definitely a whole big thing | |
| 17:18:42 | sean-k-mooney[m] | mriedem: is this yet another attempt at this or is it carring on form the previous attempts | |
| 17:18:47 | cfriesen | efried: if you send in two granular resource requests for resources1 and resources2, wouldn't it make sense to get back a dict of {resource1:<rp>, resource2:<rp>} or similar? They could still be the same RP. | |
| 17:18:47 | mriedem | and the volume image meta would be out of date | |
| 17:18:57 | mriedem | sean-k-mooney[m]: the sriov bond spec? it's old | |
| 17:19:00 | mriedem | and looks stale/abandoned | |
| 17:20:22 | sean-k-mooney[m] | mriedem: oh that is the bound spec that wanted to use neutron config element to configure bonds. ya i hated that part of it | |
| 17:20:36 | sean-k-mooney[m] | mriedem: ya there was also https://review.openstack.org/#/c/182242/ and there are 2-3 other ones dateing back to mitaka | |
| 17:21:36 | mriedem | dansmith: ok done https://review.openstack.org/#/c/532407/ | |
| 17:21:37 | efried | gibi: In case you're in the middle, just finished review of https://review.openstack.org/#/c/502306/21 | |
| 17:22:13 | sean-k-mooney[m] | mriedem: but yes no one has touched it since december so i think https://review.openstack.org/#/c/463526/43 is abandoned. its still proposed against queens | |
| 17:23:11 | dansmith | mriedem: so, we'll need to detach the volume in order for cinder to be able to do that, which is basically equivalent to root-detach, which we already failed to do in the past.. just.. sayin' | |
| 17:23:12 | mriedem | i abandoned https://review.openstack.org/#/c/182242/ today | |
| 17:23:20 | gibi | efried: thanks, I'm currently working on an update. I will try to address your comments in that as well | |
| 17:23:55 | mriedem | dansmith: detach or disconnect from the host? | |
| 17:24:11 | mriedem | we need to at least keep the volume reserved for the instance | |
| 17:24:14 | dansmith | mriedem: can we do those separately? | |
| 17:24:16 | mriedem | yes | |
| 17:24:20 | dansmith | okay | |
| 17:24:24 | dansmith | then, disconnect I guess | |
| 17:24:30 | mriedem | it's basically shelve | |
| 17:24:34 | dansmith | as long as cinder doesn't have a fit with that internally | |
| 17:24:35 | mriedem | shelve the root volume | |
| 17:24:41 | dansmith | mriedem: ...which you can't do with bfv | |
| 17:24:44 | mriedem | cinder would only care about the attachments | |
| 17:24:45 | dansmith | well, | |
| 17:24:48 | dansmith | you can maybe, | |
| 17:25:03 | dansmith | but not without detaching the root, which I guess is your point | |
| 17:25:29 | mriedem | honestly i don't know if volume-backed shelve works | |
| 17:25:36 | mriedem | since snapshot for a volume-backed instance is different in the api | |
| 17:25:36 | dansmith | I guess the root detach thing was mostly hard because of the desire to attach it to something else in the mean time, | |