As a user, I need to be able to provision bare metal resources from Service Catalogs

[alescernivec]

The idea is to provision pre-configured resources​: from the list of decommissioned servers the user should be able to choose one server and assign it with an available Server Profile. This actions is done thought Service Catalogs by having an appropriate Catalog Item. Intersight MIQ provider will probably need additional supporting resources that would allow to trigger this action.

Use case: The user chooses to “order” a specific configuration of a server from Service Catalogs. Server and server profile are chosen by the user from the list of available server profiles.

Result: New server is being commissioned and deployed with applied server profile.

Actions that are needed, and need to be provided by the Cisco Intersight ManageIQ provider:

1. Pick a server from a list of decommissioned servers.
2. Commission a server.
3. Apply a server profile to the newly commissioned server.
4. Deploy the server profile (with the assigned server).

Linked PRs: https://github.com/ManageIQ/manageiq/pull/22241, https://github.com/ManageIQ/manageiq-providers-cisco_intersight/pull/81, https://github.com/ManageIQ/manageiq-schema/pull/673, https://github.com/ManageIQ/manageiq-automation_engine/pull/514, https://github.com/ManageIQ/manageiq-content/pull/723

[alescernivec]

Step no. 3 from above should be a bit expanded and updated, also with some new concepts, e.g., the use of UCS Server Profile Templates. The reason for this is that server profiles cannot be assigned to multiple servers. First, new server profile needs to be created from the UCS server profile template in order to be assigned to a server. Therefore, step no.3 should consist of these steps: 3.1. A list of UCS Server Profile Templates should be obtained from the Intersight's API. 3.2. User chooses a Server Profile Template from the list. 3.3. New "Server Profile" is derived from the selected "Server Profile Template". (this step has not been implemented yet within the MIQ Intersight provider) 3.4. Newly created Server Profile is assigned to the newly (on behalf of the user) recommissioned server. Possibly, also tagged with additional tags, e.g., "miq_user":

[alescernivec]

@zitnik can you please have a look at my last comment and possibly, make some additional comments, ideas? thanks!

[zitnik]

The described concept / workflow looks good to me.

To avoid confusion I suggest editing the description of this issue (the use case part) - the user only chooses the Server Profile Template. The MIQ Intersight Provider then takes care of deriving a new Server Profile from this Template and assigning it to a random (first available) server.

Another thing to think about is what happens with 'orphan' Server Profiles after the servers are unassigned / decommissioned. In the described workflow, the Server Profiles are being created, so after they are not used anymore, there would be increasingly more 'stale' Server Profiles - we could think about automatically removing these Server Profiles on unassignment.

I will also check about how to manage this workflow technically with regards to many consecutive requests that need to be made to the Intersight API. The actions triggered require some time to execute on Intersight, so the workflow needs to handle polling the previous action's state before starting the next one.

[zitnik]

Some findings about how to track the execution of actions on Intersight: It is possible to track the status of longer-running actions on Intersight (e.g. server deployment) via the Workflow API. Our described workflow starts with creating a Server Profile (based on a Template). After assigning a server to this Server Profile (which is a trivial action that happens immediately and cannot be tracked), server deployment follows.

Server deployment is realized as a Workflow on Intersight. The Workflow status can be queried with a request to workflow.WorkflowInfo. The request can be filtered by our newly created Server Profile by adding the filter attribute as such: (Input.workflowContext.WorkflowSubtype eq 'Deploy') and (Input.workflowContext.InitiatorCtx.InitiatorMoid eq '6362556b77696e2d30f0447c') (where 636...7c is the Moid of the associated Server Profile). The response will contain a Status field with one of the following values: RUNNING, WAITING, COMPLETED, TIME_OUT, FAILED. Such a request can be made continuously until Status changes to one of COMPLETED / TIME_OUT / FAILED, then the user can be notified about the success or failure.

[zitnik]

Also note that the user should probably not be choosing among decommissioned servers, but rather among available (commissioned) servers that do not have a Server Profile assigned. I don't think we need to deal with (de)commissioning servers here.

[zitnik]

High-level workflow description

The suggested workflow is very simple from the user's perspective: the user only chooses a server profile template to deploy. The system then creates a server profile based on the chosen template, assigns the server profile to any available server, and deploys the server.

Optionally, a list of available servers can also be shown to the user to choose which server they want to use.

Actions needed for implementation:

1. Obtain a list of server profile templates
   • GET https://intersight.com/api/v1/server/ProfileTemplates
   • IntersightClient::ServerApi.new.get_server_profile_template_list()
2. Obtain a list of available servers
   • These are servers with no server profiles assinged
   • This is already being persisted in the ManageIQ database, no additional API calls needed to Intersight
   • Sample one-liner to retrieve available servers from the ManageIQ DB:
     PhysicalServer.where.not(id: PhysicalServerProfile.pluck(:assigned_server_id))
   • If there are no servers available, a message can be displayed and further process disabled
3. User chooses a server profile template
4. Target server is chosen either automatically or by user
5. User confirms the action
6. A new server profile is created by deriving it from the chosen server profile template
   • See Server profile creation for details below
7. The new server profile is assigned with the chosen server
   • Function available here
8. Server deployment is triggered
   • Function available here
9. Server deployment process status polling
   • See Getting status of server deployment process for details below
10. Result is shown to the user

Server profile creation / derivation from a server profile template

The bulk API object cloner query is used to derive a server profile. The source template is specified by providing its Moid. The chosen name of the new server profile is passed with the targets/name parameter.

POST https://intersight.com/api/v1/bulk/MoCloners

{
  "Sources": [
    {
      "Moid": "6346f11a77696e2d300b6049",
      "ObjectType": "server.ProfileTemplate"
    }
  ],
  "Targets": [
    {
      "Name": "derived-profile-a",
      "ObjectType": "server.Profile"
    }
  ]
}

Example using the intersight_client gem:

bulk = IntersightClient::BulkApi.new
cloner = IntersightClient::BulkMoCloner.new(
  {
    :sources => [{"Moid" => '6346f11a77696e2d300b6049', "ObjectType" => 'server.ProfileTemplate'}],
    :targets => [{"Name" => 'derived-profile-a', "ObjectType": 'server.Profile'}]
  }
)
result = bulk.create_bulk_mo_cloner(cloner)
new_profile_moid = result.responses[0].body.moid

Getting status of server deployment process

The current status of the server deployment process (workflow) can be queried with the workflow API. The exact workflow object can be obtained by filtering for server deployment (workflowType = serverconfig, workflowSubtype = Deploy) and using the moid of the server profile created in the previous step as initiatorMoid.

The response will contain a Status field with one of the following values: RUNNING, WAITING, COMPLETED, TIME_OUT, FAILED. Such a request can be made continuously until Status changes to one of COMPLETED / TIME_OUT / FAILED, then the user can be notified about the success or failure.

Examples below also contain the 'select' parameter in the requests. This tells the API to not return the whole object, but only the Status attribute. The whole workflow object might be quite large and is not required here, furthermore the Ruby intersight_client gem might encounter an error parsing the response in some cases when the entire object is requested.

GET https://intersight.com/api/v1/workflow/WorkflowInfos?$filter=Input.workflowContext.WorkflowType%20eq%20%27serverconfig%27%20and%20Input.workflowContext.WorkflowSubtype%20eq%20%27Deploy%27%20and%20Input.workflowContext.InitiatorCtx.InitiatorMoid%20eq%20%27636ce7de77696e2d302e44a8%27&$select=Status

Response example:

{
  "ObjectType": "workflow.WorkflowInfo.List",
  "Results": [
    {
      "ClassId": "workflow.WorkflowInfo",
      "Moid": "6372311d696f6e2d3006d151",
      "ObjectType": "workflow.WorkflowInfo",
      "Status": "COMPLETED"
    }
  ]
}

Example using the intersight_clinet gem:

wf_api = IntersightClient::WorkflowApi.new
wf_list = wf_api.get_workflow_workflow_info_list({
  :filter => "Input.workflowContext.WorkflowType eq 'serverconfig' and "\
             "Input.workflowContext.WorkflowSubtype eq 'Deploy' and "\
             "Input.workflowContext.InitiatorCtx.InitiatorMoid eq '#{new_profile_moid}'",
  :select => "Status" # Only return the 'Status' field from the API - the SDK may be unable to parse the result otherwise
  })
puts wf_list.results[0].status

[eilam20]

@zitnik Hi, according to action 2, will the user choose from commissioned servers that are unassigned or decommissioned servers?

[zitnik]

Hi @eilam20 They will choose from commissioned and unassigned servers. In my view, decommisioned servers are not meant to be used - or they should be commissioned first (which would be another workflow IMO). Of course, this is only my understanding. It can also be implemented differently.

[tzurvaza]

Related PRs

manageiq cisco_intersight schema automation_engine content

@alescernivec can you update the Development section with this PRs

[alescernivec]

@tzurvaza , you could just mention this issue in the respectful PRs, no? I think this automatically links the PRs with development section. Refer to https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

[alescernivec]

Actually, I think I don't have enough rights to link the PRs with this issue manually.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[miq-bot]

This issue has been automatically closed because it has not been updated for at least 3 months.

Feel free to reopen this issue if this issue is still valid.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.