/
model_component_array_post_query.go
53 lines (52 loc) · 12.8 KB
/
model_component_array_post_query.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/*
* Hardware State Manager API
*
* The Hardware State Manager (HSM) inventories, monitors, and manages hardware, and tracks the logical and dynamic component states, such as roles, NIDs, and other basic metadata needed to provide most common administrative and operational functions. HSM is the single source of truth for the state of the system. It contains the component state and information on Redfish endpoints for communicating with components via Redfish. It also allows administrators to create partitions and groups for other uses. ## Resources ### /State/Components HMS components are created during inventory discovery and provide a higher-level representation of the component, including state, NID, role (i.e. compute/service), subtype, and so on. Unlike ComponentEndpoints, however, they are not strictly linked to the parent RedfishEndpoint, and are not automatically deleted when the RedfishEndpoints are (though they can be deleted via a separate call). This is because these components can also represent abstract components, such as removed components (e.g. which would remain, but have their states changed to \"Empty\" upon removal). ### /Defaults/NodeMaps This resource allows a mapping file (NodeMaps) to be uploaded that maps node xnames to Node IDs, and optionally, to roles and subroles. These mappings are used when discovering nodes for the first time. These mappings should be uploaded prior to discovery and should contain mappings for each valid node xname in the system, whether populated or not. Nodemap is a JSON file that contains the xname of the node, node ID, and optionally role and subrole. Role can be Compute, Application, Storage, Management etc. The NodeMaps collection can be uploaded to HSM automatically at install time by specifying it as a JSON file. As a result, the endpoints are then automatically discovered by REDS, and inventory discovery is performed by HSM. The desired NID numbers will be set as soon as the nodes are created using the NodeMaps collection. It is recommended that Nodemaps are uploaded at install time before discovery happens. If they are uploaded after discovery, then the node xnames need to be manually updated with the correct NIDs. You can update NIDs for individual components by using PATCH /State/Components/{xname}/NID. ### /Inventory/Hardware This resource shows the hardware inventory of the entire system and contains FRU information in location. All entries are displayed as a flat array. ### /Inventory/HardwareByFRU Every component has FRU information. This resource shows the hardware inventory for all FRUs or for a specific FRU irrespective of the location. This information is constant regardless of where the hardware item is currently in the system. If a HWInventoryByLocation entry is currently populated with a piece of hardware, it will have the corresponding HWInventoryByFRU object embedded. This FRU info can also be looked up by FRU ID regardless of the current location. ### /Inventory/Hardware/Query/{xname} This resource gets you information about a specific component and it's sub-components. The xname can be a component, partition, ALL, or s0. Both ALL and s0 represent the entire system. ### /Inventory/RedfishEndpoints This is a BMC or other Redfish controller that has a Redfish entry point and Redfish service root. It is used to discover the components managed by this endpoint during discovery and handles all Redfish interactions by these subcomponents. If the endpoint has been discovered, this entry will include the ComponentEndpoint entries for these managed subcomponents. You can also create a Redfish Endpoint or update the definition for a Redfish Endpoint. The xname identifies the location of all components in the system, including chassis, controllers, nodes, and so on. Redfish endpoints are given to State Manager. ### /Inventory/ComponentEndpoints Component Endpoints are the specific URLs for each individual component that are under the Redfish endpoint. Component endpoints are discovered during inventory discovery. They are the management-plane representation of system components and are linked to the parent Redfish Endpoint. They provide a glue layer to bridge the higher-level representation of a component with how it is represented locally by Redfish. The collection of ComponentEndpoints can be obtained in full, optionally filtered on certain criteria (e.g. obtain just Node components), or accessed by their xname IDs individually. ### /Inventory/ServiceEndpoints ServiceEndpoints help you do things on Redfish like updating the firmware. They are discovered during inventory discovery. ### /groups Groups are named sets of system components, most commonly nodes. A group groups components under an administratively chosen label (group name). Each component may belong to any number of groups. If a group has exclusiveGroup=<excl-label> set, then a node may only be a member of one group that matches that exclusive label. For example, if the exclusive group label 'colors' is associated with groups 'blue', 'red', and 'green', then a component that is part of 'green' could not also be placed in 'red'. You can create, modify, or delete a group and its members. You can also use group names as filters for API calls. ### /partitions A partition is a formal, non-overlapping division of the system that forms an administratively distinct sub-system. Each component may belong to at most one partition. Partitions are used as an access control mechanism or for implementing multi-tenancy. You can create, modify, or delete a partition and its members. You can also use partitions as filters for other API calls. ### /memberships A membership shows the association of a component xname to its set of group labels and partition names. There can be many group labels and up to one partition per component. Memberships are not modified directly, as the underlying group or partition is modified instead. A component can be removed from one of the listed groups or partitions or added via POST as well as being present in the initial set of members when a partition or group is created. You can retrieve the memberships for components or memberships for a specific xname. ### /Inventory/DiscoveryStatus Check discovery status for all components or you can track the status for a specific job ID. You can also check per-endpoint discover status for each RedfishEndpoint. Contains status information about the discovery operation for clients to query. The discover operation returns a link or links to status objects so that a client can determine when the discovery operation is complete. ### /Inventory/Discover Discover subcomponents by querying all RedfishEndpoints. Once the RedfishEndpoint objects are created, inventory discovery will query these controllers and create or update management plane and managed plane objects representing the components (e.g. nodes, node enclosures, node cards for Mountain chassis CMM endpoints). ### /Subscriptions/SCN Manage subscriptions to state change notifications (SCNs) from HSM. You can also subscribe to state change notifications by using the HMS Notification Fanout Daemon API. ## Workflows ### Add and Delete a Redfish Endpoint #### POST /Inventory/RedfishEndpoints When you manually create Redfish endpoints, the discovery is automatically initiated. You would create Redfish endpoints for components that are not automatically discovered by REDS or MEDS. #### GET /Inventory/RedfishEndpoints Check the Redfish endpoints that have been added and check the status of discovery. #### DELETE /Inventory/RedfishEndpoints/{xname} Delete a specific Redfish endpoint. ### Perform Inventory Discovery #### POST /Inventory/Discover Start inventory discovery of a system's subcomponents by querying all Redfish endpoints. If needed, specify an ID or hostname (xname) in the payload. #### GET /Inventory/DiscoveryStatus Check the discovery status of all Redfish endpoints. You can also check the discovery status for each individual component by providing ID. ### Query and Update HMS Components (State/NID) #### GET /State/Components Retrieve all HMS Components found by inventory discovery as a named (\"Components\") array. #### PATCH /State/Components/{xname}/Enabled Modify the component's Enabled field. #### DELETE /State/Components/{xname} Delete a specific HMS component by providing its xname. As noted, components are not automatically deleted when RedfishEndpoints or ComponentEndpoints are deleted. ### Create and Delete a New Group #### GET /hsm/v2/State/Components Retrieve a list of desired components and their state. Select the nodes that you want to group. #### POST /groups Create the new group with desired members. Provide a group label (required), description, name, members etc. in the JSON payload. #### GET /groups/{group_label} Retrieve the group that was create with the label. #### GET /State/Components/{group_label} Retrieve the current state for all the components in the group. #### DELETE /groups/{group_label} Delete the group specified by {group_label}. ## Valid State Transitions ``` Prior State -> New State - Reason Ready -> Standby - HBTD if node has many missed heartbeats Ready -> Ready/Warning - HBTD if node has a few missed heartbeats Standby -> Ready - HBTD Node re-starts heartbeating On -> Ready - HBTD Node started heartbeating Off -> Ready - HBTD sees heartbeats before Redfish Event (On) Standby -> On - Redfish Event (On) or if re-discovered while in the standby state Off -> On - Redfish Event (On) Standby -> Off - Redfish Event (Off) Ready -> Off - Redfish Event (Off) On -> Off - Redfish Event (Off) Any State -> Empty - Redfish Endpoint is disabled meaning component removal ``` Generally, nodes transition 'Off' -> 'On' -> 'Ready' when going from 'Off' to booted, and 'Ready' -> 'Ready/Warning' -> 'Standby' -> 'Off' when shutdown.
*
* API version: 1.0.0
* Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
*/
package hsm_client
// There are limits to the length of an HTTP URL and query string. Hence, if we wish to query an arbitrary list of XName/IDs, it will need to be in the body of the request. This object is used for this purpose. It is similar to the analogous GET operation.
type ComponentArrayPostQuery struct {
// An array of XName/ID values for the components to query.
ComponentIDs []string `json:"ComponentIDs,omitempty"`
// Partition name to filter on, as per current /partitions/names
Partition string `json:"partition,omitempty"`
// Group label to filter on, as per current /groups/labels
Group string `json:"group,omitempty"`
// Return only component state and flag fields (plus xname/ID and type). Results can be modified and used for bulk state/flag- only patch operations.
Stateonly bool `json:"stateonly,omitempty"`
// Return only component flag field (plus xname/ID and type). Results can be modified and used for bulk flag-only patch operations.
Flagonly bool `json:"flagonly,omitempty"`
// Return only component role and subrole fields (plus xname/ID and type). Results can be modified and used for bulk role-only patches.
Roleonly bool `json:"roleonly,omitempty"`
// Return only component NID field (plus xname/ID and type). Results can be modified and used for bulk NID-only patches.
Nidonly bool `json:"nidonly,omitempty"`
// Retrieve all components with the given HMS type.
Type_ []string `json:"type,omitempty"`
// Retrieve all components with the given HMS state.
State []string `json:"state,omitempty"`
// Retrieve all components with the given HMS flag value.
Flag []string `json:"flag,omitempty"`
// Retrieve all components with the given enabled status (true or false).
Enabled []string `json:"enabled,omitempty"`
// Retrieve all components with the given software status. Software status is a free form string. Matching is case-insensitive.
Softwarestatus []string `json:"softwarestatus,omitempty"`
// Retrieve all components (i.e. nodes) with the given HMS role
Role []string `json:"role,omitempty"`
// Retrieve all components (i.e. nodes) with the given HMS subrole
Subrole []string `json:"subrole,omitempty"`
// Retrieve all components with the given HMS subtype.
Subtype []string `json:"subtype,omitempty"`
// Retrieve all components with the given architecture.
Arch []string `json:"arch,omitempty"`
// Retrieve all components (i.e. nodes) with the given HMS hardware class. Class can be River, Mountain, etc.
Class []string `json:"class,omitempty"`
// Retrieve all components (i.e. one node) with the given integer NID
Nid []string `json:"nid,omitempty"`
// Retrieve all components (i.e. nodes) with NIDs equal to or greater than the provided integer.
NidStart []string `json:"nid_start,omitempty"`
// Retrieve all components (i.e. nodes) with NIDs less than or equal to the provided integer.
NidEnd []string `json:"nid_end,omitempty"`
}