Atomia Automation Server

Administrator's guide

129 views 0

This is section describes the provisioning process and presents possible solutions for broken requests.

Before you begin

Before you continue you should read the Atomia Automation Server overview.

Overview

Whole provisioning process can be separated in two parts:

  • Preparation phase
  • Engine phase

Preparation phase

In this part of provisioning process Automation Server prepares data and creates set of actions that should be executed on resources. As a result of this phase we have services in Automation Server database that would look like at the end of provisioning process and set of commands for Automation Server Engine. If this phase fail exception will be thrown and database rollback will be executed and nothing will be saved to database. But lets explain provisioning process by example. Lets assume that user has only one complex service.

Complex service

Image 1: Complex service.

Now, user adds new child complex service. Automation Server will execute following database actions.

  • New request in provisioning_request table will be added.
  • New item in database_provisioning_commands will be added.
  • Service Service1 as parent service of service we are adding will be locked by this request (active_request column will hold ID of request).
  • New items in service_logical_struct and ucp_services (if needed) will be added (Services will be locked by this request too).

When service or package or account is locked by some request it cannot be used in other request. Let assume now that there is more then one simple services in init list of newly added service. Following database actions will be taken for each service:

  • New item in database_provisioning_commands will be added.
  • New item in simple_service_provisioning_actions will be added.
  • New Service will be added in service_logical_struct and ucp_services (if needed)

So, for services (and actions) that will be executed on resource item in simple_service_provisioning_actions table will be added.

And this is it. Request ID will be returned as a result of this phase. This request ID can be used to get status of provisioning (Pending, In Progress…)

After this phase services will looks like below.

Service overview after executed action

Image 2: Service overview after executed action.

So, all the services exist in the database, but on resource.

This request is now sent to Engine to execute provisioning operations on resource.

Engine phase

This is the place where real provisioning starts. First, engine checks if some simple service provisioning actions can be grouped (for example services can be provisioned using one call to resource). As a result resource commands are created.

Resource commands are created

Image 3: Resource commands are created.

Provisioning request change status form Pending to In Progress.

Now, Engine takes resource commands one by one and try to execute them. For every resource command following actions are executed:

  1. Execute property transformation for services involved in request
  2. Item in journal is added with status InProgress
  3. Resource provisioning command change status to InProgress
  4. Resource command is executed on resource.
  5. If resource command is successfully executed journal item is added with status Ok and resource provisioning command change status to Ok
  6. If resource command failed journal item is added with status Failed

In case of failing resource commands more then certain count automation server will start rollback procedure This procedure will:

  1. Execute rollback for every executed resource command
    1. Resource provisioning command change status to RollBackInProgress
    2. Resource undo command is executed on resource.
    3. If undo resource command is successfully executed journal item is added with status RollBackSuccessful and resource provisioning command change status to Failed
    4. If undo resource command failed journal item is added with status RollBackFailed

At the end Automation Server update status of database provisioning commands and status of request.

In case that all Resource Command are successfully executed request will change status to Ok In case of failing executing resource command but successfully executing all undo actions request will get status Failed In case of failing executing resource command but failing executing all undo actions request will get status FailedRollbackError If request is in status different then Ok or Failedstatus is not valid and requires some action from administrator. In such request services, packages or accounts are locked within request and cannot be used in other request.

Fixing broken requests

Request may not be in status Ok or Failed from various reasons. For example, IIS, Automation Server Engine, or machine has been restarted, or some of the resources has some problem etc… This is the situation where administrators action is required. UCPClientand database knowledge is required.

  • Find request and check what is the status of request. You can do this using UCPClient or database query
    • UCPClient: in UCPClient open account that is owner of this request. From menu select Requests | List requests .
    • Execute following query in database:
      select * from provisioning_request where provisioning_request.rid='00000000-0000-0000-0000-000000000007'
      

      (correct request id should be used)

  • Situation 1
    • If status of request is ProvisioningInProgress provisioning process is interrupted. Administrator should check resource command status of last executed resource command (If there is no resource commands in progress next step can be proceeded). To see resource commands and it’s statuses following query can be executed:
      select * from resource_provisioning_commands where fk_rid='00000000-0000-0000-0000-000000000007' order by resource_cmd_id
      

      To see resource commands with service properties, execute the following query:

                       SELECT     resource_provisioning_commands.resource_cmd_id, resource_provisioning_commands.fk_rid, resource_provisioning_commands.command,
                       resource_provisioning_commands.status, ucp_services.service_id, ucp_services.name, ucp_services.resource_name, ucp_services.status AS PhysicalServiceStatus,
                       ucp_services.active_request, params.param_name, params.param_value, simple_service_provisioning_actions.action,
                       simple_service_provisioning_actions.date_time, service_logical_struct.status AS LogicalServiceStatus
                       FROM         resource_provisioning_commands INNER JOIN
                       simple_service_provisioning_actions ON
                       resource_provisioning_commands.resource_cmd_id = simple_service_provisioning_actions.fk_resource_cmd_id INNER JOIN
                       service_logical_struct ON simple_service_provisioning_actions.fk_logical_service_id = service_logical_struct.lid INNER JOIN
                       ucp_services ON service_logical_struct.fk_sid = ucp_services.service_id INNER JOIN
                       params ON ucp_services.service_id = params.fk_sid
                       WHERE     (resource_provisioning_commands.fk_rid = '00000000-0000-0000-0000-000000000007')
                       ORDER BY resource_provisioning_commands.resource_cmd_id
      

      A useful query can be to see provisioning journal:

                       SELECT provisioning_journal.*, resource_provisioning_commands.*
                       FROM provisioning_journal INNER JOIN resource_provisioning_commands ON provisioning_journal.fk_cmd_id = resource_provisioning_commands.resource_cmd_id
                       where resource_provisioning_commands.fk_rid='00000000-0000-0000-0000-000000000007'
                       order by provisioning_journal.id
      

      So, Administrator should use information collected using previous queries to compare status of services with real status of services (on resource) and decide if last executed resource command is executed successfully or not. Then status of resource command should be changed to Ok or Pending .

    • Use UcpClient.exe tool to continue this request. From menu select Requests | List requests and choose request. Right click on it and choose “Continue request”.
  • Situation 2
    • If status of request is RollbackInProgress provisioning process has failed and rollback started but it is interrupted. Like in previous situation Administrator should check real state of services on resources. If rollback is successfully done (for example if command was for adding service and if service does not exist rollback has successfully done) then resource command should get status FailedUndoDone . If rollback is not done then last resource command should have status Ok .
    • Use UcpClient.exe tool to continue this request. From menu select Requests | List requests and choose request. Right click on it and choose “Continue request”.
  • Situation 3
    • If status of request is FailedRollbackError provisioning process has failed and rollback started but it rollback failed too. We should fix rollback problem and check status of last executed resource command and update it.
    • Use UcpClient.exe tool to continue this request. From menu select Requests | List requests and choose request. Right click on it and choose “Continue request”.

Was this helpful?