|
| 1 | +.. Licensed to the Apache Software Foundation (ASF) under one |
| 2 | + or more contributor license agreements. See the NOTICE file |
| 3 | + distributed with this work for additional information# |
| 4 | + regarding copyright ownership. The ASF licenses this file |
| 5 | + to you under the Apache License, Version 2.0 (the |
| 6 | + "License"); you may not use this file except in compliance |
| 7 | + with the License. You may obtain a copy of the License at |
| 8 | + http://www.apache.org/licenses/LICENSE-2.0 |
| 9 | + Unless required by applicable law or agreed to in writing, |
| 10 | + software distributed under the License is distributed on an |
| 11 | + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| 12 | + KIND, either express or implied. See the License for the |
| 13 | + specific language governing permissions and limitations |
| 14 | + under the License. |
| 15 | + |
| 16 | +
|
| 17 | +Extensions |
| 18 | +========== |
| 19 | + |
| 20 | +Extensions are a new mechanism introduced in Apache CloudStack to allow administrators to extend the platform's functionality by integrating external systems or custom workflows. Currently, CloudStack supports a single extension type called Orchestrator. |
| 21 | + |
| 22 | +In the UI, extensions can be managed under *Extensions* menu. |
| 23 | + |
| 24 | + |extensions.png| |
| 25 | + |
| 26 | +Overview |
| 27 | +~~~~~~~~ |
| 28 | + |
| 29 | +An extension in CloudStack is defined as an external binary (written in any programming language) that implements specific actions CloudStack can invoke. This allows operators to manage resource lifecycle operations outside CloudStack, such as provisioning VMs in third-party systems or triggering external automation pipelines. |
| 30 | + |
| 31 | +Extensions are managed through the API and UI, with support for configuration, resource mappings, and action execution. |
| 32 | + |
| 33 | + |create-extension.png| |
| 34 | + |
| 35 | +Configuration |
| 36 | +~~~~~~~~~~~~~ |
| 37 | + |
| 38 | +Administrators can define and manage the following components of an extension: |
| 39 | + |
| 40 | + - Entry Point: A file or script that will be executed during extension operations. |
| 41 | + |
| 42 | + - Configuration Details: Key-value properties used by the extension at runtime. |
| 43 | + |
| 44 | + - Resource Mappings: Association between extensions and CloudStack resources such as clusters, etc. |
| 45 | + |
| 46 | +Entry Point |
| 47 | +~~~~~~~~~~~ |
| 48 | + |
| 49 | +The entry point for an extension can be any binary or executable script. If no explicit entry point is provided, CloudStack uses a default base Bash script. The state of the entry point is validated across all management servers. In the UI, the Entry Point State is displayed as Not Ready if the file is missing, inaccessible, or differs across management servers. |
| 50 | + |
| 51 | +All extension entry point files are stored under a directory named after the extension within `/usr/share/cloudstack-management/extensions`. |
| 52 | + |
| 53 | +Payload |
| 54 | +~~~~~~~ |
| 55 | + |
| 56 | +CloudStack sends structured JSON payloads to the extension binary during each operation. These payloads are written to .json files stored under `/var/lib/cloudstack/management/extensions`. The extension binary is expected to read the file and return an appropriate result. CloudStack automatically attempts to clean up payload files older than one day. |
| 57 | + |
| 58 | + |
| 59 | +Custom Actions |
| 60 | +-------------- |
| 61 | + |
| 62 | +In addition to standard instance operations, extensions support custom actions. These can be configured via UI in the extension details view or the addCustomAction API. The extension entry-point must implement handlers for these action names and process any provided parameters. |
| 63 | + |
| 64 | + |add-custom-action.png| |
| 65 | + |
| 66 | +Description, allowed role types, parameters, success/error messages, configuration details, timeout can be defined during creation or update. |
| 67 | +Alowed role types can be one or more of Admin, Resource Admin, Domain Admin, User. |
| 68 | +Success and error messages will be used and returned during action execution. They allow string expansion and the following can be used to customise messgaes: |
| 69 | + |
| 70 | + - {{actionName}} for showing name of the action |
| 71 | + - {{extensionName}} for showing name of the extension |
| 72 | + - {{resourceName}} for showing name of the resource. |
| 73 | + |
| 74 | +An example usage can be - "Successfully completed {{actionName}} for {{resourceName}} using {{extensionName}}". |
| 75 | +Configuration details can be key-value pairs which will be passed to the extension entry-point during action execution. |
| 76 | +Timeout value can be configured to adjust wait time for action completion. |
| 77 | + |
| 78 | +A single parameter can have the following details: |
| 79 | + |
| 80 | + - **name**: Name of the parameter. |
| 81 | + |
| 82 | + - **type**: Type of the parameter. It can be one of the following: BOOLEAN, DATE, NUMBER, STRING |
| 83 | + |
| 84 | + - **validationformat**: Validation format for the parameter value. Supported only for NUMBER and STRING type. For NUMBER, it can be NONE or DECIMAL. For STRING, it can be NONE, EMAIL, PASSWORD, URL, UUID. |
| 85 | + |
| 86 | + - **valueoptions**: Options for the value of the parameter. This is allowed only for NUMBER and STRING type. |
| 87 | + |
| 88 | +Running Custom Action |
| 89 | +~~~~~~~~~~~~~~~~~~~~~ |
| 90 | + |
| 91 | +All enabled custom actions can then be triggered for a resource of the type the action is defined for or provided while running, using the **Run Action** view or runCustomAction API. |
| 92 | + |
| 93 | + |run-custom-action.png| |
| 94 | + |
| 95 | +Orchestrator Extension |
| 96 | +---------------------- |
| 97 | + |
| 98 | +An Orchestrator extension enables CloudStack to delegate VM orchestration to an external system. Key features include: |
| 99 | + |
| 100 | + - Cluster Mapping: Orchestrator extensions can be associated with one or more CloudStack clusters. |
| 101 | + |
| 102 | + - Hosts: Multiple hosts can be added to such clusters, ideally pointing to different physical or external hosts. |
| 103 | + |
| 104 | + - Instance Lifecycle Support: Extensions can handle basic VM actions like prepare, deploy, start, stop, reboot, status and delete. |
| 105 | + |
| 106 | + - Configuration Details: Key-value configuration details can be specified at different levels - extension, cluster mapping, host, template, service offering, instance. |
| 107 | + |
| 108 | + - Custom Actions: Admins can define custom actions beyond the standard VM operations. |
| 109 | + |
| 110 | + |
| 111 | + |run-custom-action.png| |
| 112 | + |
| 113 | + |
| 114 | +CloudStack provides sample built-in orchestrator extensions for demonstration and testing purposes. |
| 115 | + |
| 116 | + |
| 117 | +.. Images |
| 118 | +
|
| 119 | +
|
| 120 | +.. |extensions.png| image:: /_static/images/extensions.png |
| 121 | +.. |create-extension.png| image:: /_static/images/create-extension.png |
| 122 | +.. |add-custom-action.png| image:: /_static/images/add-custom-action.png |
| 123 | +.. |run-custom-action.png| image:: /_static/images/run-custom-action.png |
| 124 | +.. |run-custom-action-instance.png| image:: /_static/images/run-custom-action-instance.png |
0 commit comments