[openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

Ian Cordasco sigmavirus24 at gmail.com
Tue Aug 9 14:21:28 UTC 2016


 

-----Original Message-----
From: Steven Dake (stdake) <stdake at cisco.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: August 6, 2016 at 07:48:01
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

> an,
>  
> I value your input, but concern still stands. Amazon's compute API moves slowly in comparison  
> to Docker registry's API. Making a parity implementation to the Docker v2 registry API  
> is a complex and difficult challenge. It is much more significant then simply making  
> an API. An implementation needs to stand behind that API.

I don't disagree. I just have a higher opinion of the community's ability to achieve this goal and use Glare as the backend.

>  
> From: Ian Cordasco >  
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >  
> Date: Saturday, August 6, 2016 at 4:52 AM
> 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
>  
>  
> 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)" >  
> 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" >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >  
> Date: Friday, Mooney"OpenStack Development Mailing List (not for usage questions)"  
> son 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 >  
> 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 us"OpenStack Development Mailing List (not for usage questions)"  
> y
> :>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
>  
> __________________________________________________________________________  
> 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
>  

--  
Ian Cordasco




More information about the OpenStack-dev mailing list