In my previous blog post I described the App Orchestration workflows that are triggered after changes in the desired state. In this post I will continue with the typical flow of changes to the system and the workflows that are created.
After a Workload machine is imported the app inventory is available to create advertisements. If the advertisement is for a shared workload and there is an available farm to be used, then the “Farm allocation” workflow is created. This workflow contains steps to create the OU where the farm controller machines will be moved. This is done with the Update-OU and Move-Machine steps. The App Orchestration engine takes care of managing dependencies between steps. For example, agents will not get Move-Machine steps until the corresponding Update-OU step is successfully completed. A goal in the design of the App Orchestration engine is to make the steps as granular as possible. This has the benefit of being able to track progress or errors at specific stages.
The “Farm allocation” workflow also contains the Update-DeliveryServicesSite step which is assigned to all the Web Interface machines in the global scope and it creates the shared site for this farm. Note that this is done before actual subscriptions are created because it is meant to be shared by any tenant. This step is only assigned to shared Web Interface machines. In the previous blog I mentioned how machines are imported by monitoring all the import OUs define in the system, which correspond to catalogs and infrastructure machines. A tenant has the option to have a private import OU for Web Interface machines. For this particular case, the farm is not being used by any tenant yet, so no workflows will be created for tenant machines.
When a workload is created, available workload machines are also allocated. This is done with the “Workload machine allocation” workflow. This workflow contains the steps to create OU for the farm session host machines will be moved. As in the previous workflow, this is accomplished with the Update-OU and Move-Machines steps. In this case, however, there is one step in between: the Add-WorkloadMachine step. As its name indicates, this step actually joins the machine to the target farm.
When a tenant is created or updated, the “Update web interface” sites workflow is created. It contains Update-DeliveryServicesSite steps for each machine where the tenant requires access. This includes any private or shared machines.
If a farm is allocated for a workload, the “Update worker group” workflow is triggered. This workflow contains the Update-OU and Update-WorkerGroup steps. The OU that corresponds to the worker group is created first and then the actual XenApp worker group is created and associated to the OU. Note that the Update-OU step is assigned to the main agent but the Update-WorkerGroup step is assigned to the farm controller primary agent.
When subscriptions are created, “Subscription” workflows are also triggered. This workflow contains the Update-Application and Update-DeliveryServicesSite. The Update-Application step publishes the corresponding app in the XenApp farm. The Update-DeliveryServicesSite is created to verify that the corresponding site exists. All workflows are designed so that they can run many times. Only the changes necessary are made in order to comply with the desired state.
The last set of workflows deal with de-allocation of resources. These get triggered when machines are deleted from the system, desired capacity is reduced or tenants are removed. A common pattern to these workflows is to perform any configuration changes, such as the case of “Remove workload machine”, where the step Remove-FarmMachine actually removes the machine from the farm, and then the machines are moved to a decommission OU. Decommission workflows that do not affect machines only change configuration, such as removing an application or worker group.
Deleting some entities might cascade into deleting related objects, which in turn trigger other workflows. For example, when removing a tenant, all the associated subscriptions are also removed.
All workflows execute as soon as the agent retrieves them, but first an update notification is sent to indicate that the workflow already started. Then the possible results are success or failure. The exception to this rule is the “Remove workload machine” workflow, which contains the Start-Drain step. This step is long-running, meaning that it typically will take some time to complete. This step sets the machine to not allow new logins but then it needs to wait until all existing user sessions are logged off from the machine. This doesn’t mean the workflow is actually running all this time. It just means that the workflow will be set to running state and each time it runs it will just check for this condition to be true and only then it will return success.
Future postings in the series will describe more details on how to customize the agents and workflows.
• Provisioning machines. Part 1 and 2
• Managing Tenants (coming soon)
• Managing Advertisements
• Managing Subscriptions (coming soon)
• Patching Workload Machines (coming soon)
• Understanding Workflows. Part 1, 2 and 3
• Troubleshooting (coming soon)
• Integration with CloudPortal Services Manager (coming soon)