Open Stack

Hi Artem,

Thanks for sharing the update.
The decision was collectively taken during last cycle by glance team, as we
don't have enough people/resources to work on this front.
I will be more than happy to change this if anyone comes forward and bridge
the gaps.

Thanks & Best Regards,

Abhishek Kekane


On Tue, Mar 3, 2020 at 11:40 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
>
>>
>> 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.
>
> 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.
>
>
>> 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/23e68ac2/attachment.html>