On 09/25/15 at 09:59am, Doug Hellmann wrote:
Excerpts from Mark Voelker's message of 2015-09-25 01:20:04 +0000:
>
> On Sep 24, 2015, at 5:55 PM, Sabari Murugesan <sabari.b...@gmail.com> wrote:
>
> Hi Melanie
>
> In general, images created by glance v1 API should be accessible using v2 and
> vice-versa. We fixed some bugs [1] [2] [3] where metadata associated with an
image was
> causing incompatibility. These fixes were back-ported to stable/kilo.
>
> Thanks
> Sabari
>
> [1] - https://bugs.launchpad.net/glance/+bug/1447215
> [2] - https://bugs.launchpad.net/bugs/1419823
> [3] - https://bugs.launchpad.net/python-glanceclient/+bug/1447193
>
>
> On Thu, Sep 24, 2015 at 2:17 PM, melanie witt <melwi...@gmail.com> wrote:
> Hi All,
>
> I have been looking and haven't yet located documentation about how to
upgrade from glance v1 to glance v2.
>
> From what I understand, images and snapshots created with v1 can't be
listed/accessed through the v2 api. Are there instructions about how to migrate
images and snapshots from v1 to v2? Are there other incompatibilities between v1
and v2?
>
> I'm asking because I have read that glance v1 isn't defcore compliant and so
we need all projects to move to v2, but the incompatibility from v1 to v2 is
preventing that in nova. Is there anything else preventing v2 adoption? Could we
move to glance v2 if there's a migration path from v1 to v2 that operators can run
through before upgrading to a version that uses v2 as the default?
Just to clarify the DefCore situation a bit here:
The DefCore Committee is considering adding some Glance v2
capabilities [1] as “advisory” (e.g. not required now but might be
in the future unless folks provide feedback as to why it shouldn’t
be) in it’s next Guideline, which is due to go the Board of Directors
in January and will cover Juno, Kilo, and Liberty [2]. The Nova image
API’s are already required [3][4]. As discussion began about which
Glance capabilities to include and whether or not to keep the Nova
image API’s as required, it was pointed out that the many ways images
can currently be created in OpenStack is problematic from an
interoperability point of view in that some clouds use one and some use
others. To be included in a DefCore Guideline, capabilities are scored
against twelve Criteria [5], and need to achieve a certain total to be
included. Having a bunch of different ways to deal with images
actually hurts the chances of any one of them meeting the bar because
it makes it less likely that they’ll achieve several criteria. For
example:
One of the criteria is “widely deployed” [6]. In the case of images, both the
Nova image-create API and Glance v2 are both pretty widely deployed [7]; Glance
v1 isn’t, and at least one uses none of those but instead uses the import task
API.
Another criteria is “atomic” [8] which basically means the capability is unique
and can’t be built out of other required capabilities. Since the Nova
image-create API is already required and effectively does the same thing as
glance v1 and v2’s image create API’s, the latter lose points.
This seems backwards. The Nova API doesn't "do the same thing" as
the Glance API, it is a *proxy* for the Glance API. We should not
be requiring proxy APIs for interop. DefCore should only be using
tests that talk directly to the service that owns the feature being
tested.
I completely agree with this. I will admit to having some confusion as
to why Glance capabilities have been tested through Nova and I know
others have raised this same thought within the process.
Doug
Another criteria is “future direction” [9]. Glance v1 gets no points here
since v2 is the current API, has been for a while, and there’s even been some
work on v3 already.
There are also criteria for “used by clients” [11]. Unfortunately both Glance
v1 and v2 fall down pretty hard here as it turns out that of all the client
libraries users reported in the last user survey, it appears the only one other
than the OpenStack clients supports Glance v2 and one supports Glance v1 while
the rest all rely on the Nova API's. Even within OpenStack we don’t
necessarily have good adoption since Nova still uses the v1 API to talk to
Glance and OpenStackClient didn’t support image creation with v2 until this
week’s 1.7.0 release. [13]
So, it’s a bit problematic that v1 is still being used even within the project
(though it did get slightly better this week). It’s highly unlikely at this
point that it makes any sense for DefCore to require OpenStack Powered products
to expose v1 to end users. Even if DefCore does end up requiring Glance v2 to
be exposed to end users, that doesn’t necessarily mean Nova couldn’t continue
to use v1: OpenStack Powered products wouldn’t be required to expose v1 to end
users, but if the nova image-create API remains required then they’d have to
expose it at least internally to the cloud. But….really? That’s still sort of
an ugly position to be in, because at the end of the day that’s still a lot
more moving parts than are really necessary and that’s not particularly good
for operators, end users, developers who want interoperable ways of doing
things, or pretty much anybody else.
So basically: yes, it would be *lovely* if we could all get behind fewer ways
of dealing with images. [10]
[1] https://review.openstack.org/#/c/213353/
[2] http://git.openstack.org/cgit/openstack/defcore/tree/2016.next.json#n8
[3] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json#n23
[4] http://git.openstack.org/cgit/openstack/defcore/tree/2015.05.json#n20
[5]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst
[6]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n40
[7]
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074540.html
[8]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n87
[9]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n60
[10] Meh, entirely too many footnotes here so why not put one out of order for
fun: https://www.youtube.com/watch?v=oHg5SJYRHA0
[11]
http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst#n48
[12] See comments in
https://review.openstack.org/#/c/213353/7/working_materials/scoring.txt
[13]
http://docs.openstack.org/developer/python-openstackclient/releases.html#sep-2015
At Your Service,
Mark T. Voelker
>
> Thanks,
> -melanie (irc: melwitt)
>
>
>
>
>
>
> __________________________________________________________________________
> 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
>
>
> __________________________________________________________________________
> 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
__________________________________________________________________________
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
__________________________________________________________________________
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
