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.
>
> • 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.
> • 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.
> • 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.
>
>
> _______________________________________________
> omis-wg mailing list
> omis-wg@...
> http://lists.geni.net/mailman/listinfo/omis-wg