| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 16:56:14 | mlavalle | gibi: so I won't review the Nova spec as is. I will wait for the next iteration | |
| 16:56:53 | mriedem | uh | |
| 16:56:55 | mriedem | never seen that spec | |
| 16:57:02 | mriedem | oh wait, | |
| 16:57:20 | gibi | mlavalle: sure, I will try to do it right now | |
| 16:57:22 | mriedem | umm, that bp is already approved | |
| 16:57:24 | mriedem | dansmith: bauzas | |
| 16:57:38 | bauzas | mriedem: because the spec was approved for just *getting* extra specs | |
| 16:57:40 | mlavalle | gibi: ah ok, then I will take a look at it later today | |
| 16:57:43 | dansmith | right, so I guess this is already going to bring in a microversion for the GET changes, | |
| 16:57:45 | mriedem | oh this is an amendment | |
| 16:57:46 | gibi | mlavalle: I will ping you | |
| 16:57:52 | mlavalle | perfect | |
| 16:57:54 | bauzas | mriedem: now, it asks to pass extra specs when creating | |
| 16:57:56 | dansmith | so we just do these few extra bits in the same microversion | |
| 16:58:00 | dansmith | bauzas: no it doesn't | |
| 16:58:06 | dansmith | bauzas: it's about the return of those calls | |
| 16:58:10 | mriedem | i need to read this change first | |
| 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 | |