Open Stack

> On 05 Aug 2016, at 01:02, Jay Pipes <jaypipes at gmail.com> 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 +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.
> 
> 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 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 metadata/registry API...
> 
> -jay
> 
>> 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-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