93e2e60ec6
Text file with brief description of candidate. Change-Id: I258691325012ca55c23955718e9f1587fe166d2c
78 lines
5.2 KiB
Plaintext
78 lines
5.2 KiB
Plaintext
Hi everyone,
|
|
|
|
I would like to announce my candidacy for OpenStack Technical Committee member for
|
|
the upcoming term.
|
|
|
|
I am currently an offering manager for OpenStack initiatives at IBM and I have been
|
|
involved in the OpenStack community since 2013. I spend most of my time[1] in our
|
|
working groups including the Product, Enterprise, Application Ecosystem, and Operator
|
|
Tags team.. I have also spent a lot of talking with OpenStack users and organizations
|
|
that are new to open-source and OpenStack in order to help them with their journey into
|
|
becoming community members. The OpenStack project continues to gain adoption while also
|
|
expanding in scope with new projects and functionality. These changes continue to make
|
|
considering operator and user experience in strategic and architectural decisions ever
|
|
more critical. Furthermore, the TC itself is involved in a set of broad topics lately
|
|
(such as changing the mission statement, diversity, and mentoring to name a few) and
|
|
additional perspectives will be good for these discussions.
|
|
|
|
If elected to be a TC, I would like to focus/highlight on the topics outlined below:
|
|
* Revisit big-tent workflow for new projects.
|
|
- The big tent initiative has promoted faster and broader innovation inside
|
|
the OpenStack community and I believe we should reflect on its first year to
|
|
build a new set of best practices for both acceptance and on-boarding new
|
|
projects along with mechanisms to validate that new projects are continuing
|
|
to follow the four opens. What worked? What didn't? Should there be additional
|
|
criteria based on overall fit/need? And how can we improve this further?
|
|
|
|
* Promote a systems architecture point-of-view of the OpenStack cloud platform
|
|
- There are several initiatives under-way (with more to come) that can benefit
|
|
multiple OpenStack projects. Cross project specifications allow us to build best
|
|
practices and guidelines but they are currently treated as recommendations. If we
|
|
could develop a way to make some of the more critical needs a requirement vs.
|
|
recommendation then we could have a way to ensure that we have a way inside the
|
|
community to drive architectural changes, as necessary, for better system stability,
|
|
user experience, or performance. The other benefit would be to agree on common
|
|
needs (e.g. the quota service discussion happening right now, the online schema
|
|
migration work that has taken place in a lot of projects) and guide new projects
|
|
through adopting the changes as they start development rather than retrofit.
|
|
|
|
* Increase user and technical committee exchanges
|
|
- I would like to propose a regular cadence to discussions between the technical
|
|
and user committee members so that technical direction, and decision points, can
|
|
be shared and we could strengthen/expedite feedback from our user community into
|
|
process as needed. I have seen both parties appreciate the dialogue and find it
|
|
valuable, therefore I think anything that can strengthen this feedback loop is a
|
|
positive thing.
|
|
|
|
* Building an ecosystem for next-generation platforms
|
|
- Over the last couple of years there have been multiple complementary open-source
|
|
projects/technologies that are catering to similar application design patterns (Mesos,
|
|
k8s, Cloud Foundry, etc,). I believe projects such as Kuryr are doing a good job in
|
|
mapping OpenStack technologies like neutron to other ecosystems (e.g Docker libnetwork)
|
|
and we should continue to solicit more projects/activity that will help customers/users
|
|
build an internal platform that meets their objectives as they shift from traditional
|
|
applications to newer applications. In the end, we are all trying to meet user needs
|
|
and the answer probably lies in a complementary view of adjacent technologies versus
|
|
every need being implemented by a single platform. A successful approach to building
|
|
an ecosystem for OpenStack clouds could dramatically increase putting our code to work
|
|
through an even greater adoption rate and make OpenStack clouds viable for additional
|
|
workloads/use-cases.
|
|
|
|
My reason for focusing on these topics is based on my experience and background in the OpenStack
|
|
community. I am a core member of the Product working group[2], participate regularly in the
|
|
ops-tags-team[3], help with SuperuserTV[4], help with building the community-generated OpenStack
|
|
roadmap[5], and moderate sessions at ops-meetups.
|
|
|
|
I am passionate about the work our community produces and excited that it has found relevance for
|
|
so many people and organizations around the globe. I would like to continue to do work that
|
|
further strengthens the feedback loop between the developers and consumers of our open-source
|
|
cloud. I humbly ask for your vote to represent this need as a member of our OpenStack Technical
|
|
Committee.
|
|
|
|
|
|
[1] https://review.openstack.org/#/q/owner:ItzShamail%2540gmail.com
|
|
[2] https://wiki.openstack.org/wiki/ProductTeam
|
|
[3] https://review.openstack.org/#/q/project:openstack/ops-tags-team
|
|
[4] http://superuser.openstack.org/articles/section/superuser-tv
|
|
[5] http://www.openstack.org/software/roadmap/
|