<commit_before><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE>The VO Frontend</TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 2.4  (Linux)">
	<META NAME="CREATED" CONTENT="0;0">
	<META NAME="CHANGEDBY" CONTENT="<NAME>">
	<META NAME="CHANGED" CONTENT="20080909;13502500">
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1>The VO Frontend</H1>
<H2>Description</H2>
<P>The VO Frontend is, as the name suggests, the user interface of a
<A HREF="../index.html">glidein&nbsp;based WMS</A>.</P>
<H2>Index</H2>
<UL>
	<LI><A HREF="#overview">Overview</A> 
	<LI><A HREF="#implementation">Implementation</A> 
	<LI><A HREF="#management">The VO Frontend management</A> 
	<LI><A HREF="#run_daemon">Starting a VO Frontend Daemons</A> 
	<LI><A HREF="#ref">Reference</A> 
</UL>
<H2><A NAME="overview"></A>Overview</H2>
<P>The main task of the VO frontend is to look for user jobs and ask
the <A HREF="../factory/index.html">Glidein Factories</A> to provide
<A HREF="../index.html#glideins">glideins</A>, if needed. See the
picture below for a general overview.<BR><IMG SRC="overview.png" NAME="graphics1" ALIGN=BOTTOM WIDTH=899 HEIGHT=431 BORDER=0><BR>The
VO frontend knows nothing about the glideins or Grid sites; the only
information in has are the attributes that the various Glidein
Factories publish. This makes the life of the&nbsp;frontend much
easier, as it only has to worry about matching user job requirements
to the factory attributes.</P>
<H2><A NAME="implementation"></A>Implementation</H2>
<P>The current implementation of the VO frontend is <A HREF="http://www.python.org/">Python</A>
based. It uses a tree of process like the factory does.<BR><BR>
The sub-process (group) code is composed of 4 logical
pieces:</P>
<UL>
	<LI>an element that holds the Glidein Factory Ads, 
	<LI>an element that holds the user jobs Ads, 
	<LI>a matchmaking procedure,
	<LI>a procedure that advertises the requests, and 
	<LI><P>the glue that links the above together. 
	</P>
</UL>
<P><A NAME="match_expr"></A>The top two elements simply contact the
appropriate Condor Collector and store the data in memory.<BR><BR>The
matchmaking procedure loops over all the <A HREF="../index.html#factory_classads">factory
ads</A> and&nbsp;counts the number of idle user jobs that match the
attributes of that particular factory entry point. <BR><BR>The
matching expression is a <A HREF="http://www.python.org/doc/">Python
expression</A>, having as inputs 
</P>
<UL>
	<LI>an object holding the job attributes, named <FONT FACE="monospace"><B>job</B></FONT>,
	and&nbsp; 
	<LI><P>an object holding the entry point attributes, named <FONT FACE="monospace"><B>glidein</B></FONT>.
		</P>
</UL>
<P>Both objects are dictionaries, with keys being attribute names,
and values being attribute values.<BR><BR>A few examples:</P>
<DL>
	<DD><PRE>job[&quot;CDFMaxHours&quot;]&lt;glidein[&quot;attrs&quot;][&quot;WMSMaxHours&quot;]
job[&quot;HasData&quot;] or (glidein[&quot;site&quot;] in string.split(job[&quot;SitesWithRequiredData&quot;]))
(job[&quot;Arch&quot;] == glidein[&quot;Arch&quot;]) and (job[&quot;gccVersion&quot;]==glidein[&quot;attrs&quot;][&quot;gccVersion&quot;])</PRE></DD></DL><P>
<P>Finally, the advertise procedure loops over the counts and
	converts them into appropriate <A HREF="../index.html#frontend_classads">Condor
	Class Ads</A>.<BR><BR>The glue code is responsible of parsing the
	input parameters, loading the configuration values and loop over the
	above steps.</P>

<P>The frontend also can handle multiple proxies. The proxy selection is handled by a plugin mechanism.</P>
<H2>
<A NAME="management"></A>The VO Frontend management</H2>
<P>The VO Frontend configuration involves creating the configuration directory and files and then creating the daemons.  As in the Glidein Factory set up, an XML file is converted into a configuration tree by a configuration tool.</P>
<P>For the installer to create the VO Frontend instance from the configuration directory and grid mapfile, the following objects can be defined:</P>

<UL>
        <li><p><font face="monospace">&lt;<b>frontend frontend_name</b>="<i>your name</i>" <b>advertise_delay</b>="<i>seconds</i>" <b>loop_delay</b>="<i>nr</i>" &gt;</font><br>The frontend_name is a combination of the frontend and instance names specified during installation.  It is used to create VO Frontend instance directory and files. The delay parameters define how active the VO Frontend should be.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>match</b>&gt;&lt;<b>factory</b>&gt;&lt;<b>collectors</b>&gt;&lt;<b>collector my_identity</b>="<i><EMAIL></i>" <b>node</b>="<i>collector1.myorg.com</i>" <b>factory_identity</b>="<i>gfactory@gfactory1.my.org</i>" <b>DN</b>="<i>/DC=org/DC=doegrids/OU=Services/CN=collector/collectory1.my.org</i>"/&gt;</font><br>This shows what WMS Collector the VO Frontend will map to.  It is the mapped name for the identity of the classad. It alos tells what should be the idetnity used by the frontend itself and the expected identity of the factory
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job query_expr</b>="<i>expression</i>" &gt;</font><br>A <a href="http://www.cs.wisc.edu/condor/manual/v7.0/condor_q.html">Condor constraint</a> to be used with condor_q when looking for user jobs. (like 'JobUniverse=?=5', i.e. consider only Vanilla jobs).  If you want to consider all user jobs, this can be set to TRUE.  
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job</b>&gt;&lt;<b>schedds</b>&gt;&lt;<b>schedd fullname</b>="<i>schedd name</i>" /&gt;</font><br>When you provide the user pool collector to the installer, it will find all the available schedds.  You can specify which schedds to monitor here for user jobs.  The schedd fullname is the name under which schedd is registered with the user pool collector. 
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>monitor base_dir</b>="<i>web_dir</i>" <b>flot_dir</b>="<i>web_dir</i>" <b>javascriptRRD_dir</b>="<i>web_dir</i>" <b>jquery_dir</b>="<i>web_dir</i>" /&gt;</font><br>The <strong>base_dir</strong> defines where the web monitoring is.  The other entries point to where javascriptRRD, Flot and JQuery libraries are located.        
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>security proxy_DN</b>="<i>/DC=org/DC=doegrids/OU=Service/CN=frontend/frontend1.my.org</i>" <b>classad_proxy</b>="<i>proxy_dir</i>" <b>proxy_selection_plugin</b>="<i>ProxyAll</i>" <b>security_name</b>="<i>vofrontend1</i>"&gt;</font><br>Grid proxy to use is located in the classad_proxy directory and you must specify the full path to the proxy. security_name signifies the name under which the frontend is registered with the factory.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>security</b>&gt;&lt;<b>proxies</b>&gt;&lt;<b>proxy absfname</b>="<i>proxy</i>" <b>security_class</b>="<i>frontend</i>"/&gt;</font><br>The location of the proxy the VO Frontend forwards to the factory for use in submitting glideins.  You can have multiple proxy entries listed here.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>stage base_dir</b>="<i>web_dir</i>" <b>web_base_url</b>="<i>URL</i>"  /&gt;</font><br>The location of the web server directories.  It is the staging area where the files needed to run you job are located (i.e. condor).  You may need to change this according to your requirements.        
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>work base_dir</b>="<i>directory</i>" /&gt;</font><br>This defines the path to the VO Frontend directory.  
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>attrs</b>&gt;&lt;<b>attr name</b>="<i>attr_name</i>" <b>value</b>="<i>value</i>" <b>parameter</b>="<b>True</b>" <b>type</b>="<b>string</b>" <b>glidein_publish</b>="<i>boolean</i>" <b>job_publish</b>="<i>boolean</i>" &gt;</font><br>The following three attributes are required to be set in the frontend requests and/or published for jobs.  Others can be specified as well.
	  <ul>
	    <li><p><font face="monospace">&lt;<b>attr name</b>="<b>GLIDEIN_Collector</b>" &gt;</font><br>The contains the name of the pool collector, i.e. mymachine.mydomain.</p></li>
	    <li><p><font face="monospace">&lt;<b>attr name</b>="<b>GLIDEIN_Expose_Grid_Env</b>" &gt;</font><br>This determines if you want to expose the user to the grid environment.</p></li>
	    <li><p><font face="monospace">&lt;<b>attr name</b>="<b>USE_MATCH_AUTH</b>" &gt;</font><br>This determines whether or not you want to use match authentication.  You specify the match expression in a group section of the config file.</p></li>
	  </ul>
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>files</b>&gt;&lt;<b>file absfname</b>="<i>filepath</i>" <b>relfname</b>="<i>filename</i>" <b>executable</b>="<i>boolean</i>" /&gt;</font><br>The file parameters are used to specify the location of additional files.  The grid mapfile location must be specified.
        </p></li>
</UL>

<P>The following group parameters are used to configure multiple frontends.  If only one group is specified, they apply to all frontends.  The objects specified are used for creating and monitoring glideins.</P>
<UL>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group name</b>="<i>name</i>" <b>enabled</b>="<i>boolean</i>" &gt;</font><br>This specifies the name of the group and whether it is enabled.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>config</b>&gt;</font><br>The parameters listed here define how many glideins to create and maintain, such as <font face="monospace">idle_glideins_per_entry</font> and <font face="monospace">running_glideins_per_entry</font>.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>match match_expr</b>="<i>expr</i>" &gt;</font><br>A Python boolean expression is used to match glideins to jobs.  The glidein and job dictionaries are used in the expression, i.e. glidein["attrs"]["GLIDEIN_Site"] in job["DESIRED_Sites"].split(",").  If you want to match all, just specify True.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>factory query_expr</b>="<i>expr</i>" &gt;</font><br>A Python expression that specifies a factory constraint.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>factory</b>&gt;&lt;<b>match attrs</b>&gt;&lt;<b>match attr name</b>="<i>name</i>" &gt;</font><br>A list of glidein factory attributes used in the factory match expression.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job query_expr</b>="<i>expr</i>" &gt;</font><br>A Python expression that specifies a job constraint.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job</b>&gt;&lt;<b>match attrs</b>&gt;&lt;<b>match attr name</b>="<i>name</i>" &gt;</font><br>A list of job attributes used in the factory match expression.
        </p></li>
</UL>



<H2><A NAME="run_daemon"></A>Starting a VO Frontent Daemons</H2>
<P>Once you have the desired configuration file, move to the VO<commit_msg>Restoring changes lost during merging<commit_after><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE>The VO Frontend</TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 2.4  (Linux)">
	<META NAME="CREATED" CONTENT="0;0">
	<META NAME="CHANGEDBY" CONTENT="<NAME>">
	<META NAME="CHANGED" CONTENT="20080909;13502500">
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1>The VO Frontend</H1>
<H2>Description</H2>
<P>The VO Frontend is, as the name suggests, the user interface of a
<A HREF="../index.html">glidein&nbsp;based WMS</A>.</P>
<H2>Index</H2>
<UL>
	<LI><A HREF="#overview">Overview</A> 
	<LI><A HREF="#implementation">Implementation</A> 
	<LI><A HREF="#management">The VO Frontend management</A> 
	<LI><A HREF="#run_daemon">Starting a VO Frontend Daemons</A> 
	<LI><A HREF="#ref">Reference</A> 
</UL>
<H2><A NAME="overview"></A>Overview</H2>
<P>The main task of the VO frontend is to look for user jobs and ask
the <A HREF="../factory/index.html">Glidein Factories</A> to provide
<A HREF="../index.html#glideins">glideins</A>, if needed. See the
picture below for a general overview.<BR><IMG SRC="overview.png" NAME="graphics1" ALIGN=BOTTOM WIDTH=899 HEIGHT=431 BORDER=0><BR>The
VO frontend knows nothing about the glideins or Grid sites; the only
information in has are the attributes that the various Glidein
Factories publish. This makes the life of the&nbsp;frontend much
easier, as it only has to worry about matching user job requirements
to the factory attributes.</P>
<H2><A NAME="implementation"></A>Implementation</H2>
<P>The current implementation of the VO frontend is <A HREF="http://www.python.org/">Python</A>
based. It uses a tree of process like the factory does.<BR><BR>
The sub-process (group) code is composed of 4 logical
pieces:</P>
<UL>
	<LI>an element that holds the Glidein Factory Ads, 
	<LI>an element that holds the user jobs Ads, 
	<LI>a matchmaking procedure,
	<LI>a procedure that advertises the requests, and 
	<LI><P>the glue that links the above together. 
	</P>
</UL>
<P><A NAME="match_expr"></A>The top two elements simply contact the
appropriate Condor Collector and store the data in memory.<BR><BR>The
matchmaking procedure loops over all the <A HREF="../index.html#factory_classads">factory
ads</A> and&nbsp;counts the number of idle user jobs that match the
attributes of that particular factory entry point. <BR><BR>The
matching expression is a <A HREF="http://www.python.org/doc/">Python
expression</A>, having as inputs 
</P>
<UL>
	<LI>an object holding the job attributes, named <FONT FACE="monospace"><B>job</B></FONT>,
	and&nbsp; 
	<LI><P>an object holding the entry point attributes, named <FONT FACE="monospace"><B>glidein</B></FONT>.
		</P>
</UL>
<P>Both objects are dictionaries, with keys being attribute names,
and values being attribute values.<BR><BR>A few examples:</P>
<DL>
	<DD><PRE>job[&quot;CDFMaxHours&quot;]&lt;glidein[&quot;attrs&quot;][&quot;WMSMaxHours&quot;]
job[&quot;HasData&quot;] or (glidein[&quot;site&quot;] in string.split(job[&quot;SitesWithRequiredData&quot;]))
(job[&quot;Arch&quot;] == glidein[&quot;Arch&quot;]) and (job[&quot;gccVersion&quot;]==glidein[&quot;attrs&quot;][&quot;gccVersion&quot;])</PRE></DD></DL><P>
<P>Finally, the advertise procedure loops over the counts and
	converts them into appropriate <A HREF="../index.html#frontend_classads">Condor
	Class Ads</A>.<BR><BR>The glue code is responsible of parsing the
	input parameters, loading the configuration values and loop over the
	above steps.</P>

<P>The frontend also can handle multiple proxies. The proxy selection is handled by a plugin mechanism.</P>
<H2>
<A NAME="management"></A>The VO Frontend management</H2>
<P>The VO Frontend configuration involves creating the configuration directory and files and then creating the daemons.  As in the Glidein Factory set up, an XML file is converted into a configuration tree by a configuration tool.</P>
<P>For the installer to create the VO Frontend instance from the configuration directory and grid mapfile, the following objects can be defined:</P>

<UL>
        <li><p><font face="monospace">&lt;<b>frontend frontend_name</b>="<i>your name</i>" <b>advertise_delay</b>="<i>seconds</i>" <b>loop_delay</b>="<i>nr</i>" &gt;</font><br>The frontend_name is a combination of the frontend and instance names specified during installation.  It is used to create VO Frontend instance directory and files. The delay parameters define how active the VO Frontend should be.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>match</b>&gt;&lt;<b>factory</b>&gt;&lt;<b>collectors</b>&gt;&lt;<b>collector my_identity</b>="<i><EMAIL></i>" <b>node</b>="<i>collector1.myorg.com</i>" <b>factory_identity</b>="<i><EMAIL></i>" <b>DN</b>="<i>/DC=org/DC=doegrids/OU=Services/CN=collector/collectory1.my.org</i>"/&gt;</font><br>This shows what WMS Collector the VO Frontend will map to.  It is the mapped name for the identity of the classad. It alos tells what should be the idetnity used by the frontend itself and the expected identity of the factory
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job query_expr</b>="<i>expression</i>" &gt;</font><br>A <a href="http://www.cs.wisc.edu/condor/manual/v7.0/condor_q.html">Condor constraint</a> to be used with condor_q when looking for user jobs. (like 'JobUniverse=?=5', i.e. consider only Vanilla jobs).  If you want to consider all user jobs, this can be set to TRUE.  
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job</b>&gt;&lt;<b>schedds</b>&gt;&lt;<b>schedd fullname</b>="<i>schedd name</i>" /&gt;</font><br>When you provide the user pool collector to the installer, it will find all the available schedds.  You can specify which schedds to monitor here for user jobs.  The schedd fullname is the name under which schedd is registered with the user pool collector. 
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>monitor base_dir</b>="<i>web_dir</i>" <b>flot_dir</b>="<i>web_dir</i>" <b>javascriptRRD_dir</b>="<i>web_dir</i>" <b>jquery_dir</b>="<i>web_dir</i>" /&gt;</font><br>The <strong>base_dir</strong> defines where the web monitoring is.  The other entries point to where javascriptRRD, Flot and JQuery libraries are located.        
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>security proxy_DN</b>="<i>/DC=org/DC=doegrids/OU=Service/CN=frontend/frontend1.my.org</i>" <b>classad_proxy</b>="<i>proxy_dir</i>" <b>proxy_selection_plugin</b>="<i>ProxyAll</i>" <b>security_name</b>="<i>vofrontend1</i>"&gt;</font><br>Grid proxy to use is located in the classad_proxy directory and you must specify the full path to the proxy. security_name signifies the name under which the frontend is registered with the factory.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>security</b>&gt;&lt;<b>proxies</b>&gt;&lt;<b>proxy absfname</b>="<i>proxy</i>" <b>security_class</b>="<i>frontend</i>"/&gt;</font><br>The location of the proxy the VO Frontend forwards to the factory for use in submitting glideins.  You can have multiple proxy entries listed here.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>stage base_dir</b>="<i>web_dir</i>" <b>web_base_url</b>="<i>URL</i>"  /&gt;</font><br>The location of the web server directories.  It is the staging area where the files needed to run you job are located (i.e. condor).  You may need to change this according to your requirements.        
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>work base_dir</b>="<i>directory</i>" /&gt;</font><br>This defines the path to the VO Frontend directory.  
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>attrs</b>&gt;&lt;<b>attr name</b>="<i>attr_name</i>" <b>value</b>="<i>value</i>" <b>parameter</b>="<b>True</b>" <b>type</b>="<b>string</b>" <b>glidein_publish</b>="<i>boolean</i>" <b>job_publish</b>="<i>boolean</i>" &gt;</font><br>The following three attributes are required to be set in the frontend requests and/or published for jobs.  Others can be specified as well.
	  <ul>
	    <li><p><font face="monospace">&lt;<b>attr name</b>="<b>GLIDEIN_Collector</b>" &gt;</font><br>The contains the name of the pool collector, i.e. mymachine.mydomain.</p></li>
	    <li><p><font face="monospace">&lt;<b>attr name</b>="<b>GLIDEIN_Expose_Grid_Env</b>" &gt;</font><br>This determines if you want to expose the user to the grid environment.</p></li>
	    <li><p><font face="monospace">&lt;<b>attr name</b>="<b>USE_MATCH_AUTH</b>" &gt;</font><br>This determines whether or not you want to use match authentication.  You specify the match expression in a group section of the config file.</p></li>
	  </ul>
Other attributes can be specified as well.  They are used by the VO frontend matchmaking and job matchmaking. The format is similar to the attributes on the Factory config file.  The table below describes the &lt;attrs ... &gt; tag in more detail. <br><br>
    <table valign="top" style="border: 1px solid rgb(2, 2, 99); text-align: justify;" frame="box" width="100%" border="1px" cellpadding="2" cellspacing="0">
      <tbody><tr style="border-width: 0pt; font-weight: bold;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">Attribute Name</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">Attribute Description</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">name</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">Name of the attribute</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">value</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">Value of the attribute</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">const</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">If set to True, the attribute will be available in the constants file created in the staging area. Used only if parameter is True.</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">parameter</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">Set to True if the attribute should be passed as a parameter. Always set this to True unless you know what you are doing.</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">glidein_publish</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">If set to True, the attribute will be available in the condor_startd's classad. Used only if parameter is True.</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">job_publish</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">If set to True, the attribute will be available in the user job's environment. Used only if parameter is True.</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">comment</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">You can specify description of the attribute here.</td>
      </tr>
      <tr style="border-width: 0pt;">
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="25%">type</td>
        <td style="text-align: justify; border: 1px solid rgb(0, 0, 0); background-color: rgb(204, 204, 204);" width="75%">Type of the attribute. Supported types are 'int', 'string' and 'expr'. Type expr is equivalent to condor constant/expression in condor_vars.lst</td>
      </tr>
    </tbody></table>
<br>
An example attribute would be:</p><pre>&lt;attrs&gt;&lt;attr name="GLIDEIN_Collector" value="mymachine.mydomain" publish="True" parameter="True" const="True" glidein_publish="True" comment=”Just a test attribute”/&gt;</pre>
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>files</b>&gt;&lt;<b>file absfname</b>="<i>filepath</i>" <b>relfname</b>="<i>filename</i>" <b>executable</b>="<i>boolean</i>" /&gt;</font><br>The file parameters are used to specify the location of additional files.  The grid mapfile location must be specified.
        </p></li>
</UL>

<P>The following group parameters are used to configure multiple frontends.  If only one group is specified, they apply to all frontends.  The objects specified are used for creating and monitoring glideins.</P>
<UL>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group name</b>="<i>name</i>" <b>enabled</b>="<i>boolean</i>" &gt;</font><br>This specifies the name of the group and whether it is enabled.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>config</b>&gt;</font><br>The parameters listed here define how many glideins to create and maintain, such as <font face="monospace">idle_glideins_per_entry</font> and <font face="monospace">running_glideins_per_entry</font>.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>match match_expr</b>="<i>expr</i>" &gt;</font><br>A Python boolean expression is used to match glideins to jobs.  The glidein and job dictionaries are used in the expression, i.e. glidein["attrs"]["GLIDEIN_Site"] in job["DESIRED_Sites"].split(",").  If you want to match all, just specify True.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>factory query_expr</b>="<i>expr</i>" &gt;</font><br>A Python expression that specifies a factory constraint.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>factory</b>&gt;&lt;<b>match attrs</b>&gt;&lt;<b>match attr name</b>="<i>name</i>" &gt;</font><br>A list of glidein factory attributes used in the factory match expression.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job query_expr</b>="<i>expr</i>" &gt;</font><br>A Python expression that specifies a job constraint.
        </p></li>
        <li><p><font face="monospace">&lt;<b>frontend</b>&gt;&lt;<b>groups</b>&gt;&lt;<b>group</b>&gt;&lt;<b>match</b>&gt;&lt;<b>job</b>&gt;&lt;<b>match attrs</b>&gt;&lt;<b>match attr name</b>="<i>name</i>" &gt;</font><br>A list of job attributes used in the factory match expression.
        </p></li>
</UL>



<H2><A NAME="run_daemon"></A>Starting a VO Frontent Daemons</H2>
<P>Once you have the desired configuration file, move to the VO
{'fraction_non_alphanumeric': 0.18815605631784474, 'fraction_numerical': 0.014294414788808081, 'mean_word_length': 5.066941969137144, 'pattern_counts': {'":': 0, '<': 1176, '<?xml version=': 0, '>': 1176, 'https://': 0, 'lorem ipsum': 0, 'www.': 6, 'xml': 0}, 'pii_count': 1, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1981854', 'n_tokens_mistral': 10267, 'n_tokens_neox': 9516, 'n_words': 2644}