[openstack-dev] [tc] [all] TC Report 18-26

Thierry Carrez thierry at openstack.org
Tue Jul 3 08:34:54 UTC 2018

Zane Bitter wrote:
>> [...]
>> I think if OpenStack wants to gain back some of the steam it had 
>> before, it needs to adjust to the new world it is living in. This means:
>>   * Consider abolishing the project walls. They are driving bad 
>> architecture (not intentionally but as a side affect of structure)
> In the spirit of cdent's blog post about random ideas: one idea I keep 
> coming back to (and it's been around for a while, I don't remember who 
> it first came from) is to start treating the compute node as a single 
> project (I guess the k8s equivalent would be a kubelet). Have a single 
> API - commands go in, events come out.

Right, that's what SIG Node in Kubernetes is focused on: optimize what 
ends up running on the Kubernetes node. That's where their goal-oriented 
team structure shines, and why I'd like us to start organizing work 
along those lines as well (rather than along code repository ownership 

> [...]
> We probably actually need two groups: one to think about the 
> architecture of the user experience of OpenStack, and one to think about 
> the internal architecture as a whole.
> I'd be very enthusiastic about the TC chartering some group to work on 
> this. It has worried me for a long time that there is nobody designing 
> OpenStack as an whole; design is done at the level of individual 
> projects, and OpenStack is an ad-hoc collection of what they produce. 
> Unfortunately we did have an Architecture Working Group for a while (in 
> the sense of the second definition above), and it fizzled out because 
> there weren't enough people with enough time to work on it. Until we can 
> identify at least a theoretical reason why a new effort would be more 
> successful, I don't think there is going to be any appetite for trying 
> again.

I agree. As one of the very few people that showed up to try to drive 
this working group, I could see that the people calling for more 
architectural up-front design are generally not the people showing up to 
help drive it. Because the reality of that work is not about having good 
ideas -- "put me in charge and I'll fix everything". It's about taking 
the time to document it, advocate for it, and yes, drive it and 
implement it across project team boundaries. It's a lot more work than 
posting a good idea on an email thread wondering why nobody else is 
doing it.

Another thing we need to keep in mind is that OpenStack has a lot of 
successful users, and IMHO we can't afford to break them. Proposing 
incremental, backward-compatible change is therefore more productive 
than talking about how you would design OpenStack if you started today.

Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list