diff --git a/candidates/train/TC/flwang@catalyst.net.nz b/candidates/train/TC/flwang@catalyst.net.nz new file mode 100644 index 00000000..a1215e2f --- /dev/null +++ b/candidates/train/TC/flwang@catalyst.net.nz @@ -0,0 +1,73 @@ +Hi everyone, + +I'm announcing my candidacy for a position on the OpenStack Technical Committee. +For those of you who don't know me yet, I'm Feilong Wang, currently +working for Catalyst Cloud as head of R&D. Catalyst Cloud is a public +cloud running on OpenStack based in New Zealand, before that I worked for IBM +System & Technology Lab for OpenStack upstream work. As for OpenStack upstream, +now I'm a core contributor of OpenStack Magnum and actively involve the +integration between OpenStack and Kubernetes. Besides, I was serving as the +PTL of Zaqar (OpenStack Messaging Service) for years. Before that, I was +mainly working for Glance (OpenStack Image Service) as a core reviewer since +Folsom 2012. + +In my opinion, currently the role of the TC is more important than ever. Some +large companies already downsized their investment for OpenStack or switching +their focus to containers/k8s, but meanwhile many companies from APAC, +especially China, are heavily investing OpenStack. Although it's a pain to lose +great contributors, the companies having real requirements for OpenStack are kept. +It's a good time for us to think about how to define/care OpenStack, for whom +we're building the software and how to build a collaborative/integrated community. + +As a TC member I want to bring focus in below areas: + +#1 Integration and Collaboration + +As a distributed cloud platform, it's good to decouple different services to +make each service do one thing well. However, seems most of projects are solely +focusing on their own offering and not enough projects are paying attention to +the global impact. I would like to push a more tighter collaboration between +projects and obviously it will make the integration more easier and efficient. +Operators should expect different projects can work together smoothly just like +they're different parts within one project. As a maintainer of a public cloud +running on OpenStack, I know the pain of our ops, when they try to migrate a +service or adding a new service in existing cluster. So I'd like to see more +interlocks between PTL and TC members to understand the gaps and fill the gaps. + +#2 Users & Operators + +Listen closely to the voice of users and operators and this pretty much align +with the mission of OpenStack as below. + +"To produce the ubiquitous Open Source Cloud Computing platform that will meet +the needs of public and private clouds regardless of size, by being simple to +implement and massively scalable." + +To implement a useful, stable cloud platform, we can't work behind closed +doors, but closely work with the user and operator community. As far as I know, +except the user survey, we don't have more formal process/approach to collect +the feedback from our users and operators, though the operators mailing list +and some random forum sessions at OpenStack summit are helpful. And IMHO, +currently we’re mixing feedback collected from different perspectives. For +example, most of the feedback from operators are how to easily deploy/manage +the cloud. But the tenant user/developers' requirements are more related to +functions, UX, etc. I can see we have put a lot of effort to address the pain +of operators, but obviously, we do also need more work to make the tenant +users/developer’s life easier. + +#3 Better UX + +This is the tiny part sometimes skipped by us. But I think it's important for +us to put effort on. For example, we can release a docker image including all +our openstack clients, so user don't have to deal with python depedencies. +Another example is enforcing restricted API consistency across different +services. + + +It would be an honor to be member of your technical committee. Thanks for your +consideration! + +-- +Feilong Wang + +