| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 16:20:30 | sahid | yes yes no worries | |
| 16:20:32 | bauzas | melwitt: arouuuuund ? | |
| 16:20:41 | toabctl | kashyap, mriedem the (open)SUSE entries seems to be ok. the upcoming versions are not yet there but SLES12SP3 is the version that we need support for imo | |
| 16:21:13 | mriedem | toabctl: as the next min version you mean? | |
| 16:21:16 | bauzas | sahid: https://review.openstack.org/#/c/511188/ is on my list | |
| 16:21:19 | mriedem | for rocky, we already have the next min versions in plae | |
| 16:21:21 | mriedem | *plcae | |
| 16:21:23 | mriedem | damn it | |
| 16:21:27 | bauzas | place FTW | |
| 16:21:40 | sahid | bauzas: ah cool, thanks | |
| 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 ^ | |