<div dir="ltr"><span id="gmail-docs-internal-guid-89caf3d3-3809-e7b8-d0bc-2e2b592d6a9e"><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Hello!</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Moving away from Glance, let me remind you why we created Glare service. </span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">I am ready to discuss all these questions in this thread, and at PTG, as long as necessary.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Best,</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Mike</span></p><br><span style="font-size:11pt;font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">[1] <a href="http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf">http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf</a></span></span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 8:39 PM, Brian Rosmaita <span dir="ltr"><<a href="mailto:rosmaita.fossdev@gmail.com" target="_blank">rosmaita.fossdev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I want to give all interested parties a heads up that I have scheduled a<br>
session in the Macon room from 9:30-10:30 a.m. on Thursday morning<br>
(February 23).<br>
Here's what we need to discuss.  This is from my perspective as Glance<br>
PTL, so it's going to be Glance-centric.  This is a quick narrative<br>
description; please go to the session etherpad [0] to turn this into a<br>
specific set of discussion items.<br>
Glance is the OpenStack image cataloging and delivery service.  A few<br>
cycles ago (Juno?), someone noticed that maybe Glance could be<br>
generalized so that instead of storing image metadata and image data,<br>
Glance could store arbitrary digital "stuff" along with metadata<br>
describing the "stuff".  Some people (like me) thought that this was an<br>
obvious direction for Glance to take, but others (maybe wiser, cooler<br>
heads) thought that Glance needed to focus on image cataloging and<br>
delivery and make sure it did a good job at that.  Anyway, the Glance<br>
mission statement was changed to include artifacts, but the Glance<br>
community never embraced them 100%, and in Newton, Glare split off as<br>
its own project (which made sense to me, there was too much unclarity in<br>
Glance about how Glare fit in, and we were holding back development, and<br>
besides we needed to focus on images), and the Glance mission statement<br>
was re-amended specifically to exclude artifacts and focus on images and<br>
metadata definitions.<br>
OK, so the current situation is:<br>
- Glance "does" image cataloging and delivery and metadefs, and that's<br>
all it does.<br>
- Glare is an artifacts service (cataloging and delivery) that can also<br>
handle images.<br>
You can see that there's quite a bit of overlap.  I gave you the history<br>
earlier because we did try to work as a single project, but it did not<br>
work out.<br>
So, now we are in 2017.  The OpenStack development situation has been<br>
fragile since the second half of 2016, with several big OpenStack<br>
sponsors pulling way back on the amount of development resources being<br>
contributed to the community.  This has left Glare in the position where<br>
it cannot qualify as a Bit Tent project, even though there is interest<br>
in artifacts.<br>
Mike Fedosin, the PTL for Glare, has asked me about Glare becoming part<br>
of the Glance project again.  I will be completely honest, I am inclined<br>
to say "no".  I have enough problems just getting Glance stuff done (for<br>
example, image import missed Ocata).  But in addition to doing what's<br>
right for Glance, I want to do what's right for OpenStack.  And I look<br>
at the overlap and think ...<br>
Well, what I think is that I don't want to go through the Juno-Newton<br>
cycles of argument again.  And we have to do what is right for our users.<br>
The point of this session is to discuss:<br>
- What does the Glance community see as the future of Glance?<br>
- What does the wider OpenStack community (TC) see as the future of Glance?<br>
- Maybe, more importantly, what does the wider community see as the<br>
obligations of Glance?<br>
- Does Glare fit into this vision?<br>
- What kind of community support is there for Glare?<br>
My reading of Glance history is that while some people were on board<br>
with artifacts as the future of Glance, there was not a sufficient<br>
critical mass of the Glance community that endorsed this direction and<br>
that's why things unravelled in Newton.  I don't want to see that happen<br>
again.  Further, I don't think the Glance community got the word out to<br>
the broader OpenStack community about the artifacts project, and we got<br>
a lot of pushback along the lines of "WTF? Glance needs to do images"<br>
variety.  And probably rightly so -- Glance needs to do images.  My<br>
point is that I don't want Glance to take Glare back unless it fits in<br>
with what the community sees as the appropriate direction for Glance.<br>
And I certainly don't want to take it back if the entire Glance<br>
community is not on board.<br>
Anyway, that's what we're going to discuss.  I've booked one of the<br>
fishbowl rooms so we can get input from people beyond just the Glance<br>
and Glare projects.<br>
[0] <a href="https://etherpad.openstack.org/p/pike-glance-glare-discussion" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/pike-glance-glare-<wbr>discussion</a><br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>