Open Stack

+1. very good discussion.
________________________________________
From: Sean Dague [sean at dague.net]
Sent: Wednesday, May 25, 2016 3:48 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

I've been watching the threads, trying to digest, and find the way's
this is getting sliced doesn't quite slice the way I've been thinking
about it. (which might just means I've been thinking about it wrong).
However, here is my current set of thoughts on things.

1. Should OpenStack be open to more languages?

I've long thought the answer should be yes. Especially if it means we
end up with keystonemiddleware, keystoneauth, oslo.config in other
languages that let us share elements of infrastructure pretty
seamlessly. The OpenStack model of building services that register in a
service catalog and use common tokens for permissions through a bunch of
services is quite valuable. There are definitely people that have Java
applications that fit into the OpenStack model, but have no place to
collaborate on them.

(Note: nothing about the current proposal goes anywhere near this)

2. Is Go a "good" language to add to the community?

Here I am far more mixed. In programming language time, Go is super new.
It is roughly the same age as the OpenStack project. The idea that Go and
Python programmers overlap seems to be because some shops that used
to do a lot in Python, now do some things in Go.

But when compared to other languages in our bag, Javascript, Bash. These
are things that go back 2 decades. Unless you have avoided Linux or the
Web successfully for 2 decades, you've done these in some form. Maybe
not being an expert, but there is vestigial bits of knowledge there. So
they *are* different. In the same way that C or Java are different, for
having age. The likelihood of finding community members than know Python
+ one of these is actually *way* higher than Python + Go, just based on
duration of existence. In a decade that probably won't be true.

3. Are there performance problems where python really can't get there?

This seems like a pretty clear "yes". It shouldn't be surprising. Python
has no jit (yes there is pypy, but it's compat story isn't here). There
is a reason a bunch of python libs have native components for speed -
numpy, lxml, cryptography, even yaml throws a warning that you should
really compile the native version for performance when there is full
python fallback.

The Swift team did a very good job demonstrating where these issues are
with trying to get raw disk IO. It was a great analysis, and kudos to
that team for looking at so many angles here.

4. Do we want to be in the business of building data plane services that
will all run into python limitations, and will all need to be rewritten
in another language?

This is a slightly different spin on the question Thierry is asking.

Control Plane services are very unlikely to ever hit a scaling concern
where rewriting the service in another language is needed for
performance issues. These are orchestrators, and the time spent in them
is vastly less than the operations they trigger (start a vm, configure a
switch, boot a database server). There was a whole lot of talk in the
threads of "well that's not innovative, no one will want to do just
that", which seems weird, because that's most of OpenStack. And it's
pretty much where all the effort in the containers space is right now,
with a new container fleet manager every couple of weeks. So thinking
that this is a boring problem no one wants to solve, doesn't hold water
with me.

Data Plane services seem like they will all end up in the boat of
"python is not fast enough". Be it serving data from disk, mass DNS
transfers, time series database, message queues. They will all
eventually hit the python wall. Swift hit it first because of the
maturity of the project and they are now focused on this kind of
optimization, as that's what their user base demands. However I think
all other data plane services will hit this as well.

Glance (which is partially a data plane service) did hit this limit, and
the way it is largely mitigated by folks is by using Ceph and exposing that
directly to Nova so now Glance is only in the location game and metadata
game, and Ceph is in the data plane game.

When it comes to doing data plan services in OpenStack, I'm quite mixed.
The technology concerns for data plane
services are quite different. All the control plane services kind of
look and feel the same. An API + worker model, a DB for state, message
passing / rpc to put work to the workers. This is a common pattern and
is something which even for all the project differences, does end up
kind of common between parts. Projects that follow this model are
debuggable as a group not too badly.

5. Where does Swift fit?

This I think has always been a tension point in the community (at least
since I joined in 2012). Swift is an original service of OpenStack, as
it started as Swift and Nova. But they were very different things. Swift
is a data service, Nova was a control plane. Much of what is now
OpenStack is Nova derivative in some way (some times direct extractions
(Glance, Cinder, Ironic), some times convergent paths (Neutron). And
then with that many examples, lots of other things built in similar ways.

Swift doesn't use common oslo components. That actually makes debugging
it quite different compared to the rest of OpenStack. The lack of
oslo.log means structured JSON log messages to Elastic Search, are not
a thing. Swift has a very different model in it's service split.
Swift doesn't use global requirements. Swift ensures it can run without
Keystone, because their goal is Swift everywhere, whether or not it's
part of the rest of OpenStack.

These are all fine goals, but they definitely have led to tensions on
all sides.

And I think part of the question is "are these tensions that need to be
solved" or "is this data that this thing is different". Which isn't to
say that Swift is bad, it's just definitively different than much of the
ecosystem. Maybe Swift should be graduated beyond OpenStack, because
it's scope cross cuts much differently. Ceph isn't part of OpenStack,
but it's in 50% of installs. libvirt isn't part of OpenStack, but it's
in 90% of installs. And in both of those cases OpenStack is one of the
biggest drivers of their use.

Which, gets contentious because people feel like this is kicking
something out. And that I can understand. There is a lot of emotion
wrapped up in labels and who gets to be on the the OpenStack home page.
I wish there wasn't. Good software should get deployed because it is
good and solves a need, not because of labels. I'm not sure Swift users
really care that Swift is OpenStack. They care that Swift is Swift. And
Swift being Swift, but not being OpenStack would open up degrees of
freedom in Swift being more Swift centric without the same friction
from the rest of of the ecosystem.

...

Honestly, we probably need to just address #5 first and foremost. It's
been dodged around for a long time, the tensions haven't gotten any better.
We have just decided the standoff around Swift being different is going
to remain.
The global requirements proposal is a good example of that
https://review.openstack.org/#/c/88736/ - 434 revisions later.

>From that we have one data point on #4. Are we going to be building a
set of data plane services that can't be in python? If Swift wasn't the
leading
example here would we be having the conversation at all?

        -Sean

--
Sean Dague
http://dague.net


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev