Open Stack

Hello! Thanks for bring this topic up.

First of all, as I mentioned before, the great work was done in Mitaka, so
Glance v2 adoption in Nova it is not a question of "if", and not even a
question of "when" (in Newton), but the question of "how".

There is a set of commits that make this trick:
1. Xen plugin
https://review.openstack.org/#/c/266933
Sean gave us several good suggestions how we can improve it. In short:

   - Make this only add new glance method calls *upload_vhd_glancev2 *
   *download_vhd_glancev2* which do the v2 work
   - Don't refactor existing code to do common code here, copy / paste /
   update instead. We want the final code to be optimized for v1 delete, not
   for v1 fixing (it was done in previous patchsets, but then I made the
   refactor to reduce the amount of code)

2. 'Show' image info
https://review.openstack.org/#/c/228578
Another 'schema-based' handler is added there. It transforms glance v2
image output to format adopted in nova.image.

We have to take in account that image properties in v1 are passed with http
headers which makes them case insensetive. In v2 image info is passed as
json document and 'MyProperty' and 'myproperty' are two different
properties. Thanks Brian Rosmaita who noticed it
http://lists.openstack.org/pipermail/openstack-dev/2016-February/087519.html

Also in v1 user can create custom properties like 'owner' or 'created_at'
and they are stored in special dictionary 'properties'. v2 images have flat
structure, which means that all custom properties are located on the same
level as base properties. It leads to the fact if v1 image has a custom
property that has name coincided with the name of base property, then this
property will be ignored in v2.

3. Listing of artifacts in v2 way
https://review.openstack.org/#/c/238309
There I added additional handlers that transforms v1 image filters in v2,
along with sorting parameters.

'download' and 'delete' patches are included in #238309 since they are
trivial

4. 'creating' and 'updating' images'
https://review.openstack.org/#/c/259097
<https://review.openstack.org/#/c/259097/18>
What were added there:

   - transformation to 2-stepped image creation (creation of instance in db
   + file uploading)
   - special handler for creation active images with size '0' without image
   data
   - the ability to set custom location for an image
   ('show_multiple_locations' option must be enabled in glance config for
   doing that)
   - special handler to remove custom properties from the image:
   purge_props flag in v1 vs. props_to_remove list in v2

What else has to be done:

   - Splitting in 2 patches is required: 'create' and 'update' to make it
   easier to review.
   - Matt suggested that it's better not to hardcode method logic for v1
   and v2 apis. But rather we should create a a common base class which is
   subclassed for v1/v2 specific callback (abstract) methods, and then we
   could have a factory that, given the version, provides the client impl
   we're going to deal with.

5. Also we have a bug: https://bugs.launchpad.net/nova/+bug/1539698
Thanks Samuel Matzek who found it. There is a fix
https://review.openstack.org/#/c/274203/ , but it has contradictory
opinions. If you can suggest a better solution, then I'll be happy :)


If you have any questions about how it was done feel free to send me emails
(mfedosin at mirantis.com) or ping me in IRC (mfedosin)

And finally I really want to thank you all for supporting this transition
to v2 - it's a big update for OpenStack and without community help it
cannot be done.

Best regards,
Mikhail Fedosin

<https://bugs.launchpad.net/nova/+bug/1539698>

On Wed, Apr 6, 2016 at 9:35 AM, Nikhil Komawar <nik.komawar at gmail.com>
wrote:

> Inline comment.
>
> On 4/1/16 10:16 AM, Sean Dague wrote:
> > On 04/01/2016 10:08 AM, Monty Taylor wrote:
> >> On 04/01/2016 08:45 AM, Sean Dague wrote:
> >>> The glance v2 work is currently blocked as there is no active spec,
> >>> would be great if someone from the glance team could get that rolling
> >>> again.
> >>>
> >>> I started digging back through the patches in detail to figure out if
> >>> there are some infrastructure bits we could get in early regardless.
> >>>
> >>> #1 - new methods for glance xenserver plugin
> >>>
> >>> Let's take a simplified approach on this patch -
> >>> https://review.openstack.org/#/c/266933 and only change the
> >>> xenapi/etc/xapi.d/plugins/ content in the following ways.
> >>>
> >>> - add upload/download_vhd_glance2 methods. Don't add an api parameter.
> >>> Add these methods mostly via copy/paste as we're optimizing for
> deleting
> >>> v1 not for fixing v1.
> >>>
> >>> That will put some infrastructure in place so we can just call the v2
> >>> actions based on decision from higher up the stack.
> >>>
> >>> #2 - move discover major version back to glanceclient -
> >>>
> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108
> >>>
> >>>
> >>> I don't understand why this was ever in nova. This really should be
> >>>
> >>> glanceclient.discover... something. It uses internal methods from
> >>> glanceclient and internal structures of the content returned.
> >> FWIW, I use:
> >>
> >> from glanceclient.common import utils as glance_utils
> >> endpoint, detected_version = glance_utils.strip_version(endpoint)
> >>
> >> To part of trying to figure this out as a consumer. Of course, that's
> >> partially because like most of the openstack clients, there is no
> >> exposed API for querying versions, since you have to tell the
> >> constructor what major version you want to construct.
> > You can do that because you are using service catalogue entries for
> > glance. We're not there yet (and the path to get there is... odd for a
> > bunch of reasons).
> >
> > The information that nova has is the config option api_servers -
> >
> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25
> >
> > Which are unversioned endpoints.
> >
>
> Yeah, using the glance endpoint behind LB would be a (b)sad idea. Also,
> I don't know if we want to un/recommend on using private vs. public
> glance installations. Would be great to get some feedback for other
> Glance discussions too.
>
> >>> Catching, if desired, should also be on the glanceclient side.
> >>> glanceclient.reset_version() could exist to clear any caching.
> >>>
> >>> #3 - Ideally we'd also have a
> >>>
> >>> client = glanceclient.AutoClient(endpoint, ... ) which basically does
> >>> glanceclient.discover and returns us the right client automatically.
> >>> client.version provides access to the version information if you need
> to
> >>> figure out what version of a client you have.
> >> You should just do:
> >>
> >> import os_client_config
> >>
> >> client = os_client_config.legacy_client('image') since all of that work
> >> is pretty much already done.
> >>
> >> If glanceclient grows the ability to be used without a priori knowledge
> >> of the version, I'll certainly start to use it  there.
> > That assumes credentials locally, right? Nova is building glance clients
> > with the context it received the request in as -
> >
> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85
> > - so this is happening as the same user as initiated the Nova API call.
> >
> > The on-behalf-of needs here make this a bit more complicated.
> >
> >       -Sean
> >
> >
> >
>
>
> --
>
> Thanks,
> Nikhil
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160406/5f9edaa8/attachment.html>