Open Stack

On 07/08/15 14:02 +0000, Jesse Cook wrote:
>I largely agree with the points made in the messages by Nikhil and Erno. A
>few additional points.
>
>One of the biggest use cases that I heard for glance_store (true, false,
>or otherwise) was that Glance is a bottleneck and an unnecessary proxy to
>the stores and consumers should be able to interface with the stores
>directly. A few lessons learned from creating and subsequently killing
>Glance Bypass internally (bypass Glance to interface directly with the
>store i.e. Swift in our case):

True and false. I've heard several times that Glance is the bottleneck
but no, that was not the main reason for this library to be pulled
out. One reason, besides it allowing services talk to Glance's stores
directly was to allow for "fancier" things like CoW, etc. This can be
translated in "faster boot times" but again, that's a side effect of
some of the features that are being targeted.

>1. The proxy is not free, but it¹s not the bottleneck (assuming you have
>decent networking on your Glance API nodes)
>2. Maintaining the code to interface directly with the object store is
>expensive and reinvents what Glance already does killing the value of
>moving Glance out of Nova tree

Not really. Glance is more than a simple interface to a storage.
Glance is an image registry that happens to store images itself.
Honeslty, once we have a better API, the glance_store shouldn't
receive much changes other than bug fixes - that should not be
underestimated - and new stores(?).

>3. Loses the abstraction provided by Glance

I'm failing to see what abstraction we are loosing here. Mind
elaborating more? I read this as a one-line version of #2 but I assume
I'm just missing the point.

>4. Allows retrying uploads (this is being fixed in Glance in Liberty along
>with other reliability and performance improvements)

This would be handled by the service consuming glance_store. Sure,
Glance could do this for you but there's an extra cost there. Also,
lets not forget that using glance_store is *optional*.

>
>My current perception is that glance_store raises confidence issues
>outside the community with the Glance and causes confusion about what and
>how to consume the project. It¹s a leaky abstraction and leads to a path
>of maintaining multiple APIs and circular dependencies.

Ok, I'll need you to elaborate more on this as well. What confidence
issues does it raise? What confusion is it causing? It's been around
for 3 - or 4? - cycles already, it's been packaged, shipped and
installed. It's deprecated some stores and people are well aware of
what it does - at least I haven't head any complains on that side - so
I fail to see your point here, again.

Again, if you are refering to the the current API as the leaky
abstraction, I believe we all know how we can fix that.

>Glance should provide a single clean API that ensures data
>consistency, is performant, and has reliability guarantees.

This I agree with and I believe Glance does that - well without the
consistent, performant and reliable parts ;). Seriously, I don't think
glance_store takes the Glance team through a path that leads to worse
APIs. If anything, I really hope that it'll help us to focus more on
the Glance API.

There's a lot to improve and way more to do. I think glance_store is
the lease worrysome of our problems.

>
>One other thought: After seeing some of the discussion on IRC I want to
>remind people that the sunken cost fallacy can strongly influence one¹s
>position, so please think carefully about the use cases and value outside
>the cost already put into splitting it out.

It has not much to do with this, really. I mentioned that we had put
lots of efforts in pulling it out, true. But lets be honest, there's
more to it than past efforts and we should not focus on seeing the
current benefit but the future benefit.

Thanks for all the insights,
Flavio

>On 8/7/15, 3:56 AM, "Kuvaja, Erno" <kuvaja at hp.com> wrote:
>
>>Hi,
>>
>>Flagged Nova and Cinder into this discussion as they were the first
>>intended adopters iirc.
>>
>>I don't have big religious view about this topic. I wasn't huge fan of
>>the idea separating it in the first place and I'm not huge fan of keeping
>>it separate either.
>>
>>After couple of cycles we have so far witnessed only the downside of
>>glance_store being on it's own. We break even our own gate with our own
>>lib releases, we have one extra bug tracker to look after and even not
>>huge but it just increases the load on the release and stable teams as
>>well.
>>
>>In my understanding the interest within Nova to consume glance_store
>>directly has pretty much died off since we separated it, please do
>>correct me if I'm wrong.
>>I haven't heard anyone expressing any interest to consume glance_store
>>directly within Cinder either.
>>So far I have failed to see use-case for glance_store alone apart from
>>Glance API Server and the original intended use-cases/consumers have
>>either not expressed interest what so ever or directly expressed being
>>not interested.
>>
>>Do we have any reason what so ever keeping doing the extra work to keep
>>these two components separate? I'm more than happy to do so or at least
>>extend this discussion for a cycle if there is projects out there
>>planning to utilize it. I don't want to be in middle of separating it
>>again next cycle because someone wanted to consume and forked out the old
>>tree because we decided to kill it but I'm not keen to take the overhead
>>of it either without reason.
>>
>>- Erno
>>
>>> -----Original Message-----
>>> From: Nikhil Komawar [mailto:nik.komawar at gmail.com]
>>> Sent: Friday, August 07, 2015 6:21 AM
>>> To: openstack-dev at lists.openstack.org
>>> Subject: [openstack-dev] [Glance] glance_store and glance
>>>
>>> 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. 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.
>>> 2. another upload path for users for the convenience of tasks -- not
>>> preferable as we don't want to expose this library to users.
>>> 3. ease of addition of newer drivers for the developers -- drivers are
>>>only
>>> being removed since.
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Please find some corresponding discussion from the latest Glance weekly
>>> meeting:
>>> http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-08-06-
>>> 14.03.log.html#l-21
>>>
>>> --
>>>
>>> Thanks,
>>> Nikhil
>>>
>>>
>>> __________________________________________________________
>>> ________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-
>>> request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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