Open Stack

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/53e34f4b/attachment-0001.html>