[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