Open Stack

On 09/08/15 18:41 -0700, Mike Perez wrote:
>On 13:07 Aug 07, Jay Pipes wrote:
>> Hi Nik, some comments inline, but tl;dr I am strongly against
>> returning the glance_store library to the Glance source repository.
>> Explanations inline...
>>
>> On 08/07/2015 01:21 AM, Nikhil Komawar wrote:
>> >Hi,
>> >
>> >During the mid-cycle we had another proposal that wanted to put back the
>> >glance_store library back into the Glance repo and not leave it is as a
>> >separate repo/project.
>> >
>> >The questions outstanding are: what are the use cases that want it as a
>> >separate library?
>> >
>> >The original use cases that supported a separate lib have not had much
>> >progress or adoption yet.
>>
>> This is really only due to a lack of time to replace the current
>> nova/image/download/* stuff with calls to the glance_store library.
>> It's not that the use case has gone away; it's just a lack of time to
>> work on it.
>
>When Cinder wanted to integrate os-brick (initiator code library) into Nova,
>Cinder folks integrated it themselves [1]. Has anyone from Glance been spending
>the time to do this? If so, are there reviews you can give so we can see why
>things are blocked?

There have been sessions that I personally attended in Atlanta and
Paris. There was one in Vancouver that I didn't attend. These sessions
were to work on the future of the Nova->Glance interaction. The
conclusion of these discussions has always been that we should migrate
Nova to Glance V2 before allowing it to consume glance_store.

I'll stop here otherwise we'll get into the whys/whats of why this
hasn't happened yet.

>
>> > There have been complaints about overhead of
>> >maintaining it as a separate lib and version tracking without much gain.
>>
>> I don't really see much overhead in maintaining a separate lib,
>> especially when it represents functionality that can be used by
>> Cinder and Nova directly.
>
>As mentioned earlier Cinder is doing os-brick for both Cinder and Nova to
>consume. Other projects are planning to use it as well, and it has been a huge
>win to take some complications from other projects that aren't focusing on
>block storage like we are. I recommend creating a gerrit dashboard [2] to
>include a separate library with Glance reviews. I'm also not sure of what
>overhead there could be besides having do release.
>
><snip>
>
>> >4. cleaner api / more methods that support backend store capabilities -
>> >a separate library is not necessarily needed, smoother re-factor is
>> >possible within Glance codebase.
>>
>> So, here's the crux of the issue. Nova and Cinder **do not want to
>> speak the Glance REST API** to either upload or download image bits
>> from storage. Streaming image bits through the Glance API endpoint is
>> a needless and inefficient step, and Nova and Cinder would like to
>> communicate directly with the backend storage systems.
>>
>> glance_store IS the library that would enable Nova and Cinder to
>> communicate directly with the backend storage systems. The Glance API
>> will only be used by Nova and Cinder to get information *about* the
>> images in backend storage, not the image bits themselves.
>
>+1
>
>Provide a way to talk to the implementation, and step out of the way to let it
>do what it does best. This is no different than other Openstack projects.
>
>In Cinder, image copying to a volume is a huge problem today. We have a Cinder
>glance_store [2] that is being revived to leave the images stored in the block
>storage backends themselves, which, oh my goodness is using os-brick!!
>
>The block storage backends know how to do efficient image copying/cloning to
>their volumes, not Glance.
>

Jay/Mike

Thanks for the feedback on the validity of the use cases. That was the
goal of this thread and I'm glad you both stepped up.

Flavio


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150810/8a94c590/attachment.pgp>