+ </para>
+ <para> <emphasis> Site-specific </emphasis> accessors can be
+ defined in <emphasis>
+ /usr/share/plc_api/PLC/Accessors/Accessors_site.py </emphasis>
+ that will be preserved across updates of the PLCAPI rpm.
+ </para>
+ <para>
+ This mechanism does not currently support setting slice
+ tags that apply only on a given node or nodegroup.
+ </para>
+ </section>
+
+ <section id="expose-in-api">
+ <title> Through regular Add/Get/Update methods </title>
+ <para>
+ Finally, tags may also get manipulated through the
+ <emphasis>AddNode</emphasis>, <emphasis>GetNodes</emphasis>,
+ and <emphasis>UpdateNode</emphasis> methods:
+
+ <itemizedlist>
+ <listitem> <para>
+ The <literal>define_accessors</literal> function in the
+ Accessors factory has an optional argument named <literal>
+ expose_in_api </literal>. When this is set, the
+ corresponding tag becomes visible from the Add/Get/Update
+ methods almost as if it was a native tag.
+ </para> </listitem>
+
+ <listitem><para>
+ So for instance the following code would be legal and do as expected:
+<programlisting>
+# create a x86_64 node
+>>> AddNode({'hostname':'pl1.foo.com','arch':'x86_64'})
+# get details for pl1.foo.com including tag 'arch' tag
+>>> GetNodes(['pl1.foo.com'],['boot_state','node_type','arch'])
+# set the 'deployment' tag
+>>> UpdateNode('pl1.foo.com',{'deployment':'beta'})
+# get all alpha and beta nodes
+>>> GetNodes({'deployment':'*a'},['hostname','deployment'])
+</programlisting>
+ </para></listitem>
+
+ <listitem><para>
+ The current limitation about tags as opposed to native
+ fields is that, for performance, tags won't get returned
+ when using the implicit set of columns. So for instance:
+<programlisting>
+# get all details for 'pl1.foo.com'
+>>> node=GetNodes(['pl1.foo.com'])[0]
+# this did not return the 'arch' tag
+>>> 'arch' in node
+False
+</programlisting>
+ </para></listitem>
+
+ </itemizedlist>
+ </para>
+ </section>
+ </section>
+
+ <section id="nodegroups">
+ <title>Nodegroups</title>
+
+ <para> In earlier versions up to v4.2, <emphasis> NodeGroups
+ </emphasis> used to be defined extensively. So you would,
+ basically, create an empty nodegroup instance, and then use
+ <emphasis> AddNodeToNodeGroup </emphasis> or <emphasis>
+ DeleteNodeFromNodeGroup </emphasis> to manage the nodegroup's
+ contents. </para>
+
+ <para> The new model has been redefined as follows. You now define
+ a nodegroup as the set of nodes for which a given <emphasis> Tag
+ </emphasis> has a given value, which are defined once and for good
+ when creating the <emphasis> NodeGroup </emphasis> object. </para>
+
+ <para> So for instance for managing the set of nodes that are
+ running various levels of software code, PLC has defined two
+ <emphasis> NodeGroups </emphasis> named <literal> alpha </literal>
+ and <literal> beta </literal>. With the new model, we would now do
+ something like the following, using the built-in <literal>
+ deployment </literal> tag that is created for that purpose:
+<programlisting>
+>>> AddNodeGroup('alphanodes','deployment','alpha')
+21
+>>> AddNodeGroup('betanodes','deployment','beta')
+21
+>>> for ng in GetNodeGroups(['alphanodes','betanodes'],['groupname','node_ids']): print ng
+{'groupname': u'alphanodes', 'node_ids': []}
+{'groupname': u'betanodes', 'node_ids': []}
+>>> SetNodeDeployment('vnode01.inria.fr','alpha')
+>>> for ng in GetNodeGroups(['alphanodes','betanodes'],['groupname','node_ids']): print ng
+{'groupname': u'alphanodes', 'node_ids': [1]}
+{'groupname': u'betanodes', 'node_ids': []}
+>>> SetNodeDeployment('vnode01.inria.fr','beta')
+>>> for ng in GetNodeGroups(['alphanodes','betanodes'],['groupname','node_ids']): print ng
+{'groupname': u'alphanodes', 'node_ids': []}
+{'groupname': u'betanodes', 'node_ids': [1]}
+</programlisting>
+</para>
+