Subauthorities
Sub-authorities
Overview
In general, sub-authorities are a GENI mechanism allowing any authority to (recursively) divide its namespace, and grant permissions to other principals to administer those namespace portions in a controlled way. So far, ProtoGENI makes use of this facility only to allow slice authorities to make Emulab project structure visible in the SA namespace (which in turn allows CMs involved in the slice to make policy decisions based on project membership, if they want to).
Conventions
Project URNs
Slices associated with a particular Emulab project follow a specific naming convention. Assuming the SA's URN is
urn:publicid:IDN+slice-authority.org+authority+sa
then a slice foo would ordinarily be named:
urn:publicid:IDN+slice-authority.org+slice+foo
However, if this slice were designated as belonging to the project bar, then the project name would be inserted as an extra level in the URN "authority" hierarchy, appearing like this:
urn:publicid:IDN+slice-authority.org:bar+slice+foo
Project URLs
Emulab SAs also offer per-project XMLRPC interfaces, which are essentially the same ordinary (flat) SA API, but the per-project sub-authorities are accessed at different URLs. There is no need for the URL naming scheme to be well-known or consistent, since the top-level SA will advertise all URLs when necessary, but it is documented here for completeness.
If the top-level SA is accessed at
https://www.slice-authority.org/protogeni/xmlrpc/sa
then the sub-SA corresponding to project bar will be found at
https://www.slice-authority.org/protogeni/xmlrpc/project/bar/sa
User procedure
From the user's perspective, the only difference between using the ordinary flat SA and a per-project SA is that the procedure to obtain a slice credential changes somewhat. (The Flack client is compatible with per-project slice credentials, but doesn't yet have a streamlined mechanism for requesting them. This is under consideration for future work.)
A user can bring up slivers within a per-project slice by following these steps:
- Create or join the appropriate project at the Emulab SA. There is currently no way to do this through any GENI interface; the user must log in to the Emulab web site, manage the project from there (e.g. using the "Join Existing Project" option in the "Experimentation" menu), and wait for approval.
- Discover the proper sub-SA URL to use. There are two possibilities
here:
- Ask the SA itself which projects and corresponding URLs to use.
A Resolve() call on the user URN will yield a list of
valid projects, and a URL for each of them. The lookupuser
test script can show this information --- invoke is as:
lookupuser.py -d name
where name is the user name in question (final component of the user URN). - If the user already knows the proper project to use and is familiar with the URL naming convention above, they can simply compute it themselves.
- Ask the SA itself which projects and corresponding URLs to use.
A Resolve() call on the user URN will yield a list of
valid projects, and a URL for each of them. The lookupuser
test script can show this information --- invoke is as:
- Register a slice with the sub-authority. This must be done with the
URL obtained in the previous step, but is otherwise identical to the
normal slice registration procedure. For example:
registerslice.py -l https://www.slice-authority.org/protogeni/xmlrpc/project/bar/sa -n subsatest
(Note that the slice name must be unique across ALL slices at the SA, not just the slices within the same project. This is a limitation of the current implementation, and not a general restriction.) - If the slice registration was successful, save a copy of the
slice credential from the sub-SA:
getslicecredential.py -l https://www.slice-authority.org/protogeni/xmlrpc/project/bar/sa -n subsatest > project-slice-credential
- From now on, the user can operate with the sub-SA slice credential exactly like any other -- it can be imported into Flack and used to bring up slivers, or it could be passed to the createsliver test script, etc.