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
