Solaris JET

In the midsts of time when dinosaurs roamed the earth, I worked at Sun Microsystems in a number of roles. From manufacturing support through to client facing professional services, ending up as a subject matter expert for high availability and high end systems. The number of Sun systems that I’ve built will be astronomical and for anyone who knows me, it ended up being a passion; but as Scott McNealy used to say, also a ‘Pet Peeve’. Not that it was difficult; it was how multiple engineers could take the same specification for a system build and create entirely different end results. Not great when you want consistency and repeatability.

Scratching an itch

It wasn’t just me that was struggling with this problem, and through the thoughtfulness of one of our managers, a number of us were corralled into a meeting room. You all complain about the same problem; come up with a solution.

There were two of us for whom this was clearly a passion and by the end of the meeting, we’d kind of sorted out a blueprint that covered the requirements of the others and now just needed to deliver it.

Although not what we originally called it, the ‘JumpStart Enterprise Toolkit’ (JET) was born.

JumpStart

Solaris had an automated build facililty that could be triggered in the firmware - JumpStart; we used it to put systems on automatic test in the manufacturing lines. This was the 90’s; USB was still to be invented and not all devices had CD drives. Even if they did, the life expectancy of a CD in a manufacturing environment is shorter than the half-life of a helium-2 atom - something in the 10^-9 seconds range is about right.

In manufacturing it was pretty straight forward; the system did a network boot and then ran a pre-determined test suite, based on the hardware. This was hardware testing - checking all the expected components and additional cards were there and working. Not the infinite possibilities of customer and 3rd party applications.

The basic build technology was documented and supported by Sun, but it really required a customer to commit time and resources to set up, perfect and maintain. For a small business with one or two machines, not worth the time and effort - build things by hand.

Dot-Com Boom

With Sun being the darling hardware for the Dot-Com era and an internet presence being top priority, we started to see people embark on horizontal scaling. Kit was flowing out of manufacturing and customers were needing it built to their specification ’today’; not one or two machines, but in the 10’s and 100’s. Just how many copies of a Solaris CD does a field engineer need to have? For those that have been there - booting off a CD and answering the installation questions is a slow and tedious task at the best of times. When you’ve just had to physically rack 100 servers in a customer data centre the week before Christmas and they want them running ’now’, standing there even with a couple of CDs and monitors on trolleys isn’t a ‘happy place’.

JET

The basic premise of JET was to provide a template system; engineer fills in a text file with some simple options, all of the hard work to setup JumpStart is then done by scripts. Not all systems had graphical heads, so most of this was done on a serial console - it had to be text based at the very least. Set one system building, connect your laptop to the next on; continue down the rack and then head off for lunch. As Sun then integrated lights out management into many of their systems, it became even easier as all this could be done using a network connection; no need for serial cables either.

Today, we’ve got Ansible, Puppet, Chef and a myriad of others. JET was DevOps before the term was conceived. Add this to the list of things where what Sun was doing was ahead of it’s time (to go with Sun Ray thin clients, NFS, ZFS, Containers, Lights out Management on servers by default and on and on).

Extensible by Design

We knew that when we built it to scratch our ‘itch’, others would want to adapt and do more with it, so from the very start we made it modular and extensible. Anyone could write a ‘module’ for JET that did a specific job and presented options to the installer. For those familiar with DevOps today, think Ansible ‘roles’, but in a more controlled fashion.

To come full circle, JET was eventually incorporated into the Sun manufacturing processes; primarily for doing ‘build to order’ installs. It meant the same tool that was used in the factory could be used by a field engineer or even a customer, to rebuild a server at any time.

Scaling Out

Before too long, every Sun field engineer was using it to speed up installs and as authors, we even got to speak at a couple of conferences to the masses. Where it was really making a difference though was in the staging and customer integration areas of manufacturing. Customers could come to Sun, spend time working with our engineers and develop their system builds. We’d physically build the servers and then deploy their builds onto them for testing. Once signed off, that build could then be replicated by the manufacturing teams and delivered straight to site. Now the field engineer just had to do basic tests and get a sign off. No more CDs or lengthy waits for systems to install.

Sounds obvious now, but when we were doing this, none of the other big manufacturers were.

Maui JET Modules

Although I can’t publish a copy of the JET software here (it’s now owned and controlled by Oracle), since I left Sun myself and a few other of the original custodians of JET did consultancy work for a number of customers. Those modules can be found in the Resources section and as for most OSS, come with no warranties for fitness of purpose.

If you come across something with Solaris JET and need help, now you know where to come….

Credits

All of the Sun and Solaris names and logos are now © and ™ Oracle Corporation, along with the terms ‘JumpStart’ and probably ‘JumpStart Enterprise Toolkit’. I seem to remember having to register that with the Sun lawyers at one point.

The Enterprise 450 was the first platform where I was responsible for integrating it into the manufacturing systems so it could process through the shop floor. Still got the Tazmo team t-shirt and remember vividly the conference call to the shop floor team from a phone box on Tiree, squashed in with the product manager, as the project was running late and we had booked a windsurfing trip for just after it was supposed to finish. No way we were going to miss the trip, and hey, we’d done all the hard work so ‘what could possibly go wrong’…..

Netra’s and all of the big iron Enterprise kit (10K, 25K) were the mainstay of dot com and then onwards into hardware virtualisation and some seriously large high availability clusters for customers that can’t be named.

The mainstay of the JET team were myself and Mike, with lots of help from Bruce, Chris, Tom and Gordon. Geoff for believing in us from the outset and arranging the fateful initial meeting. There were lots of other people that helped - notably Howard for making it a part of EIS for installation engineers, and Jeff from manufacturing who got it into the staging and build to order processes.

Truly a team effort and an absolute pleasure to consider you all as colleagues.

• Software
• Solaris