Add Mohamemd Naser to TC
Change-Id: I5e62f35e63c932e97e4bde340a02c0807a58ce43
This commit is contained in:
parent
8259c8fc59
commit
44f0b513e7
61
candidates/victoria/TC/mnaser@vexxhost.com
Normal file
61
candidates/victoria/TC/mnaser@vexxhost.com
Normal file
@ -0,0 +1,61 @@
|
||||
Hi everyone,
|
||||
|
||||
I want to run again for the OpenStack technical committee for the upcoming cycle.
|
||||
|
||||
I have been a long time operator of OpenStack with a focus on never using a
|
||||
local for, which has resulted in my involvement with many different projects
|
||||
by making quality-of-life improvements for these services that can help other
|
||||
deployers.
|
||||
|
||||
I've contributed and worked with different sizes of teams inside OpenStack.
|
||||
From our big projects such as Nova to projects providing specific services
|
||||
such as Magnum and pretty much most deployments tools at this point.
|
||||
|
||||
On the operator side, I've helped run one of the longest-running OpenStack
|
||||
public clouds and many private clouds. I've also interacted with many other
|
||||
OpenStack operators that are not as involved in our community, which gives me
|
||||
a significant exposure to our operator story and what that looks like outside
|
||||
our community of known operators.
|
||||
|
||||
I believe it's time now for me to start driving significant changes in our
|
||||
community to simplify the operator experience, and I think that should start
|
||||
from the technical committee. We're seeing the world evolve around us with
|
||||
new technologies, but we've remained relatively stable and stuck to
|
||||
our "known and trusted" stack.
|
||||
|
||||
Operators have historically had a lot of frustrations with systems like
|
||||
RabbitMQ and their clustering issues, which end up making the OpenStack
|
||||
experience disappointing. There are many new ways of doing RPC, which we can
|
||||
leverage and help make it even easier to run OpenStack (things such as gRPC).
|
||||
|
||||
We've also had a history of making it complicated to use containers to deploy
|
||||
OpenStack and historically refused to ship "official" containers. The OpenDev
|
||||
community has built our a step of tooling that can allow us to ship containers
|
||||
very quickly, with nothing more than a well written bindep.txt file and a
|
||||
simple multi-stage build. It's about time that we start having official images
|
||||
and easy ways to deploy OpenStack to reduce those barriers.
|
||||
|
||||
We define OpenStack as a "cloud operating system." We struggle to deliver much
|
||||
more than the essential infrastructure components. The drive behind OpenStack
|
||||
was to allow people to get more than the necessary infrastructure components.
|
||||
Still, large amounts of different efforts lead us into complicated ways of having
|
||||
to wrangle VMs to run services.
|
||||
|
||||
With popular container orchestrators and schedulers, OpenStack has a perfect
|
||||
platform to be able to launch those services. By setting up a proper framework,
|
||||
we can start delivering many services such as database as a service, memory store
|
||||
as a service, and so much more by building out Kubernetes operators. It also
|
||||
opens up a whole domain of possible contributors that can use those operators
|
||||
without OpenStack.
|
||||
|
||||
In closing, I don't expect everyone to agree with all the different ideas I'm
|
||||
putting out. We may only drive just a few of them, or maybe none of them.
|
||||
However, I want to convince you that we need to change. I can understand they
|
||||
sound like big leaps, and they may seem uncomfortable. However, they are
|
||||
genuinely some of the things we need to do to continue to be relevant and put
|
||||
us at the leading edge of technology like we used to be years ago.
|
||||
|
||||
Thank you for reading this.
|
||||
|
||||
Regards,
|
||||
Mohammed
|
Loading…
x
Reference in New Issue
Block a user