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