On 07/13/2017 08:42 AM, Erno Kuvaja wrote:
On Wed, Jul 12, 2017 at 1:21 AM, Monty Taylor <[email protected]> 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.
Just clarify something here. These plans are still not aligned with
current plans in Glance community. So we have no intention to
deprecate the Images API v2 nor stop supporting it. If Glare wants to
maintain functional par with Images API v2 and we get every single
deployment/project consuming Glance to move to Glare, then we can talk
again but the foreseeable future Glance is moving forward with the
Images API v2 maintained and supported (and developed forward within
our resources).
AH! Sorry for the confusion generated on my part- let me clarify.
What I'm talking about is the technical work that would be an absolute
requirement for us to CONSIDER the proposal to merge the efforts or
replace one with the other. By no means has such a decision been made.
What I'm talking about is that glance is the image service, and the
image services is one of the most fundamental parts of the stack.
Changing the codebase that provides it is not a decision that can be
taken lightly. There are MANY considerations. However - before any of
the other considerations can be looked at, the technical path must at
least be POSSIBLE.
(Like, I'm not going ot review your patch if it's still failing pep8
tests - I'm going to wait until it at least is working code, then we can
talk about the patch)
For a while this spring it looked like worst case scenario we need to
put glance to maintenance mode, freezing new development and drop the
project to just take care of bug fixes etc. The situation looks much
brighter at the moment when our call to arms was responded well and
we've seen people stepping in and making sure we stay afloat. For the
majority of the Glance team it has been, as long as I've been part of
it, very clear that Glance is one of the core projects and the utmost
priority is to provide stable and functional image service. Anything
outside of that is almost second class citizen based on the resources
and people we have and at least personally I will keep driving that
being the priority.
That's awesome news!
So please stop assuming Glance is shutting down just because Glare is
still around.
I'm not at all - and again I apologize for coming across as if I was
implying otherwise.
Back to the actual topic Glare becoming part of big tent. I thought
this was the case already and I'm totally supportive including Glare
there. The project has matured a lot from the times it was incubated
within Glace and I do see the value for artifact repository.
Yes. Me too. I'm digging in and responding to the glance/glare piece
because it was part of what was suggested as part of the message about
glare becoming official. It is not required in my mind for glare to
replace glance to become official. However, since that was suggested as
part of the rationale, it feels like we should take that suggestion
seriously and talk about what that actually means. If the intent is to
become official so that glare can replace glance and a long-term
co-existence would be a problem, I think we should know that up front
and judge accordingly.
It's also possible that this suggestion ISN'T fundamental to the
suggestion, in which case we can consider it to be orthogonal.
I'm also
super happy to hear that the project has gain some full time
developers to drive it forward after Mirantis stopped running it. Bit
cynically if those people want to spend their time trying to be Glance
instead of Glance, that's their call. Personally I won't be part of
those efforts and I think the Artifact Repository could do with some
love focusing on their core delivery rather than chasing up Glance.
That said as it's not my core focus, it''s also not my business to
tell them as community what they should do.
Good luck!
- Erno "jokke" Kuvaja
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"
I truly hope this is not what we're planning to do as community. Even
the few necessary changes moving from Images API v1 to Images API v2
showed how much pain it is. And that was well communicated and
documented for years ahead we even defaulted to v2.
Yah. As a human who deals with the consuming differences - lemme tell
you - holy hell it's painful. I also keep having to remind people that
it doesn't matter which version of the API the latest release of
OpenStack 'supports' - as a client consumer ALL of them must be
supported, because deployments update when deployments update. That
means adding a new major version is always ADDING not replacing.
Deprecating/removing is mostly useful as it relates to intra-openstack
services. When we remove glance v1 it means that Nova doesn't have to
deal with v1 + v2 - which is good, so doing that is valuable.
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
__________________________________________________________________________
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
