Wednesday, February 20, 2008

QA Testing With The Zone Manager

One of the great things that I love to do at Sun is work on Directory Services. I have worked on directory server as an architect and consultant in Sun Professional Services, as an engineer in Directory Deployment Engineering, and now as an architect in the Communications Market Area of Software Sales.

In each of these roles, one of the aspects of keeping up with the product is evaluating it for myself. In engineering I also did quite a bit of Quality Assurance (QA) testing as well. David in his comment asked if The Zone Manager could be used for QA testing. I responded that The Zone Manager is an ideal tool for that very purpose.

For this post, I thought it would be cool to give you a basic QA setup script that I have used to test the zip install, CLI setup and web admin setup of DSEE 6.2. With the following invocation of The Zone Manager, I add a sparse zone named dsee, disable all un-necessary services, setup TCP/IP and name services, read-only mount /data, remotely install tomcat5 from Blastwave, and finally runs my ds setup script.
# zonemgr -a add -n dsee6 -z /zones -P sundsee6 -s lock \
-G tomcat5 -I "|bfe0|24|dsee6" -r /data \
-C /etc/resolv.conf -C /etc/nsswitch.conf \
-X "/data/scripts/ ds1 sundsee6"
Note that the ds1 parameter passed to the script is the instance name given to the ds instance setup by the script. Also sundsee6 is the password given for the DSCC console and the rootdn user (cn=Directory Manager)of the directory server instance.

The script installs DSEE6 from the zip file located in /data/images, sets up a directory server instance named ds1, and sets up the Directory Service Console (DSCC).

Once finishes running, you can login to the DSCC via the URL:

Here is a screen shot of the DSCC login page.

Here is a screen shot of what it looks like once you have logged in.

There are lots of great things to see in the new directory console. However, one of my absolute favorites is the ability to see the replication topology. Kudos once again to engineering for that tremendous feature.

The value of zones and The Zone Manager relative to software quality assurance is that you can in a repeatable and automated way create a fresh new image of Solaris configured to your specifications, install your product and test it any way you like. Tear down the zone and repeat the process for every build of your software product. Some may think this is overkill. However if your software installs packages, changes system configuration files, or in any way doesn't cleanly clean up after itself during un-installation you have no way of guaranteeing that each QA run starts from the same starting point.

David, I hope that you find this QA example useful.



zeroG said...

How about installing the solaris native pkg version using such a script [zone manager] ?

Brad Diggs said...

Hi Zerog,

I apologize for not responding sooner. I somehow missed your comment until just now. That is a great question. I have considered adding support for native pkdgadd.

There are three challenges for this option that I foresee.

First, for a given native package file. There were enough variations to the native package format (zipped/tar/rar compressed package file, package directory, ..) that I didn't want to all those possibilities within the zone manager (at least at this time).

Second, there is the matter of package dependency resolution.

And last but not least, there is the matter of where to get the package. If I was to offer this kind of feature, I would want to give you the ability to specify multiple repository formats. For example: a local file, a file available over http/https/ftp/sftp/scp on a remote server, a file available via remote nfs mount, ... Further on this topic, if you wanted to use an ordered list of repositories, how would you specify this?

These three issues are sufficient enough that I think that it is worth the wait for Solaris to resolve these issues before trying to invent (or re-invent) how to solve them through the zone manager.

Fortunately, I believe that all three will eventually resolved via the pkg feature of project Indiana. Until then, Blastwave is a great alternative.