Open Stack

On 11/09/2015 09:46 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> I do wonder what the cause of varying quality is in the distros. I do
>> understand that some distros aren't licensing the test suite. But they
>> are all building from the same upstream.
> Except that they all use significant (and different) patchsets on top of
> that "same upstream". Ubuntu for example currently carries 69 patches on
> top of OpenJDK 7 source.
>
I can't speak explicitly for Ubuntu, but this is the norm for anything 
from a Distro;  they pick a version  for the LTS release and then choose 
the patches to continue to apply to that version. Red Hat does this with 
OpenStack, as well as OpenJDK and the Kernel.  The same is true of 
Python, too.

Java is a different language than Python.  I understand that many people 
dislike it for verbosity, its proprietary history, and so forth.  But 
with the OpenJDK, we have the same rules for releasing it as we do for 
Python, Ruby, Perl, Common Lisp, COBOL, Fortran, Ada, C++, and Go.  Hope 
to add Rust to that litany, soon, too.

I personally like Java, but feel like we should focus on limiting the 
number of languages we need to understand in order to Do OpenStack 
development.  I personally find Python annoying since I like type 
safety, but I've come to understand it.  The fact that Puppet already 
makes us jump to Ruby already makes it hard.  One reason I prefer the 
recent inroads by Ansible is that it lets me stick to a single language 
for the business logic.  It has nothing to do with the relative 
technical merits of Python versus Ruby.

For the most part, the third party tools we've had to integrate have 
been native apps, at least on the Keystone side;  LDAP, Database, and 
Memcache are all native for performance reasons.  The Dogpile 
abstraction would allow us to do Cassandra, but that never materialized.

As an example: I've been pointing out that we should be defaulting to  
Dogtag for Certificates.  Dogtag is a Java server app.  This is due to 
its long history as an OpenSource CA with very demanding deployments 
hardening it.  However, I don't think it should be the CA abstraction 
for OpenStack.  I would recommend a Native tool, Certmonger, with a 
mechanism that can be extended by Python.  This would allow for a native 
python implementation, or any other that actual deployments would chose 
to use, as the CA implementation.

Let's keep the toolchain understandable, but for the right reasons.