KAI Packaging

 

Licensing

 

To understand the issues of KAI packaging, one needs to understand the issues of how it is licensed, as this has changed over time and the various license formats are incompatible. Further, Kuck & Associates releases a different version of the software for each licensing format, increasing the complexity of distribution and support.

 

The Release 3.3 compiler came in two license flavors: “node-locked”, which was used only for Unix systems, and “personal-use”, which applied to Linux only.  Both used a licensing scheme that looked for the value of the KCC_LICENSE environmental variable; the Unix (node-locked) version also required the KCC_SERIAL to be set.  Both of these numbers were generated by software developed by Kuck & Associates, using a proprietary algorithm.  There is no way to look at a license and know whether it is correct or for which machine it as been generated.  Both license versions were supported by the initial version of the kai_key product, which provided two versions: v3_node_locked and v3_personal_use.

 

In Release 3.4, Kuck & Associates changed the way in which they did licensing.  The “node-locked” licensing was modified to use the FLEXlm product, allowing the introduction of per-seat licensing served from a centralized license server, both for Unix and Linux machines.  However, the message traffic generated by communication with the license server (6 messages exchanged for every object file generated) was determined to be excessive within the Fermilab environment, as a full compilation of CDF or D0 code could easily cause 60,000 or more messages to be exchanged.

 

As an alternative, a special agreement was reached with Kuck & Associates which allowed the creation of a special FLEXlm license that allowed unlimited use within a specified machine.  This is still referred to at Fermilab as a “node-locked” license but it is in fact a “per-seat” license (Kuck & Associates terminology) with an unlimited number of users specified, which means that the FLEXlm license validation routines do not need to communicate with a local or remote license server.

 

As of Release 3.4, the Linux version comes in two flavors.  The “personal use” flavor uses the same format KCC_LICENSE key used in Release 3.3, which is not tied to a specific IP address. It should be used on Linux machines that are used by a single individual. The “node locked” license flavor uses a FLEXlm license file.  It should be used on Linux machines that are shared by a number of people.

 

As a result of the complexities of the new licensing scheme, the kai_key product was redone as the v2_* series, with ups qualifiers used to distinguish the different license types.

 

Releases That Get Packaged

 

Release 3.3

 

Release 3.4

 

Release 4.0

 

 

 

Steps To Package

  1. Check out the packaging environment from CVS. The ups/packaging environment is stored in cdcvs repository, under kai and kai_key.  The compiler is within the kai product, the licensing support is within the kai_key product. You may need to make changes to both products in order to package a new version of the compiler.
  2. There is no automatic notification that the vendor has a new version available.  Therefore, check the vendor’s download web page frequently for updates or wait until an early adopter asks for a packaged version.
  3. Verify that you have a valid license key to do the packaging.  License keys often become invalid with a new release, or over time as they expire (in the past, some were cut to expire when annual licenses expired, but this strategy has been rethought by the vendor, but many expiring licenses still exist).  It is neither predictable nor always documented whether the license key will remain valid; if in doubt, contact the vendor for a new key.  Note that you will need a separate key for each type packaged.
  4. Download the release file from the vendor (http://ww.kai.com/ ).  The format for Unix versions is tar, the Linux version is packaged as an rpm. Place the tar/rpm file within the kai directory that has been checked out from cvs. 
  5. As each release and Unix/Linux flavor has been packaged differently, the steps needed to do packaging are contained within a shell script that is named according to the release to be packaged.  If you are packaging a new version, copy package_v<old> to package_v<new>, as it is often the case that multiple versions must be supported at one time.
  6. Modify the package_v<new> script to reflect the new release numbers, both as provided by the vendor and used by ups.  Check tar file names to see if the pattern has changed; if so, make adjustments following documentation contained within the package script.
  7. It is easiest to package within AFS space, using the Computing Division’s build nodes, to insure a consistent environment. (Using experiment machines can be problematic as they have been locally tailored). The package script has been constructed so that it can only package the version on a specfic machine (i.e. an Irix version can only be packaged on an SGI machine).  This is because some of the installation scripts that the vendor provides use machine-specific commands and look for underlying C compiler components in specific places.
  8. Update the kai_key product to include any new license keys.  Set up the kai_key product, as some of the installation scripts work better if they have a valid license. (Note: each of the installation scripts was written by a different person, so each works differently, and the installation scripts for the FLEXlm licensed versions were done by outside consultants.)
  9. To package, execute the “package_v<new>” script.  Examine the resulting output, which will indicate errors as detected, or that the packaging was successful.  Note: the vendor frequently modifies the question/answer sequences of the installation scripts.  As the package script automatically answers the installation script questions, it is important to verify that the answers remain correct.  If you suspect that the sequence is different, install the package once by hand, carefully noting the question/answer sequences and updating the appropriate unpack routine to answer the questions appropriately.
  10. In order to test, you need to set up both the kai and kai_key products.  As the kai product sets up the kai_key product, you need to make sure that the correct version of both products is set up, whatever your preferred sequence.  I have found it easiest to put the products in fnkits then install both products in my own ups database, thereby verifying both packaging and retrieval from fnkits.
  11. Verify that the packaging is correct by compiling and executing “hello world” programs with different options that vary the libraries loaded.  The test directory contains a makefile that invokes the “TestScript” script, or that script can be invoked directly.
  12. Finally, if you have not already done so, put kai and kai_key into fnkits and do appropriate notifications (see upd documentation).  Both kai and kai_key contain a makefile in their top directory that was generated from the product_template product.  I use the “addproduct” and “delproduct” targets to add and remove the product from fnkits, overriding the version and flavor variables as needed.