Open Stack

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
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200303/1d6e1d06/attachment-0001.html>