Extensions
Framework &
Orchestrate
Anything
Harikrishna Patnala, Abhishek Kumar @ CloudStack India User Group 2025
About us
● PMC and Committer @ Apache
CloudStack project
● Been involved with the project
for over 6 years now
● Staff Software Engineer @
ShapeBlue
Abhishek
● PMC and Committer @ Apache
CloudStack project
● Born and brought up in CloudStack
● Lead Software Engineer @
ShapeBlue
Hari
Why Extensions???
● Plug in External Logic Easily
○ Integrate custom scripts or tools directly into CloudStack workflows
○ Ideal for operators and developers outside the core project
● Decouples external logic from core CloudStack
● Enhances automation use-cases
● Define custom actions
What can be achieved ?
● Can integrate new VM provisioners or hypervisors
○ Proxmox
○ Hyper-V
○ MaaS
○ Baremetal
● Define custom actions like
○ Snapshots
○ Clone operations
○ Backups
● Can integrate new Network extensions
Extensions
Framework
● Integrates external
systems and workflows
● An executable binary or
script in any programming
language that acts as a
bridge between
CloudStack and the
external system
● Targeted for 4.21.0 release
Extensions Framework - contd.
● Extensions of different types can be defined. Current iteration
will support Orchestrator type.
● Communication using JSON structured payload
● Ability to define custom actions to provide further flexibility
● Extension binary or script file(s) will be placed at
/usr/share/cloudstack-management/extensions/<EXTENSION_NAME>
● Extension data will be stored at
/var/lib/cloudstack/management/extensions/<EXTENSION_NAME>
Extension - Workflow
Extension - Workflow Example
● Operators can define
custom actions for
each extension
● Supports user-defined
input parameters,
success/error
messages, allowed
role types
● Actions can be linked
to specific resource
types
Custom
Actions
Custom Actions - Workflow
Orchestrator
Extension
● Allows instance deployment on external
systems
● Built-in extensions added for:
○ Proxmox
○ Hyper-V
● Allows deploy, start, stop, reboot,
expunge operations. More can be
added using custom actions
● (Optional) Prepare action allows
extension to update some of the fields
CloudStack instance before deployment
○ Eg. MAC address for the instance
Built-in Extensions
Adding
extension
● Basic details -
name, path, type,
type-specific
configuration
● Optional metadata
in form of key-value
pair which will be
passed to the
binary/script
Registering
extension
with
resource(s)
● Select resource
● Optional metadata
in form of key-value
pair which will be
passed to the
binary/script
Add additional resources
For orchestrator,
● Host
● Template
● Service offering (optional)
Use
extension
(Trigger
action)
● No specific
difference for end-
user
● For orchestrator,
end-user will select
the corresponding
template and
instance will be
deployed
Adding
custom
action
● Define name,
description, allowed
roles, timeout,
parameters,
success/error
messages
● Parameter can be
defined for different
types and validation
format
● Messages allow string
expansion
● Optional metadata
Running
custom
action
● Run action show for
the applicable
resources
● Auto generated UI
with value options,
validations
Demo
Future & What’s Next
● Will be a part of CloudStack 4.21.0 release #
● New types - network, authenticator, etc
● Usability improvements - feedback from community
● Extension marketplace???
Discuss
Q & A, feedback…
https://github.com/apache/cloudstack/pull/9752
https://github.com/apache/cloudstack-documentation/pull/523
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Extensions+Fr
amework+-++Orchestartor+or+External+Deployment+Integration
https://download.cloudstack.org/testing/nightly/

Extensions Framework (XaaS) - Enabling Orchestrate Anything

  • 1.
    Extensions Framework & Orchestrate Anything Harikrishna Patnala,Abhishek Kumar @ CloudStack India User Group 2025
  • 2.
    About us ● PMCand Committer @ Apache CloudStack project ● Been involved with the project for over 6 years now ● Staff Software Engineer @ ShapeBlue Abhishek ● PMC and Committer @ Apache CloudStack project ● Born and brought up in CloudStack ● Lead Software Engineer @ ShapeBlue Hari
  • 3.
    Why Extensions??? ● Plugin External Logic Easily ○ Integrate custom scripts or tools directly into CloudStack workflows ○ Ideal for operators and developers outside the core project ● Decouples external logic from core CloudStack ● Enhances automation use-cases ● Define custom actions
  • 4.
    What can beachieved ? ● Can integrate new VM provisioners or hypervisors ○ Proxmox ○ Hyper-V ○ MaaS ○ Baremetal ● Define custom actions like ○ Snapshots ○ Clone operations ○ Backups ● Can integrate new Network extensions
  • 5.
    Extensions Framework ● Integrates external systemsand workflows ● An executable binary or script in any programming language that acts as a bridge between CloudStack and the external system ● Targeted for 4.21.0 release
  • 6.
    Extensions Framework -contd. ● Extensions of different types can be defined. Current iteration will support Orchestrator type. ● Communication using JSON structured payload ● Ability to define custom actions to provide further flexibility ● Extension binary or script file(s) will be placed at /usr/share/cloudstack-management/extensions/<EXTENSION_NAME> ● Extension data will be stored at /var/lib/cloudstack/management/extensions/<EXTENSION_NAME>
  • 7.
  • 8.
  • 9.
    ● Operators candefine custom actions for each extension ● Supports user-defined input parameters, success/error messages, allowed role types ● Actions can be linked to specific resource types Custom Actions
  • 10.
  • 11.
    Orchestrator Extension ● Allows instancedeployment on external systems ● Built-in extensions added for: ○ Proxmox ○ Hyper-V ● Allows deploy, start, stop, reboot, expunge operations. More can be added using custom actions ● (Optional) Prepare action allows extension to update some of the fields CloudStack instance before deployment ○ Eg. MAC address for the instance
  • 12.
  • 13.
    Adding extension ● Basic details- name, path, type, type-specific configuration ● Optional metadata in form of key-value pair which will be passed to the binary/script
  • 14.
    Registering extension with resource(s) ● Select resource ●Optional metadata in form of key-value pair which will be passed to the binary/script
  • 15.
    Add additional resources Fororchestrator, ● Host ● Template ● Service offering (optional)
  • 16.
    Use extension (Trigger action) ● No specific differencefor end- user ● For orchestrator, end-user will select the corresponding template and instance will be deployed
  • 17.
    Adding custom action ● Define name, description,allowed roles, timeout, parameters, success/error messages ● Parameter can be defined for different types and validation format ● Messages allow string expansion ● Optional metadata
  • 18.
    Running custom action ● Run actionshow for the applicable resources ● Auto generated UI with value options, validations
  • 19.
  • 20.
    Future & What’sNext ● Will be a part of CloudStack 4.21.0 release # ● New types - network, authenticator, etc ● Usability improvements - feedback from community ● Extension marketplace???
  • 21.
    Discuss Q & A,feedback… https://github.com/apache/cloudstack/pull/9752 https://github.com/apache/cloudstack-documentation/pull/523 https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Extensions+Fr amework+-++Orchestartor+or+External+Deployment+Integration https://download.cloudstack.org/testing/nightly/

Editor's Notes

  • #11 Continues with VM Ingestion functionality first introduced in CloudStack 4.14 with VMware support Would make CloudStack onboarding easier.
  • #13 CloudStack currently support native, LDAP and SAML based authentication
  • #14 CloudStack currently support native, LDAP and SAML based authentication
  • #16 CloudStack currently support native, LDAP and SAML based authentication
  • #17 CloudStack currently support native, LDAP and SAML based authentication
  • #18 CloudStack currently support native, LDAP and SAML based authentication