[openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

Matt Riedemann mriedem at linux.vnet.ibm.com
Tue Apr 12 19:52:07 UTC 2016



On 4/6/2016 6:15 AM, Mikhail Fedosin wrote:
> 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.

If we're going to literally delete all of the 'if version == 1' paths in 
the nova code in a couple of releases from now, maybe this doesn't 
matter, it just seemed cleaner to me as a way to abstract the common 
parts and subclass the version-specific handling.

>
> 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 <mailto: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
> <mailto: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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list