Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-27
16:21:45 mriedem https://github.com/openstack/nova/blob/ed55dcad83d5db2fa7e43fc3d5465df1550b554c/nova/virt/libvirt/driver.py#L207
16:21:47 mriedem toabctl: ^
16:22:41 mriedem kashyap: andreas_s is the person to ask for zkvm
16:22:52 toabctl mriedem, I'm saying the versions are up-to-date. so Rocky seems to be fine
16:23:11 mriedem yeah, we're talking about what the next min versions should be in S
16:24:47 toabctl mriedem, so do you plan to use a higher version than currently supported on SLES/openSUSE? looks like most other distros have lower versions currently
16:25:14 toabctl mriedem, but there will be SLES15 and openSUSE Leap 15 soon. both will have newer versions. let me check these
16:25:29 mriedem toabctl: likely not no, the next min version should be compatible with what the various distros can support in S
16:25:40 mriedem the point of the next min version isn't to be the bleeding edge
16:25:49 mriedem it's to raise the bar, but still be a minimum that can be supported across distros
16:26:30 imacdonn mriedem kashyap toabctl Do keep stvnoyes1 and I in the loop, please .... QEMU/KVM version for Oracle Linux could be a bit tricky ... I think somenew newer is in the works there, but I can't make any public statements at the moment
16:26:40 imacdonn something* newer
16:27:03 openstackgerrit Merged openstack/nova master: add check before adding cpus to cpuset_reserved https://review.openstack.org/539865
16:27:12 openstackgerrit Merged openstack/nova master: Docs: modernise links https://review.openstack.org/556024
16:29:25 gibi sahid: responded in https://review.openstack.org/#/c/511188/13
16:29:57 cfriesen kashyap: just added a comment to your cpu feature flag review, but might make sense to discuss it here....seems like libvirt does allow you to set additional features when using host-model, do we want to artificially restrict that?
16:36:39 jaypipes gibi, mlavalle: gotta love etherpad conversations. even better than IRC conversations... ;)
16:37:00 mlavalle jaypipes: it was a good idea
16:37:23 mlavalle if there is a lot to discuss, it seems more orderly
16:39:06 openstackgerrit Ed Leafe proposed openstack/nova-specs master: Add Generation to Consumers https://review.openstack.org/556971
16:39:22 edleafe cdent: jaypipes: efried: ^^
16:39:34 efried edleafe: noyce
16:39:34 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Few correction in the server filter/sort spec https://review.openstack.org/527019
16:39:38 cdent edleafe: roger that
16:42:15 efried bauzas: ^ I think you wanted to refer to that from your spec
16:42:31 efried bauzas: Add Generation to Consumers https://review.openstack.org/556971 that is
16:42:41 bauzas mmm ?
16:42:50 bauzas it's 18:42 here and my brain dropped
16:43:04 bauzas and I still have to write a spec :p
16:50:18 dansmith bauzas: on this: https://review.openstack.org/#/c/554134/3
16:50:50 dansmith bauzas: I get the desire for consistency, but it seems to me that on POST, extra_specs would always be empty, and on PUT you can't modify them anyway (right?)
16:51:21 dansmith I guess maybe that's a reason to do it for PUT, but POST seems completely trivial
16:52:31 bauzas dansmith: sec, verifying
16:52:43 bauzas dansmith: because IIRC, you can *create* a flavor and passing a spec
16:52:53 dansmith bauzas: see the comments in the spec that say no
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

Earlier   Later