Open Stack

I like the idea for which things to prune. Sounds reasonable to me.

For the most part they were technological implementations around a social/governance problem. They can't be pruned until that is resolved.

I was pushed that way too for my issues and rather then spawn a new project, I just gave up on creating a new project. So it has gone both ways. Either new projects sprang up or use cases were dropped.

Either way, the governence/social aspect needs solving. I still think that is the TC's job to solve.

How?

Thanks,
Kevin
________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Monday, January 21, 2019 1:15 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: [tc] [all] Please help verify the role of the TC

On 18/01/19 1:57 AM, Doug Hellmann wrote:
> Chris Dent <cdent+os at anticdent.org> writes:
>
>> On Thu, 17 Jan 2019, Zane Bitter wrote:
>>
>>>> Thus: What if the TC and PTLs were the same thing? Would it become
>>>> more obvious that there's too much in play to make progress in a
>>>> unified direction (on the thing called OpenStack), leading us to
>>>> choose less to do, and choose more consistency and actionable
>>>> leadership? And would it enable some power to execute on that
>>>> leadership.
>>>
>>> I'm not sure we need to speculate, because as you know the TC and PTLs
>>> literally were the same thing prior to 2014-ish. My recollection is that
>>> there were pluses and minuses, but on the whole I don't think it had the
>>> effect you're suggesting it might.
>>
>> Part and parcel of what I'm suggesting is that less stuff would be
>> considered in the domain of "what do we do?" such that the tyranny of
>> the old/existing projects that you describe is a feature not a bug,
>> as an in-built constraint.
>>
>> It's not a future I really like, but it is one strategy for enabling
>> moving in one direction: cut some stuff. Stop letting so many
>> flowers bloom.
>>
>> Letting those flowers bloom is in the camp of "contribution in,
>> all its many and diverse forms".
>
> What would you prune?

As a frequent and loud advocate for allowing all of those new projects
in, I feel like this is a good moment to take stock and consider whether
I might have been mistaken to do so, if only to reassure other folks
that they can attempt to answer the question without me yelling at them ;)

I do think Chris offers a valid line of enquiry, even though (like him)
I don't really like the future that it leads to.

I would identify two classes of project that we might consider for
pruning in this scenario.

* There are a number of projects that in a perfect world would arguably
be just a feature rather than a separate service. The general pattern
was usually that they had to do something on the compute node that was
easier *socially* to get implemented in a separate project; often they
also had to do something in the control plane that could potentially
have been handled by a combination of other services, but again it was
easier to throw that code into the project too rather than force
multiple hard dependencies on cloud operators that wanted the feature.
Pruning these projects could in theory lead to a more technically
justifiable design for the features they support, and help build a
critical mass of users for the more generic control plane services (I'm
thinking of e.g. Mistral) that might have been used by multiple
features, instead of being effectively reimplemented in various
hard-coded configurations by multiple projects.

* There are a number of projects that proceeded a long way down the path
despite containing fundamental design flaws due to workarounds for
missing features in services they depended on. In at least one case,
multiple companies toiled away diligently for years taking over from one
another as each, successively, ran out of runway while still waiting for
features to build a sustainable design on top of. In the meantime, we
added them to OpenStack and encouraged/demanded that they spend a good
fraction of their time and effort on not breaking existing users from
release to release. Pruning these projects might folks interested in
them the opportunity to forego backwards-compatibility in favour of
ensuring the features they need are present first, and then rapidly
iterating toward a long-term sustainable design.


The problem I still see with this it is that we made all of these
decisions for good reasons, which were about getting feedback. We
encouraged projects to guarantee backwards compatibility because that's
needed to get users to use it for real and give feedback. We added
projects that depended on missing features in part to provide feedback
to other teams on what features were needed. We added projects that were
really features because users needed those features, and there was no
other way to hear their feedback.

Clearly in some cases, that was not enough. But it's very hard to see
how we can get the features users want done with even _less_ feedback.

It could be that we don't actually want to get those features done, but
interestingly (and slightly surprisingly) during the technical vision
exercise nobody suggested we delete every design goal except for "Basic
Physical Data Center Management". (If you *do* think we should do that,
please propose it as a patch so we can discuss it.) It seems like we all
actually kinda agree on where we want to get, but some of the critical
paths to getting there may be blocked by other priorities.

At this point I actually wouldn't be too unhappy to see a reset, where
we said OK we are not going to worry about this other stuff until we've
re-architected the building blocks to operate in such a way that they
can support all of the additional services we want. Especially if we had
a specific plan for prioritising those aspects. But how are we going to
get feedback on what exactly it is we need to do without folks in the
community building those additional services and features, and users
using them? That's not a rhetorical question; if you have ideas I'd like
to hear them.

cheers,
Zane.