Well don't let me stop ya :) On 8/9/16, 7:21 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
> > >-----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
