election/candidates/newton/TC/ed_leafe.txt
EdLeafe 3f944dc4c5 Adding Ed Leafe candidacy for TC
Change-Id: I962f30d8c119e21a31fa81ebba6234c64826d2b0
2016-03-29 14:08:24 +00:00

67 lines
3.7 KiB
Plaintext

Greetings!
I am announcing my candidacy for the OpenStack Technical Committee. As a
long-time developer, I have been part of projects that have succeeded and
others that have not; in either event, I always learned something to apply to
the next endeavor. I would like to use that experience to help guide OpenStack
forward as part of the TC.
For those who may not know me, my name is Ed Leafe (edleafe on IRC), and I have
been involved in OpenStack since the very beginning as part of the original
Nova team. I am currently employed by IBM to work 100% of my time on upstream
OpenStack, so I would have the freedom to devote as much time as needed to my
TC duties. I have been participating in the TC meetings for over a year, and am
familiar with the issues that come before it. I believe that I could contribute
a lot more as a member of the TC, and that's why I'm asking for your vote.
Here are some of the issues that I would like to focus on:
* Improving the user experience
Part of my current job is mentoring fellow IBMers who are new to OpenStack in
what it is, how to use it, etc. Have you ever tried to explain how to set up
and configure OpenStack to anyone? Then you know just how difficult it is.
That's one of the reasons I have been involved in groups such as the API
working group, the Nova API team, and the Configuration Option cleanup efforts,
as they represent places where OpenStack needs improvement. The recent efforts
to open dialogs between ops and devs is a great start, and I'd certainly like
to build on that. As a TC member, I would promote efforts to make all of
OpenStack more manageable to deploy and maintain, since the coolest software in
the world is useless if people can't get it running.
* Adding clarity to the Big Tent
Opening up the OpenStack world to projects without having to go through the
incubation and co-gating requirements was a huge step forward, but the feedback
I've heard about the resulting mix is that it is confusing. A few months ago
the TC added the 'starter-kit' tag to the baseline projects you would need to
install to get OpenStack running; this was a good first step, but I think we
need is a way to separate the "guts" of OpenStack from the parts that are built
on top of that core. Is a project part of OpenStack itself? Or is it something
that works on top of OpenStack (or any other cloud)? I'd like to see projects
clearly separated into those that provide 'cloud' services, and those that work
with those cloud pieces to make them easier to deploy/manage/report. Why is
this distinction important? Because I feel that OpenStack should only have a
single project for any particular service, and if someone has an idea for
making it better, they need to work with the existing project, not compete. But
in the world of projects built on top of OpenStack services, I say let's invite
competition! There doesn't have to be a single "winner", as these will more
likely tend to be solving particular use cases. Forcing these to be in a single
project usually results in bloated, inefficient code.
* Promoting consistency across OpenStack projects
There is some inconsistency within a single project like Nova, but when you
work with multiple projects, the inconsistencies are glaring. And while the TC
is not a strong-arm enforcer of standards, it does have considerable influence
on how projects evolve, and I would like to see the TC push harder at
establishing standards, as the API Working Group is doing, and then encouraging
adoption of those standards across projects. The sanity of our operators is at
stake!
In closing, I'd like to say that anyone who cares enough about OpenStack to
want to be a part of the TC will certainly be worth your vote. I hope that I've
presented enough to earn your vote.