Status for Andrew DeFaria

For immediate release...

Recently Gantry mentioned the following problem:

Error Prone Deliveries:

Another problem is that Reinaldo's private files have to be merged manually.

Ross, Andrew, and I are in a similar situation now where we have to take a snapshot of directories in a view over to seast1 in order to do development, then remember what we changed and copy them back in and deliver.

We have already made several mistakes.

The problem here is that we have two different Clearcase registry regions and subnets, code is developed in one region and run in the other. Gantry proposed a solution of writing more script to maintain that will essentially copy things between systems. I would like to propose an alternative...

Release process

What if we instead had a release process such that we deliver our development to the feature stream that is then automatically seen over on the cclinux region? Code is developed through the WOR process on the RAN and delivered to the feature stream. This stream has an official view which is exported to the cclinux region where it is mounted directly into place¹. Since all processes that utilize these scripts do so through this base they are all automatically and immediately updated when the view is updated. Additionally code is developed cognizant of this base such that an alternate base can easily be set allowing one to test the release before making it official.

Solution proposed

Exporting a view

Clearcase has the ability to export a view/vob path from a view server to any other machine. This allows you to "access Clearcase from a machine which does not have Clearcase" (see ct man export_mvfs). In order to do this a systems administrator adds a line to /etc/exports.mvfs on the view server where the view resides using the format of:

/view/<view_name>/vobs/<vobpath><netgroup or machine>

And executes the /opt/rational/clearcase/etc/export_mvfs -a command. Additionally <view_name> should be started².

Official view

Additionally, as noted above, a view must be utilized. I suggest using what I like to call official views for this. An official view is merely a view not associated with any particular person (e.g. maybe ccadm) that serves in an official capacity. This view usually has a simple config spec such as the following:

element * REL_1.0 -nocheckout

thereby limiting what was seen through the view as only that which is labeled with REL_1.0. The release process therefore consisted of applying the REL_1.0 label and poof! Automatically and immediately the new version was available. Updating to say a REL_1.1 release would involve then simply a ct setcs and a changing of REL_1.0 to REL_1.1.

For UCM based views, translate the above to applicable baselines...

Importing the view

On the client machine, importing the view is simply a mount command. The suggestion here is to mount directly to our base, /usr/local/east:

$ mount view1:/views/<official view>/vobs/rantest /usr/local/east

(Actually this should be added to /etc/fstab for automatic, at boot time, mounting).

Security and visibility

There is concern regarding exposing too much visibility of vob elements in the cclinux region. Since /etc/exports.mvfs allows us to specify an exacting path of what is exported we can insure that we are only exporting the .../vobs/rantest portion or even a subdirectory(s) under rantest. This should sufficiently limit the scope of what's exposed.

Notes

1. This assumes that we adopt a concept of a base variable from which everything emanates (e.g. /usr/local/east)
2. At HP I devised a simply script solution to insure that views listed in /etc/views_to_start would be started at boot up on the view servers.

Comments? Concerns?