Open Stack

Hello!


Let me quickly describe my vision of the problem. I asked this question to
Brian last Friday, because it is evident that the projects have the
intersection in functionality. For this reason, I proposed to bring Glare
back and develop it as a new generation of Glance service. Perhaps such a
solution would be more correct from my point of view.

Moving away from Glance, let me remind you why we created Glare service.

Almost every project works with some binary data and must store it
somewhere, and almost always storage itself is not the part of the
project's mission. This issue has often been neglected. For this reason
there is no single recommended method for storing of binary data, which
would have a unified public api and hide all the things of the internal
storage infrastructure.

These questions were answered by Glare. First of all, the service allows to
use different storages for various types of artifacts - an operator can
assign the storage of large files, such as virtual machine images, to
Swift, and for relatively small ones, such as Heat templates, use a mysql
database.

Then, we have to admit that data tends to change, so we added a versioning
of artifacts and dependencies between them, that the user was convenient to
take the data of required version.

Often a "binary data" refers to more than one specific object, but a whole
lot of files. Therefore, we have implemented the ability to create
arbitrary nested folders per one artifact and store multiple files there.
And for sure users can receive any file with a single API request.

For validation and conversion of uploaded data Glare introduces the concept
of hooks for the operation. Thus the operator can extend the basic
functionality of the system and add integration with third-party systems
for each artifact type. For example, for Nokia we implemented integration
with custom TOSCA validator.

This is just a small overview of the key features of the service. For sure,
at the moment Glare is able to do all that Glance can do (except maybe a
sharing of artifacts), on the other hand we have added a number of new
features, that were requested by cloud operators for a long time.

Fyi, now we in Nokia are preparing additional API, which corresponds to the
ETSI VNF Packaging Specification [1]. So support of Image v2 API is not an
impossible task, and we may implement it as an alternative way of
interaction with "Images" artifact type. In this case Nova and other
services using Glance are absolutely indifferent to what service provides
Image API.

All tasks related to documentation and packaging are solvable. We’re
working on them together with Nokia, so I can assure you that the documents
and packages will be available this spring. The same story is for Ansible
and Puppet.

Now back again to our question. What I'd like is that Glare will receive
due recognition. Doing a project on the outskirts of OpenStack is not I
really want to. Therefore, it would be nice to develop Glare as a natural
evolution of Glance, associated with the requirements of operators and the
market in general. For Glance team is a good chance to try something new
and interesting, and of course gain new experience.

I am ready to discuss all these questions in this thread, and at PTG, as
long as necessary.

Best,

Mike

[1]
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf

On Fri, Feb 10, 2017 at 8:39 PM, Brian Rosmaita <rosmaita.fossdev at gmail.com>
wrote:

> 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.
>
> cheers,
> brian
>
> [0] https://etherpad.openstack.org/p/pike-glance-glare-discussion
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170213/54d77875/attachment.html>