Open Stack

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.

The other choice is to tell our users "we don't care about you AT ALL 
and just yanked one of the most fundamental pieces of the core IaaS APIs 
out from under you YOLO"

There is work here - but it's just work - none of it is impossible. 
What's important is to keep our eyes on the fact that there are a TON of 
people using the glance API and we CANNOT screw them. We have service 
discovery, we have version discovery - they are used by the things that 
consume openstack apis - we can use them for this.


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

Yay - I think it's a great thing to do in the glare api.

For a glance v2 api layer, we just need to have an API controller that 
receives /v2/images/{image_id}/actions/deactivate does the status. That 
should not be terribly hard to code - it can likely just translate the 
call internally and dispatch the patch controller with the right values set.

> Despite this not being my preferred option, I definitely prefer it over the
> "compatible" client library.
> 
> Flavio
> 
> -- 
> @flaper87
> Flavio Percoco
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>