On 11/07/17 19:21 -0500, Monty Taylor wrote:
On 07/11/2017 06:47 AM, Flavio Percoco wrote:On 11/07/17 14:20 +0300, Mikhail Fedosin wrote:On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor <mord...@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".I think this is a deal breaker. The problem is - if glare doesn't provide a v2 compat layer, then a deployer is going to have to run glance AND glare at the same time and we'll have to make sure both glance and glare can write to the same backend. The reason is that with our major version bumps both versions co-exist for a period of time which allows consumers to gracefully start consuming the nicer and newer api while not being immediately broken when the old api isn't there. What we'd be looking at is: * a glare service that runs two endpoints - an /image endpoint and an /artifact endpoint - and that registers the /image endpoint with the catalog as the 'image' service_type and the /artifact endpoint with the catalog as the 'artifact' service_type followed by a deprecation period of the image endpoint from the bazillion things that use it and a migration to the artifact service. OR First - immediately bump the glare api version to 3.0. This is affect some glare users, but given the relative numbers of glance v. glare users, it may be the right choice. Run a single set of versioned endpoints - no /v1, /v2 has /image at the root and /v3 has /artifact at the root. Register that endpoint with the catalog as both artifact and image. That means service and version discovery will find the /v2 endpoint of the glare service if someone says "I want 'image' api 'v2'". It's already fair game for a cloud to run without v1 - so that's not a problem. (This, btw, is the reason glare has to bump its api to v3 - if it still had a v1 in its version discovery document, glance users would potentially find that but it would not be a v1 of the image API) In both cases, /v2/images needs to be the same as glance /v2/images. If both are running side-by-side, which is how we normally do major version bumps, then client tools and libraries can use the normal version discovery process to discover that the cloud has the new /v3 version of the api with service-type of 'image', and they can decide if they want to use it or not. Yes - this is going to provide a pile of suck for the glare team, because they're going to have to maintain an API mapping layer, and they're going to have to maintain it for a full glance v2 api deprecation period. Becaue glance v2 is in DefCore, that is longer than a normal deprecation period - but that's life.
Right! This is the extended version of what I tried to say. :D I'm not a huge fan of the Glare team having a Glance v2 API but I think it's our best option forward. FWIW, this WAS tried before but a bit different. Remeber the Glance v3 discussion? That Glance v3 was Glare living in the Glance's codebase. The main difference now is that it would be Glare providing Glance's v2 and Glare's v3 rather than Glance doing yet another major version change. I still think we should figure out how to migrate a Glance deployment to Glare (database, stores, etc) before the work on this API even starts. I would like to see a good plan forward for this. Ultimately, the thing I definitely don't want to see happening is any logic being hard-coded inside client libraries. Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
