This blog entry shows how to stitch slices belonging to potentially different users together. The video demonstrates the workflow and a short discussion below outlines limitations of the current implementation.
Several API operations have been introduced to support slice-to-slice stitching:
- permitSliceStitch – informs controller that the owner of this reservation (node or VLAN, see below) is allowing stitching of other slices to this reservation using a specific password
- revokeSliceStitch – the inverse of permit, removes permission to stitch to any other slice. Existing stitches are not affected.
- performSliceStitch – stitch a reservation in one slice to a reservation in another slice using a password set by permitSliceStitch
- undoSliceStitch – undo an existing stitch between two reservations
- viewStitchProperties – inspect whether a given reservation allows stitching and whether there are active or inactive stitches from other slices
- provides information like slice stitched to, reservation stitched to, DN identifier of the owner of the other slice, when the stitch was performed and if unstitched, when.
Caveats and useful facts:
- Slices that you are attempting to stitch must be created by the same controller
- The reservations that you are trying to stitch together must be on the same aggregate/rack
- You cannot stitch pieces of the same slice to itself
- Only stitching of compute nodes (VMs and baremetal) to VLANs/links is allowed. This will not work for shared vlans or links connecting to storage (those aren’t real reservations in the ORCA sense)
- Stitching is asymmetric (one side issues permit, the other side performs the stitch)
- Unstitching is symmetric (either side can unstitch from the other, password is not required)
- Each stitching operation has a unique guid and this is how it is known in the system
- An inactive stitch is distinguished from an active stitch by the presence of ‘undone‘ property indicating date/time in RFC3399 format when the unstitching operation was performed
- Passwords (bearer tokens) used to authorize stitching operation are stored according to best security practices (salted and transformed). They are meant to be communicated between slice owners out-of-band (phone/email/SMS/IM/pigeons).
- Stitching to point-to-point links is allowed, however keep in mind that if you used automatic IP assignment, the two nodes that are the endpoints of the link will have a /30 netmask, which means if you stitch more nodes into that link, they won’t be able to communicate with existing nodes until you set a common broader netmask on all nodes
- Note that ORCA enforces IP address assignment by guest-side neucad tool running in the VM. If you are reassigning IP address manually on the node, remember to kill that daemon first, otherwise it will overwrite your changes.
- No NDL manifest support. Stitching is not visible in the manifest and can only be deduced by querying a node or a link for its stitching properties
- Consequently no RSpec manifest support
- No GENI API support