Indiana University comments on OMIS use Cases

 Posted on the OMIS-wiki…..

Comments on OMIS Use Cases (and other OMIS issues)

Michael raised several issues in his latest message about OMIS Use Cases.  We would like to add a bit to that discussion in two areas, ticket terminology and notifications and operational data sharing.

Ticket Terminology

Michael raised a question of terminology confusion between “trouble tickets” and “resource tickets” if both are called “tickets”.   We have a suggestion here.  It seems to us that one way to eliminate this confusion is to talk about tickets and tokens.  A component issues a token (or resource token [RT]) that can be redeemed for services.  These tokens are directed toward a Clearinghouse (and perhaps later used in a conversation between the Clearinghouse and an experiment).  A trouble ticket (TT) would be created by a NOC (Aggregate Ops or GENI Ops), and would describe a problem (current issue) or an event (future issue).  A TT would (could) be shared with a Clearinghouse and experimenters.  But, tokens and tickets would be issued by different entities (components and Ops).

Notifications and operational data sharing

The very pervasive issue of “notifications” and operational data sharing seems to be a crucial area that deserves detailed discussion.  An open question posed by Michael in all Use Cases relates to how interrelated experiments would notify each other about service issues.  The issue of notifications seems one of basic importance to operations, and one which cuts across all of the use cases mentioned.  As Michael states, notification is a difficult and problematic area.  Should notifications come from a myriad of NOCs, or be channeled through some kind of normalizing system to coordinate and standardize the notifications?  Who does Ops (GENI or Aggregate) notify about outages (emergency or scheduled)?  How does an experiment, end user, or aggregate signal its desire to receive notices?  How do notification recipients signal what type of notifications they want to receive, and how they want to receive them?  How does an experiment or an aggregate signal its intention to send out notices reflecting its internal state?  These issues are already complex even for networks that are simpler and less federated, such as the NLR and Internet2 networks.   We’ve already begun to see keen interest in developing a rich mix of push/pull notifications of customized granularity and audience.  Some in the community want to see only a very small set of notifications for very specific things.  Others want to see everything they can.  Some want a simple system to “poll” for network status information.  Others want notifications to be pushed out very aggressively through a number of channels.  Given the diversity of audience for GENI-related notifications, this will only be more complicated (and important) for GENI.

Here are some initial ideas based on our experience.

1. Any notification feature must be automated as much as possible.  This will have implications for (among other things) the data structure that describes experiments, aggregates and clearinghouses.  This seems obvious.  But, this network will be way too complex for much “operator intervention” at the notification level.
2. For notification information to be exchanged there must be some process for information providers (the ones producing notifications) and information consumers (the ones wanting to see notifications) to opt-in, and authorize the exchange of information.  This process must be strict enough to protect against information flooding or leaking, but must also be simple enough so it doesn’t become a roadblock to research information sharing and so it doesn’t inadvertently slow down operational troubleshooting and maintenance.
3. Standards for notification formats could be very helpful. If notifications can be sent in a standardized format, the Aggregate owners and Experimenters can use the notifications programmatically. This could be to update the aggregates trouble ticketing system or to change the configuration/ suspend an experiment.