Supported Use Cases¶
This document makes a weak stab at articulating the use cases which
geni-lib is expected to support. This is in
an attempt to provide guidance on architecture decisions for new features to make sure we don’t break existing use
Exact Request Rspec Creation¶
The most basic use of
geni-lib is to write a small script whose sole purpose is to create a single rspec, from
a simple evaluation of end-to-end instructions. Such a use may involve basic parameters, but does not take input from
active querying of the federation. This provides code that is easy to edit to change behaviour, but otherwise is
indistinguishable from editing an XML file.
This use case should not be complicated.
Modular / Multi-rspec Creation¶
It is often useful to provide subtrees of resource definitions that are not complete Request objects (a specific VM disk image, memory/disk configuration and execution scripts, etc). These trees can then be composed into Request objects for novel topologies. In this vein, it is also useful to create more than one Request at a time, composing them together for issuing to separate aggregates.
It is valuable and must be possible for users to hold in memory multiple advertisement and manifest rspec wrappers at the same time. At the very minimum the following resource tuples must be able to exist in memory at the same time:
- (site, advertisement)
- (site, slice, manifest)
At the moment any number of instances of these combinations are supported - any change to restrict these instances to being unique (e.g. only one advertisement per site at a time, etc.) will have to be well justified.
Aggregate / Clearinghouse Actions¶
Users should be able to operate on many aggregates and clearinghouses in the same script. There is a current (and likely ongoing) requirement that the user only be configured to use one control framework (and credentials) at a time. If more than one CH supports the same credentials and API, they should be able to be used concurrently, as AMs also must. Users are responsible for completing all previous credentialed federation actions before changing the CF or credentials their context refers to.