| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-02 | |||
| 16:41:20 | artom | mordred, ah, for example for things like new fields in responses? sdk just shows them with no added logic | |
| 16:41:25 | artom | (Right?) | |
| 16:41:26 | gmann | yeah, like adding the field in response is same list | |
| 16:42:04 | mordred | yeah, well, we need to add new fields when they're added | |
| 16:42:27 | mordred | but - we already are up to date with most fields as of like the mid-2.4x or 2.5x - just not labeled that way | |
| 16:42:37 | mordred | so for many of them we're already caught up :) | |
| 16:42:48 | mordred | and for new ones adding support is _usually_ very trivial - one or two lines | |
| 16:43:00 | mordred | the behavior breaks - like changing live migration - those take some real thought | |
| 16:43:08 | mordred | but - those require real thought to do the feature too | |
| 16:44:20 | artom | Yeah, the live migration thing was ugly | |
| 16:44:32 | artom | But let's not revisit that :) | |
| 16:44:33 | gmann | is it not we need to bump the python-novaclint version on OSC because we maintain the MAX_VERSION there and increase when no change needed | |
| 16:44:38 | mordred | yeah. but - that's one of the ones where I'm quite happy with our support | |
| 16:45:36 | mriedem | in my experience adding feature parity for compute API microversions to OSC, for example, is not always so trivial, especially when the people reviewing the changes aren't from the nova team or aren't familiar with how the API works | |
| 16:46:12 | gmann | +1 | |
| 16:46:13 | mordred | I agree - although I'd like to make progress on changing that :) | |
| 16:46:14 | artom | mordred, alright, we'll probably talk this over at the PTG again, but the initial "action item" of "require sdk patch, use as opportunity to catch up a bit" makes sense to me | |
| 16:46:17 | mriedem | so random person throws up a change and the OSC team just basically trusts that it's correct from an API POV and then their review is based on UX standards for OSC | |
| 16:46:37 | mriedem | mordred: there was progress while i was pushing it from the nova team, but ... | |
| 16:46:41 | mriedem | someone needs to fill those shoes | |
| 16:46:49 | artom | Yeah, having someone from the project reviewing the change should be a must | |
| 16:46:50 | mordred | mriedem: we just need to clone you | |
| 16:47:14 | artom | Doesn't have to be core | |
| 16:47:21 | gmann | I can volunteer for that | |
| 16:47:26 | artom | Like, I feel I have a good enough handle on it to give +1s | |
| 16:47:29 | artom | (Or -1s) | |
| 16:47:35 | mriedem | no it doesn't have to be a core, but it's good to be familiar with the actual API change and spec and all that | |
| 16:47:42 | artom | ... which I never did, so mea culpa, I guess | |
| 16:47:49 | mriedem | and the people that review API changes and specs are ... usually cores | |
| 16:48:14 | artom | Well, assuming the api-ref is correct and complete, that's good enough doc, no? | |
| 16:48:26 | mriedem | anyway, if the api side core review enforces good docs / api ref then anyone should be able to review the client side changes | |
| 16:48:31 | mriedem | jinx | |
| 16:48:41 | artom | And if you review the sdk change, look at the api-ref, and can't grok if it makes sense or not, it means we've failed at api-ref | |
| 16:48:54 | mriedem | lots of ifs | |
| 16:49:05 | artom | And butts | |
| 16:49:10 | artom | (Sorry) | |
| 16:49:12 | mriedem | candy and nuts | |
| 16:49:17 | gmann | mriedem: how you do, monitoring yourself or osc team add as reviewer etc ? | |
| 16:49:29 | gmann | you did | |
| 16:49:58 | mriedem | i'd have to find my old etherpad that was tracking the compute API microversion gaps in OSC | |
| 16:50:10 | mriedem | but that's usually how i'd track things, then once there was a review up i'd add myself as reviewer yeah | |
| 16:50:16 | mriedem | i also just started making the changes myself | |
| 16:50:21 | artom | https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps ? | |
| 16:50:23 | gmann | ohk, i know that etherpad. | |
| 16:50:25 | mriedem | then was made OSC core about a month before i left :) | |
| 16:50:52 | mriedem | artom: close: https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc | |
| 16:51:52 | mriedem | note the gap continues to widen, | |
| 16:52:00 | mriedem | and we're not tracking the last few new microversions in there | |
| 16:52:09 | artom | Yeah, that's what prompted by question | |
| 16:52:23 | artom | We're adding new mvs, but not requiring changes to sdk | |
| 16:52:34 | artom | It's a battle we can't win | |
| 16:52:46 | mriedem | just takes someone that cares and discipline | |
| 16:53:15 | artom | So better just give up then, right? | |
| 16:53:18 | mriedem | sure | |
| 17:00:30 | artom | sean-k-mooney, tbh I wasn't really planning on attending those - ML is fine with me | |
| 17:00:51 | artom | I can share the info, but don't feel like taking on planning tasks | |
| 17:01:58 | artom | That's TC's job, and I have no TC ambitions | |
| 17:02:43 | artom | (Or whatever other committee handles that) | |
| 17:03:19 | bauzas | artom: well, the problem is that lots of operators (including the ones that are getting a certain product from a big red company) are told to use OSC by the documentation | |
| 17:03:44 | bauzas | which is fine if you wanna have a stable and interoperable experience | |
| 17:03:48 | bauzas | (eg. with public clouds) | |
| 17:04:01 | sean-k-mooney | artom: well the indivugal teams normlaly work out the detailed timetable | |
| 17:04:04 | mriedem | osc isn't only good for that, | |
| 17:04:15 | mriedem | a unified CLI is important for new users to openstack, even if it's just your private cloud | |
| 17:04:17 | sean-k-mooney | so i dont expect the tc to do that just beasue it now virutal | |
| 17:04:25 | mriedem | needing to install and learn 10 different python-*client project CLIs sucks | |
| 17:04:57 | sean-k-mooney | yep i agreee with ^ | |
| 17:04:58 | mriedem | all with their own options and command structure | |
| 17:05:00 | bauzas | I'm just saying that a company that provides top-notch features to their customers and provide internal docs about using OSC should also care about making sure OSC is workable for those top-notch featureds | |
| 17:05:22 | artom | bauzas, yeah, that's an argument for centralizing on osc/sdk and eventually getting rid of novaclient altogether :) | |
| 17:05:27 | dansmith | mriedem: I agree with that in principle of course, but I don't know that I agree that osc is currently better | |
| 17:05:32 | artom | Which is what we're doing :) | |
| 17:05:34 | sean-k-mooney | which compay might that be ? :P and yes | |
| 17:05:41 | mriedem | dansmith: not until someone works to make it better | |
| 17:05:45 | mriedem | e.g. the bfv gaps | |
| 17:05:49 | mriedem | live migration sucking ass | |
| 17:05:52 | dansmith | yep, as long as that's in the mix | |
| 17:06:03 | bauzas | I personnally gave up with this. | |
| 17:06:06 | dansmith | mriedem: and all the version override hacks you have to do to do anything | |
| 17:06:19 | mriedem | yup the version discovery is way better in nova cli | |
| 17:06:26 | mriedem | s/way better/exists/ | |
| 17:07:05 | sean-k-mooney | mriedem: i do think that if you use an option that requries a min cli you should not have to specify it with osc like you do today | |
| 17:07:08 | dansmith | tbh I've seen less confusion from the different project clients than I have from people wondering how they're supposed to know when to use a given version to do something in nova | |
| 17:07:22 | mriedem | sean-k-mooney: that's shade or oaktree or whatever mordred had before | |
| 17:07:25 | sean-k-mooney | but im not sure the bevhior of nova cli always using latest is actully good | |
| 17:07:50 | mriedem | "the nova cli is not a bash sdk" | |
| 17:08:07 | dansmith | you can run fooclient --help and bumble the way through a thing, but you can't do that with osc help because you don't have the magic version decoder ring | |
| 17:08:31 | mriedem | the osc help should tell you what version is needed to do things, | |
| 17:08:41 | sean-k-mooney | dansmith: ya its both better and worse that it show you the help for the microversion you specify | |
| 17:08:41 | mriedem | but that's been a gap in people reviewing and enforcing those osc changes | |
| 17:08:56 | sean-k-mooney | if you dont know the microverion exits your screwed | |
| 17:09:24 | dansmith | mriedem: okay I've literally never seen that on a help, but maybe because the things I needed didn't have it | |
| 17:09:37 | mriedem | e.g. https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server-event.html#server-event-show | |
| 17:09:49 | mriedem | part of the gaps closure in that etherpad is just adding stuff like that to the help | |
| 17:09:54 | dansmith | mriedem: oh that's in the docs not in the --help? | |
| 17:09:58 | mriedem | same | |
| 17:10:03 | mriedem | docs are generated from the help | |
| 17:10:07 | mriedem | like osc-placement | |
| 17:10:32 | dansmith | okay well, I've never seen it in the help for things I was looking at, but okay | |
| 17:10:52 | mriedem | another example for 2.73 that tssurya added https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-lock | |