[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