On 04/06/15 12:19 +0900, Joe Gordon wrote:
On Mon, Jun 1, 2015 at 6:11 AM, Flavio Percoco <fla...@redhat.com> wrote:
On 01/06/15 13:30 +0100, John Garbutt wrote:
On 1 June 2015 at 13:10, Flavio Percoco <fla...@redhat.com> wrote:
On 01/06/15 11:57 +0100, John Garbutt wrote:
On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
On 5/26/15 12:57 PM, Jesse Cook wrote:
We also had some hallway talk about putting the v1
and v2 APIs on top
of
the v3 API. This forces faster adoption, verifies
supportability via
v1
and
v2 tests, increases supportability of v1 and v2
APIs, and pushes out
the
need to kill v1 API.
Let's discuss more as time and development progresses
on that
possibility.
v3
API should stay EXPERIMENTAL for now as that would help
us understand
use-cases
across programs as it gets adopted by various
code-bases. Putting v1/v2
on
top
of v3 would be tricky for now as we may have breaking
changes with code
being
relatively-less stable due to narrow review domain.
I actually think we'd benefit more from having V2 on top of
V3 than
not doing it. I'd probably advocate to make this M material
rather
than L but I think it'd be good.
I think regardless of what we do, I'd like to kill v1 as it
has a
sharing model that is not secure.
Given v1 has lots of users, killing it will be hard.
If you maintained v1 support as v1 on top of v3 (or v2 I
guess), could
you not do something like permanently disable the "bad bits" of
the
API?
I agree it'll be hard but, at least for v1, I believe it should
happen. It has some security issues (mostly related to image
sharing)
that are not going to be fixed there.
OK, I guess you mean this one:
https://wiki.openstack.org/wiki/OSSN/1226078
The idea being, users listing their images, and updating image
metadata via v1, don't get broken during the evolution?
The feedback we got at the summit (even from OPs) was that we could
go
ahead, mark it as deprecated, give a deprecation period and then
turn
it off.
I am surprised by that reply, but OK.
FWIW, moving Nova from glance v1 to glance v2, without breaking
Nova's
public API, will require someone getting a big chunk of glance
v1 on
top of glance v2.
AFAIK, the biggest issue right now is "changed-since" which is
something Glance doesn't have in v2 but it's exposed throught
Nova's
image API.
Thats the big unanswered question that needs fixing in any spec we
would approve around this effort.
I don't have an answer myself right now.
I'm happy you brought this up. What are Nova's plans to adopt
Glance's
v2 ? I heard there was a discussion and something along the lines
of
creating a library that wraps both APIs came up.
We don't have anyone who has stepped up to work on it at his point.
I think the push you made around this effort in kilo is the latest
updated on this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/
remove-glanceclient-wrapper.html
It would be great if we could find a glance/nova CPL to drive this
effort.
So, unless the library is proposed and some magic happens, is it safe
to assume that the above spec is still valid and that folks can work
on it?
Where can I find more info about this?
I suspect it will be included on our liberty priority TODO list, that
I am yet to write, but I expect to appear here:
http://specs.openstack.org/openstack/nova-specs/
I really think nova should put some more effort on helping this
happen. The work I did[0] - all red now, I swear it wasn't - during
Kilo didn't get enough attention even before we decided to push it
back. Not a complain, really. However, I'd love to see some
cross-project efforts on making this happen.
[0] https://review.openstack.org/#/c/144875/
As there is no one to work on the effort, we haven't made it a
priority for liberty.
If someone is able to step up to help complete the work, I can do my
best to help get that effort reviewed, by raising its priority, just
as we did in Kilo.
IIRC, the patch wasn't far from being ready. The latest patch-sets
relied on the gate to run some tests and the biggest issue I had -
still have - is that this script[0] didn't even use glanceclient but
direct http calls. The issue, to be precises, is that I didn't have
ways to test it locally, which made the work painful.
If there's a way to do it - something that has already being asked -
it'd be great.
This said, I'm not sure how much time I'll have for this but I'm
trying to find someone that could help out.
https://review.openstack.org/#/c/144875/30/plugins/xenserver/xenapi/etc/
xapi.d/plugins/glance,cm
I suspect looking at how to slowly move towards v2, rather than going
for a "big bang" approach, will make this easier to land. That and
solving how we implement "changed-since", if thats not available in
the newer glance APIs. Honestly, part of me wonders about skipping v2,
and going straight to v3.
Regardless, I think we should enable people to run on a v2 only
deployment. Not a crazy thought, I think. We'll have to think this
through a bit more.
This sounds like a more pressing issue, talking about working on yet another
major API change (V3) before V1 is deprecated sounds premature to me. Otherwise
we end up in a situation where operators need to run all 3 glance APIs. Glance
V2 appears to have been finalized in Grizzly, and over 2 years later, it isn't
really used. So I am skeptical at the notion of working on yet another major
API overhaul before the V1 can finally be deprecated.
I'll just say that V2 not being widely used is mostly Glance team's fault. The details are long and not useful for this convo but I believe the team has learned from this experience. That said, I don't think we can just put v3 on hold but it won't be supported until this v1/v2 thing is cleared out (this means it'll be turned off by default). It'll take a couple of cycles to get this all done. Flavio -- @flaper87 Flavio Percoco
pgpUY9Q4QvBzF.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
