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
<[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".
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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
