5.1.1: Standards: vDevice Control Plane

Control Plane

The Control Plane is a central component responsible for facilitating interaction between external users or systems and the internal behaviour of both virtual devices (vComponents) and physical rack setups. Control messages are used to configure and control devices, whether they're virtual or physically connected racks, depending on the platform configuration. 

Key Points

• WebSocket Interface (for vDevices):

  • When dealing with virtual devices (vComponents), the Control Plane exposes a WebSocket server that provides a connection for external stimulus.
  • Test users, automation tools, or other systems use this WebSocket interface to send control messages to virtual components in real-time.

• Control for Physical Rack Setups:

  • In a physical rack setup, the WebSocket is not used. Instead, the ControlPlaneClass interprets the control messages, determining whether they are intended for a virtual device or a physical rack, and converts them into commands that control the physical rack via python_raft control classes.   - If the message involves controlling external hardware, the ControlPlaneClass uses the python_raft control classes to handle the necessary configurations and manage the rack’s hardware interactions.

• Control Messages:

  • Control messages are structured using YAML format and are designed to control both virtual and physical setups based on the system configuration.
  • The same message format can apply to both virtual and physical environments. For instance, a command to power on a device could either trigger an action on a virtual HDMI device or, if connected externally to a rack, control the actual hardware via python_raft.
  • The ControlPlaneClass interprets each message and routes it to the appropriate target—either via a WebSocket to a virtual device or through python_raft to a physical rack.

• Unified Message Handling:

  • The Control Plane seamlessly handles both virtual and physical environments by using the same control message structure. The ControlPlaneClass decides whether the message is targeting a virtual device or a physical rack, ensuring flexible and unified control.   - For virtual devices, the control message is routed through a WebSocket to the relevant vComponent.   - For physical racks, the control message is processed by the ControlPlaneClass, which converts it into commands for the python_raft control classes to configure and control the hardware directly.

• Python Raft Integration:

  • When using python_raft, the system sends control messages to the ControlPlaneClass, which interprets them and interacts with the python_raft control classes to manage the physical hardware.   - If the system is configured for virtual devices, the ControlPlaneClass will instead forward the message via the WebSocket to the relevant vComponent.

Control Plane Workflow

1. Message Reception

The ControlPlaneClass receives control messages. Depending on the nature of the message and the platform configuration, it determines whether the message is targeting a virtual device or an external rack setup.

• vDevice Setup: The control message is sent through the WebSocket and processed by the vDevice Controller, which forwards the message to the appropriate vComponent.
• Rack Setup: If the message requires controlling external hardware, the ControlPlaneClass converts the message into specific commands for the python_raft control classes, which then control the rack hardware.

2. Message Routing

• For virtual components, the message is routed through the WebSocket to the relevant vComponent, which processes the message and acts accordingly.
• For rack setups, the ControlPlaneClass uses the python_raft control classes to control the hardware directly, without the need for a WebSocket.

3. Component or Rack Response

• vComponents interpret and execute the control message, triggering actions such as powering on a device, switching inputs, or sending callbacks.

• Rack setups receive the control commands from python_raft, and the hardware is configured or controlled based on the instructions in the message (e.g., powering on, connecting devices, etc.).

Considerations for Control Plane Messages

• Unified Message Structure: Control messages for both virtual and physical environments are unified and pre-defined. The ControlPlaneClass interprets these messages and determines the target (virtual or physical) based on the platform configuration.
• Platform Configuration: The ControlPlaneClass determines the appropriate actions based on the nature of the message and the system’s platform configuration—whether it's a virtual or physical (rack) environment.
• Logging and Debugging: Debugging tools will capture control messages and their processing outcomes to ensure smooth operation and easy diagnosis in both virtual and physical setups.

Advantages of Using the Control Plane

• Unified Control for Mixed Environments: The same control plane can manage both virtual devices and physical racks, ensuring seamless control across environments.
• Modular and Scalable: New vComponents or additional physical rack configurations can easily be integrated into the system using the same control message structure.
• Real-time Configuration: The WebSocket interface (for vDevices) and the python_raft control classes (for racks) allow real-time control of both virtual and physical systems.
• Platform-agnostic Flexibility: The Control Plane adapts to the environment, whether it’s controlling virtual test environments or physical hardware, making it a versatile tool for a wide range of deployment scenarios.

Overview of expected operation

graph TD
    subgraph ControlPlaneClass
        A(Control Plane) -->|Message Routing| B{Platform Configuration}
    end
    
    B -->|vDevice| C[WebSocket Interface]
    B -->|Rack Setup| D[python_raft Control Classes]
    
    subgraph vDevice Setup
        C --> E[vComponent 1]
        C --> F[vComponent 2]
        C --> G[vComponent N]
    end

    subgraph Rack Setup
        D --> M[Control Component 1]
        D --> N[Control Component 2]
        D --> O[Control Component N]
        M --> H[Rack Hardware 1]
        N --> I[Rack Hardware 2]
        O --> J[Rack Hardware N]
    end

    A -. External stimulus .-> K[Test User]
    K --> A

Loading