Open Stack

Well don't let me stop ya :)

On 8/9/16, 7:21 AM, "Ian Cordasco" <sigmavirus24 at gmail.com> wrote:

> 
>
>-----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
>