<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, 6 Mar 2020, 00:03 melanie witt, <<a href="mailto:melwittt@gmail.com">melwittt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3/5/20 12:11, Adam Harwell wrote:<br>
> Well, part of maintaining feature parity is that the features should be <br>
> added to the OSC by the project team at the time they're made -- you're <br>
> already doing the work to add them to your own client, so instead, do <br>
> the same amount of work but add them in OSC instead! It doesn't seem <br>
> incredibly onerous to me. If the OSC plugin for your project IS the <br>
> official client, then there's no duplication of effort. I think saying <br>
> "someone else had better implement our features in a timely fashion" is <br>
> a bit irresponsible. Though, this is coming from working on a project <br>
> where we aren't used to being included as a "core piece" and having any <br>
> work done for us, ever...<br>
<br>
I think this is the key point regarding the lack of feature parity in <br>
OSC for some projects.<br>
<br>
If you are a new-enough project to have begun your CLI as an OSC plugin <br>
(examples: ironic client, placement client, and more) then adding a <br>
feature to the client is one shot. You add support in the plugin and <br>
you're done.<br>
<br>
If you are an older project (examples: nova client, glance client) then <br>
you have a two-step process for adding a feature to OSC. For older <br>
projects, OSC imports the legacy clients and calls their python bindings <br>
to make the API calls. So for nova, if you want to add a feature to the <br>
client, you have to add it to the legacy nova client. This is required. <br>
Then, to add it to OSC you have to add it to OSC and have OSC call the <br>
newly added legacy binding for the feature. This is [technically] <br>
optional. This is why parity is missing.<br></blockquote></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Hopefully in some days for glance this will not be necessary anymore, since there is a patch waiting to be merged, which switches OSC to SDK for Glance and removes glanceclient from dependencies. For neutron it is not required since long time.</div><div dir="auto"><br></div><div dir="auto">But still, what you say was real way to implement things, but it doesn't mean it is a correct or the easiest way. Instead if team once invests time to bring OSC Plugin, which bases on SDK in parity ... - the old client might be deprecated and you don't have this double efforts.</div><div dir="auto"><br></div><div dir="auto">The SDK/OSC team can not and should not try to catch all projects with their features each release - it is impossible (there are just 3 active cores in SDK now but hundreds of projects we might want to support). This team enables projects in a "unified technology stack" so that they become responsible for implementing all new features there.</div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It pains me a bit to write it ^ because you may be thinking, "what's so <br>
difficult about going the extra step to add a feature to OSC after <br>
adding it to nova client?" I don't know. Maybe people are too stressed <br>
and busy. If it's not "required", it gets deferred. Maybe people don't <br>
feel familiar enough with OSC to add the feature there as well. There <br>
could be a lot of different reasons.<br>
<br>
So, not trying to make excuses here but just sharing my opinion on why <br>
adding features to OSC is not so simple for some projects.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">It's not if you prioritize things not correctly and chooses complex direction.</div><div dir="auto"><br></div><div dir="auto">I'm laughing so loud, that this "storm" started just out of one question "OSC works correct, but curl not, so what am I doing wrong". It just one more time convinces me in some form of radicalisation of some projects against bringing things in order.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Artem</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
-melanie<br>
<br>
> Also, things are also definitely moving in a better direction now with <br>
> the probable addition of project team liasons as cores in SDK/OSC, which <br>
> should alleviate a lot of the issues around "response time" on reviews, <br>
> when you do put in the effort to add features yourself.<br>
> <br>
> --Adam<br>
> <br>
> On Fri, Mar 6, 2020, 00:15 Erno Kuvaja <<a href="mailto:ekuvaja@redhat.com" target="_blank" rel="noreferrer">ekuvaja@redhat.com</a> <br>
> <mailto:<a href="mailto:ekuvaja@redhat.com" target="_blank" rel="noreferrer">ekuvaja@redhat.com</a>>> wrote:<br>
> <br>
> On Wed, Mar 4, 2020 at 1:19 AM Ghanshyam Mann<br>
> <<a href="mailto:gmann@ghanshyammann.com" target="_blank" rel="noreferrer">gmann@ghanshyammann.com</a> <mailto:<a href="mailto:gmann@ghanshyammann.com" target="_blank" rel="noreferrer">gmann@ghanshyammann.com</a>>> wrote:<br>
> <br>
> ---- On Tue, 03 Mar 2020 13:00:35 -0600 Tim Bell<br>
> <<a href="mailto:tim.bell@cern.ch" target="_blank" rel="noreferrer">tim.bell@cern.ch</a> <mailto:<a href="mailto:tim.bell@cern.ch" target="_blank" rel="noreferrer">tim.bell@cern.ch</a>>> wrote ----<br>
> ><br>
> ><br>
> > On 3 Mar 2020, at 19:55, Tim Bell <<a href="mailto:tim.bell@cern.ch" target="_blank" rel="noreferrer">tim.bell@cern.ch</a><br>
> <mailto:<a href="mailto:tim.bell@cern.ch" target="_blank" rel="noreferrer">tim.bell@cern.ch</a>>> wrote:<br>
> ><br>
> ><br>
> > On 3 Mar 2020, at 19:20, Albert Braden<br>
> <<a href="mailto:Albert.Braden@synopsys.com" target="_blank" rel="noreferrer">Albert.Braden@synopsys.com</a> <mailto:<a href="mailto:Albert.Braden@synopsys.com" target="_blank" rel="noreferrer">Albert.Braden@synopsys.com</a>>><br>
> wrote:<br>
> > Sean, thank you for clarifying that.<br>
> ><br>
> > Was my understanding that the community decided to focus on<br>
> the unified client incorrect? Is the unified/individual client<br>
> debate still a matter of controversy? Is it possible that the<br>
> unified client will be deprecated in favor of individual clients<br>
> after more discussion? I haven’t looked at any of the individual<br>
> clients since 2018 (except for osc-placement which is kind of a<br>
> special case), because I thought they were all going away and<br>
> could be safely ignored until they did, and I haven’t included<br>
> any information about the individual clients in the<br>
> documentation that I write for our users, and if they ask I have<br>
> been telling them to not use the individual clients. Do I need<br>
> to start looking at individual clients again, and telling our<br>
> users to use them in some cases?<br>
> ><br>
> ><br>
> ><br>
> > I remember a forum discussion where a community goal was<br>
> proposed to focus on OSC rather than individual project CLIs (I<br>
> think Matt and I were proposers). There were concerns on the<br>
> effort to do this and that it would potentially be multi-cycle.<br>
> > BTW, I found the etherpad from Berlin<br>
> (<a href="https://etherpad.openstack.org/p/BER-t-series-goals" rel="noreferrer noreferrer" target="_blank">https://etherpad.openstack.org/p/BER-t-series-goals</a>) and the<br>
> associated mailing list discussion at<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.html" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.html</a><br>
> <br>
> Yeah, we are in process of selecting the Victoria cycle<br>
> community-wide goal and this can be good candidate. I agree with<br>
> the idea/requirement of a multi-cycle goal.<br>
> Another option is to build a pop-up team for the Victoria cycle<br>
> to start burning down the keys issues/work. For both ways<br>
> (either goal or pop-up team), we need<br>
> some set of people to drive it. If anyone would like to<br>
> volunteer for this, we can start discussing the details.<br>
> <br>
> [1]<br>
> <a href="http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866.html" rel="noreferrer noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866.html</a><br>
> <br>
> -gmann<br>
> <br>
> Yeah, lets propose this as community goal again as it worked so well<br>
> last time. |ಠ_ಠ|<br>
> <br>
> I think your most help wanted list/pop-up team is much more<br>
> realistic approach. Lets see if there is enough interest to actually<br>
> make it happen. What comes to our previous experience with Glance<br>
> and moving to endorse osc, I think I'm not alone stating that we can<br>
> discuss this again after osc has kept feature parity (and I mean to<br>
> current release, not feature parity 2 years ago kind of thing) and<br>
> actively addressed raised issues at least for a couple of cycles.<br>
> Obviously if you/your users wants to use it meanwhile, that your<br>
> call. If we cannot get that level of commitment, how do we expect to<br>
> support this long term?<br>
> <br>
> I'm not willing to put our users through that misery again as it<br>
> happened last time as long as I'm core in this project.<br>
> <br>
> - jokke<br>
> <br>
> ><br>
> > My experience in discussion with the CERN user community and<br>
> other OpenStack operators is that OSC is felt to be the right<br>
> solution for the end user facing parts of the cloud (admin<br>
> commands could be another discussion if necessary). Experienced<br>
> admin operators can remember that glance looks after images and<br>
> nova looks after instances. Our average user can get very<br>
> confused, especially given that OSC supports additional options<br>
> for authentication (such as Kerberos and Certificates along with<br>
> clouds.yaml) so users need to re-authenticate with a different<br>
> openrc to work on their project.<br>
> > While I understand there are limited resources all round, I<br>
> would prefer that we focus on adding new project functions to<br>
> OSC which will eventually lead to feature parity.<br>
> > Attracting ‘drive-by’ contributions from operations staff<br>
> for OSC work (it's more likely to be achieved if it makes the<br>
> operations work less e.g. save on special end user documentation<br>
> by contributing code). This is demonstrated from the CERN team<br>
> contribution to the OSC ‘coe' and ‘share' functionality along<br>
> with lots of random OSC updates as listed hat<br>
> <a href="https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient" rel="noreferrer noreferrer" target="_blank">https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient</a>)<br>
> <br>
> > BTW, I also would vote for =auto as the default.<br>
> > Tim<br>
> > We are on Rocky now but I expect that we will upgrade as<br>
> necessary to stay on supported versions.<br>
> ><br>
> > From: Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" target="_blank" rel="noreferrer">sean.mcginnis@gmx.com</a><br>
> <mailto:<a href="mailto:sean.mcginnis@gmx.com" target="_blank" rel="noreferrer">sean.mcginnis@gmx.com</a>>><br>
> > Sent: Tuesday, March 3, 2020 9:50 AM<br>
> > To: <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank" rel="noreferrer">openstack-discuss@lists.openstack.org</a><br>
> <mailto:<a href="mailto:openstack-discuss@lists.openstack.org" target="_blank" rel="noreferrer">openstack-discuss@lists.openstack.org</a>><br>
> > Subject: Re: OSC future (formerly [glance] Different<br>
> checksum between CLI and curl)<br>
> ><br>
> > On 3/3/20 11:28 AM, Albert Braden wrote:<br>
> > Am I understanding correctly that the Openstack community<br>
> decided to focus on the unified client, and to deprecate the<br>
> individual clients, and that the Glance team did not agree with<br>
> this decision, and that the Glance team is now having a pissing<br>
> match with the rest of the community, and is unilaterally<br>
> deciding to continue developing the Glance client and refusing<br>
> to work on the unified client, or is something different going<br>
> on? I would ask everyone involved to remember that we operators<br>
> are down here, and the yellow rain falling on our heads does not<br>
> smell very good.<br>
> > I definitely would not characterize it that way.<br>
> > With trying not to put too much personal bias into it,<br>
> here's what I would say the situation is:<br>
> > - Some part of the community has said OSC should be the only<br>
> CLI and that individual CLIs should go away<br>
> > - Glance is a very small team with very, very limited resources<br>
> > - The OSC team is a very small team with very, very limited<br>
> resources<br>
> > - CLI capabilities need to be exposed for Glance changes and<br>
> the easiest way to get them out for the is by updating the<br>
> Glance CLI<br>
> > - No one from the OSC team has been able to proactively help<br>
> to make sure these changes make it into the OSC client (see<br>
> bullet 3)<br>
> > - There exists a sizable functionality gap between<br>
> per-project CLIs and what OSC provides, and although a few<br>
> people have done a lot of great work to close that gap, there is<br>
> still a lot to be done and does not appear the gap will close at<br>
> any point in the near future based on the current trends<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> <br>
<br>
<br>
</blockquote></div></div>