Open Stack

On 02/13/2017 07:47 AM, Ian Cordasco wrote:
> -----Original Message-----
> From: Clint Byrum <clint at fewbar.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Date: February 12, 2017 at 20:09:04
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [tc][glance][glare][all]
> glance/glare/artifacts/images at the PTG
> 
>> Excerpts from Brian Rosmaita's message of 2017-02-10 12:39:11 -0500:
>>> I want to give all interested parties a heads up that I have scheduled a
>>> session in the Macon room from 9:30-10:30 a.m. on Thursday morning
>>> (February 23).
>>>
>>> Here's what we need to discuss. This is from my perspective as Glance
>>> PTL, so it's going to be Glance-centric. This is a quick narrative
>>> description; please go to the session etherpad [0] to turn this into a
>>> specific set of discussion items.
>>>
>>> Glance is the OpenStack image cataloging and delivery service. A few
>>> cycles ago (Juno?), someone noticed that maybe Glance could be
>>> generalized so that instead of storing image metadata and image data,
>>> Glance could store arbitrary digital "stuff" along with metadata
>>> describing the "stuff". Some people (like me) thought that this was an
>>> obvious direction for Glance to take, but others (maybe wiser, cooler
>>> heads) thought that Glance needed to focus on image cataloging and
>>> delivery and make sure it did a good job at that. Anyway, the Glance
>>> mission statement was changed to include artifacts, but the Glance
>>> community never embraced them 100%, and in Newton, Glare split off as
>>> its own project (which made sense to me, there was too much unclarity in
>>> Glance about how Glare fit in, and we were holding back development, and
>>> besides we needed to focus on images), and the Glance mission statement
>>> was re-amended specifically to exclude artifacts and focus on images and
>>> metadata definitions.
>>>
>>> OK, so the current situation is:
>>> - Glance "does" image cataloging and delivery and metadefs, and that's
>>> all it does.
>>> - Glare is an artifacts service (cataloging and delivery) that can also
>>> handle images.
>>>
>>> You can see that there's quite a bit of overlap. I gave you the history
>>> earlier because we did try to work as a single project, but it did not
>>> work out.
>>>
>>> So, now we are in 2017. The OpenStack development situation has been
>>> fragile since the second half of 2016, with several big OpenStack
>>> sponsors pulling way back on the amount of development resources being
>>> contributed to the community. This has left Glare in the position where
>>> it cannot qualify as a Bit Tent project, even though there is interest
>>> in artifacts.
>>>
>>> Mike Fedosin, the PTL for Glare, has asked me about Glare becoming part
>>> of the Glance project again. I will be completely honest, I am inclined
>>> to say "no". I have enough problems just getting Glance stuff done (for
>>> example, image import missed Ocata). But in addition to doing what's
>>> right for Glance, I want to do what's right for OpenStack. And I look
>>> at the overlap and think ...
>>>
>>> Well, what I think is that I don't want to go through the Juno-Newton
>>> cycles of argument again. And we have to do what is right for our users.
>>>
>>> The point of this session is to discuss:
>>> - What does the Glance community see as the future of Glance?
>>> - What does the wider OpenStack community (TC) see as the future of Glance?
>>> - Maybe, more importantly, what does the wider community see as the
>>> obligations of Glance?
>>> - Does Glare fit into this vision?
>>> - What kind of community support is there for Glare?
>>>
>>> My reading of Glance history is that while some people were on board
>>> with artifacts as the future of Glance, there was not a sufficient
>>> critical mass of the Glance community that endorsed this direction and
>>> that's why things unravelled in Newton. I don't want to see that happen
>>> again. Further, I don't think the Glance community got the word out to
>>> the broader OpenStack community about the artifacts project, and we got
>>> a lot of pushback along the lines of "WTF? Glance needs to do images"
>>> variety. And probably rightly so -- Glance needs to do images. My
>>> point is that I don't want Glance to take Glare back unless it fits in
>>> with what the community sees as the appropriate direction for Glance.
>>> And I certainly don't want to take it back if the entire Glance
>>> community is not on board.
>>>
>>> Anyway, that's what we're going to discuss. I've booked one of the
>>> fishbowl rooms so we can get input from people beyond just the Glance
>>> and Glare projects.
>>>
>>
>> Does anybody else feel like this is deja vu of Neutron's inception?
>>
>> While I understand sometimes there are just incompatibilities in groups,
>> I think we should probably try again. Unfortunately, it sounds like
>> Glare already did the Neutron thing of starting from scratch and sort
>> of overlapping in functionality, instead of the Cinder thing where you
>> forklift the code from one project into a new one and pay close attention
>> to the peaceful transition of users. But we've been here before and we
>> can do better. :)
>>
>> Given that, I'm hoping some folks who helped with the Neutron transition
>> can attend this session and share what Neutron learned so that if Glare
>> does take over for images, we don't end up in a multi-cycle quagmire
>> where Glance is frozen and Glare is moving too fast for Glance devs to
>> transition.
>>
>> FWIW, I think a generic control plane service to catalog blobs of
>> useful data uploaded by users for other services is a good idea. I do
>> not think the end product should have a data plane component (we have
>> Swift for that).
> 
> So I 100% agree with you that these shouldn't have a data plane
> component. The only reason the Glare team might disagree with you is
> that they're talking about storing secrets (see also that thread I
> started about Barbican a little while back) for users. I would expect
> they would want some kind of control (assuming any of the Glare team
> knows how to safely and securely store such secrets at rest) over the
> storage backend for those.
> 
> Further, at the moment, both Glance and Glare use some rather
> inefficient ways of receiving and forwarding the blobs of data they
> receive. If we look at how other systems are architected (AWS for
> example) users have to upload those blobs to the data plane services
> first and then tell the other control plane services where to find
> them. This is why Rackspace's Images V2 is structured the way it is
> and Glance is working on the image-import specifications to make v2
> more interoperable.

Yah- whatever we do with the services as long as the thing moving
forward implements the image-import spec, we'll be good. That took WAY
too long with input from WAY too many people to have all of the corner
cases it covers not be covered. (Rackspace upload-to-swift case needs to
be supported, small cloud without swift needs to be covered, and users
need to not get screwed in the process - the spec is the result of a ton
of really good and really important conversations)

Which is my way of saying that I do not believe we can have these
services _not_ have a data plane component at this point - but we have a
design in flight that is as good a compromise as we're likely to get at
this point.

> That said, I'm convinced neither Glare nor Glance have learned the
> scaling issues from the current designs. At best, the last I looked,
> Glare has learned not to inherit Glance's caching design which has
> been frequently (and *rightfully*) criticized for the effect on
> network usage. Beyond that, Glare adds artificial constraints (which
> are subpar for their design) that I suspect will only frustrate people
> looking for a more generic artifact storage solution.
> 
> I'm certain, however, that none of this will be discussed at the PTG
> because these tend to be glossed over (and I won't be there to push on
> these pain points).

I'll be there, and will do my best to push on them in your absence.