D.3. Inheritance, the <resources> Block, and Reusing Resources

D.3. Inheritance, the <resources> Block, and Reusing Resources

Some resources benefit by inheriting values from a parent resource; that is commonly the case in an NFS service. Example D.5, “NFS Service Set Up for Resource Reuse and Inheritance” shows a typical NFS service configuration, set up for resource reuse and inheritance.

<resources>
  <nfsclient name="bob" target="bob.test.com" options="rw,no_root_squash"/>
  <nfsclient name="jim" target="jim.test.com" options="rw,no_root_squash"/>
  <nfsexport name="exports"/>
</resources>
<service name="foo">
  <fs name="1" mountpoint="/mnt/foo" device="/dev/sdb1" fsid="12344">
    <nfsexport ref="exports">  <!-- nfsexport's path and fsid
        attributes are inherited from the mountpoint and fsid
	attribute of the parent fs resource -->
    <nfsclient ref="bob"/> <!-- nfsclient's path is inherited
        from the mountpoint and the fsid is added to the options
	string during export -->
    <nfsclient ref="jim"/ >
  </nfsexport>
</fs>
<fs name="2" mountpoint="/mnt/bar" device="/dev/sdb2" fsid="12345">
  <nfsexport ref="exports">
    <nfsclient ref="bob"/> <!-- Because all of the critical
       data for this resource is either defined in the resources block
       or inherited, we can reference it again! -->
    <nfsclient ref="jim"/>
  </nfsexport>
</fs>
<ip address="10.2.13.20"/>
</service>
Example D.5. NFS Service Set Up for Resource Reuse and Inheritance

If the service were flat (that is, with no parent/child relationships), it would need to be configured as follows:

In Example D.5, “NFS Service Set Up for Resource Reuse and Inheritance” however, the NFS client resources nfsclient:bob and nfsclient:jim are defined once; likewise, the NFS export resource nfsexport:exports is defined once. All the attributes needed by the resources are inherited from parent resources. Because the inherited attributes are dynamic (and do not conflict with one another), it is possible to reuse those resources — which is why they are defined in the resources block. It may not be practical to configure some resources in multiple places. For example, configuring a file system resource in multiple places can result in mounting one file system on two nodes, therefore causing problems.


Note: This documentation is provided {and copyrighted} by Red Hat®, Inc. and is released via the Open Publication License. The copyright holder has added the further requirement that Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. The CentOS project redistributes these original works (in their unmodified form) as a reference for CentOS-5 because CentOS-5 is built from publicly available, open source SRPMS. The documentation is unmodified to be compliant with upstream distribution policy. Neither CentOS-5 nor the CentOS Project are in any way affiliated with or sponsored by Red Hat®, Inc.