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

[Steven Dake (stdake)]

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

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

[Ian Cordasco]

 

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

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

[Kirill Zaitsev]

 Undoubtedly, in the short term it will be painful, but I believe that in the 
long run Glare will win.

Let’s hope that projects, that use Glare would also win from this decision. =)

It seems to me, that murano is currently the only one that has been actively 
trying to incorporate glare into it’s development process. We have a 
(non-voting) integration job with glare backend. The split probably means, that 
devstack (and thus dsvm job) installations would be run via plugin from new 
repository. I would like to ask glance and glare teams to approach the process 
responsibly and not remove the code until it’s ready to be used from the new 
repo.

I’m going to echo Tim’s concerns and suggest that glare team put packaging and 
ease of use/deployment high on the list of new projects priorities.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

On 5 août 2016 at 21:11:12, Mikhail Fedosin (mfedo...@mirantis.com) wrote:

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.

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.

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

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

[Steven Dake (stdake)]

Ian,

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.

Regards
-steve

From: Ian Cordasco <sigmaviru...@gmail.com<mailto:sigmaviru...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, August 6, 2016 at 4:52 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
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)" 
<std...@cisco.com<mailto: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<mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto: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<mailto: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<mailto: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]
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 o

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

[Ian Cordasco]

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

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

[Steven Dake (stdake)]

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<mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto: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<mailto: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<mailto: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]
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<mailto: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
:>conf

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

[Fox, Kevin M]

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]
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<mailto: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: 
openstac

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

[Hongbin Lu]

Replied inline.

From: Mikhail Fedosin [mailto: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<mailto: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://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

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

[Mikhail Fedosin]

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.

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

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

[Jonathan D. Proulx]

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

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

[stuart . mclaren]

I think this makes sense.

"Should Artifacts be part of Glance?" is something folks have been
debating for several years now, with seemingly equal numbers on
each side.

Even though it was far from unanimous, several summits ago it was decided
to aim for a a v3 Glance API which would support all artifact types,
including images. That turned out to be too ambitious for a project that
really was starting at times to operate close to maintenance mode. (
eg I haven't contributed at all this cycle). The realisation that
V3 wasn't going to happen in our lifetime, difficulties mapping between
V3 and V2 (and V1!) calls, and (IIRC) DefCore feedback, meant V3 was
abandoned: we'd have two separate APIs. That's actually a decision that
was taken a while ago, and isn't new.

As a previously stressed out operator (is there any other kind?) I
understand that anything that means you have more work to do is painful,
and should be considered a negative. But it shouldn't be the only
consideration. For me, moving a distinct API to its own project makes
the most longterm sense.

Thanks to Mike, Alex, Kairat et al for their (hopefully continuing)
Glance contributions and patience.

-Stuart


Hi all,
after 6 months of Glare v1 API development we have decided to continue our
work in a separate project in the "openstack" namespace with its own core
team (me, Kairat Kushaev, Darja Shkhray and the original creator -
Alexander Tivelkov). We want to thank Glance community for their support
during the incubation period, valuable advice and suggestions - this time
was really productive for us. I believe that this step will allow the Glare
project to concentrate on feature development and move forward faster.
Having the independent service also removes inconsistencies in
understanding what Glance project is: it seems that a single project cannot
own two different APIs with partially overlapping functionality. So with
the separation of Glare into a new project, Glance may continue its work on
the OpenStack Images API, while Glare will become the reference
implementation of the new OpenStack Artifacts API.

Nevertheless, Glare team would like to continue to collaborate with the
Glance team in a new - cross-project - format. We still have lots in
common, both in code and usage scenarios, so we are looking forward for
fruitful work with the rest of the Glance team. Those of you guys who are
interested in Glare and the future of Artifacts API are also welcome to
join the Glare team: we have a lot of really exciting tasks and will always
welcome new members.
Meanwhile, despite the fact that my focus will be on the new project, I
will continue to be part of the Glance team and for sure I'm going to
contribute in Glance, because I am interested in this project and want to
help it be successful.

We'll have the formal patches pushed to project-config earlier next week,
appropriate repositories, wiki and launchpad space will be created soon as
well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC
Mondays in #openstack-meeting-alt, it will just become a Glare project
meeting instead of a Glare sub-team meeting. Please feel free to join!

Best regards,
Mikhail Fedosin

P.S. For those of you who may be curious on the project name. We'll still
be called "Glare", but since we are on our own now this acronym becomes
recursive: GLARE now stands for "GLare Artifact REpository" :)
-- next part --
An HTML attachment was scrubbed...
URL: 


--


__
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

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

[Flavio Percoco]

On 04/08/16 15:46 +, Alexander Tivelkov wrote:

I am the one who started the initiative 2.5 years ago, and was always
advocating the "let's stay in Glance" approach during numerous discussions
on "where should it belong" for all these years.
Now I believe that it is time to move forward indeed. Some things remain to
be defined (first of all the differences and responsibility sharing between
Images and Artifacts APIs), but I am fully supportive of this move and
strongly believe it is a step in a right direction. Thanks Mike, Nikhil,
Flavio, Erno, Stuart, Brian and all others who helped Glare on this rough
path.



Thank you all for putting up with the Glance team changes of priorities. I
appreaciate all the effort you have put on this.

Flavio




On Thu, Aug 4, 2016 at 6:29 PM Mikhail Fedosin 
wrote:


Hi all,
after 6 months of Glare v1 API development we have decided to continue our
work in a separate project in the "openstack" namespace with its own core
team (me, Kairat Kushaev, Darja Shkhray and the original creator -
Alexander Tivelkov). We want to thank Glance community for their support
during the incubation period, valuable advice and suggestions - this time
was really productive for us. I believe that this step will allow the Glare
project to concentrate on feature development and move forward faster.
Having the independent service also removes inconsistencies in
understanding what Glance project is: it seems that a single project cannot
own two different APIs with partially overlapping functionality. So with
the separation of Glare into a new project, Glance may continue its work on
the OpenStack Images API, while Glare will become the reference
implementation of the new OpenStack Artifacts API.

Nevertheless, Glare team would like to continue to collaborate with the
Glance team in a new - cross-project - format. We still have lots in
common, both in code and usage scenarios, so we are looking forward for
fruitful work with the rest of the Glance team. Those of you guys who are
interested in Glare and the future of Artifacts API are also welcome to
join the Glare team: we have a lot of really exciting tasks and will always
welcome new members.
Meanwhile, despite the fact that my focus will be on the new project, I
will continue to be part of the Glance team and for sure I'm going to
contribute in Glance, because I am interested in this project and want to
help it be successful.

We'll have the formal patches pushed to project-config earlier next week,
appropriate repositories, wiki and launchpad space will be created soon as
well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC
Mondays in #openstack-meeting-alt, it will just become a Glare project
meeting instead of a Glare sub-team meeting. Please feel free to join!

Best regards,
Mikhail Fedosin

P.S. For those of you who may be curious on the project name. We'll still
be called "Glare", but since we are on our own now this acronym becomes
recursive: GLARE now stands for "GLare Artifact REpository" :)
__
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


--
Regards,
Alexander Tivelkov



__
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



--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

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

[Flavio Percoco]

On 04/08/16 13:47 -0500, Ian Cordasco wrote:

 

-Original Message-
From: Tim Bell <tim.b...@cern.ch>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 4, 2016 at 13:19:02
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



> On 04 Aug 2016, at 19:34, Erno Kuvaja wrote:
>
> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote:
>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>>
>>> On 04 Aug 2016, at 17:27, Mikhail Fedosin >
wrote:
>>>>
>>>> Hi all,
>>>>>> after 6 months of Glare v1 API development we have decided to continue
>>>> our work in a separate project in the "openstack" namespace with its own
>>>> core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
>>>> Alexander Tivelkov). We want to thank Glance community for their support
>>>> during the incubation period, valuable advice and suggestions - this time
>>>> was really productive for us. I believe that this step will allow the
>>>> Glare project to concentrate on feature development and move forward
>>>> faster. Having the independent service also removes inconsistencies
>>>> in understanding what Glance project is: it seems that a single project
>>>> cannot own two different APIs with partially overlapping functionality. So
>>>> with the separation of Glare into a new project, Glance may continue its
>>>> work on the OpenStack Images API, while Glare will become the reference
>>>> implementation of the new OpenStack Artifacts API.
>>>>
>>>
>>> I would suggest looking at more than just the development process when
>>> reflecting on this choice.
>>> While it may allow more rapid development, doing on your own will increase
>>> costs for end users and operators in areas like packaging, configuration,
>>> monitoring, quota … gaining critical mass in production for Glare will
>>> be much more difficult if you are not building on the Glance install base.
>>
>> I have to agree with Tim here. I respect that it's difficult to build on
>> top of Glance's API, rather than just start fresh. But, for operators,
>> it's more services, more API's to audit, and more complexity. For users,
>> they'll now have two ways to upload software to their clouds, which is
>> likely to result in a large portion just ignoring Glare even when it
>> would be useful for them.
>>
>> What I'd hoped when Glare and Glance combined, was that there would be
>> a single API that could be used for any software upload and listing. Is
>> there any kind of retrospective or documentation somewhere that explains
>> why that wasn't possible?
>>
>
> I was planning to leave this branch on it's own, but I have to correct
> something here. This split is not introducing new API, it's moving the
> new Artifact API under it's own project, there was no shared API in
> first place. Glare was to be it's own service already within Glance
> project. Also the Artifacts API turned out to be fundamentally
> incompatible with the Images APIs v1 & v2 due to the totally different
> requirements. And even the option was discussed in the community I
> personally think replicating Images API and carrying the cost it being
> in two services that are fundamentally different would have been huge
> mistake we would have paid for long time. I'm not saying that it would
> have been impossible, but there is lots of burden in Images APIs that
> Glare really does not need to carry, we just can't get rid of it and
> likely no-one would have been happy to see Images API v3 around the
> time when we are working super hard to get the v1 users moving to v2.
>
> Packaging glance-api, glance-registry and glare-api from glance repo
> would not change the effort too much compared from 2 repos either.
> Likely it just makes it easier when the logical split it clear from
> the beginning.
>
> What comes to Tim's statement, I do not see how Glare in it's own
> service with it's own API could ride on the Glance install base apart
> from the quite false mental image these two thing being the same and
> based on the same code.
>

To give a concrete use case, CERN have Glance deployed for images. We are 
interested in
the ecosystem
around Murano and are actively using Heat. We deploy using RDO with RPM 
packages, Puppet-OpenStack
for configuration, a set of machines serving Glance in an HA set up ac

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

[Tim Bell]

> On 05 Aug 2016, at 01:02, Jay Pipes  wrote:
> 
> On 08/04/2016 06:40 PM, Clint Byrum wrote:
>> Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400:
>>> On 08/04/2016 05:30 PM, Clint Byrum wrote:
 Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
> I disagree. I see glare as a superset of the needs of the image api and 
> one feature I need thats image related was specifically shot down as "the 
> artefact api will solve that".
> 
> You have all the same needs to version/catalog/store images. They are not 
> more special then a versioned/cataloged/stored heat templates, murano 
> apps, tuskar workflows, etc. I've heard multiple times, members of the 
> glance team saying  that once glare is fully mature, they could stub out 
> the v1/v2 glance apis on top of glare. What is the benefit to splitting 
> if the end goal is to recombine/make one project irrelevant?
> 
> This feels like to me, another case of an established, original tent 
> project not wanting to deal with something that needs to be dealt with, 
> and instead pushing it out to another project with the hope that it just 
> goes away. With all the traction non original tent projects have gotten 
> since the big tent was established, that might be an accurate conclusion, 
> but really bad for users/operators of OpenStack.
> 
> I really would like glance/glare to reconsider this stance. OpenStack 
> continuously budding off projects is not a good pattern.
> 
 
 So very this.
>>> 
>>> Honestly, operators need to move past the "oh, not another service to
>>> install/configure" thing.
>>> 
>>> With the whole "microservice the world" movement, that ship has long
>>> since sailed, and frankly, the cost of adding another microservice into
>>> the deployment at this point is tiny -- it should be nothing more than a
>>> few lines in a Puppet manifest, Chef module, Ansible playbook, or Salt
>>> state file.
>>> 
>>> If you're doing deployment right, adding new services to the
>>> microservice architecture that OpenStack projects are being pushed
>>> towards should not be an issue.
>>> 
>>> I find it odd that certain folks are pushing hard for the
>>> shared-nothing, microservice-it-all software architecture and yet
>>> support this mentality that adding another couple (dozen if need be)
>>> lines of configuration data to a deployment script is beyond the pale to
>>> ask of operators.
>>> 
>> 
>> Agreed, deployment isn't that big of a deal. I actually thought Kevin's
>> point was that the lack of focus was the problem. I think the point in
>> bringing up deployment is simply that it isn't free, not that it's the
>> reason to combine the two.
> 
> My above statement was more directed to Kevin and Tim, both of whom indicated 
> that adding another service to the deployment was a major problem.
> 

The difficulty I have with additional projects is that there are often major 
parts missing in order to deploy in production. Packaging, Configuration 
management manifests, Monitoring etc. are not part
of the standard deliverables but are left to other teams. Having had to fill in 
these gaps for 4 OpenStack projects so far already, they are not trivial to do 
and I feel the effort required
for this was not considered as part of the split decision.

 It's clear there's been a disconnect in expectations between the outside
 and inside of development.
 
 The hope from the outside was that we'd end up with a user friendly
 frontend API to artifacts, that included more capability for cataloging
 images.  It sounds like the two teams never actually shared that vision
 and remained two teams, instead of combining into one under a shared
 vision.
 
 Thanks for all your hard work, Glance and Glare teams. I don't think
 any of us can push a vision on you. But, as Kevin says above: consider
 addressing the lack of vision and cooperation head on, rather than
 turning your backs on each-other. The users will sing your praises if
 you can get it done.
>>> 
>>> It's been three years, two pre-big-tent TC graduation reviews (one for a
>>> split out murano app catalog, one for the combined project team being
>>> all things artifact), and over that three years, the original Glance
>>> project has at times crawled to a near total stop from a contribution
>>> perspective and not indicated much desire to incorporate the generic
>>> artifacts API or code. Time for this cooperation came and went with
>>> ample opportunities.
>>> 
>>> The Glare project is moving on.
>> 
>> The point is that this should be reconsidered, and that these internal
>> problems, now surfaced, seem surmountable if there's actually a reason
>> to get past them. Since it seems from the start, Glare and Glance never
>> actually intended to converge on a generic artifacts API, but rather
>> to simply tolerate one 

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

[Hongbin Lu]

I disagree as well. From users perspective, Glare looks like a Glance API v3. 
Having Glare and Glance as two independent services is quite confusing. I guess 
you would get a lot of questions like "what is the difference between Glance 
and Glare?", "does Glance depends on Glare?", "is Glare a backend of Glance?", 
etc.

Also, if Glare is splitted out as an independent service, it will be hard for 
other services to depend on Glare since few people are willing to depend on a 
new service, not to mention the risk that Glare might become a persistently 
single-vendor project thus having problems to join the big-tent. In comparison, 
if Glare is under Glance, it will have less adoption problems.

Best regards,
Hongbin

> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: August-04-16 3:21 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
> 
> I disagree. I see glare as a superset of the needs of the image api and
> one feature I need thats image related was specifically shot down as
> "the artefact api will solve that".
> 
> You have all the same needs to version/catalog/store images. They are
> not more special then a versioned/cataloged/stored heat templates,
> murano apps, tuskar workflows, etc. I've heard multiple times, members
> of the glance team saying  that once glare is fully mature, they could
> stub out the v1/v2 glance apis on top of glare. What is the benefit to
> splitting if the end goal is to recombine/make one project irrelevant?
> 
> This feels like to me, another case of an established, original tent
> project not wanting to deal with something that needs to be dealt with,
> and instead pushing it out to another project with the hope that it
> just goes away. With all the traction non original tent projects have
> gotten since the big tent was established, that might be an accurate
> conclusion, but really bad for users/operators of OpenStack.
> 
> I really would like glance/glare to reconsider this stance. OpenStack
> continuously budding off projects is not a good pattern.
> 
> Thanks,
> Kevin
> 
> From: Erno Kuvaja [ekuv...@redhat.com]
> Sent: Thursday, August 04, 2016 10:34 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
> 
> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum <cl...@fewbar.com> wrote:
> > Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
> >>
> >> On 04 Aug 2016, at 17:27, Mikhail Fedosin
> <mfedo...@mirantis.com<mailto:mfedo...@mirantis.com>> wrote:
> >> >
> >> > Hi all,
> >> > > > after 6 months of Glare v1 API development we have decided to
> >> > > > continue
> >> > our work in a separate project in the "openstack" namespace with
> >> > its own core team (me, Kairat Kushaev, Darja Shkhray and the
> >> > original creator - Alexander Tivelkov). We want to thank Glance
> >> > community for their support during the incubation period, valuable
> >> > advice and suggestions - this time was really productive for us. I
> >> > believe that this step will allow the Glare project to concentrate
> >> > on feature development and move forward faster. Having the
> >> > independent service also removes inconsistencies in understanding
> >> > what Glance project is: it seems that a single project cannot own
> >> > two different APIs with partially overlapping functionality. So
> >> > with the separation of Glare into a new project, Glance may
> >> > continue its work on the OpenStack Images API, while Glare will
> become the reference implementation of the new OpenStack Artifacts API.
> >> >
> >>
> >> I would suggest looking at more than just the development process
> >> when reflecting on this choice.
> >> While it may allow more rapid development, doing on your own will
> >> increase costs for end users and operators in areas like packaging,
> >> configuration, monitoring, quota ... gaining critical mass in
> >> production for Glare will be much more difficult if you are not
> building on the Glance install base.
> >
> > I have to agree with Tim here. I respect that it's difficult to build
> > on top of Glance's API, rather than just start fresh. But, for
> > operators, it's more services, more API's to audit, and more
> > complex

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

[Jay Pipes]

On 08/04/2016 06:40 PM, Clint Byrum wrote:

Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400:

On 08/04/2016 05:30 PM, Clint Byrum wrote:

Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:

I disagree. I see glare as a superset of the needs of the image api and one feature I 
need thats image related was specifically shot down as "the artefact api will solve 
that".

You have all the same needs to version/catalog/store images. They are not more 
special then a versioned/cataloged/stored heat templates, murano apps, tuskar 
workflows, etc. I've heard multiple times, members of the glance team saying  
that once glare is fully mature, they could stub out the v1/v2 glance apis on 
top of glare. What is the benefit to splitting if the end goal is to 
recombine/make one project irrelevant?

This feels like to me, another case of an established, original tent project 
not wanting to deal with something that needs to be dealt with, and instead 
pushing it out to another project with the hope that it just goes away. With 
all the traction non original tent projects have gotten since the big tent was 
established, that might be an accurate conclusion, but really bad for 
users/operators of OpenStack.

I really would like glance/glare to reconsider this stance. OpenStack 
continuously budding off projects is not a good pattern.



So very this.


Honestly, operators need to move past the "oh, not another service to
install/configure" thing.

With the whole "microservice the world" movement, that ship has long
since sailed, and frankly, the cost of adding another microservice into
the deployment at this point is tiny -- it should be nothing more than a
few lines in a Puppet manifest, Chef module, Ansible playbook, or Salt
state file.

If you're doing deployment right, adding new services to the
microservice architecture that OpenStack projects are being pushed
towards should not be an issue.

I find it odd that certain folks are pushing hard for the
shared-nothing, microservice-it-all software architecture and yet
support this mentality that adding another couple (dozen if need be)
lines of configuration data to a deployment script is beyond the pale to
ask of operators.



Agreed, deployment isn't that big of a deal. I actually thought Kevin's
point was that the lack of focus was the problem. I think the point in
bringing up deployment is simply that it isn't free, not that it's the
reason to combine the two.


My above statement was more directed to Kevin and Tim, both of whom 
indicated that adding another service to the deployment was a major problem.



It's clear there's been a disconnect in expectations between the outside
and inside of development.

The hope from the outside was that we'd end up with a user friendly
frontend API to artifacts, that included more capability for cataloging
images.  It sounds like the two teams never actually shared that vision
and remained two teams, instead of combining into one under a shared
vision.

Thanks for all your hard work, Glance and Glare teams. I don't think
any of us can push a vision on you. But, as Kevin says above: consider
addressing the lack of vision and cooperation head on, rather than
turning your backs on each-other. The users will sing your praises if
you can get it done.


It's been three years, two pre-big-tent TC graduation reviews (one for a
split out murano app catalog, one for the combined project team being
all things artifact), and over that three years, the original Glance
project has at times crawled to a near total stop from a contribution
perspective and not indicated much desire to incorporate the generic
artifacts API or code. Time for this cooperation came and went with
ample opportunities.

The Glare project is moving on.


The point is that this should be reconsidered, and that these internal
problems, now surfaced, seem surmountable if there's actually a reason
to get past them. Since it seems from the start, Glare and Glance never
actually intended to converge on a generic artifacts API, but rather
to simply tolerate one another (back when I supported their merging,
I never thought this would be the case), then of course, it wasn't going
to go well.

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.


That would leave the Glance project team to focus on glance_store, 
stabilizing storage drivers and maybe working on utilities to transform 
image formats and/or provide some unified incremental diff'ing solution 
for both container and VM images now that they no longer need to deal 
with a 

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

[Clint Byrum]

Excerpts from Jay Pipes's message of 2016-08-04 18:14:46 -0400:
> On 08/04/2016 05:30 PM, Clint Byrum wrote:
> > Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
> >> I disagree. I see glare as a superset of the needs of the image api and 
> >> one feature I need thats image related was specifically shot down as "the 
> >> artefact api will solve that".
> >>
> >> You have all the same needs to version/catalog/store images. They are not 
> >> more special then a versioned/cataloged/stored heat templates, murano 
> >> apps, tuskar workflows, etc. I've heard multiple times, members of the 
> >> glance team saying  that once glare is fully mature, they could stub out 
> >> the v1/v2 glance apis on top of glare. What is the benefit to splitting if 
> >> the end goal is to recombine/make one project irrelevant?
> >>
> >> This feels like to me, another case of an established, original tent 
> >> project not wanting to deal with something that needs to be dealt with, 
> >> and instead pushing it out to another project with the hope that it just 
> >> goes away. With all the traction non original tent projects have gotten 
> >> since the big tent was established, that might be an accurate conclusion, 
> >> but really bad for users/operators of OpenStack.
> >>
> >> I really would like glance/glare to reconsider this stance. OpenStack 
> >> continuously budding off projects is not a good pattern.
> >>
> >
> > So very this.
> 
> Honestly, operators need to move past the "oh, not another service to 
> install/configure" thing.
> 
> With the whole "microservice the world" movement, that ship has long 
> since sailed, and frankly, the cost of adding another microservice into 
> the deployment at this point is tiny -- it should be nothing more than a 
> few lines in a Puppet manifest, Chef module, Ansible playbook, or Salt 
> state file.
> 
> If you're doing deployment right, adding new services to the 
> microservice architecture that OpenStack projects are being pushed 
> towards should not be an issue.
> 
> I find it odd that certain folks are pushing hard for the 
> shared-nothing, microservice-it-all software architecture and yet 
> support this mentality that adding another couple (dozen if need be) 
> lines of configuration data to a deployment script is beyond the pale to 
> ask of operators.
> 

Agreed, deployment isn't that big of a deal. I actually thought Kevin's
point was that the lack of focus was the problem. I think the point in
bringing up deployment is simply that it isn't free, not that it's the
reason to combine the two.

> > It's clear there's been a disconnect in expectations between the outside
> > and inside of development.
> >
> > The hope from the outside was that we'd end up with a user friendly
> > frontend API to artifacts, that included more capability for cataloging
> > images.  It sounds like the two teams never actually shared that vision
> > and remained two teams, instead of combining into one under a shared
> > vision.
> >
> > Thanks for all your hard work, Glance and Glare teams. I don't think
> > any of us can push a vision on you. But, as Kevin says above: consider
> > addressing the lack of vision and cooperation head on, rather than
> > turning your backs on each-other. The users will sing your praises if
> > you can get it done.
> 
> It's been three years, two pre-big-tent TC graduation reviews (one for a 
> split out murano app catalog, one for the combined project team being 
> all things artifact), and over that three years, the original Glance 
> project has at times crawled to a near total stop from a contribution 
> perspective and not indicated much desire to incorporate the generic 
> artifacts API or code. Time for this cooperation came and went with 
> ample opportunities.
> 
> The Glare project is moving on.
> 

The point is that this should be reconsidered, and that these internal
problems, now surfaced, seem surmountable if there's actually a reason
to get past them. Since it seems from the start, Glare and Glance never
actually intended to converge on a generic artifacts API, but rather
to simply tolerate one another (back when I supported their merging,
I never thought this would be the case), then of course, it wasn't going
to go well.

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.

Anyway, it's done, and I think we should take it as a lesson that team
mergers are complicated social activities, not technical ones, and so
they should be handled with care.

__
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

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

[Jay Pipes]

On 08/04/2016 05:30 PM, Clint Byrum wrote:

Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:

I disagree. I see glare as a superset of the needs of the image api and one feature I 
need thats image related was specifically shot down as "the artefact api will solve 
that".

You have all the same needs to version/catalog/store images. They are not more 
special then a versioned/cataloged/stored heat templates, murano apps, tuskar 
workflows, etc. I've heard multiple times, members of the glance team saying  
that once glare is fully mature, they could stub out the v1/v2 glance apis on 
top of glare. What is the benefit to splitting if the end goal is to 
recombine/make one project irrelevant?

This feels like to me, another case of an established, original tent project 
not wanting to deal with something that needs to be dealt with, and instead 
pushing it out to another project with the hope that it just goes away. With 
all the traction non original tent projects have gotten since the big tent was 
established, that might be an accurate conclusion, but really bad for 
users/operators of OpenStack.

I really would like glance/glare to reconsider this stance. OpenStack 
continuously budding off projects is not a good pattern.



So very this.


Honestly, operators need to move past the "oh, not another service to 
install/configure" thing.


With the whole "microservice the world" movement, that ship has long 
since sailed, and frankly, the cost of adding another microservice into 
the deployment at this point is tiny -- it should be nothing more than a 
few lines in a Puppet manifest, Chef module, Ansible playbook, or Salt 
state file.


If you're doing deployment right, adding new services to the 
microservice architecture that OpenStack projects are being pushed 
towards should not be an issue.


I find it odd that certain folks are pushing hard for the 
shared-nothing, microservice-it-all software architecture and yet 
support this mentality that adding another couple (dozen if need be) 
lines of configuration data to a deployment script is beyond the pale to 
ask of operators.



It's clear there's been a disconnect in expectations between the outside
and inside of development.

The hope from the outside was that we'd end up with a user friendly
frontend API to artifacts, that included more capability for cataloging
images.  It sounds like the two teams never actually shared that vision
and remained two teams, instead of combining into one under a shared
vision.

Thanks for all your hard work, Glance and Glare teams. I don't think
any of us can push a vision on you. But, as Kevin says above: consider
addressing the lack of vision and cooperation head on, rather than
turning your backs on each-other. The users will sing your praises if
you can get it done.


It's been three years, two pre-big-tent TC graduation reviews (one for a 
split out murano app catalog, one for the combined project team being 
all things artifact), and over that three years, the original Glance 
project has at times crawled to a near total stop from a contribution 
perspective and not indicated much desire to incorporate the generic 
artifacts API or code. Time for this cooperation came and went with 
ample opportunities.


The Glare project is moving on.

Best,
-jay

__
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

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

[Clint Byrum]

Excerpts from Fox, Kevin M's message of 2016-08-04 19:20:43 +:
> I disagree. I see glare as a superset of the needs of the image api and one 
> feature I need thats image related was specifically shot down as "the 
> artefact api will solve that".
> 
> You have all the same needs to version/catalog/store images. They are not 
> more special then a versioned/cataloged/stored heat templates, murano apps, 
> tuskar workflows, etc. I've heard multiple times, members of the glance team 
> saying  that once glare is fully mature, they could stub out the v1/v2 glance 
> apis on top of glare. What is the benefit to splitting if the end goal is to 
> recombine/make one project irrelevant?
> 
> This feels like to me, another case of an established, original tent project 
> not wanting to deal with something that needs to be dealt with, and instead 
> pushing it out to another project with the hope that it just goes away. With 
> all the traction non original tent projects have gotten since the big tent 
> was established, that might be an accurate conclusion, but really bad for 
> users/operators of OpenStack. 
> 
> I really would like glance/glare to reconsider this stance. OpenStack 
> continuously budding off projects is not a good pattern.
> 

So very this.

It's clear there's been a disconnect in expectations between the outside
and inside of development.

The hope from the outside was that we'd end up with a user friendly
frontend API to artifacts, that included more capability for cataloging
images.  It sounds like the two teams never actually shared that vision
and remained two teams, instead of combining into one under a shared
vision.

Thanks for all your hard work, Glance and Glare teams. I don't think
any of us can push a vision on you. But, as Kevin says above: consider
addressing the lack of vision and cooperation head on, rather than
turning your backs on each-other. The users will sing your praises if
you can get it done.

__
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

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

[Erno Kuvaja]

That's fine, I might have an idea who have been saying so, but that
statement has never been the consensus even among the Glance core
team. In fct you would be well aware of this if you did follow the
pretty colorful discussion around glance spec.

We also have not had any intention to provide versioned images as that
would break our immutability promise (the image data will stay
consistent to the id through the image life once it has turned to
"active" state, as in you will always get same data, if any, out when
you do image-download to specific image ID).

So no I don't see us recombine these projects in any foreseeable
future and I'd be perfectly fine if some future day Glance becomes
obsolete because Glare does it's job better.

What comes to the reconsidering the stance, I'd love to see the
community being able to work out the issues and do the development
together. On the other hand I've been telling to Mike for quite a
while that they really should consider spinning Glare off. In reality
this will be much better for the Glare future development, the teams
who have been waiting desperately for last couple of cycles to get
consuming it and it will also make bit of room for Glance community to
fully focus on the things that are important to the Glance consumers
rather than trying to divide the attention.

- Erno

On Thu, Aug 4, 2016 at 8:20 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> I disagree. I see glare as a superset of the needs of the image api and one 
> feature I need thats image related was specifically shot down as "the 
> artefact api will solve that".
>
> You have all the same needs to version/catalog/store images. They are not 
> more special then a versioned/cataloged/stored heat templates, murano apps, 
> tuskar workflows, etc. I've heard multiple times, members of the glance team 
> saying  that once glare is fully mature, they could stub out the v1/v2 glance 
> apis on top of glare. What is the benefit to splitting if the end goal is to 
> recombine/make one project irrelevant?
>
> This feels like to me, another case of an established, original tent project 
> not wanting to deal with something that needs to be dealt with, and instead 
> pushing it out to another project with the hope that it just goes away. With 
> all the traction non original tent projects have gotten since the big tent 
> was established, that might be an accurate conclusion, but really bad for 
> users/operators of OpenStack.
>
> I really would like glance/glare to reconsider this stance. OpenStack 
> continuously budding off projects is not a good pattern.
>
> Thanks,
> Kevin
> 
> From: Erno Kuvaja [ekuv...@redhat.com]
> Sent: Thursday, August 04, 2016 10:34 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
>
> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum <cl...@fewbar.com> wrote:
>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>>
>>> On 04 Aug 2016, at 17:27, Mikhail Fedosin 
>>> <mfedo...@mirantis.com<mailto:mfedo...@mirantis.com>> wrote:
>>> >
>>> > Hi all,
>>> > > > after 6 months of Glare v1 API development we have decided to continue
>>> > our work in a separate project in the "openstack" namespace with its own
>>> > core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
>>> > Alexander Tivelkov). We want to thank Glance community for their support
>>> > during the incubation period, valuable advice and suggestions - this time
>>> > was really productive for us. I believe that this step will allow the
>>> > Glare project to concentrate on feature development and move forward
>>> > faster. Having the independent service also removes inconsistencies
>>> > in understanding what Glance project is: it seems that a single project
>>> > cannot own two different APIs with partially overlapping functionality. So
>>> > with the separation of Glare into a new project, Glance may continue its
>>> > work on the OpenStack Images API, while Glare will become the reference
>>> > implementation of the new OpenStack Artifacts API.
>>> >
>>>
>>> I would suggest looking at more than just the development process when
>>> reflecting on this choice.
>>> While it may allow more rapid development, doing on your own will increase
>>> costs for end users and operators in areas like packaging, configuration,
>>> monitoring, quota … gaining critical mass in production for Glare will
>>> be mu

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

[Fox, Kevin M]

I get that. I don't blame Mirantis for that either. Thats a really difficult 
place to be in.

This is the kind of silo disconnect I've been talking about though, where users 
of a project have real concrete needs, and the project doesn't listen as they 
think the current solution is "good enough" for everyone.

And another case where, this is probably the right call to make at the 
project(s) level under the circumstances in order to make progress again. But 
probably should be solved at a general OpenStack Architecture level or the TC 
so that technical architecture requirements and user feedback can be 
incorporated into the process rather then split on non technical reason, making 
the operator/user experience worse, not better for OpenStack as a whole.

Thanks,
Kevin

From: Ian Cordasco [sigmaviru...@gmail.com]
Sent: Thursday, August 04, 2016 11:47 AM
To: Tim Bell; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] 
Glare as a new Project

-Original Message-
From: Tim Bell <tim.b...@cern.ch>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 4, 2016 at 13:19:02
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

>
> > On 04 Aug 2016, at 19:34, Erno Kuvaja wrote:
> >
> > On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote:
> >> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
> >>>
> >>> On 04 Aug 2016, at 17:27, Mikhail Fedosin >
> wrote:
> >>>>
> >>>> Hi all,
> >>>>>> after 6 months of Glare v1 API development we have decided to continue
> >>>> our work in a separate project in the "openstack" namespace with its own
> >>>> core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
> >>>> Alexander Tivelkov). We want to thank Glance community for their support
> >>>> during the incubation period, valuable advice and suggestions - this time
> >>>> was really productive for us. I believe that this step will allow the
> >>>> Glare project to concentrate on feature development and move forward
> >>>> faster. Having the independent service also removes inconsistencies
> >>>> in understanding what Glance project is: it seems that a single project
> >>>> cannot own two different APIs with partially overlapping functionality. 
> >>>> So
> >>>> with the separation of Glare into a new project, Glance may continue its
> >>>> work on the OpenStack Images API, while Glare will become the reference
> >>>> implementation of the new OpenStack Artifacts API.
> >>>>
> >>>
> >>> I would suggest looking at more than just the development process when
> >>> reflecting on this choice.
> >>> While it may allow more rapid development, doing on your own will increase
> >>> costs for end users and operators in areas like packaging, configuration,
> >>> monitoring, quota … gaining critical mass in production for Glare will
> >>> be much more difficult if you are not building on the Glance install base.
> >>
> >> I have to agree with Tim here. I respect that it's difficult to build on
> >> top of Glance's API, rather than just start fresh. But, for operators,
> >> it's more services, more API's to audit, and more complexity. For users,
> >> they'll now have two ways to upload software to their clouds, which is
> >> likely to result in a large portion just ignoring Glare even when it
> >> would be useful for them.
> >>
> >> What I'd hoped when Glare and Glance combined, was that there would be
> >> a single API that could be used for any software upload and listing. Is
> >> there any kind of retrospective or documentation somewhere that explains
> >> why that wasn't possible?
> >>
> >
> > I was planning to leave this branch on it's own, but I have to correct
> > something here. This split is not introducing new API, it's moving the
> > new Artifact API under it's own project, there was no shared API in
> > first place. Glare was to be it's own service already within Glance
> > project. Also the Artifacts API turned out to be fundamentally
> > incompatible with the Images APIs v1 & v2 due to the totally different
> > requirements. And even the option wa

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

[Fox, Kevin M]

I disagree. I see glare as a superset of the needs of the image api and one 
feature I need thats image related was specifically shot down as "the artefact 
api will solve that".

You have all the same needs to version/catalog/store images. They are not more 
special then a versioned/cataloged/stored heat templates, murano apps, tuskar 
workflows, etc. I've heard multiple times, members of the glance team saying  
that once glare is fully mature, they could stub out the v1/v2 glance apis on 
top of glare. What is the benefit to splitting if the end goal is to 
recombine/make one project irrelevant?

This feels like to me, another case of an established, original tent project 
not wanting to deal with something that needs to be dealt with, and instead 
pushing it out to another project with the hope that it just goes away. With 
all the traction non original tent projects have gotten since the big tent was 
established, that might be an accurate conclusion, but really bad for 
users/operators of OpenStack. 

I really would like glance/glare to reconsider this stance. OpenStack 
continuously budding off projects is not a good pattern.

Thanks,
Kevin

From: Erno Kuvaja [ekuv...@redhat.com]
Sent: Thursday, August 04, 2016 10:34 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

On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>
>> On 04 Aug 2016, at 17:27, Mikhail Fedosin 
>> <mfedo...@mirantis.com<mailto:mfedo...@mirantis.com>> wrote:
>> >
>> > Hi all,
>> > > > after 6 months of Glare v1 API development we have decided to continue
>> > our work in a separate project in the "openstack" namespace with its own
>> > core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
>> > Alexander Tivelkov). We want to thank Glance community for their support
>> > during the incubation period, valuable advice and suggestions - this time
>> > was really productive for us. I believe that this step will allow the
>> > Glare project to concentrate on feature development and move forward
>> > faster. Having the independent service also removes inconsistencies
>> > in understanding what Glance project is: it seems that a single project
>> > cannot own two different APIs with partially overlapping functionality. So
>> > with the separation of Glare into a new project, Glance may continue its
>> > work on the OpenStack Images API, while Glare will become the reference
>> > implementation of the new OpenStack Artifacts API.
>> >
>>
>> I would suggest looking at more than just the development process when
>> reflecting on this choice.
>> While it may allow more rapid development, doing on your own will increase
>> costs for end users and operators in areas like packaging, configuration,
>> monitoring, quota … gaining critical mass in production for Glare will
>> be much more difficult if you are not building on the Glance install base.
>
> I have to agree with Tim here. I respect that it's difficult to build on
> top of Glance's API, rather than just start fresh. But, for operators,
> it's more services, more API's to audit, and more complexity. For users,
> they'll now have two ways to upload software to their clouds, which is
> likely to result in a large portion just ignoring Glare even when it
> would be useful for them.
>
> What I'd hoped when Glare and Glance combined, was that there would be
> a single API that could be used for any software upload and listing. Is
> there any kind of retrospective or documentation somewhere that explains
> why that wasn't possible?
>

I was planning to leave this branch on it's own, but I have to correct
something here. This split is not introducing new API, it's moving the
new Artifact API under it's own project, there was no shared API in
first place. Glare was to be it's own service already within Glance
project. Also the Artifacts API turned out to be fundamentally
incompatible with the Images APIs v1 & v2 due to the totally different
requirements. And even the option was discussed in the community I
personally think replicating Images API and carrying the cost it being
in two services that are fundamentally different would have been huge
mistake we would have paid for long time. I'm not saying that it would
have been impossible, but there is lots of burden in Images APIs that
Glare really does not need to carry, we just can't get rid of it and
likely no-one would have been happy to see Images API v3 around the
time when we are working super h

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

[Erno Kuvaja]

On Thu, Aug 4, 2016 at 7:13 PM, Tim Bell  wrote:
>
>> On 04 Aug 2016, at 19:34, Erno Kuvaja  wrote:
>>
>> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum  wrote:
>>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:

 On 04 Aug 2016, at 17:27, Mikhail Fedosin 
 > wrote:
>
> Hi all,
>>> after 6 months of Glare v1 API development we have decided to continue
> our work in a separate project in the "openstack" namespace with its own
> core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
> Alexander Tivelkov). We want to thank Glance community for their support
> during the incubation period, valuable advice and suggestions - this time
> was really productive for us. I believe that this step will allow the
> Glare project to concentrate on feature development and move forward
> faster. Having the independent service also removes inconsistencies
> in understanding what Glance project is: it seems that a single project
> cannot own two different APIs with partially overlapping functionality. So
> with the separation of Glare into a new project, Glance may continue its
> work on the OpenStack Images API, while Glare will become the reference
> implementation of the new OpenStack Artifacts API.
>

 I would suggest looking at more than just the development process when
 reflecting on this choice.
 While it may allow more rapid development, doing on your own will increase
 costs for end users and operators in areas like packaging, configuration,
 monitoring, quota … gaining critical mass in production for Glare will
 be much more difficult if you are not building on the Glance install base.
>>>
>>> I have to agree with Tim here. I respect that it's difficult to build on
>>> top of Glance's API, rather than just start fresh. But, for operators,
>>> it's more services, more API's to audit, and more complexity. For users,
>>> they'll now have two ways to upload software to their clouds, which is
>>> likely to result in a large portion just ignoring Glare even when it
>>> would be useful for them.
>>>
>>> What I'd hoped when Glare and Glance combined, was that there would be
>>> a single API that could be used for any software upload and listing. Is
>>> there any kind of retrospective or documentation somewhere that explains
>>> why that wasn't possible?
>>>
>>
>> I was planning to leave this branch on it's own, but I have to correct
>> something here. This split is not introducing new API, it's moving the
>> new Artifact API under it's own project, there was no shared API in
>> first place. Glare was to be it's own service already within Glance
>> project. Also the Artifacts API turned out to be fundamentally
>> incompatible with the Images APIs v1 & v2 due to the totally different
>> requirements. And even the option was discussed in the community I
>> personally think replicating Images API and carrying the cost it being
>> in two services that are fundamentally different would have been huge
>> mistake we would have paid for long time. I'm not saying that it would
>> have been impossible, but there is lots of burden in Images APIs that
>> Glare really does not need to carry, we just can't get rid of it and
>> likely no-one would have been happy to see Images API v3 around the
>> time when we are working super hard to get the v1 users moving to v2.
>>
>> Packaging glance-api, glance-registry and glare-api from glance repo
>> would not change the effort too much compared from 2 repos either.
>> Likely it just makes it easier when the logical split it clear from
>> the beginning.
>>
>> What comes to Tim's statement, I do not see how Glare in it's own
>> service with it's own API could ride on the Glance install base apart
>> from the quite false mental image these two thing being the same and
>> based on the same code.
>>
>
> To give a concrete use case, CERN have Glance deployed for images.  We are 
> interested in the ecosystem
> around Murano and are actively using Heat.  We deploy using RDO with RPM 
> packages, Puppet-OpenStack
> for configuration, a set of machines serving Glance in an HA set up across 
> multiple data centres  and various open source monitoring tools.
>
> The multitude of projects and the day two maintenance scenarios with 11 
> independent projects is a cost and adding further to this cost for the 
> production deployments of OpenStack should not be ignored.
>
> By Glare choosing to go their own way, does this mean that

Let me give you concrete answers. I will put the answer that differs
if Glare would stay as glance service in () otherwise the answer
applies to both cases.
>
> - Can the existing RPM packaging for Glance be used to deploy Glare ? If 
> there needs to be new packages defined, this is additional cost for the RDO 
> team (and the equivalent 

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

[Ian Cordasco]

 

-Original Message-
From: Tim Bell <tim.b...@cern.ch>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 4, 2016 at 13:19:02
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

>  
> > On 04 Aug 2016, at 19:34, Erno Kuvaja wrote:
> >
> > On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum wrote:
> >> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
> >>>
> >>> On 04 Aug 2016, at 17:27, Mikhail Fedosin >  
> wrote:
> >>>>
> >>>> Hi all,
> >>>>>> after 6 months of Glare v1 API development we have decided to continue
> >>>> our work in a separate project in the "openstack" namespace with its own
> >>>> core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
> >>>> Alexander Tivelkov). We want to thank Glance community for their support
> >>>> during the incubation period, valuable advice and suggestions - this time
> >>>> was really productive for us. I believe that this step will allow the
> >>>> Glare project to concentrate on feature development and move forward
> >>>> faster. Having the independent service also removes inconsistencies
> >>>> in understanding what Glance project is: it seems that a single project
> >>>> cannot own two different APIs with partially overlapping functionality. 
> >>>> So
> >>>> with the separation of Glare into a new project, Glance may continue its
> >>>> work on the OpenStack Images API, while Glare will become the reference
> >>>> implementation of the new OpenStack Artifacts API.
> >>>>
> >>>
> >>> I would suggest looking at more than just the development process when
> >>> reflecting on this choice.
> >>> While it may allow more rapid development, doing on your own will increase
> >>> costs for end users and operators in areas like packaging, configuration,
> >>> monitoring, quota … gaining critical mass in production for Glare will
> >>> be much more difficult if you are not building on the Glance install base.
> >>
> >> I have to agree with Tim here. I respect that it's difficult to build on
> >> top of Glance's API, rather than just start fresh. But, for operators,
> >> it's more services, more API's to audit, and more complexity. For users,
> >> they'll now have two ways to upload software to their clouds, which is
> >> likely to result in a large portion just ignoring Glare even when it
> >> would be useful for them.
> >>
> >> What I'd hoped when Glare and Glance combined, was that there would be
> >> a single API that could be used for any software upload and listing. Is
> >> there any kind of retrospective or documentation somewhere that explains
> >> why that wasn't possible?
> >>
> >
> > I was planning to leave this branch on it's own, but I have to correct
> > something here. This split is not introducing new API, it's moving the
> > new Artifact API under it's own project, there was no shared API in
> > first place. Glare was to be it's own service already within Glance
> > project. Also the Artifacts API turned out to be fundamentally
> > incompatible with the Images APIs v1 & v2 due to the totally different
> > requirements. And even the option was discussed in the community I
> > personally think replicating Images API and carrying the cost it being
> > in two services that are fundamentally different would have been huge
> > mistake we would have paid for long time. I'm not saying that it would
> > have been impossible, but there is lots of burden in Images APIs that
> > Glare really does not need to carry, we just can't get rid of it and
> > likely no-one would have been happy to see Images API v3 around the
> > time when we are working super hard to get the v1 users moving to v2.
> >
> > Packaging glance-api, glance-registry and glare-api from glance repo
> > would not change the effort too much compared from 2 repos either.
> > Likely it just makes it easier when the logical split it clear from
> > the beginning.
> >
> > What comes to Tim's statement, I do not see how Glare in it's own
> > service with it's own API could ride on the Glance install base apart
> > from the quite false mental image these two thing bei

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

[Fox, Kevin M]

+1. This moves yet more work towards the operators. That should be taken into 
account.

Thanks,
Kevin

From: Tim Bell [tim.b...@cern.ch]
Sent: Thursday, August 04, 2016 8:55 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


On 04 Aug 2016, at 17:27, Mikhail Fedosin 
<mfedo...@mirantis.com<mailto:mfedo...@mirantis.com>> wrote:

Hi all,
after 6 months of Glare v1 API development we have decided to continue our work 
in a separate project in the "openstack" namespace with its own core team (me, 
Kairat Kushaev, Darja Shkhray and the original creator - Alexander Tivelkov). 
We want to thank Glance community for their support during the incubation 
period, valuable advice and suggestions - this time was really productive for 
us. I believe that this step will allow the Glare project to concentrate on 
feature development and move forward faster. Having the independent service 
also removes inconsistencies in understanding what Glance project is: it seems 
that a single project cannot own two different APIs with partially overlapping 
functionality. So with the separation of Glare into a new project, Glance may 
continue its work on the OpenStack Images API, while Glare will become the 
reference implementation of the new OpenStack Artifacts API.


I would suggest looking at more than just the development process when 
reflecting on this choice.
While it may allow more rapid development, doing on your own will increase 
costs for end users and operators in areas like packaging, configuration, 
monitoring, quota … gaining critical mass in production for Glare will be much 
more difficult if you are not building on the Glance install base.
Tim
Nevertheless, Glare team would like to continue to collaborate with the Glance 
team in a new - cross-project - format. We still have lots in common, both in 
code and usage scenarios, so we are looking forward for fruitful work with the 
rest of the Glance team. Those of you guys who are interested in Glare and the 
future of Artifacts API are also welcome to join the Glare team: we have a lot 
of really exciting tasks and will always welcome new members.
Meanwhile, despite the fact that my focus will be on the new project, I will 
continue to be part of the Glance team and for sure I'm going to contribute in 
Glance, because I am interested in this project and want to help it be 
successful.

We'll have the formal patches pushed to project-config earlier next week, 
appropriate repositories, wiki and launchpad space will be created soon as 
well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC Mondays 
in #openstack-meeting-alt, it will just become a Glare project meeting instead 
of a Glare sub-team meeting. Please feel free to join!

Best regards,
Mikhail Fedosin

P.S. For those of you who may be curious on the project name. We'll still be 
called "Glare", but since we are on our own now this acronym becomes recursive: 
GLARE now stands for "GLare Artifact REpository" :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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

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

[Tim Bell]

> On 04 Aug 2016, at 19:34, Erno Kuvaja  wrote:
> 
> On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum  wrote:
>> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>> 
>>> On 04 Aug 2016, at 17:27, Mikhail Fedosin 
>>> > wrote:
 
 Hi all,
>> after 6 months of Glare v1 API development we have decided to continue
 our work in a separate project in the "openstack" namespace with its own
 core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
 Alexander Tivelkov). We want to thank Glance community for their support
 during the incubation period, valuable advice and suggestions - this time
 was really productive for us. I believe that this step will allow the
 Glare project to concentrate on feature development and move forward
 faster. Having the independent service also removes inconsistencies
 in understanding what Glance project is: it seems that a single project
 cannot own two different APIs with partially overlapping functionality. So
 with the separation of Glare into a new project, Glance may continue its
 work on the OpenStack Images API, while Glare will become the reference
 implementation of the new OpenStack Artifacts API.
 
>>> 
>>> I would suggest looking at more than just the development process when
>>> reflecting on this choice.
>>> While it may allow more rapid development, doing on your own will increase
>>> costs for end users and operators in areas like packaging, configuration,
>>> monitoring, quota … gaining critical mass in production for Glare will
>>> be much more difficult if you are not building on the Glance install base.
>> 
>> I have to agree with Tim here. I respect that it's difficult to build on
>> top of Glance's API, rather than just start fresh. But, for operators,
>> it's more services, more API's to audit, and more complexity. For users,
>> they'll now have two ways to upload software to their clouds, which is
>> likely to result in a large portion just ignoring Glare even when it
>> would be useful for them.
>> 
>> What I'd hoped when Glare and Glance combined, was that there would be
>> a single API that could be used for any software upload and listing. Is
>> there any kind of retrospective or documentation somewhere that explains
>> why that wasn't possible?
>> 
> 
> I was planning to leave this branch on it's own, but I have to correct
> something here. This split is not introducing new API, it's moving the
> new Artifact API under it's own project, there was no shared API in
> first place. Glare was to be it's own service already within Glance
> project. Also the Artifacts API turned out to be fundamentally
> incompatible with the Images APIs v1 & v2 due to the totally different
> requirements. And even the option was discussed in the community I
> personally think replicating Images API and carrying the cost it being
> in two services that are fundamentally different would have been huge
> mistake we would have paid for long time. I'm not saying that it would
> have been impossible, but there is lots of burden in Images APIs that
> Glare really does not need to carry, we just can't get rid of it and
> likely no-one would have been happy to see Images API v3 around the
> time when we are working super hard to get the v1 users moving to v2.
> 
> Packaging glance-api, glance-registry and glare-api from glance repo
> would not change the effort too much compared from 2 repos either.
> Likely it just makes it easier when the logical split it clear from
> the beginning.
> 
> What comes to Tim's statement, I do not see how Glare in it's own
> service with it's own API could ride on the Glance install base apart
> from the quite false mental image these two thing being the same and
> based on the same code.
> 

To give a concrete use case, CERN have Glance deployed for images.  We are 
interested in the ecosystem
around Murano and are actively using Heat.  We deploy using RDO with RPM 
packages, Puppet-OpenStack
for configuration, a set of machines serving Glance in an HA set up across 
multiple data centres  and various open source monitoring tools.

The multitude of projects and the day two maintenance scenarios with 11 
independent projects is a cost and adding further to this cost for the 
production deployments of OpenStack should not be ignored.

By Glare choosing to go their own way, does this mean that

- Can the existing RPM packaging for Glance be used to deploy Glare ? If there 
needs to be new packages defined, this is additional cost for the RDO team (and 
the equivalent .deb teams) or will the Glare team provide this ?
- Can we use our existing templates for Glance for configuration management ? 
If there need to be new ones defined, this is additional work for the Chef and 
Ansible teams or will the Glare team provide this ?
- Log consolidation and parsing using the various OsOps 

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

[Erno Kuvaja]

On Thu, Aug 4, 2016 at 5:20 PM, Clint Byrum  wrote:
> Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
>>
>> On 04 Aug 2016, at 17:27, Mikhail Fedosin 
>> > wrote:
>> >
>> > Hi all,
>> > > > after 6 months of Glare v1 API development we have decided to continue
>> > our work in a separate project in the "openstack" namespace with its own
>> > core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
>> > Alexander Tivelkov). We want to thank Glance community for their support
>> > during the incubation period, valuable advice and suggestions - this time
>> > was really productive for us. I believe that this step will allow the
>> > Glare project to concentrate on feature development and move forward
>> > faster. Having the independent service also removes inconsistencies
>> > in understanding what Glance project is: it seems that a single project
>> > cannot own two different APIs with partially overlapping functionality. So
>> > with the separation of Glare into a new project, Glance may continue its
>> > work on the OpenStack Images API, while Glare will become the reference
>> > implementation of the new OpenStack Artifacts API.
>> >
>>
>> I would suggest looking at more than just the development process when
>> reflecting on this choice.
>> While it may allow more rapid development, doing on your own will increase
>> costs for end users and operators in areas like packaging, configuration,
>> monitoring, quota … gaining critical mass in production for Glare will
>> be much more difficult if you are not building on the Glance install base.
>
> I have to agree with Tim here. I respect that it's difficult to build on
> top of Glance's API, rather than just start fresh. But, for operators,
> it's more services, more API's to audit, and more complexity. For users,
> they'll now have two ways to upload software to their clouds, which is
> likely to result in a large portion just ignoring Glare even when it
> would be useful for them.
>
> What I'd hoped when Glare and Glance combined, was that there would be
> a single API that could be used for any software upload and listing. Is
> there any kind of retrospective or documentation somewhere that explains
> why that wasn't possible?
>

I was planning to leave this branch on it's own, but I have to correct
something here. This split is not introducing new API, it's moving the
new Artifact API under it's own project, there was no shared API in
first place. Glare was to be it's own service already within Glance
project. Also the Artifacts API turned out to be fundamentally
incompatible with the Images APIs v1 & v2 due to the totally different
requirements. And even the option was discussed in the community I
personally think replicating Images API and carrying the cost it being
in two services that are fundamentally different would have been huge
mistake we would have paid for long time. I'm not saying that it would
have been impossible, but there is lots of burden in Images APIs that
Glare really does not need to carry, we just can't get rid of it and
likely no-one would have been happy to see Images API v3 around the
time when we are working super hard to get the v1 users moving to v2.

Packaging glance-api, glance-registry and glare-api from glance repo
would not change the effort too much compared from 2 repos either.
Likely it just makes it easier when the logical split it clear from
the beginning.

What comes to Tim's statement, I do not see how Glare in it's own
service with it's own API could ride on the Glance install base apart
from the quite false mental image these two thing being the same and
based on the same code.

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

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

[Clint Byrum]

Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +:
> 
> On 04 Aug 2016, at 17:27, Mikhail Fedosin 
> > wrote:
> > 
> > Hi all,
> > > > after 6 months of Glare v1 API development we have decided to continue
> > our work in a separate project in the "openstack" namespace with its own
> > core team (me, Kairat Kushaev, Darja Shkhray and the original creator -
> > Alexander Tivelkov). We want to thank Glance community for their support
> > during the incubation period, valuable advice and suggestions - this time
> > was really productive for us. I believe that this step will allow the
> > Glare project to concentrate on feature development and move forward
> > faster. Having the independent service also removes inconsistencies
> > in understanding what Glance project is: it seems that a single project
> > cannot own two different APIs with partially overlapping functionality. So
> > with the separation of Glare into a new project, Glance may continue its
> > work on the OpenStack Images API, while Glare will become the reference
> > implementation of the new OpenStack Artifacts API.
> > 
> 
> I would suggest looking at more than just the development process when
> reflecting on this choice.
> While it may allow more rapid development, doing on your own will increase
> costs for end users and operators in areas like packaging, configuration,
> monitoring, quota … gaining critical mass in production for Glare will
> be much more difficult if you are not building on the Glance install base.

I have to agree with Tim here. I respect that it's difficult to build on
top of Glance's API, rather than just start fresh. But, for operators,
it's more services, more API's to audit, and more complexity. For users,
they'll now have two ways to upload software to their clouds, which is
likely to result in a large portion just ignoring Glare even when it
would be useful for them.

What I'd hoped when Glare and Glance combined, was that there would be
a single API that could be used for any software upload and listing. Is
there any kind of retrospective or documentation somewhere that explains
why that wasn't possible?

__
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

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

[Erno Kuvaja]

On Thu, Aug 4, 2016 at 4:46 PM, Alexander Tivelkov
 wrote:
> I am the one who started the initiative 2.5 years ago, and was always
> advocating the "let's stay in Glance" approach during numerous discussions
> on "where should it belong" for all these years.
> Now I believe that it is time to move forward indeed. Some things remain to
> be defined (first of all the differences and responsibility sharing between
> Images and Artifacts APIs), but I am fully supportive of this move and
> strongly believe it is a step in a right direction. Thanks Mike, Nikhil,
> Flavio, Erno, Stuart, Brian and all others who helped Glare on this rough
> path.
>
>
> On Thu, Aug 4, 2016 at 6:29 PM Mikhail Fedosin 
> wrote:
>>
>> Hi all,
>> after 6 months of Glare v1 API development we have decided to continue our
>> work in a separate project in the "openstack" namespace with its own core
>> team (me, Kairat Kushaev, Darja Shkhray and the original creator - Alexander
>> Tivelkov). We want to thank Glance community for their support during the
>> incubation period, valuable advice and suggestions - this time was really
>> productive for us. I believe that this step will allow the Glare project to
>> concentrate on feature development and move forward faster. Having the
>> independent service also removes inconsistencies in understanding what
>> Glance project is: it seems that a single project cannot own two different
>> APIs with partially overlapping functionality. So with the separation of
>> Glare into a new project, Glance may continue its work on the OpenStack
>> Images API, while Glare will become the reference implementation of the new
>> OpenStack Artifacts API.
>>
>> Nevertheless, Glare team would like to continue to collaborate with the
>> Glance team in a new - cross-project - format. We still have lots in common,
>> both in code and usage scenarios, so we are looking forward for fruitful
>> work with the rest of the Glance team. Those of you guys who are interested
>> in Glare and the future of Artifacts API are also welcome to join the Glare
>> team: we have a lot of really exciting tasks and will always welcome new
>> members.
>> Meanwhile, despite the fact that my focus will be on the new project, I
>> will continue to be part of the Glance team and for sure I'm going to
>> contribute in Glance, because I am interested in this project and want to
>> help it be successful.
>>
>> We'll have the formal patches pushed to project-config earlier next week,
>> appropriate repositories, wiki and launchpad space will be created soon as
>> well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC
>> Mondays in #openstack-meeting-alt, it will just become a Glare project
>> meeting instead of a Glare sub-team meeting. Please feel free to join!
>>
>> Best regards,
>> Mikhail Fedosin
>>
>> P.S. For those of you who may be curious on the project name. We'll still
>> be called "Glare", but since we are on our own now this acronym becomes
>> recursive: GLARE now stands for "GLare Artifact REpository" :)
>> __
>> 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
>
> --
> Regards,
> Alexander Tivelkov
>
> __
> 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
>

Glare is dead, Long Live Glare!

It's sad to see the child moving out of the house, but I'm sure this
is the right thing to do to keep the momentum ongoing while she
matures.

- Erno

__
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

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

[Tim Bell]

On 04 Aug 2016, at 17:27, Mikhail Fedosin 
> wrote:

Hi all,
after 6 months of Glare v1 API development we have decided to continue our work 
in a separate project in the "openstack" namespace with its own core team (me, 
Kairat Kushaev, Darja Shkhray and the original creator - Alexander Tivelkov). 
We want to thank Glance community for their support during the incubation 
period, valuable advice and suggestions - this time was really productive for 
us. I believe that this step will allow the Glare project to concentrate on 
feature development and move forward faster. Having the independent service 
also removes inconsistencies in understanding what Glance project is: it seems 
that a single project cannot own two different APIs with partially overlapping 
functionality. So with the separation of Glare into a new project, Glance may 
continue its work on the OpenStack Images API, while Glare will become the 
reference implementation of the new OpenStack Artifacts API.


I would suggest looking at more than just the development process when 
reflecting on this choice.
While it may allow more rapid development, doing on your own will increase 
costs for end users and operators in areas like packaging, configuration, 
monitoring, quota … gaining critical mass in production for Glare will be much 
more difficult if you are not building on the Glance install base.
Tim
Nevertheless, Glare team would like to continue to collaborate with the Glance 
team in a new - cross-project - format. We still have lots in common, both in 
code and usage scenarios, so we are looking forward for fruitful work with the 
rest of the Glance team. Those of you guys who are interested in Glare and the 
future of Artifacts API are also welcome to join the Glare team: we have a lot 
of really exciting tasks and will always welcome new members.
Meanwhile, despite the fact that my focus will be on the new project, I will 
continue to be part of the Glance team and for sure I'm going to contribute in 
Glance, because I am interested in this project and want to help it be 
successful.

We'll have the formal patches pushed to project-config earlier next week, 
appropriate repositories, wiki and launchpad space will be created soon as 
well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC Mondays 
in #openstack-meeting-alt, it will just become a Glare project meeting instead 
of a Glare sub-team meeting. Please feel free to join!

Best regards,
Mikhail Fedosin

P.S. For those of you who may be curious on the project name. We'll still be 
called "Glare", but since we are on our own now this acronym becomes recursive: 
GLARE now stands for "GLare Artifact REpository" :)
__
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

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

[Alexander Tivelkov]

I am the one who started the initiative 2.5 years ago, and was always
advocating the "let's stay in Glance" approach during numerous discussions
on "where should it belong" for all these years.
Now I believe that it is time to move forward indeed. Some things remain to
be defined (first of all the differences and responsibility sharing between
Images and Artifacts APIs), but I am fully supportive of this move and
strongly believe it is a step in a right direction. Thanks Mike, Nikhil,
Flavio, Erno, Stuart, Brian and all others who helped Glare on this rough
path.


On Thu, Aug 4, 2016 at 6:29 PM Mikhail Fedosin 
wrote:

> Hi all,
> after 6 months of Glare v1 API development we have decided to continue our
> work in a separate project in the "openstack" namespace with its own core
> team (me, Kairat Kushaev, Darja Shkhray and the original creator -
> Alexander Tivelkov). We want to thank Glance community for their support
> during the incubation period, valuable advice and suggestions - this time
> was really productive for us. I believe that this step will allow the Glare
> project to concentrate on feature development and move forward faster.
> Having the independent service also removes inconsistencies in
> understanding what Glance project is: it seems that a single project cannot
> own two different APIs with partially overlapping functionality. So with
> the separation of Glare into a new project, Glance may continue its work on
> the OpenStack Images API, while Glare will become the reference
> implementation of the new OpenStack Artifacts API.
>
> Nevertheless, Glare team would like to continue to collaborate with the
> Glance team in a new - cross-project - format. We still have lots in
> common, both in code and usage scenarios, so we are looking forward for
> fruitful work with the rest of the Glance team. Those of you guys who are
> interested in Glare and the future of Artifacts API are also welcome to
> join the Glare team: we have a lot of really exciting tasks and will always
> welcome new members.
> Meanwhile, despite the fact that my focus will be on the new project, I
> will continue to be part of the Glance team and for sure I'm going to
> contribute in Glance, because I am interested in this project and want to
> help it be successful.
>
> We'll have the formal patches pushed to project-config earlier next week,
> appropriate repositories, wiki and launchpad space will be created soon as
> well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC
> Mondays in #openstack-meeting-alt, it will just become a Glare project
> meeting instead of a Glare sub-team meeting. Please feel free to join!
>
> Best regards,
> Mikhail Fedosin
>
> P.S. For those of you who may be curious on the project name. We'll still
> be called "Glare", but since we are on our own now this acronym becomes
> recursive: GLARE now stands for "GLare Artifact REpository" :)
> __
> 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
>
-- 
Regards,
Alexander Tivelkov
__
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-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

[Mikhail Fedosin]

Hi all,
after 6 months of Glare v1 API development we have decided to continue our
work in a separate project in the "openstack" namespace with its own core
team (me, Kairat Kushaev, Darja Shkhray and the original creator -
Alexander Tivelkov). We want to thank Glance community for their support
during the incubation period, valuable advice and suggestions - this time
was really productive for us. I believe that this step will allow the Glare
project to concentrate on feature development and move forward faster.
Having the independent service also removes inconsistencies in
understanding what Glance project is: it seems that a single project cannot
own two different APIs with partially overlapping functionality. So with
the separation of Glare into a new project, Glance may continue its work on
the OpenStack Images API, while Glare will become the reference
implementation of the new OpenStack Artifacts API.

Nevertheless, Glare team would like to continue to collaborate with the
Glance team in a new - cross-project - format. We still have lots in
common, both in code and usage scenarios, so we are looking forward for
fruitful work with the rest of the Glance team. Those of you guys who are
interested in Glare and the future of Artifacts API are also welcome to
join the Glare team: we have a lot of really exciting tasks and will always
welcome new members.
Meanwhile, despite the fact that my focus will be on the new project, I
will continue to be part of the Glance team and for sure I'm going to
contribute in Glance, because I am interested in this project and want to
help it be successful.

We'll have the formal patches pushed to project-config earlier next week,
appropriate repositories, wiki and launchpad space will be created soon as
well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC
Mondays in #openstack-meeting-alt, it will just become a Glare project
meeting instead of a Glare sub-team meeting. Please feel free to join!

Best regards,
Mikhail Fedosin

P.S. For those of you who may be curious on the project name. We'll still
be called "Glare", but since we are on our own now this acronym becomes
recursive: GLARE now stands for "GLare Artifact REpository" :)
__
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