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.
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
