Open Stack

On 11/07/17 14:20 +0300, Mikhail Fedosin wrote:
>On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor <mordred at inaugust.com> wrote:
>
>> On 07/10/2017 04:31 PM, Mikhail Fedosin wrote:
>>> Third, all these changes can be hidden in Glare client. So if we try a
>>> little, we can achieve 100% compatibility there, and other projects can use
>>> Glare client instead of Glance's without even noticing the differences.
>>>
>>
>> I think we should definitely not do this... I think instead, if we decide
>> to go down this road, we want to look at adding an endpoint to glare that
>> speaks glance v2 API so that users can have a transition period while
>> libraries and tools get updated to understand the artifacts API.
>
>
>This is optional and depends on the project developers. For my part, I can
>only offer the most compatible client, so that the Glance module can be
>simply copied into the new Glare module.

Unfortunately, adding this sort of logic to the client is almost never the right
choice. To be completely honest, I'm not even convinced having a Glance-like API
in Glare is the right thing to do. As soon as that API hits the codebase, you'll
have to maintain it.

Anything that delays the transition to the new thing is providing a fake bridge
to the users. It's a bridge that will be blown-up eventually.

To make a hypothetical transition from Glance to Glare works smoothly, we should
first figure out how to migrate the database (assuming this has not been done
yet), how to migrate the images, etc. Only when these things have been figured
out, I'd start worrying about what compatibility layer we want to provide. The
answer could also be: "Hey, we're sorry but, the best thing you can do is to
migrate your code base as soon as possible".

>> If projects use Glance without client, it means that some direct API
>>> requests will need to be rewritten. But in any case, the number of
>>> differences between Glance v1 and Glance v2 was much larger, and we
>>> switched pretty smoothly. So I hope everything will be fine here, too.
>>>
>>
>> v1 vs v2 is still a major headache for end users. I don't think it's ok
>> for us to do that to our users again if we can help it.
>>
>> However, as you said, conceptually the calls are very similar so making an
>> API controller that can be registered in the catalog as "image" should be
>> fairly easy to do, no?
>>
>Indeed, the interfaces are almost identical. And all the differences were
>made on purpose.
>
>For example, deactivating an image in Glance looks like *POST*
>/v2/images/{image_id}/actions/deactivate with empty body.
>At one time, Chris Dent advised us to avoid such decisions, and simply
>change the status of the artifact to 'deactivated' using *PATCH*, which we
>did.

Despite this not being my preferred option, I definitely prefer it over the
"compatible" client library.

Flavio

--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170711/645e20ab/attachment.sig>