Namespaces

Registered by Lin Yang on 2016-10-05

Create namespaces which can be used with host aggregates of rackscale system to separate groups of systems. The umbrella namespaces within the Rack Scale Architecture are labeled “RSA” and “non-RSA” depending on how Rack Scale Architecture and non- Rack Scale Architecture resources are partitioned. All further namespaces are applicable only within the umbrella of an “RSA” namespace. The following are examples of namespaces that could be defined within the Rack Scale Architecture:
1. Location Namespace – Nested namespaces based on Pod/Rack/Drawer location hierarchy of the compute module
2. VLAN Namespace – Namespace defined based on VLANs created on the Drawer switch
3. Security Namespace
4. Power-Thermal Namespace – Namespace created on physical power delivery and thermal management data
5. Storage Namespace
6. QoS Namespace

1. At startup, the Controller enumerates the existing Rack Scale Architecture resources and creates a set of default namespaces. For example, a top level Pod-namespace is created and all the Racks are enumerated to create a namespace for each one of them; the Drawers in each rack are then enumerated to create “Drawer-namespace”.
2. An end-user instantiates a new VM. The VM flavor captures its resource requirements.
3. The scheduler determines the candidate host on which the VM should land. This is a scheduler that is Rack Scale Architecture-aware, therefore, the candidate host could be one which is not yet composed.
4. If the candidate host is available, then VM is spawned on it.
5. Else, OpenStack pauses instantiation and issues a request to the Controller to compose a new node. Host resource requirements are derived from the flavor and passed to the Controller.
6. Rack Scale Architecture Controller composes a new node in response to the request.
7. It sets up appropriate parameters on platform components (on host, Drawer Switch, TORS) based on the requirements received. For example, set network bandwidth to 1Gbps instead of 10Gbps.
8. The composed host is then added to appropriate namespaces. If a namespace doesn’t exist, then a new namespace is created. Host is powered-on.
9. Controller also adds the newly composed host to a new host-aggregate or existing host aggregate within OpenStack.
10. Controller signals to OpenStack that composition is complete.
11. OpenStack then resumes VM instantiation operation
12. If any of steps 6 to 10 fail, then the Controller sends an indication of the failure to OpenStack, which signals VM instantiation error with a message “No suitable host”.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Mrittika Ganguli
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

maliniB: This BP reads like a giant use case. Will benefit from being broken into smaller components. For instance, with respect to namespaces, each time a node is created, it will naturally have some pod/rack/draw affiliations. We could have a cloud-registration method that has different southbound implementations. For an OpenStack southbound implementation, it would result in registering the node with ironic or nova for bare metal versus virtual machine hosting, and also adding it to host aggregates such as rack-aggregate<i>, draw-aggregate<j> etc. The host aggregate labels would then play a role during regular OpenStack scheduling such as affinity and anti-affinity.

mganguli: OK. will break this down. (1) registration service (2)aggregate controller

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.