121 lines
6.5 KiB
Plaintext
121 lines
6.5 KiB
Plaintext
I would like to serve the community on the Technical Committee again.
|
|
|
|
For those of you who don't know me:
|
|
|
|
* I've served on the TC since it was the PPB.
|
|
|
|
* I founded and am past-PTL of OpenStack Infra.
|
|
|
|
* I also serve on the OpenStack Board of Directors as an Individual Member,
|
|
which is a position I've held since the formation of the Foundation.
|
|
|
|
Our culture and our commonality define us and draw us together, and that's
|
|
a good thing. We are one of the world's most successful Open Source projects.
|
|
The reason we're so successful is that we've always valued the we over the I.
|
|
We've always made choices that maxmize our ability to work with each other,
|
|
even if those choices might dimish the ability of some 'Brilliant Jerk' to
|
|
amaze us with their brilliance and just how big of a jerk they can be.
|
|
|
|
We should continue to hold strong to our idea of an environment where we're
|
|
all equal, where we can all work together regardless of background and where
|
|
collaboration is valued in its own right.
|
|
|
|
** OpenStack is One Project. **
|
|
|
|
Together we are much greater than the sum of our parts. It's vital that we
|
|
all understand that and actively look for ways to work together. It's hard,
|
|
of course. It's much easier to hunker down with a few close friends and shut
|
|
out all the noise as distraction. However, our primary advantage is that there
|
|
are a lot of us, and that we work together. The world is replete with projects
|
|
that are tightly controlled by a single person or a single company. We're
|
|
different, and it can give us strength. But it will only be a strength when
|
|
we all pull together and actively look for ways in which we can align with each
|
|
other, rather than looking for legalistic lists of ways in which we are
|
|
required to.
|
|
|
|
As our community is one of our greatest strengths, we need to become better
|
|
at being steadfast in our adherance to each other. When our friends get tired
|
|
and decide that all of this community crap is too hard, we need to provide
|
|
them support and help them to understand that not only is the community part
|
|
not a waste of time, it is, in fact, one of the most important aspects of
|
|
who we are.
|
|
|
|
** OpenStack delivers computers via an API, not VMs. **
|
|
|
|
Any positioning that our primary unit of operation is a VM is antiquated and
|
|
wrong. Bare metal, VMs and Containers are all essential building blocks - and
|
|
more importantly each of those being able to exist in a shared networking
|
|
context able to access the same storage resources is the ballgame. Any time
|
|
any part of our community wants to suggest that one of the three have primacy
|
|
over the others, we need to lovingly but firmly put our foot down and stand up
|
|
for our users.
|
|
|
|
We are not in competition with Kubernetes, Mesos or Docker. They're all
|
|
wonderful projects that solve problems for their users. All three of them
|
|
need to run on an Infrastructure. We should be the friendliest Infrastructure
|
|
for them.
|
|
|
|
** Success is defined by empowering our Users to solve their problems. **
|
|
|
|
OpenStack has IPv6 support. None of the closed-source Public Clouds do. We
|
|
should be more proud of that. OpenStack can give you a direct L2 IP that
|
|
isn't forced to pass through a NAT layer. None of the closed-source Public
|
|
Clouds can do that. Oracle just annouced that as an "exciting" thing that
|
|
would set their new Public Cloud apart. It's not exciting, it's basic
|
|
functionality that the other clouds lack, and they're late to the party. We've
|
|
had it for years, and we should be proud of that. We should not chase
|
|
mediocrity by accepting the premise that the feature definitions in a set of
|
|
existing closed-source Public Clouds are the gospel. We should instead empower
|
|
our end-users by putting the tools of computing that they actually want in
|
|
their hands, not just the tools someone else thinks they should want.
|
|
|
|
NAT is a hack, it's not a feature. We should treat it as the lame second-class
|
|
citizen it truly is, and we should make all the other clouds who are not us
|
|
ashamed that it's the only crappy networking they give their users. We should
|
|
continue to love our users.
|
|
|
|
** The world is a really big place with a bunch of really wonderful people. **
|
|
|
|
We have OpenStack Public Clouds all over the world, in more geographical
|
|
locations than any of the closed-source Public Clouds. We should all be proud
|
|
of that. There is not a US-centric single giant OpenStack Public Cloud ...
|
|
but that's a good thing, not a failure. Single clouds are single points of
|
|
failure, both from a technology standpoint and from a 'random executive has
|
|
an agenda' standpoint. An ecosystem of clouds running the same software but
|
|
run by different operators with different needs and goals is an ecosystem
|
|
we should all be proud of - and we can be proud of that today.
|
|
|
|
We have grassroots OpenStack communities world-wide full of amazing people.
|
|
We have people all over the world who are solving problems with OpenStack.
|
|
We should all be proud of that.
|
|
|
|
** There are still plenty of challenges ahead of us. **
|
|
|
|
The end user experience with OpenStack is scattered and deployer decisions
|
|
leak through APIs in too many places. We can and should fix that.
|
|
|
|
Even though we've spent years working on consolidation, we still have a
|
|
fragmented Operations story. It turns out there are a considerable number
|
|
of OpenStack clouds out there being run by teams of 3-4 people - but our
|
|
project organizational structure lends itself to assuming that cloud operators
|
|
will have a team-per-service. Having an operational team per OpenStack service
|
|
might be a choice some of the largest Operators make - but even then it's
|
|
an exceptionally wasteful model and should not be what we assume is the norm.
|
|
We can and should continue to aggressively improve the consistency of
|
|
experience for our Operators in addition to our End Users.
|
|
|
|
The world is not just written in Python. The time has come for us to develop
|
|
a legitimate story about what non-Python API services look like in an OpenStack
|
|
context. However, our community, its ability to collaborate effectively, our
|
|
Operators and our End Users are all more important than any individual's
|
|
personal preferences. Accordingly, our exploration of new options
|
|
must be done in the context of our existing users and projects. We already
|
|
have risen to an exceptionally difficult challenge of balancing stable
|
|
releases AND continuous delivery as equally important deliery vehicles. We
|
|
cannot accept new service languges into the fold until both delivery use cases
|
|
have compelling stories, else we risk regressing on the progress we've made in
|
|
this space so far.
|
|
|
|
We have a lot of work to do, but we can do it if we work together. I'd like to
|
|
continue helping, and will do everything I can to ensure that we succeed.
|