Open Stack

On 07/12/2017 02:02 AM, Flavio Percoco wrote:
> 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

\o/

> 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.

Yes. I wholeheartedly agree.

As I said to Erno, I don't think this is necessarily fundamentally a 
right or wrong thing right now - only that before we can truly consider 
whether it's a good or bad move otherwise, the technical story must 
actually exist. That involves the in-place backend migration working and 
frontend api compat.

There are pros and cons to both things.

If we could wind up with one larger team of aligned humans driving to 
success on a shared mission, that would potentially be awesome. If, on 
the other hand, we simply swap out glance with seven years of production 
experience for glare with more features and the benefit of having been 
able to potentially learn from areas glance hit but also lose the humans 
who worked on glance - that could be quite sad. On the third hand, while 
it's awesome that glance has more humans now, being in the situation we 
were in recently where it was hard to get folks to resource it is also a 
bad place to be.

There are many things that are worthy of discussion. Most of them are 
not possible to dig in to before technical alignment can be demonstrated.