| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-02 | |||
| 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 | |
| 17:14:26 | sean-k-mooney | but we dont do that today in many cases we say to use option x you need to pass version y | |
| 17:15:18 | sean-k-mooney | i have noticed that lately with osc-placment when trying ot use some operation but im sure we have the same behviaor in the nova supprot in osc | |
| 17:15:22 | mordred | right - I think there's actually a third option which can be more aggressive about new things while not breaking people - but I need to write it up | |
| 17:16:04 | mordred | from my end-user pov - if I *ever* have to give osc a version for a reason other than "I am a developer debugging the rest api" something has completely failed | |
| 17:16:23 | dansmith | mordred: ++ | |
| 17:16:26 | mordred | which is not to say that this failure isn't happening consistently today :) | |
| 17:16:37 | mordred | but - it's a failure from an UX perspective and I want to fix it | |
| 17:16:51 | mordred | s/want/am going to/ | |
| 17:17:12 | mordred | I will know I'm successful when everyone here thinks it's behaving properly ;) | |
| 17:17:14 | dansmith | "if you've ever had to pass a version to OSC in the last six months, you get an ATC pass to the summit" | |
| 17:17:22 | mordred | dansmith: ++ | |
| 17:18:09 | sean-k-mooney | mordred: you will have to get the ironic folks on board too | |
| 17:18:36 | sean-k-mooney | mordred: sicne they went ahead and impleemnted the same version negoction logic in there plugin they had in the legacy client | |
| 17:19:10 | mordred | sean-k-mooney: yeah - I've already got good ironic support done by the ironic team in sdk though - so I think I'm closer with them | |
| 17:19:34 | sean-k-mooney | mordred: i think one thing to condiser is moveing everything after nova v2.0 out of osc and into a nova plugin | |
| 17:19:44 | mordred | I want to get rid of all plugins | |
| 17:20:02 | sean-k-mooney | mordred: well part of the issue currently is geting things landed in osc | |
| 17:20:17 | mordred | right. that's based on the past - we're making some massive changes | |
| 17:20:25 | sean-k-mooney | so project wich plugisn could make progress but "core" project had an issue | |
| 17:20:26 | mordred | so - gimme a little bit to let those changes percolate | |
| 17:20:52 | sean-k-mooney | sure im glad the sdk and ocs team are combined/combinging | |
| 17:31:45 | sean-k-mooney | mordred: honestly if we could deprecate the nova clinet and deliver changes as easily as we can today to osc for V that would be awsome but there are still a long list of gaps to close before that is realistic | |
| 17:33:02 | artom | sean-k-mooney, I don't think anyone disagrees - but to paraphrase mriedem, and directly quote Nike, "just do it" :) | |
| 17:37:39 | mordred | sean-k-mooney: I agree ... but I'm going to make a concerted push to see how many of those gaps I can close and how much I can ease the situation | |
| 17:38:37 | mordred | might not work, obviously- but otoh - getting novaclient parity and being able to deprecate it would be a _huge_ step forward in terms of gravity, so I think it's worth extra attention | |
| 17:39:35 | openstackgerrit | Merged openstack/nova master: Add test coverage of existing server diagnostics policies https://review.opendev.org/716800 | |
| 17:40:19 | sean-k-mooney | well i almost never need to use nova client for day to day things but it does happen. | |
| 17:40:31 | sean-k-mooney | i should really just chagne https://review.opendev.org/#/c/643578/ back to evacuate too | |
| 17:44:12 | sean-k-mooney | mordred: should i just abandon ^ by the way or if i rebase it and change the command back to evacuate will it get reviews | |