[openstack-dev] [tc] open question to the candidates

Clark Boylan cboylan at sapwetik.org
Mon Oct 3 23:20:55 UTC 2016


On Mon, Oct 3, 2016, at 08:30 AM, gordon chung wrote:
> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?

Yes, I think the TC should be a proactive committee. I think the
OpenStack wide goals work has been a good push towards being more
proactive. As for scope I believe the current process of soliciting
feedback from the community then picking a small number of achievable
goals to focus on per release cycle is a good place to start. Chances
are it won't be perfect, but if we don't try something progress can't be
made. Then in a cycle look back on what worked and what didn't and
refine the process.

Ideally OpenStack wide goals should affect the breadth of our projects
and users. Specifically goals like becoming python 3 compatible and
testing on python 3 are great. CPython 2 has a limited lifetime and
OpenStack (not just Nova, Glance, etc) needs to be planning ahead to
deal with this. It isn't something that can happen overnight and we
should agree on a common plan to address this so that we don't end up
with some projects doing Python 3 and others doing PyPy* to the
detriment of our developers and users.

Another example of a place where project wide goals make sense is in
ensuring that OpenStack runs and is tested on newer distro releases as
they become available. OpenStack isn't deployed in a vacuum and we
should do what we can to make sure that the barriers to deployment don't
begin at "can't deploy OpenStack on the distro most people are trying to
deploy OpenStack on". In the past we have done a reasonable job at
uplifting OpenStack onto new distro releases and making sure the tests
run properly. The recent Trusty to Xenial transition has been somewhat
painful though. Part of that is probably my fault, but we should stop
expecting magical gnomes to do all the work for OpenStack and call it
out as an explicit goal in the future for all of OpenStack.

As a user of OpenStack clouds I would also like to see more push for a
consistent experience as presented to our end users. Tons of work has
been done to make this much better than it was a few years ago, but
there is so much more we can do. It would make me so happy if we could
make OpenStack useable without knowledge of the underlying cloud
implementation choices. This actually ends up being problematic due to
many small issues so I am not sure if this makes sense as an OpenStack
wide goal, but it should illustrate the level at which I think the TC
should be proactive.

* I have nothing against PyPy and this shouldn't be interpreted as an
argument against using it beyond CPython 2's end of life, but I think
that we need to solve large scale problems like this consistently so
that developers, operators, and our users don't have to juggle a half
dozen toolsets to get anything done with OpenStack.

Hope this helps,
Clark



More information about the OpenStack-dev mailing list