Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev