-----Original Message----- From: Steven Dake (stdake) <std...@cisco.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: August 6, 2016 at 07:48:01 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Ian Cordasco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev