[tc] [all] Please help verify the role of the TC

Chris Dent cdent+os at anticdent.org
Thu Jan 17 17:00:29 UTC 2019


On Thu, 17 Jan 2019, Doug Hellmann wrote:

[i wrote]:
>> 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?

I don't think it should be up to me to decide. That would be a thing
"we" (in whatever form) would decide.

But if pressed to make a list for the sake of conversation I would
endeavor to limit things based on a couple strawperson criteria
(below). As I said above I'm not clear that this is the right thing,
to do, but it is a potential strategy. Being included in the
examples below isn't a suggestion that the thing listed is no good,
or should not exist. Rather that it _might_ be healthier with a
boundary between it and OpenStack. A clear boundary could allow
these flowers to bloom nearby, as well as others.

Strategies to figure out what could be removed:

* Stuff that could be done via existing non-openstack tools or more
   generic tools that address cloudy-stuff in general. Much of the
   stuff in telemetry or orchestration would fit here and some
   utilities: Telemetry, Cloudkitty, Freezer, Heat, Karbor, Magnum,
   Monasca, Zun to name just some. If the remaining services are
   produced in a way that provides suitable observability, then tools
   like Prometheus, the ELK stack, what have you can play a big part
   and ansible, terraform, related friends can too.

* Deployment tooling (Tripleo, Kolla, Openstackansible, etc) and
   packaging. It all needs to exist, but it clouds the picture and
   direction of OpenStack, the thing you have once it is deployed or
   installed. In a very bad analogy: I make gabbi and I'm not
   responsible for it becoming an RPM, nor for maintaining pip which
   is used to install it, but RPMs and pip are very important.

   If we had a one-true-deployment tool, then having that in this new
   and smaller OpenStack could make sense, but if we want there to be
   many tools enabling them to be independent communities from each
   other could be refreshing.

Do I think this is a good idea? I don't know. It's just thinking out
loud with half-baked ideas for the sake of conversation with the
ever-optimistic hope that it might inspire an actually good idea.

Do I think something like this is likely to happen? Not really. Ship
sailed.

Could a hybrid that includes some of this happen? Potentially,
especially if the idea of top-level projects in the foundation
grows.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent


More information about the openstack-discuss mailing list