Open Stack

However, interested parties could start a project like the ec2 project that
is independently released and provides that compatibility using glare

On Aug 6, 2016 5:18 AM, "Steven Dake (stdake)" <stdake at cisco.com> wrote:

> Kevin,
>
> Agree it would be a very useful feature, however, easier said then done.
> Part of Docker's approach is to "move fast";they schedule releases every 2
> months.  I'm sure the glare team is quite competent, however, keeping API
> parity on such a fast moving project such as the docker registry API is a
> big objective not to be undertaken lightly.  If  there isn't complete API
> parity with the docker rregistry v2 API, the work wouldn't be particularly
> useful to many in the container communities inside OpenStack as Hongbin
> pointed out.
>
> Regards
> -steve
>
> From: "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Friday, August 5, 2016 at 2:29 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker]
> Glare as a new Project
>
> If glare was docker repo api compatible though, I think it would be quite
> useful. then each tenant doesn't have to set one up themselves.
>
> Thanks,
> Kevin
>
> ------------------------------
> *From:* Hongbin Lu [hongbin.lu at huawei.com]
> *Sent:* Friday, August 05, 2016 1:29 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker]
> Glare as a new Project
>
> Replied inline.
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedosin at mirantis.com
> <mfedosin at mirantis.com>]
> *Sent:* August-05-16 2:10 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker]
> Glare as a new Project
>
>
>
> Thank you all for your responses!
>
>
>
> 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. Undoubtedly, in the
> short term it will be painful, but I believe that in the long run Glare
> will win.
>
>
>
> 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.
>
>
>
> *[Hongbin Lu] Magnum doesn’t have any plan to store docker images at
> Glare, because COE (i.e. Kubernetes) is simply incompatible with any API
> other than docker registry. Zun might have use cases to store docker images
> at Glare if Glare is part of Glance, but I am reluctant to set a dependency
> on Glare if Glare is a totally branch new service.*
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> For this reason I think Glare's adoption is important and it will be a
> huge step forward for OpenStack and the whole community.
>
>
>
> Thanks again! If you want to support us, please vote for our talk on
> Barcelona summit - https://www.openstack.org/summit/barcelona-2016/vote-
> for-speakers/ Search "Glare" and there will be our presentation.
>
>
>
> Best,
>
> Mike
>
>
>
> On Fri, Aug 5, 2016 at 5:22 PM, Jonathan D. Proulx <jon at csail.mit.edu>
> wrote:
>
>
> I don't have a strong opinion on the split vs stay discussion. It
> does seem there's been sustained if ineffective attempts to keep this
> together so I lean toward supporting the divorce.
>
> But let's not pretend there are no costs for this.
>
> On Thu, Aug 04, 2016 at 07:02:48PM -0400, Jay Pipes wrote:
> :On 08/04/2016 06:40 PM, Clint Byrum wrote:
>
> :>But, if I look at this from a user perspective, if I do want to use
> :>anything other than images as cloud artifacts, the story is pretty
> :>confusing.
> :
> :Actually, I beg to differ. A unified OpenStack Artifacts API,
> :long-term, will be more user-friendly and less confusing since a
> :single API can be used for various kinds of similar artifacts --
> :images, Heat templates, Tosca flows, Murano app manifests, maybe
> :Solum things, maybe eventually Nova flavor-like things, etc.
>
> The confusion is the current state of two API's, not having a future
> integrated API.
>
> Remember how well that served us with nova-network and neutron (né
> quantum).
>
> I also agree with Tim's point.  Yes if a new project is fully
> documented and integrated well into packaging and config management
> implementing it is trivial, but history again teaches this is a long
> road.
>
> It also means extra dev overhead to create and mange these
> supporting structures to hide the complexity from end users. Now if
> the two project are sufficiently different this may not be a
> significant delta as the new docs and config management code would be
> need in the old project if the new service stayed stayed there.
>
> -Jon
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160806/9679f1bf/attachment.html>