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)" <std...@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....@pnnl.gov> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Friday, August 5, 2016 at 2:29 PM > 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 > > 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...@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:mfedo...@mirantis.com > <mfedo...@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 <j...@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-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