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 ([email protected] <mailto:[email protected]>) 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 <[email protected] <mailto:[email protected]>> 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: [email protected]?subject:unsubscribe <http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
