Open Stack

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.Fox at 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 [ekuvaja at 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 <clint at fewbar.com> wrote:
> > Excerpts from Tim Bell's message of 2016-08-04 15:55:48 +0000:
> >>
> >> On 04 Aug 2016, at 17:27, Mikhail Fedosin
> <mfedosin at mirantis.com<mailto:mfedosin at 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 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev