Open Stack

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
>>><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".
>
>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
-------------- 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/20170712/f9d9d94e/attachment.sig>