<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><blockquote type="cite" class="clean_bq"><div dir="ltr"> Undoubtedly, in the short term it will be painful, but I believe that in the long run Glare will win.</div></blockquote></div> <div><br></div><div>Let’s hope that projects, that use Glare would also win from this decision. =)</div><div><br></div><div>It seems to me, that murano is currently the only one that has been actively trying to incorporate glare into it’s development process. We have a (non-voting) integration job with glare backend. The split probably means, that devstack (and thus dsvm job) installations would be run via plugin from new repository. I would like to ask glance and glare teams to approach the process responsibly and not remove the code until it’s ready to be used from the new repo.</div><div><br></div><div>I’m going to echo Tim’s concerns and suggest that glare team put packaging and ease of use/deployment high on the list of new projects priorities.</div><div><br></div> <div id="bloop_sign_1470734581979404032" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Kirill Zaitsev</div><div style="font-family:helvetica,arial;font-size:13px">Murano Project Tech Lead</div><div style="font-family:helvetica,arial;font-size:13px">Software Engineer at</div><div style="font-family:helvetica,arial;font-size:13px">Mirantis, Inc</div></div> <br><p class="airmail_on">On 5 août 2016 at 21:11:12, Mikhail Fedosin (<a href="mailto:mfedosin@mirantis.com">mfedosin@mirantis.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">
<div>Thank you all for your responses!</div>
<div><br></div>
<div>From my side I can add that our separation is a deliberate
step. We pre-weighed all pros and cons and our final decision was
that moving forward as a new project is the lesser of two evils.</div>
<div><br></div>
<div>Also, I want to say, that Glare was designed as an open
project and we want to build a good community with members from
different companies. Glare suppose to be a backend for Heat (and
therefore TripleO), App-Catalog, Tacker and definitely Nova. In
addition we are considering the possibility of storage Docker
containers, which may be useful for Magnum.</div>
<div><br></div>
<div>Then, I think that comparison between Image API and Artifact
API is not correct. Moreover, in my opinion Image API imposes
artificial constraints. Just imagine that your file system can only
store images in JPG format (more precisely, it could store any
data, but it is imperative that all files must have the extension
".jpg"). Likewise Glance - I can put there any data, it can be both
packages and templates, as well as video from my holiday. And this
interface, though not ideal, may not work for all services. But
those artificial limitations that have been created, do Glance
uncomfortable even for storing images.</div>
<div><br></div>
<div>On the other hand Glare provides unified interface for all
possible binary data types. If we take the example with filesystem,
in Glare's case it supports all file extensions, folders, history
of file changes on your disk, data validation and conversion,
import/export files from different computers and so on. These
features are not presented in Glance and I think they never will,
because of deficiencies in the architecture. </div>
<div><br></div>
<div>For this reason I think Glare's adoption is important and it
will be a huge step forward for OpenStack and the whole
community.</div>
<div><br></div>
<div>Thanks again! If you want to support us, please vote for our
talk on Barcelona summit - <a href="https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/">
https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/</a>
Search "Glare" and there will be our presentation.</div>
<div><br></div>
<div>Best,</div>
<div>Mike </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 5, 2016 at 5:22 PM, Jonathan
D. Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't have a strong opinion on the split vs stay discussion.
It<br>
does seem there's been sustained if ineffective attempts to keep
this<br>
together so I lean toward supporting the divorce.<br>
<br>
But let's not pretend there are no costs for this.<br>
<br>
On Thu, Aug 04, 2016 at 07:02:48PM -0400, Jay Pipes wrote:<br>
:On 08/04/2016 06:40 PM, Clint Byrum wrote:<br>
<br>
:>But, if I look at this from a user perspective, if I do want
to use<br>
<span class="">:>anything other than images as cloud artifacts,
the story is pretty<br>
:>confusing.<br>
:<br>
:Actually, I beg to differ. A unified OpenStack Artifacts
API,<br>
:long-term, will be more user-friendly and less confusing since
a<br>
:single API can be used for various kinds of similar artifacts
--<br>
:images, Heat templates, Tosca flows, Murano app manifests,
maybe<br>
:Solum things, maybe eventually Nova flavor-like things, etc.<br>
<br></span>The confusion is the current state of two API's, not
having a future<br>
integrated API.<br>
<br>
Remember how well that served us with nova-network and neutron
(né<br>
quantum).<br>
<br>
I also agree with Tim's point. Yes if a new project is
fully<br>
documented and integrated well into packaging and config
management<br>
implementing it is trivial, but history again teaches this is a
long<br>
road.<br>
<br>
It also means extra dev overhead to create and mange these<br>
supporting structures to hide the complexity from end users. Now
if<br>
the two project are sufficiently different this may not be a<br>
significant delta as the new docs and config management code would
be<br>
need in the old project if the new service stayed stayed
there.<br>
<br>
-Jon<br>
<div class="HOEnZb">
<div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<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>
</div>
</div>
</blockquote>
</div>
<br></div>
__________________________________________________________________________
<br>OpenStack Development Mailing List (not for usage questions)
<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<br></div></div></span></blockquote></body></html>