On 09/25/15 at 03:09pm, Mark Voelker wrote:
On Sep 25, 2015, at 10:42 AM, Andrew Laski <and...@lascii.com> wrote:
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.
Because it turns out that’s how most of the world is dealing with images.
Generally speaking, the nova image API and glance v2 API’s have roughly equal
adoption among public and private cloud products, but among the client SDK’s
people are using to interact with OpenStack the nova image API’s have much
better adoption (see notes in previous message for details). So we gave the
world lots of different ways to do the same thing and the world has strongly
adopted two of them (with reasonable evidence that the Nova image API is
actually the most-adopted of the lot). If you’re looking for the most
interoperable way to create an image across lots of different OpenStack clouds
today, it’s actually through Nova.
I understand that reasoning, but still am unsure on a few things.
The direction seems to be moving towards having a requirement that the
same functionality is offered in two places, Nova API and Glance V2 API.
That seems like it would fragment adoption rather than unify it.
Also after digging in on image-create I feel that there may be a mixup.
The image-create in Glance and image-create in Nova are two different
things. In Glance you create an image and send the disk image data in
the request, in Nova an image-create takes a snapshot of the instance
provided in the request. But it seems like DefCore is treating them as
equivalent unless I'm misunderstanding.
At Your Service,
Mark T. Voelker
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://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DoHg5SJYRHA0&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc&m=7GN2Z6neK-F2gi0ByCirYmqR6sCFjhWPEfaNmlQtUp4&s=y1hzWonwPHabYRZrdKG5X8PNnkHpQ2SNeOuLc489B1s&e=
[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
__________________________________________________________________________
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
