[openstack-dev] [Nova] FFE Request: Ephemeral RBD image support
xarses at gmail.com
Thu Mar 13 20:16:33 UTC 2014
I disagree with the new dependency graph here, I don't think its reasonable
continue to have the Ephemeral RBD patch behind both glance v2 support and
image-multiple-location. Given the time that this has been in flight, we
should not be holding up features that do exist for features that don't.
I think we should go back to the original work proposed by Josh in  and
clean it up to be resubmitted once we re-open for Juno. If some
re-factoring for RBD is needed when glance v2 or image-multiple-location
does land, we would be happy to assist.
On Thu, Mar 13, 2014 at 12:04 PM, Josh Durgin <josh.durgin at inktank.com>wrote:
> On 03/12/2014 04:54 PM, Matt Riedemann wrote:
>> On 3/12/2014 6:32 PM, Dan Smith wrote:
>>> I'm confused as to why we arrived at the decision to revert the commits
>>>> since Jay's patch was accepted. I'd like some details about this
>>>> decision, and what new steps we need to take to get this back in for
>>> Jay's fix resolved the immediate problem that was reported by the user.
>>> However, after realizing why the bug manifested itself and why it didn't
>>> occur during our testing, all of the core members involved recommended a
>>> revert as the least-risky course of action at this point. If it took
>>> almost no time for that change to break a user that wasn't even using
>>> the feature, we're fearful about what may crop up later.
>>> We talked with the patch author (zhiyan) in IRC for a while after making
>>> the decision to revert about what the path forward for Juno is. The
>>> tl;dr as I recall is:
>>> 1. Full Glance v2 API support merged
>>> 2. Tests in tempest and nova that exercise Glance v2, and the new
>>> 3. Push the feature patches back in
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>> Those are essentially the steps as I remember them too. Sean changed
>> the dependencies in the blueprints so the nova glance v2 blueprint is
>> the root dependency, then multiple images and then the other download
>> handler blueprints at the top. I haven't checked but the blueprints
>> should be marked as not complete (not sure what that would be now) and
>> marked for next, the v2 glance root blueprint should be marked as high
>> priority too so we get the proper focus when Juno opens up.
> These reverts are still confusing me. The use of glance's v2 api
> is very limited and easy to protect from errors.
> These patches use the v2 glance api for exactly one call - to get
> image locations. This has been available and used by other
> features in nova and cinder since 2012.
> Jay's patch fixed the one issue that was found, and added tests for
> several other cases. No other calls to glance v2 are used. The method
> Jay fixed is the only one that accesses the response from glanceclient.
> Furthermore, it's trivial to guard against more incompatibilities and
> fall back to downloading normally if any errors occur. This already
> happens if glance does not expose image locations.
> Can we consider adding this safety valve and un-reverting these patches?
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
If google has done it, Google did it right!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev