Update from Lars Marowsky-Bree dated 6/13/2002. His comments on the mailing
list are below:

Changes which have been incorporated:

• Meta-data no longer read from a static file, but queried from the Resource Agent itself via a "meta-data" query.

• Path to the RA changed; they now reside in /usr/ocf/resource.d/<VendorTag>/<ResourceAgent>
  
  See section 3.2 for details.

• The dependencies have been reworked; they are now _strictly_ meant to provide a start/stop ordering similiar to the LSB init setup.
  
  This also means that we'll have to come up with a naming scheme for the dependencies; we should borrow as much as possible from the LSB work here.
  
  I have dropped all references to more complex dependencies for now.
  
  Smarter dependency handling is left to the implementation for now.

• The meta-data now has a container where vendor specific information can be stored. See 5.4. for details.

• action "validate-all" to validate the instance parameters added.
  
  See 3.4.x and 3.6.3
  
  I believe that "validate-field" would be a mistake; calling the RA (potentially on another node) for each field entered would incur a slowdown for the UI and make it user-unfriendly. I admit I don't have a good idea how to do it better.

• The meta-data only supports string / integer / boolean type fields for now, as well as a static default value for them.
  
  Yes, this is "inadequate" from a UI point of view, but lets conclude we will NOT solve the format-description / dynamic validation problem within a reasonable amount of time and postpone this until someone comes up with an actually sensible idea. Let's conclude that we aren't UI gurus and make it someone else's problem; they can start with putting their UI-specific stuff into the vendor sections.
  
  Validation is - for now - left to the RA via the validate-all action.
  
  Keep in mind that the meta-data _does_ have provision for localized parameter descriptions; a cluster admin should hopefully be able to read these.

TODO:

• Dependency naming scheme

• We need a "ready to run" query action for resources with primary/secondary properties, like drbd or mirrored databases; in general, where only one node can bring up the resources or where there is a significant cost difference between multiple nodes.