defaria.com/blogs/Status/archives/000427.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml" />
  11
  12    <title>Status for Andrew DeFaria: Triggers</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/000426.html" title="PQA Code Page/SJ Vob move" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/000430.html" title="Clearquest Franchise/PQA Invalid ASCII characters" />
  17
  18
  19
  20
  21
  22    <script type="text/javascript" src="http://defaria.com/blogs/Status/mt-site.js"></script>
  23 </head>
  24 <body class="layout-one-column" onload="individualArchivesOnLoad(commenter_name)">
  25    <div id="container">
  26       <div id="container-inner" class="pkg">
  27
  28          <div id="banner">
  29             <div id="banner-inner" class="pkg">
  30                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  31                <h2 id="banner-description">Searchable status reports and work log</h2>
  32             </div>
  33          </div>
  34
  35          <div id="pagebody">
  36             <div id="pagebody-inner" class="pkg">
  37                <div id="alpha">
  38                   <div id="alpha-inner" class="pkg">
  39
  40                      <p class="content-nav">
  41                         <a href="http://defaria.com/blogs/Status/archives/000426.html">&laquo; PQA Code Page/SJ Vob move</a> |
  42                         <a href="http://defaria.com/blogs/Status/">Main</a>
  43                         | <a href="http://defaria.com/blogs/Status/archives/000430.html">Clearquest Franchise/PQA Invalid ASCII characters &raquo;</a>
  44                      </p>
  45
  46                      <a id="a000427"></a>
  47                      <div class="entry" id="entry-427">
  48                         <h3 class="entry-header">Triggers</h3>
  49                         <div class="entry-content">
  50                            <div class="entry-body">
  51                               <ul>
  52   <li>Worked on mktriggers script to mktriggers for all regions, all vobs</li>
  53 </ul>
  54                            </div>
  55                            <div id="more" class="entry-more">
  56                               <h2>Trigger Standardization</h2>
  57
  58 <p>I have been trying to centralize and standardize triggers. The idea here is to be able to add all the triggers to all of the necessary vobs quickly and easily and to insure that triggers - implementors of policy - are consistently applied. As triggers are not replicated by Multisite it is essential that you can add triggers to a replicate if needed. For example, we need it to add triggers to the new replicas of the San Jose and Irvine vobs. Also new triggers and new vobs come into being and you usually want to make sure that all vobs have the appropriate triggers in force.</p>
  59
  60 <blockquote><strong>Note:</strong> For example, the vob /vobs/CommEngine is replicated from Irvine <-> San Jose. Irvine has a set of triggers applied to their replica and we have a different set.
  61 </blockquote>
  62
  63 <p>Within Broadcom there are various vobs in various regions. This makes automation a little more difficult but not impossible. Some standardization of what triggers go where and how Clearcase gains access to the trigger code is necessary. One way I've seen companies accomplish this in the past was to create an administration vob and place trigger code in that vob. This vob would be replicated to all sites and trigger code made available through the use of a snapshot view in a well known location. Other administrative scripts can be shared in a similar fashion. Additionally we need to address differences between Windows and Unix.</p>
  64
  65 <h2>Inconsistent paths</h2>
  66
  67 <p>As it stands now triggers seem to be in a few places and I don't think that this places are kept in sync. As such I see inconsistencies that are confusing me. For example there are the following paths to triggers mentioned in /home/vobadm/scripts/mktrtype.sh:</p>
  68
  69 <div class="code"><pre>
  70        ccase-atla-1)
  71           NTPATH="\\\cc-atla-storage\ccase\script\trigger"
  72           UNIXPATH="/projects/ccase/script/trigger"
  73           ;;
  74
  75        ccase-blr-1)
  76           NTPATH="\\\cc-blr-storage\ccase\script\trigger"
  77           UNIXPATH="/projects/ccase/script/trigger"
  78           ;;
  79
  80        ccase-brsa-1)
  81           NTPATH="\\\cc-brsa-storage\ccase\script\trigger"
  82           UNIXPATH="/projects/ccase/script/trigger"
  83           ;;
  84
  85        ccase-irva-2)
  86           NTPATH="\\\Fs-irva-37\ccase\script\trigger"
  87           UNIXPATH="/projects/ccase/script/trigger"
  88           ;;
  89
  90        ccase-irva-4)
  91           NTPATH="\\\Fs-irva-37\ccase\script\trigger"
  92           UNIXPATH="/projects/ccase/script/trigger"
  93           ;;
  94
  95        ccase-irva-tst)
  96           NTPATH="\\\Fs-irva-37\ccase\script\trigger"
  97           UNIXPATH="/projects/ccase/script/trigger"
  98           ;;
  99
 100        ccase-mhtb-1)
 101           NTPATH="\\\cc-mhtb-storage\ccase\script\trigger"
 102           UNIXPATH="/projects/ccase/script/trigger"
 103           ;;
 104
 105        ccase-peka-1)
 106           NTPATH="\\\cc-peka-storage\ccase\script\trigger"
 107           UNIXPATH="/projects/ccase/script/trigger"
 108           ;;
 109
 110        ccase-rmna-3)
 111           NTPATH="\\\cc-rmna-storage\ccase\script\trigger"
 112           UNIXPATH="/projects/ccase/script/trigger"
 113           ;;
 114
 115        ccase-sdoa-1|ccase-sdoa-2)
 116           NTPATH="\\\Fs-irva-37\ccase\script\trigger"
 117           UNIXPATH="/projects/ccase/script/trigger"
 118           ;;
 119
 120        ccase-sj1-1)
 121           NTPATH="\\\cc-sj-storage\ccase\bse\script\trigger"
 122           UNIXPATH="/projects/ccase/bse/script/trigger"
 123           ;;
 124
 125        ccase-tlva-1|ccase-tlva-1.il.broadcom.com)
 126           NTPATH="\\\cc-tlva-storage\ccase\script\trigger"
 127           UNIXPATH="/projects/ccase/script/trigger"
 128           ;;
 129 </pre></div>
 130
 131 <p>As you can see the NTPATH varies where the UNIXPATH is largely the same (ccase-sj1-1 puts scripts under bse). Also, with ccase-rmna-3 it says /projects/ccase/script/trigger yet is currently using /projects/cc4/triggers and the differences between those two directories are many. Which one is correct? Why the bse directory for San Jose?</p>
 132
 133 <p>I assume that the reasons for the different NTPATH names is to avoid going over the WAN to get trigger script code. I also assume that this is mitigated on Unix by use of the automounter and yet we cannot say that UNIXPATH is always the same due to the difference in San Jose. I wonder if DFS could be used to provide a consistent, globally well known path to trigger code under Windows...</p>
 134
 135 <p>In any event the question that rises is how are these various repositories of code kept in sync if at all?</p>
 136
 137 <h2>Inconsistent Application of Triggers</h2>
 138
 139 <p>Normally there are a certain set of triggers that are implementing policy that are consistently applied to all vobs (or at least all vobs in a region). For example, usually empty branches are considered bad and to be avoided. Thus there is normally a trigger script applied to all vobs to avoid this. Or if an organization determines that rmelem should not be performed then it is enforced with a trigger on all vobs. Yet there doesn't seem to be any triggers consistently applied to all vobs. In fact many vobs have no triggers at all!</p>
 140
 141 <p>I see, for example, 3 different triggers for preop checkins: GIpreci, preci and test_preci. Triggers could be written that can be applied to any vob and then they act only if the conditions are such that they should do something. IOW for situations where they don't apply they simple exit.</p>
 142
 143 <p>There are also triggers that do nothing but allow people to proceed or not based on whether the user is on an "approved" list. They carry with them a long list of -nusers. I would think that that would be more difficult to maintain than for a trigger to be written that opens up a file of approved users and validates the user based on that. Then to add/change/delete users one merely needs to update the data file, not re-create a trigger in a vob and then have to worry about what other vobs need their triggers updated. Of course the trigger would need to deal with the issue of what is the global file pathname to that data file.</p>
 144                            </div>
 145                         </div>
 146                         <p class="entry-footer">
 147                            <span class="post-footers">Posted by  on September 25, 2005 11:04 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000427.html">Permalink</a>
 148                         </p>
 149                      </div>
 150
 151
 152
 153
 154                   </div>
 155                </div>
 156             </div>
 157          </div>
 158       </div>
 159    </div>
 160 </body>
 161 </html>