Page History

...

// ProvisioningSpec defines the desired state of Provisioning
type ProvisioningSpec struct {
        Masters []Master `json:"master,omitempty"`
        Workers []Worker `json:"worker,omitempty"`
        Replicas int32  `json:"replicas,omitempty"`
}

// ProvisioningStatus defines the observed state of 
// Provisioning
type ProvisioningStatus struct {
        // Names of provisioning agent pods when a deployment
        // is running
        PodAgents []string `json"podAgents,omitempty"`
}
// Provisioning is the Schema for the provisionings API
type Provisioning struct {
        metav1.TypeMeta   `json:",inline"`
        metav1.ObjectMeta `json:"metadata,omitempty"`

        Spec   ProvisioningSpec   `json:"spec,omitempty"`
        Status ProvisioningStatus `json:"status,omitempty"`
}

// ProvisioningList contains a list of Provisioning
type ProvisioningList struct {
        metav1.TypeMeta `json:",inline"`
        metav1.ListMeta `json:"metadata,omitempty"`
        Items           []Provisioning `json:"items"`
}

// master struct contains resource requirements for a master 
// node
type Master struct {
        CPU int32      `json:"cpu,omitempty"`
        Memory string  `json:"memory,omitempty"`
}

// worker struct contains resource requirements for a worker node
type Worker struct {
        CPU int32      `json:"cpu,omitempty"`
        Memory string  `json:"memory,omitempty"`
        SRIOV bool     `json:"sriov,omitempty"`
        QAT  bool      `json:"qat,omitempty"`
}

...

// ProvisioningSpec defines the desired state of Provisioning

type ProvisioningSpec struct {

        Masters []Master `json:"master,omitempty"`

        Workers []Worker `json:"worker,omitempty"`

        Replicas int32  `json:"replicas,omitempty"`

}

// ProvisioningStatus defines the observed state of 

// Provisioning

type ProvisioningStatus struct {

        // Names of provisioning agent pods when a deployment

        // is running

        PodAgents []string `json"podAgents,omitempty"`

}

// Provisioning is the Schema for the provisionings API

type Provisioning struct {

        metav1.TypeMeta   `json:",inline"`

        metav1.ObjectMeta `json:"metadata,omitempty"`

        Spec   ProvisioningSpec   `json:"spec,omitempty"`

        Status ProvisioningStatus `json:"status,omitempty"`

}

// ProvisioningList contains a list of Provisioning

type ProvisioningList struct {

        metav1.TypeMeta `json:",inline"`

        metav1.ListMeta `json:"metadata,omitempty"`

        Items           []Provisioning `json:"items"`

}

// master struct contains resource requirements for a master 

// node

type Master struct {

        CPU int32      `json:"cpu,omitempty"`

        Memory string  `json:"memory,omitempty"`

}

// worker struct contains resource requirements for a worker node

type Worker struct {

        CPU int32      `json:"cpu,omitempty"`

        Memory string  `json:"memory,omitempty"`

        SRIOV bool     `json:"sriov,omitempty"`

        QAT  bool     `json:"qat,omitempty"`

}

The variables in the ProvisioningSpec struct are used to create the data structures in the yaml spec for the custom resource. Three variables are added to the ProvisioningSpecstruct;

1. Masters: This variable will contain an array of Master objects. The master struct as defined in the *-types.go file above contains CPU and memory information, this information would be used by the BPA operator to determine which compute nodes to assign the role of Master to when it gets the baremetal list from the API server.
2. Workers: This variable will contain an array of Worker objects. Similar to the case of the Masters variables, the Worker struct will contain resource requirements for the Worker nodes and the BPA operator will use this information to determine which hosts to assign the role of worker.
3. Replicas: An integer that defines the number of pods that should run when the CR is deployed.

In the ProvisioningStatus struct, the podAgents variable is defined. This variable will display a list of the names of the pods that are part of the provisioning agent deployment when the status of the deployment is queried.5.3. Sample

 Sample Provisioning CR YAML file

...

apiVersion: bpa.akraino.org/v1alpha1

...

kind: Provisioning

...

metadata:

...

  name: provisioning-sample

...

spec:

...

  master:

    cpu: 10

    memory: 4Gi

  worker:

    cpu: 20

    memory: 8Gi

...

  master:
    cpu: 10
    memory: 4Gi
  worker:
    cpu: 20
    memory: 8Gi
  replicas: 2

The YAML file above can be used to create a provisioning custom resource which is an instance of the provisioning CRD describes above. The spec.master field corresponds to the Masters variable in the ProvisioningSpec struct of the *-types.go file, while the  spec.worker field corresponds to the Workers variable in the ProvisioningSpec struct of the *-types.go file and the spec.replica field corresponds to the Replicas variable in the same struct. 

...

The replicas spec tells the controller that in this CR deployment, at any instance, there should be 2 pods running the provisioning agent. If a pod dies, the controller reconciles this and immediately starts a new pod running the provisioning agent.

Open Questions

1. How does the BPA operator get the SSH information of the compute hosts ?

Future Work

      This This proposal would make it possible to assign roles to nodes based on the features discovered. Currently, the proposal makes use of CPU, memory, SRIOV and QAT. However the baremetal operator list returns much more information about the nodes, we would be able to extend this feature to allow the operator assign roles based on more complex requirements such as CPU model. This would feed into Hardware Platform Awareness (HPA)

References

1. https://wiki.akraino.org/pages/viewpage.action?pageId=11995877&show-miniview
2. https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#advanced-topics

...