On 11/07/17 14:20 +0300, Mikhail Fedosin wrote:
On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor <[email protected]> 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 APIrequests 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
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
