| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-02 | |||
| 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 | mriedem | but that's been a gap in people reviewing and enforcing those osc changes | |
| 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: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 | |
| 17:11:02 | mriedem | yeah it's a constant fight to make sure people remember to add those, | |
| 17:11:05 | mriedem | and get people to backfill them | |
| 17:11:08 | mriedem | hence the etherpad | |
| 17:11:33 | dansmith | in that one page, one says "use version X" and another says "use version X by passing --this-complicated-arg-thing" | |
| 17:11:49 | dansmith | but yeah, it would definitely be better if that was all consistent enough to rely on | |
| 17:12:09 | rambo_li | Excuse me, sean-k-mooney ralonsoh Please Let’s talk about the bug here: | |
| 17:12:09 | rambo_li | Excuse me, sean-k-mooney ralonsoh Please Let’s talk about the bug here: | |
| 17:12:09 | rambo_li | https://bugs.launchpad.net/neutron/+bug/1815989 And what is our plan to solve this bug? | |
| 17:12:11 | openstack | Launchpad bug 1815989 in OpenStack Compute (nova) "OVS drops RARP packets by QEMU upon live-migration causes up to 40s ping pause in Rocky" [Medium,In progress] - Assigned to sean mooney (sean-k-mooney) | |
| 17:12:13 | dansmith | I'm not helping so I know I can't complain too much, but in the current state of the world, I don't see osc as better | |
| 17:13:04 | mordred | mriedem: fwiw - I want to completely change what the version story is in osc - and I agree with sean-k-mooney - I do not think you should have to specify a min version on the cli | |
| 17:13:09 | sean-k-mooney | rambo_li: at the moment im not working on it, the patch i submited shoudl fix it but they dont work anymore due to rebases and refacoting | |
| 17:13:25 | mordred | it is that way for hysterical raisins and I think those raisins are no longer useful to us | |
| 17:14:04 | sean-k-mooney | mordred: if we default to oldest that support feature ex it keeps the stablity and if you want the new behavior you ask for it | |
| 17:14:07 | mordred | I am planning on writing something up so we can discuss it around PTG time to make sure it meets what people are wanting | |