Open Stack

Folks,

I think we should clarify the problem we are discussing.
The discussion started when the response to "there could be a bug in
OSC" was "we are not recommending OSC".
I don't feel like OSC lagging behind per-project-specific client in
terms of features is a bad thing considering the workload.
On the other hand, suddenly making OSC "not recommended" for a project
already supported by / supporting OSC is a <<bad thing>>. (TM)
I feel like there should be an official on how we are going to handle
the clients situation and just document it.

-yoctozepto

wt., 3 mar 2020 o 19:11 Erno Kuvaja <ekuvaja at redhat.com> napisał(a):
>
> On Tue, Mar 3, 2020 at 6:14 AM Artem Goncharov <artem.goncharov at gmail.com> wrote:
>>
>>
>>
>> On Tue, 3 Mar 2020, 06:08 Abhishek Kekane, <akekane at redhat.com> wrote:
>>>
>>> Hi All,
>>>
>>> Thank you for making this different thread,
>>>
>>> OSC is not up to date with the current glance features and neither it has shown any interest in doing so.
>>> From glance prospective we also didn't have any bandwidth to work on adding these support to OSC.
>>
>>
>>
>> That's honestly not true this days
>
>
> It's very much true that we do not have cycles for it. If you have found the time now after we've been complaining about the issues without any concrete actions for cycles, great for those who wants to use it.
>>>
>>>
>>> There is some major feature gap between current OSC and Glance and that's the reason why glance does not recommend to use OSC.
>>
>>
>> That's still not reason to say please don't use it anymore.
>
>
> But it very much is.
>
> Tells quite a bit about the communication within the community that this is the first time we hear you actively working on those bits and making progress. Yet the osc is still lacking good year+ behind the feature parity and if the _demand_ is to use osc, "I'm just one person and have only so much time for this" is not good enough. Don't get me wrong, kudos to you to actually taking it on, but too little too late I guess.
>
> If 95-100% of user issues with client gets resolved by "Have you tried to use the native glanceclient instead?" and the response is "Yes, it works, thanks." it very much tells that we should not be supporting and promoting the tooling that is not under our control and just does not work. (BTW we do encourage all those users to take their osc issues to the osc team to get fixed, yet we get these raised to us every so often.) This really got to the point where we had that very same discussion in multiple OpenStack summits in a row after the call was made that everything should move to osc and every time we got the same response "We know there are problems and we will look into it." After so many cycles and the gap growing not shrinking just got us to the point of moving forwards (or reverting back to something that actually works for our users). BTW we did announce this and it was discussed in PTG.
>>
>>
>>> 1. Support for new image import workflow
>>
>> Partially implemented by me and I continue working on that
>>
>>> 2. Support for hidden images
>>
>> Implemented
>>
>>> 3. Support for multihash
>>>
>>> 4. Support for multiple stores
>>
>>
>> I am relying on OSC and especially for image service trying to bring it in a more useful state, thus fixing huge parts in SDK.
>
>
> That's great and obviously you have the freedom to choose  the client you prefer to use. Just like we have a moral responsibility to our users to provide them reference client that is up to date, works and the issues raised gets attention.
>
> This is all beyond the personal preference, which I get very mixed feedback of depending to whom I talk to. If I send the mail to the mailing list I get those same handful of people yelling right away how unified client is the only way to go and even thinking anything else is heresy. When I talk with people in the field, customers and users in the hallway tracks the message is much more mixed. The osc target audience prefers or just uses GUI instead, then there is a good portion of people who really don't care as they use some automation suite anyways, there is the old school guys who prefers a tool for a job as in the dedicated clients(I have to admit for disclaimer I belong to this group myself) and then there is a group of people who really don't care as long as the client they use every now and then just works. So honestly outside of those few voices in this mailing list I very rarely hear the demand of unified client and much more get the request to provide something that works, which was the major driver for our decision.
>
> Harsh, absolutely; justified, I'd like to think so. And this is just my personal experience with Glance, we're in a blessed situation of not jumping into the microversions bandwagon which seems to be totally hidden can of worms from us in this topic.
>
> For all the rest of you interested about the topic, next time you start demanding us to go to osc again, please put your money where your mouth is first and help those guys to deliver.
>
> Best,
> Erno "jokke" Kuvaja
>
>>
>>>
>>> If anyone is interested to take up this work it will be great.
>>>
>>> Thanks & Best Regards,
>>>
>>> Abhishek Kekane
>>>
>>>
>>> On Tue, Mar 3, 2020 at 12:24 AM Sean Mooney <smooney at redhat.com> wrote:
>>>>
>>>> On Mon, 2020-03-02 at 18:05 +0000, Albert Braden wrote:
>>>> > As an openstack operator I was pretty ecstatic to hear that the assortment of clients would be replaced by a single
>>>> > client. I would be disappointed to find that a component would not integrate and would continue to use a separate
>>>> > client. This would be a step backward IMO.
>>>> >
>>>> > The discussion about microversions goes over my head, but I would hope to see the developers get together and solve
>>>> > the issue and continue working toward integration.
>>>> just to summerisie it in a non technical way.
>>>> the project specific cli had a convention where the client would ask the api what the newest micoverion it supported
>>>> and defualt to that if the clinet suported it. that meant that the same command executed against two different clouds
>>>> with different versions of openstakc deploy could have different behavior and different responces. so from an
>>>> interoperablity point of view that is not great but from a usablity point of view the fact enduser dont have to care
>>>> about microverions and the client would try to do the right thing made some things much simpler.
>>>>
>>>> the unifeid client (osc) chose to priorities interoperablity by defaulting to the oldest micorverions, so for nova that
>>>> would be 2.0/2.1 meaning that if you execute the same command on two different cloud with different version of nova it
>>>> will behave the same but if you want to use a feature intoduced in a later micorverion you have to explcitly request
>>>> that via --os-compute-api-version or set that as a env var or in you cloud.yaml
>>>>
>>>> so really the difference is that osc requires the end user to be explictl about what micoversion to use and therefor be
>>>> explict about the behavior of the api they expect (this is what we expect application that use the the api should do)
>>>> where as the project client tried to just work and use the latest microverion which mostly workd excpet where we remove
>>>> a feature in a later micorverions. for example we removed the force option on some move operation in nova because
>>>> allowing forcing caused many harder to fix issues. i dont thnk the nova clinet would cap at the latest micorvierion that
>>>> allowed forcing. so the poject client genreally did not guarantee that a command would work without specifcing a new
>>>> micorverison it just that we remove things a hell of a lot less often then we add them.
>>>>
>>>> so as an end user that is the main difference between using osc vs glance clinet other then the fact i belive there is a
>>>> bunch of stuff you can do with glance client that is missing in osc. parity is a spereate disucssion but it is vaild
>>>> concern.
>>>>
>>>> -----Original Message-----
>>>> > From: Radosław Piliszek <radoslaw.piliszek at gmail.com>
>>>> > Sent: Monday, March 2, 2020 9:07 AM
>>>> > To: openstack-discuss <openstack-discuss at lists.openstack.org>
>>>> > Subject: Re: [glance] Different checksum between CLI and curl
>>>> >
>>>> > Folks,
>>>> >
>>>> > sorry to interrupt but I think we have diverged a bit too much from the subject.
>>>> > Only last Gaetan message is on topic here.
>>>> > Please switch to new subject to discuss OSC future.
>>>> >
>>>> > -yoctozepto
>>>> >
>>>> > pon., 2 mar 2020 o 18:03 Tim Bell <tim.bell at cern.ch> napisał(a):
>>>> > >
>>>> > >
>>>> > >
>>>> > > On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>>>> > >
>>>> > > Hi,
>>>> > >
>>>> > > On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano at redhat.com> wrote:
>>>> > > >
>>>> > > > On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote:
>>>> > > > > On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane at redhat.com> wrote:
>>>> > > > > > Hi Gaëtan,
>>>> > > > > >
>>>> > > > > > Glance team doesn't recommend to use OSC anymore.
>>>> > > > > > I will recommend you to check the same behaviour using
>>>> > > > > > python-glanceclient.
>>>> > > > >
>>>> > > > > That's not cool - everyone has switched to OSC. It's also the first
>>>> > > > > time I've heard of it.
>>>> > > > >
>>>> > >
>>>> > > From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers.
>>>> > >
>>>> > > There has been great progress with Manila to get shares included (
>>>> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_-23_c_642222_26_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=gfnHFJM7fXXAlOxyUenF0xGqH3gNiec3LxN-Gd5Ey-o&s=SYi8yPy9Dz0CgrkT5P6rTzs3141Gj4K9zO4Ht3GTYAk&e=
>>>> > >  ) and it would be a pity if we’re asking our end users to understand all of the different project names and
>>>> > > inconsistent options/arguments/syntax.
>>>> > >
>>>> > > We had hoped for a project goal to get everyone aligned on OSC but there was not consensus on this, I’d still
>>>> > > encourage it to simplify the experience for OpenStack cloud consumers.
>>>> > >
>>>> > > Tim
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>>
>>>>