Open Stack

On 07/08/15 01:21 -0400, 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.

I replied to a different email in this thread but I'd like to reply to
the original one to make sure my take on this is clear.

>
>The questions outstanding are: what are the use cases that want it as a
>separate library?

As mentioned in the meeting you linked in your email, I'm against
merging glance_store back into Glance. A few reasons below.

>The original use cases that supported a separate lib have not had much
>progress or adoption yet. There have been complaints about overhead of
>maintaining it as a separate lib and version tracking without much gain.
>The proposals for the re-factor of the library is also a worrysome topic
>in terms of the stability of the codebase.
>
>The original use cases from my memory are:
>1. Other projects consuming glance_store -- this has become less likely
>to be useful.

As mentioned by Jay/Mike and as I also mentioned in the meeting, this
is not true. Actually, based on the meeting logs, I believe this
statement is being made on the assumption that other proposals - like
the seam library Jessee proposed[0] - will be acceted. We can't make
plans based on things that haven't happend yet and that clearly have
different, strong, opinions.

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

If by users you mean people using glanceclient then I think this
statement is not valid either. The reason is that we've discussed this
in the past and we've clearly said that these is a library that is to
be consumed by services - especially with the current API - rather
than by end-users.

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

Which is a good thing. We've removed drivers that are not maintained
anymore, which will give us more time and bandwidth to dedicate to
hypothetical new drivers. The ease of addition exists, the fact that
there are no new drivers is not a real problem.

Also, these drivers don't need to live in glance_store, that's one of
the points of having stevedore in place to handle these plugins for
us.

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

We can work on a less agressive re-factor if needed. The problem with
the current proposed re-factor is not the re-factor itself but the
lack of attention from the community.

If we want the library's API to be cleaned up, we need to get to it. I
proposed the first version of that spec that Cindy took over later on.
The spec hasn't been changed much because there has not been enough
feedback other than "show me the code".

Admitedly, the re-factored code hasn't been shown entirely but lets be
honest with ourselves, if the proposal is the issue, the code won't
fix it. Lets work on a smoother refactor and get this over with. (Note
that the proposal says clearly that it'll add a new API but it'll keep
the older to give enough time for services to migrate).[1]

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

Fair enough. However, this is not new and it has been fixed elsewhere,
I believe. I also think we should have a better public API to be able
to provide better ACL guarantees.

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

In case it wasn't clear, I'm against merging this back into Glance and
it has nothing to do with the Sunk Cost Fallacy[2] as Jesse mentioned
in one of his emails. There are no just past efforts on this library.
There are on-going efforts to make it lighter and hopefully better,
there are efforts on having services consuming it.

One last note. I don't believe the benefits of this library should be
messured just on how many projects are using it or whether we have a
maintenance cost or not - which I don't think we really have.

For instance, the library gives us a better code structure, it allows
for other services to consume it and talk to external stores that are
not managed by Glance - why not?. In addition to this, it will help us
building a better abstraction for the library and hopefully a more
secure interaction between the Glance's API and the store, which we
didn't have because the code was in Glance's code base. This doesn't
mean a proper abstraction shouldn't have been built, though.

Anyway, no, please, lets not merge it back.
Flavio


[0] https://review.openstack.org/#/c/194303/
[1] https://review.openstack.org/#/c/188050/
[2] https://en.wikipedia.org/wiki/Sunk_costs

-- 
@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/b9f99ea2/attachment.pgp>