wiki:GeniOmisUseIntro

Version 1 (modified by Mike Patton, 14 years ago) (diff)

--

OMIS Use Cases

At the second GENI Engineering Conference Aaron Falk presented a Use Case for how a researcher would set up and operate an experiment. The main body didn't include much relevant to OMIS, but there was an additional "Mini Use Case" on a single slide that talked about emergency shutdown. Both of these started us thinking about how various operational uses would look.

These are some GENI Use Cases covering aspects of the OMIS WG's charter. They describe the steps that happen for several Operations events. These Use Cases have a common set of Actors and Assumptions which you may want to review before reading the actual Use Cases.

The Use Cases written up so far:

There's a terminology problem in all of the use cases that I haven't quite figured out how to deal with...the term "ticket" is used to refer to two very different things... I hope that, from context, it can always be figured out. The tickets that the NOC manages are for reporting and tracking problems and other events. Since these use cases are all about dealing with various operational incidents, these kinds of tickets feature prominently. There are also tickets issued by components, a cryptographic data structure, that promise resources and can be redeemed to get the service described on the ticket. When there's potential for confusion, the type the NOC deals with can be qualified as "trouble tickets", but the other kind doesn't have a similar adjective that can be applied.


If you have ideas for additional OMIS related use case(s) (since the ones written up so far are all O&M we could use a few I or S ones, or, for S, just expand the existing ones [including Aaron's?] to include all the security steps), please feel free to write them up or send suggestions to the mailing list (you have to join in order to post).

Open questions

There are some open questions common to all of these Use Cases:

  • In the use cases we speak of notifying someone related to the slice in question. But, when experiments are composed another experiment might be using the service in the affected slice, but otherwise not be connected to that slice. It would be nice if there was a way for any researcher to register an interest in events affecting a slice, so that researchers that are relying on some other experiment for a service can get included in tickets for slices in that experiment.