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
pgphdLsmpn5tH.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
