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