Open Stack

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.