On 3/5/20 12:11, Adam Harwell wrote:
> Well, part of maintaining feature parity is that the features should be
> added to the OSC by the project team at the time they're made -- you're
> already doing the work to add them to your own client, so instead, do
> the same amount of work but add them in OSC instead! It doesn't seem
> incredibly onerous to me. If the OSC plugin for your project IS the
> official client, then there's no duplication of effort. I think saying
> "someone else had better implement our features in a timely fashion" is
> a bit irresponsible. Though, this is coming from working on a project
> where we aren't used to being included as a "core piece" and having any
> work done for us, ever...

I think this is the key point regarding the lack of feature parity in
OSC for some projects.

If you are a new-enough project to have begun your CLI as an OSC plugin
(examples: ironic client, placement client, and more) then adding a
feature to the client is one shot. You add support in the plugin and
you're done.

If you are an older project (examples: nova client, glance client) then
you have a two-step process for adding a feature to OSC. For older
projects, OSC imports the legacy clients and calls their python bindings
to make the API calls. So for nova, if you want to add a feature to the
client, you have to add it to the legacy nova client. This is required.
Then, to add it to OSC you have to add it to OSC and have OSC call the
newly added legacy binding for the feature. This is [technically]
optional. This is why parity is missing.

It pains me a bit to write it ^ because you may be thinking, "what's so
difficult about going the extra step to add a feature to OSC after
adding it to nova client?" I don't know. Maybe people are too stressed
and busy. If it's not "required", it gets deferred. Maybe people don't
feel familiar enough with OSC to add the feature there as well. There
could be a lot of different reasons.

So, not trying to make excuses here but just sharing my opinion on why
adding features to OSC is not so simple for some projects.

Cheers,
-melanie

> Also, things are also definitely moving in a better direction now with
> the probable addition of project team liasons as cores in SDK/OSC, which
> should alleviate a lot of the issues around "response time" on reviews,
> when you do put in the effort to add features yourself.
>
>      --Adam
>
> On Fri, Mar 6, 2020, 00:15 Erno Kuvaja <ekuvaja@redhat.com
> <mailto:ekuvaja@redhat.com>> wrote:
>
>     On Wed, Mar 4, 2020 at 1:19 AM Ghanshyam Mann
>     <gmann@ghanshyammann.com <mailto:gmann@ghanshyammann.com>> wrote:
>
>         ---- On Tue, 03 Mar 2020 13:00:35 -0600 Tim Bell
>         <tim.bell@cern.ch <mailto:tim.bell@cern.ch>> wrote ----
>           >
>           >
>           > On 3 Mar 2020, at 19:55, Tim Bell <tim.bell@cern.ch
>         <mailto:tim.bell@cern.ch>> wrote:
>           >
>           >
>           > On 3 Mar 2020, at 19:20, Albert Braden
>         <Albert.Braden@synopsys.com <mailto:Albert.Braden@synopsys.com>>
>         wrote:
>           > Sean, thank you for clarifying that.
>           >
>           > Was my understanding that the community decided to focus on
>         the unified client incorrect? Is the unified/individual client
>         debate still a matter of controversy? Is it possible that the
>         unified client will be deprecated in favor of individual clients
>         after more discussion? I haven’t looked at any of the individual
>         clients since 2018 (except for osc-placement which is kind of a
>         special case), because I thought they were all going away and
>         could be safely ignored until they did, and I haven’t included
>         any information about the individual clients in the
>         documentation that I write for our users, and if they ask I have
>         been telling them to not use the individual clients. Do I need
>         to start looking at individual clients again, and telling our
>         users to use them in some cases?
>           >
>           >
>           >
>           > I remember a forum discussion where a community goal was
>         proposed to focus on OSC rather than individual project CLIs (I
>         think Matt and I were proposers).  There were concerns on the
>         effort to do this and that it would potentially be multi-cycle.
>           > BTW, I found the etherpad from Berlin
>         (https://etherpad.openstack.org/p/BER-t-series-goals) and the
>         associated mailing list discussion at
>         http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.html
>
>         Yeah, we are in process of selecting the Victoria cycle
>         community-wide goal and this can be good candidate. I agree with
>         the idea/requirement of a multi-cycle goal.
>         Another option is to build a pop-up team for the Victoria cycle
>         to start burning down the keys issues/work. For both ways
>         (either goal or pop-up team), we need
>         some set of people to drive it. If anyone would like to
>         volunteer for this, we can start discussing the details.
>
>         [1]
>         http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866.html
>
>         -gmann
>
>     Yeah, lets propose this as community goal again as it worked so well
>     last time. |ಠ_ಠ|
>
>     I think your most help wanted list/pop-up team is much more
>     realistic approach. Lets see if there is enough interest to actually
>     make it happen. What comes to our previous experience with Glance
>     and moving to endorse osc, I think I'm not alone stating that we can
>     discuss this again after osc has kept feature parity (and I mean to
>     current release, not feature parity 2 years ago kind of thing) and
>     actively addressed raised issues at least for a couple of cycles.
>     Obviously if you/your users wants to use it meanwhile, that your
>     call. If we cannot get that level of commitment, how do we expect to
>     support this long term?
>
>     I'm not willing to put our users through that misery again as it
>     happened last time as long as I'm core in this project.
>
>     - jokke
>
>           >
>           > My experience in discussion with the CERN user community and
>         other OpenStack operators is that OSC is felt to be the right
>         solution for the end user facing parts of the cloud (admin
>         commands could be another discussion if necessary). Experienced
>         admin operators can remember that glance looks after images and
>         nova looks after instances. Our average user can get very
>         confused, especially given that OSC supports additional options
>         for authentication (such as Kerberos and Certificates along with
>         clouds.yaml) so users need to re-authenticate with a different
>         openrc to work on their project.
>           > While I understand there are limited resources all round, I
>         would prefer that we focus on adding new project functions to
>         OSC which will eventually lead to feature parity.
>           > Attracting ‘drive-by’ contributions from operations staff
>         for OSC work (it's more likely to be achieved if it makes the
>         operations work less e.g. save on special end user documentation
>         by contributing code).  This is demonstrated from the CERN team
>         contribution to the OSC  ‘coe' and ‘share' functionality along
>         with lots of random OSC updates as listed hat
>         https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient)
>
>           > BTW, I also would vote for =auto as the default.
>           > Tim
>           > We are on Rocky now but I expect that we will upgrade as
>         necessary to stay on supported versions.
>           >
>           > From: Sean McGinnis <sean.mcginnis@gmx.com
>         <mailto:sean.mcginnis@gmx.com>>
>           > Sent: Tuesday, March 3, 2020 9:50 AM
>           > To: openstack-discuss@lists.openstack.org
>         <mailto:openstack-discuss@lists.openstack.org>
>           > Subject: Re: OSC future (formerly [glance] Different
>         checksum between CLI and curl)
>           >
>           > On 3/3/20 11:28 AM, Albert Braden wrote:
>           > Am I understanding correctly that the Openstack community
>         decided to focus on the unified client, and to deprecate the
>         individual clients, and that the Glance team did not agree with
>         this decision, and that the Glance team is now having a pissing
>         match with the rest of the community, and is unilaterally
>         deciding to continue developing the Glance client and refusing
>         to work on the unified client, or is something different going
>         on? I would ask everyone involved to remember that we operators
>         are down here, and the yellow rain falling on our heads does not
>         smell very good.
>           > I definitely would not characterize it that way.
>           > With trying not to put too much personal bias into it,
>         here's what I would say the situation is:
>           > - Some part of the community has said OSC should be the only
>         CLI and that individual CLIs should go away
>           > - Glance is a very small team with very, very limited resources
>           > - The OSC team is a very small team with very, very limited
>         resources
>           > - CLI capabilities need to be exposed for Glance changes and
>         the easiest way to get them out for the is by updating the
>         Glance CLI
>           > - No one from the OSC team has been able to proactively help
>         to make sure these changes make it into the OSC client (see
>         bullet 3)
>           > - There exists a sizable functionality gap between
>         per-project CLIs and what OSC provides, and although a few
>         people have done a lot of great work to close that gap, there is
>         still a lot to be done and does not appear the gap will close at
>         any point in the near future based on the current trends
>           >
>           >
>           >
>           >
>           >
>