Open Stack

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.

 > 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.

> The proposals for the re-factor of the library is also a worrysome topic
> in terms of the stability of the codebase.

You have a link for this? I'm not familiar with this proposal and would 
like to read the spec...

> The original use cases from my memory are:
> 1. Other projects consuming glance_store -- this has become less likely
> to be useful.

How has this become less likely to be useful?

> 2. another upload path for users for the convenience of tasks -- not
> preferable as we don't want to expose this library to users.

What do you mean by "convenience of tasks" above? Also, by "expose this 
library to users", you are referring to normal tenants as users, right? 
Not administrative or service users, yes?

> 3. ease of addition of newer drivers for the developers -- drivers are
> only being removed since.

I don't think this has anything to do with glance_store being a separate 
code repository.

> 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.

This is why I was hopeful that the Artifact Repository API would allow 
Glance to just focus on being an excellent repository for metadata, and 
get out of the business of transferring, transforming, uploading, or 
downloading image bits.

I'm a little disappointed that this does not seem to be the direction 
that the Glance team is moving, and would like to know a bit more about 
what the future direction of the Glance project is.

> Also, the authN/Z complexities and ACL restrictions on the back-end
> stores can be potential security loopholes with the library and Glance
> evolution separately.

Sure, I understand that concern, but I believe that if the glance_store 
library interface is seen as essentially a "privileged system library", 
and you prevent all tenant-facing usage of it (pretty easy to do), then 
we'll be fine.

> In order to move forward smoothly on this topic in Liberty, I hereby
> request input from all concerned developer parties. The decision to keep
> this as a separate library will remain in effect if we do not come to
> resolution within 2 weeks from now. However, if there aren't any
> significant use cases we may consider a port back of the same.

Honestly, I'm a little perplexed why this is even being brought up. 
Aren't there quite a few high priority items in the Glance roadmap that 
would take precedence over this kind of move?

Best,
-jay