[openstack-dev] [all] [dlm] Zookeeper and openjdk, mythbusted

Joshua Harlow harlowja at fastmail.com
Mon Nov 9 20:25:10 UTC 2015


Adam Young wrote:
> 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.

+1

If you haven't looked at how many patches some RHEL packages have you 
might want to, 69 patches is nothing from what I have seen...

For example (rpm detailing program here):

https://gist.github.com/harlowja/9b443d1af13a57a48f4f

$ python rpm-info.py 
"http://vault.centos.org/6.5/os/Source/SPackages/libvirt-0.10.2-29.el6.src.rpm" 
http://vault.centos.org/6.5/os/Source/SPackages/qemu-kvm-0.12.1.2-2.415.el6.src.rpm

--------------------------
Getting details for 2 rpms
--------------------------
Downloading: 
http://vault.centos.org/6.5/os/Source/SPackages/libvirt-0.10.2-29.el6.src.rpm
[################################] 22378/22378 - 00:00:02
Downloading: 
http://vault.centos.org/6.5/os/Source/SPackages/qemu-kvm-0.12.1.2-2.415.el6.src.rpm
[################################] 9601/9601 - 00:00:01

-------------
Gathered info
-------------
+-------------------------------------+-----------+
| Filename                            |   Patches |
+=====================================+===========+
| libvirt-0.10.2-29.el6.src.rpm       |       538 |
+-------------------------------------+-----------+
| qemu-kvm-0.12.1.2-2.415.el6.src.rpm |      3497 |
+-------------------------------------+-----------+

IMHO at least java has a TCK, does libvirt have one or KVM..., because 
with the number of patches listed above, who knows exactly what version 
of libvirt or qemu is really running (the version number IMHO makes less 
sense when there are 3400+ patches).

>
> 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.
>
>
>
>
>
>
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list