Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
16:52:56 bauzas in the same novaclient call
16:53:18 dansmith maybe, but not on the actual POST of /flavors
16:53:28 dansmith confirmed in flavor_manage
16:53:33 bauzas hah
16:53:40 bauzas then I trampled my brain
16:53:41 dansmith it's not that it's a bad thing,
16:53:44 bauzas if so, I agree with you
16:53:57 dansmith it's just like.. I'm not sure I get the point of doing a microversion for that
16:54:00 dansmith mriedem: know anything about this?
16:54:20 gibi jaypipes, mlavalle: this etherpad discussion was really useful, thanks
16:54:40 mlavalle gibi, jaypipes: Thank You
16:54:43 bauzas dansmith: I guess the main concern is "should we accept that ?"
16:54:57 bauzas I mean, accepting to create a flavor with some extra specs
16:55:13 dansmith well, that's a different question/change than proposed by this spec addition :)
16:55:31 bauzas right
16:55:41 bauzas honestly, that would be a separate spec then
16:55:43 bauzas -1
16:56:11 cfriesen when asking placement for candidates, does nova-scheduler ask placement to limit how many candidates are returned, or does it get *all* of the possible candidates?
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 efried mriedem: I'm nitpicking your patches so dansmith will +1 me.
17:11:53 mriedem that reminds 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

Earlier   Later