JPRT: Sun Hardware is so COOL!

JPRT: Sun Hardware is so COOL!

First, I am NOT a hardware geek, I'm a software developer. But I appreciate reliable hardware and when you can utilize the same hardware for multiple operating systems, that's versatile hardware!

A little over a year ago I started working on this internal project I eventually called JPRT. Yes, that's what I've been spending a great deal of my time for the last year. ;\^) It's 100% Java, but does use some shell scripts and executes some Unix utlities from Java. The development has all been done in NetBeans, starting with version 4 and currently I'm using 5.5beta2 (with the findbugs plugin, which I'll blog about soon). It's taken a little while to 'learn the NetBeans ropes', but overall it's been a pleasure, and I am addicted. Anyway, I started with an existing and very successful internal product called PRT that the HotSpot VM engineers had been using to help the developers in dealing with builds and tests on all the various platforms. So this JPRT system concept is not new, most of the credit for the idea goes to the PRT implementors, and the original IMGR tool that existed before PRT.

So what's the name stand for? I'm not sure anyone remembers now, but I'm using "JDK Performance Reliability Test"... but I think the P letter could also mean "Putback". But that doesn't matter much. Effectively it's a system that helps developers guarantee that changes made to the product builds on all platforms and is tested on all platforms (not full blown QA testing, but selected testing that provides a 'reliability' guarantee). And done prior to any putback or commit of the changes. It also guarantees that the source base is ALWAYS in a known 'good' build and test state. (I'll blog on the java.net site about the JPRT system in general and the specific trials and tribulations of being a JDK developer, JPRT is just part of the story. ;\^) [See http://weblogs.java.net/blog/kellyohair/archive/2006/09/jprt_buildtest.html].

When it came to ordering hardware for JPRT we went with 100% pure Sun hardware, using the Sun X64 hardware to run both the X86 and X64 OS's we needed. This turns out to be very handy, all rack mounted, 2 SPARC machines, and 6 X64 machines. We probably could have just used one SPARC box, but we wanted to make sure we had multiple machines so all platforms could be built in parallel. Also, when it comes time to troubleshoot hardware, there is nothing like having a clone handy to swap parts with. (And no, I didn't physically install the machines or bolt them to the rack, that was done by our mysterious and talented lab person, who must get very cold being in those machine rooms all hours of the day and night. Those labs are kind of creepy if you ask me.).

So we needed these 8 platforms:

  • Solaris 8 SPARC
  • Solaris 8 SPARCV9
  • Solaris 8 X86
  • Solaris 10 X64
  • Linux X86 (Redhat A.S. 2.1)
  • Linux X64 (SuSe 8 SP4)
  • Windows 2000 X86
  • Windows 2003 X64

We've had problems getting Solaris 8 X86 to install, so for now we are using Solaris 10 X86 (is anyone REALLY using Solaris 8 X86 out there?). And we discovered that the X64 machines didn't come with the hardware necessary to install them in the rack (silly for us to expect a rack mount machine to come with the hardware to put them in a rack. ;\^).

Many people don't realize that building products like the JDK often require the use of very old OS releases, so that the resulting built product is capable of running on the largest set of OS releases (the least common platform story). And that once a product is shipped being built on a platform, that build platform must be pretty much frozen and kept available for all future update and patch builds. So build platforms are typically old and don't go away for a long time.

I know I know, there are ways to run older OS's in things like XEN or VMware, and there are many cross compiler products out there, but sometimes it's just easier to simply have one machine per OS/arch. And a big issue is total turnaround time for the developer, the wall-clock time was critical, so as much as possible, we break up the tasks and do things in parallel. And often the fastest processor isn't as important as the speed of the disk, so when we pick out machines it usually isn't the latest and greatest. But this project will be looking at some alternatives in the future, but for now, I thought I'd share this 'all Sun Hardware' project. Not that we can't add non-Sun hardware, but it just looks so COOL when you see the rack of Sun equipment running Solaris, Linux, and Windows! ;\^)

The JPRT system (like it's parent PRT) accepts change submits from users, and creates jobs in a queue. Eventually as a job reaches the head of the queue, it bundles up the sources and sends them down a socket to each of the clients (in parallel). So all 8 Sun machines start grinding away building. Once the builds complete, tests are started. And if everything is successful, and the user has requested it, the changes will be putback to the parent source repository with detailed records. The job is then archived away. It currently only provides a set of command-line tools, but for developers that hasn't been an issue.

Sometimes a drawing helps. Here is a crude depiction of what the system looks like today:

It will probably change and morph over the years. Eventually we hope that this will feed into the more extensive testing grid and performance grid systems that the Quality and Performance teams have.

-kto

Comments:

Post a Comment:
Comments are closed for this entry.
About

Various blogs on JDK development procedures, including building, build infrastructure, testing, and source maintenance.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today