Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Commits on Apr 21, 2010
  1. update tags

    convert-repo authored
Commits on Oct 21, 2003
  1. Updated as per tytso's comments.

    lmb authored
Commits on Aug 7, 2003
  1. DocBook version of the resource agent spec

    david authored
Commits on Aug 1, 2003
  1. Fixing spelling errors

    ragnar authored
  2. Fixes pointed out by horms.

    lmb authored
    Various spelling fixes and a vi accident for section 5.1/5.2 were
Commits on Jul 30, 2003
  1. Changes discussed at the OLS2003 meeting as well as changes required to

    lmb authored
    make them consistent.
Commits on Jun 14, 2003
  1. From a posting from Joe DiMartino dated 12/19/2002:

    alanr authored
    Hello OCF!
    Here is a cut at the event notification API without membership, etc.
    I have gutted most of the extra text about the scope and context that
    this event service expects.
    Note: I have not spent any time to figure out the docbook format that
    was suggested.  It's still ascii, but changed to be more man-page'ish.
    h1. removed all non-event subject matter (membership, etc)
    h2. name changes for clarity:
    		replaced 'register' with 'subscribe',
    		replaced 'class' with 'topic',
    		replaced 'callback' with 'on_event'
    h3. added get_event() interface
    h4. changed semantics of handle_events() to differ from get_event().
    	get_event() is the manual way to process events and requires
    	the use of poll/select and a file descriptor.  handle_events()
    	[notice the plural now] will pass control to the event service
    	to make calling the on_event functions seem more automatic and
    	less like a clunky get_event().
    Outstanding issues:
    i1.  file descriptor vs. event descriptor (was token)
    	If you recall, v0.2 returned a "token" from register() that
    	was passed to subsequent calls and needed to be converted to
    	a file descriptor for poll/select.  A poll/select is inevitable
    	in this programming model, so in v0.3 the token was removed
    	and a file descriptor was returned instead.  This cut out the
    	middle man (and a function or two), but Ram seems to still
    	want a token of some sort.
    	In this go, you will notice an "event descriptor" that takes
    	the place of the v0.2 token.  There is also a way to convert
    	the ed into a file descriptor.  I would prefer to put it back
    	to a simple file descriptor.
    i2. on_event function replacement
    	In v0.2, there was a "set_callback" routine to swap out the
    	current on_event (callback) function.  That was removed in
    	v0.3 because many thought it was extra complexity that would
    	not be useful.  Alan disagrees, however, and wants it back in.
    	It is still absent from this pre-draft.
    i3. publish interfaces
    	This partial pre-draft still does not cover message allocation,
    	message stuffing, and message/event publishing interfaces.
    i4. distributed vs. local
    	There was some discussion once about the scope of delivery for
    	events.  If an instance of the event service runs on every node
    	in a cluster, should all events in each event topic be seen at
    	all locations?  Or, should there be some provision for "local
    	only" topics, such as "this node's connectivity".
    	In addition, making the event service available as a cluster-
    	wide service (for applications external to the cluster) has
    	slightly different implications than an event service intended
    	for the cluster (internal) components.
    i5. creation of event topics
    	This is not covered yet.  It can be done administratively or
    	with programming interfaces or both.  This issue is tightly
    	coupled with #i4, as there may be a need to specify "local" or
    	"global" at topic creation time.  In either case, there is
    	an event name space issue if it needs to be kept coherent
    	across the cluster.
    I'm sure there are more outstanding issues, but I can't think of them
    just now...
    As ever, happy reading.
    Happy Holidays!
    - Joe DiMartino
  2. From a posting from Joe DiMartino dated 8/16/2002.

    alanr authored
    Not too long ago, in a discussion far far away...
    there was talk about using separate file descriptors per event class,
    and other simplifications of the API interfaces.  The topic quickly
    changed to partial membership and other semantic changes to the
    membership events.  Then a series of synchronous interfaces were
    proposed to replace the asynchronous callbacks.
    Updates to the draft API document were delayed while discussions
    continued in the hopes of incorporating partial membership semantics
    along with the promised separate file descriptor support.
    Bottom line: The partial membership stuff will take longer to sort
    out, and I wanted to commit the rest to paper before I forgot. :-)
    This draft proposal updates the programming interface (API) section
    to match the examples posted previously, and provides support for
    separate file descriptors per event class.  It does NOT include any
    updates (except for typos and clarifications) to the membership events
    and their semantics - i.e., partial membership is still not covered yet.
    Also, this document does not include any of the proposed synchronous
    get_* interfaces.
    Best regards,
    - Joe DiMartino
  3. From a posting from Joe DiMartino dated 4/12/2002:

    alanr authored
    Hello OCF list,
    Enclosed, please find the initial draft proposal for the Cluster Event
    Notification API (v0.1).
    As suggested by Bruce Walker on a previous OCF posting, we have decided
    to give only one part of this document at a time for general review.
    This document will EVENTUALLY cover:
    	a. event notification service
    	b. connectivity events and semantics
    	c. membership events and semantics
    	d. group messaging events and semantics
    Currently, this text covers only (a).  The Data Structures section
    hints at some events for (b) (c) and (d), but please don't dwell on
    that now.
    The examples section is intended to increase the understanding of
    the event model.  However, there are no examples of in-kernel usage
    and three user-level examples are combined into one.
    Happy Reading!
    - Ram Pai and Joe DiMartino
Commits on Jun 12, 2003
  1. Switched the unode field to the uniqueid field as requested by the ma…

    alanr authored
    list.  This change origianlly dated Wed Oct 30 17:18:44 2002 UTC.
  2. Added first version of oc_membership.h to CVS repository.

    alanr authored
    Original was dated 1 October, 2003.
  3. Updated the XML example to LMB's latest version as of

    alanr authored
  4. Added LMB's first version of the DTD to CVS.

    alanr authored
  5. Lars' most recent set of changes.

    alanr authored
    None of these changes had hit the mailing list, so I left out one particular
    change which we hadn't agreed on.  The rest are minor...
  6. Changes from Lars Marowsky-Bree dated 7/31/2002.

    alanr authored
    Minor clarifications.
  7. Update from Lars Marowsky-Bree dated 6/13/2002. His comments on the m…

    alanr authored
    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
      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
      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
    - 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.
  8. Removed a file whose name I misspelled :-(

    alanr authored
  9. First version of Resource Agent DTD document.

    alanr authored
    Dated 3/15/2002 from Lars Marowsky-Bree.
  10. Update from LMB dated 3/15/2002.

    alanr authored
  11. Lars' first version of this document.

    alanr authored
  12. I added this directory by mistake.

    alanr authored
  13. Initial revision

    alanr authored
Something went wrong with that request. Please try again.