Status for Andrew DeFaria

• Added source command to easter. This is the interactive equivalent of the -file option
• Changed history to log a -file <file> as a "source <file>" into the history file
• Changed prompt to
• "easter>"
• Documented easter on the wiki
• Added rudimentary set/get commands to add things to the global $_optis hash. This allows the interactive user to set options like activecalls or displaylevel interactively for the during of the easter run. Note, there is no checking to insure the option if valid (i.e. set foo=bar is perfectly acceptable even though there is no "foo" option) nor is proper checking of balancing/mismatching of quotes (e.g. The results of set foo = "unbalanced or mismatched quotes' are undefined).

Posted by Andrew DeFaria at 02:02 PM | Permalink | TrackBacks (0)

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?

Posted by Andrew DeFaria at 02:49 PM | Permalink | TrackBacks (0)

Rexec Complications

Rexec is a Perl module written by me. There are several things that Rexec provides but at it's core it essentially provides an object oriented interface to a remote command line. Rexec attempts to provide functionality by handling the details in nominal cases however it's basic paradigm is that it expects to be able to execute a command on the remote system, for that command to block and for the command to finish and to properly set the exit status. Rexec accomplishes this by using Expect. When instantiated, Rexec attempts to log into the remote machine using a cascading fallback of ssh, rsh and telnet (unless the caller has explicitly requested a particular protocol). User name and password can be supplied or passwordless login must be configured for Rexec to succeed to connect to the remote system.

Thereafter the caller calls the exec method to execute the remote command. Rexec wraps that command with two echo statements that mark the beginning and ending of the command's output as well as the status of the command. Rexec then gathers up the output lines and status, storing them in the object, and returning the output lines as an array (and the status obtainable using the status method). The caller can then proceed accordingly.

But the above does assume that commands are of the nature that they block while operating and that they set the exit code properly. No effort is made to do any output redirection, nor are any assumptions made about the command being executed.

The first problem arises when the caller has a need to "background" a task. Normally in Unix this means adding a "&" to the end of the line to indicate to put the command in the background. In such a case we run into two problems that the normal shell also has to deal with, that being how to handle asynchronous I/O and how to handle the exit status, which can come at any time. So far no functionality has been added to handle any asynchronous I/O - the answer here is don't do that!!!, at least, for now.

Exit status is also not gracefully handled in that it is not attempted to be captured at all.

What Rexec does normally is to add an echo <unique start string> to the front of the command and an echo <unique end string with status>. Then Rexec scans the output for the start and ending strings and knows that the strings inbetween must have resulted from the output from the command. Rexec also gathers the exit status from the later echo statement. Of course, this assume the command blocks and properly sets the exit status.

Now, if Rexec finds a "&" at the end of the command it will treat it as nonblocking. It does not add the start nor the ending echoes and makes no attempt at gathering neither output nor exit status from this command. Another potential problem are commands which do not indicate their desire to be backgrounded (by specifying the trailing "&" character) but background themselves nonetheless.

Another, odd problem was also discovered when the remote command ended up doing yet another ssh to another system. Such a command also does not return, or at least not right away. Worse yet, there is a good possibility that that 2nd remote ssh will result in a prompt that will be mistaken for the 1st session's prompt by Rexec! No easy way around this either!

Finally, other commands will likewise have a problem when executed remotely. For example: "vi /tmp/foo". But then again, even Expect has problems with this. So we can't be all things to all people but that doesn't mean we cannot be helpful nonetheless.

Posted by Andrew DeFaria at 02:24 PM | Permalink | TrackBacks (0)