Confirmed.
On 10/04/2013 11:14 AM, Monty Taylor wrote:
Hi all!
I would like to continue serving the project on the OpenStack TC.
Background
----------
I've been with this bad boy since before day 1, and you can pretty much
blame me for trunk gating. You can also blame me for the bzr days - so
I'm not going to try to claim that I'm always right. :) I started and
until yesterday have been the PTL of the OpenStack Infrastructure team.
During my tenure there, we have grown what is quite possibly one of the
largest elastic build farms dedicated to a single project anywhere. More
importantly than large though, we've spent the effort to make as much of
our ops work as is possible completely open and able to receive changes
via code review in the exact same manner as the OpenStack projects
themselves.
The OpenStack Infrastructure system themselves are a scalable
application that runs across two clouds. This means that I am, as part
of that team, a very large user of OpenStack, which I believe gives me
an excellent perspective on what users of OpenStack might want. (hint:
vendor differences in how I get a sane hostname on a system I'm spinning
up - not what I want)
I work a LOT on cross-project coordination, compatibility and
automation. I have commits in every single OpenStack repo. In addition
to infra, have worked on pbr, hacking, openstack/requirements and
oslo.sphinx. I helped battle this cycle's setuptools/distribute re-merge
and ensuing upgrade nightmare. I landed patches in tox upstream to allow
us to skip the costly sdist step and use setup.py develop directly in
the virtualenv.
I'm also one of the only people who can have a conversation with ttx
about how our version numbers work and understand every nuance. I wrote
the code in pbr that encodes the design inside of ttx's brain.
Adjacent to OpenStack, I've managed to convince HP to fund me and a
group of merry troublemakers to work on OpenStack. One of the things
that has sprung from that is the TripleO project. I can't take credit
for any of the actual code there, but this is a TC candidacy, not a
developer cadidacy, and I think a large portion of being on the TC is
being able to steward the success of something both with and without
directly coding on it yourself.
I'm also a member of the Python Software Foundation and have been
working hard this cycle to start to align and integrate better with what
upstream Python do. Despite our intent to be good python people, it
turns out we do a bunch of things quite differently. Over time, I think
it would be better for those differences to decrease. I'm currently
working on writing my first PEP.
Platform
--------
The following was said to me on IRC a couple of day ago. It was not
meant as a compliment, but I will take it as one, and I think it quite
explicitly sums up why I should be on the TC:
mordred: it is infact you who are thinking narrowly *only* considering
openstack's goals
I believe that OpenStack is "One Project". I believe it is in our best
interest to be one. I believe that the more we work together across the
projects, the more better OpenStack will be.
As a TC member, I will continue to strive to enhance the view that
OpenStack itself is an important thing and it not just a loose
confederation of friendly projects.
I have an expansive view of the scope of OpenStack. I do not think that
'pure IaaS' as a limiting factor in the definition serves or will serve
any of our users. I think that instead of trying to come up with random
or theoretical labels and then keeping ourselves inside of the
pre-defined label, we should focus on writing software that solves
problems for users. trove and savana are great examples of this. As a
user, I want to store my data in a database, and I want to run some
map-reduce work. I'm not interested in figuring out the best way to
administer a MySQL instance inside of a VM. So, as a user, a database
service helps me write scalable cloud-based applications, and having it
be part of OpenStack means I can write that scalable cloud-based
applications that span multiple clouds.
As a TC member, I will continue to support a viewpoint that a consistent
set of features across clouds is important to a user, and the more
features there are that the user can count on to be in all of the
OpenStack clouds, the better the user experience will be.
I believe that the users of clouds are our users, not just the deployers
of clouds. In fact, if I have to choose between the desires of the users
of clouds and the desires of deployers of clouds, I will choose in favor
of the users of clouds.
As a TC member, I will strive to consider the needs of the end users in
discussions we have about coordinated choices and overall shape of
OpenStack.
Lastly, as a person who only considers OpenStack's goals and does not
have a direct affiliation with any of the individual projects, I believe
I'm in a good position to mediate issues between projects should they
arise. Thus far, I do not believe that the TC has had to act in that
capacity, but ultimately it is one of the things we can be called upon
to do.
As a TC member, I will place OpenStack's interests over the interests of
any individual project if a conflict between the project and OpenStack,
or a project with another project should a arise.
Thank you for reading all of these words, and thank you for the trust
you've placed in me as a TC member so far.
Monty
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
