April 2026

May 2026

June 2026

July 2026

Roadmap

Add Trilio for OpenStack support.Trilio is an enterprise-grade backup as a service solution for OpenStack.

Completed

Trilio integration

Marius Leustean

Hi,Unless we are missing something, it currently appears that when adding an interface during the “Create Cloud Server” workflow in OSIE, there is no option to disable port security on the associated OpenStack port.In our environment, the majority of networks are private and secured externally (e.g. via firewalls), so port-level security enforcement is often not required. As a result, we typically disable port security on interfaces.<h4>Current Limitations</h4><ul><li>When creating a server in OSIE, interfaces are automatically created with port security enabled.</li><li>There is no option in the UI to disable port security at the point of interface creation.</li><li>If a port is created with port security enabled, it cannot be disabled afterwards via OSIE.</li><li>The only current workaround is to pre-create a port with port security disabled and then attach it during server creation.</li></ul><h4>Feature Request</h4>We would like the ability to:<ul><li>Disable port security when creating an interface in the OSIE UI (e.g. checkbox or toggle).</li><li>Modify port security settings on an existing port via OSIE after creation.</li></ul>Thanks!

Disable Port Security

Kevin.Pannell

Unless I’ve missed something, it doesn’t appear possible to assign or modify a volume storage policy after an instance or volume has been created.From what we can see, the storage policy needs to be defined at the point of deployment, and cannot be changed afterwards without recreating the volume.From a provider perspective, this presents some operational challenges. For example, we may need to move workloads between different storage tiers (e.g. performance vs capacity) as requirements evolve over time, or as part of optimisation or commercial changes. Being able to update the storage policy post-deployment would allow this to be handled more flexibly and without disruption.As administrators, we can work around this where required (for example by recreating volumes or handling this outside of OSIE), however this adds operational overhead and reduces the overall efficiency of managing customer environments at scale.Could you confirm whether there is a supported method for modifying storage policy after deployment? If not, would this be something that could be considered as a feature request? Thanks!

Storage Policies

can have a coupon facility for user order or falvor based coupan, can share with users, to apply the discount, based on product or event.

coupons facility while ordering service

Radhe

When restoring a snapshot, one of the options is selective. When attempting to do a selective restore via Osie it does not prompt for the details for the restore (via OpenStack this asks for which VMs to restore, sizing, placement etc.). Attempting a selective restore via Osie results in an error: Invalid restore options: 'instances' field is not in found in options['instances']

In Progress

Trilio selective restore

bens

When creating a Trilio workload, if the schedule is set an error is returned that the date does not match the expected format. This happens when creating a workload or updating an existing workload: Unacceptable parameters: start_date: 2026-04-27 does not match format '%m/%d/%Y'. Examples: 06/05/2014, 07/15/2014

Trilio workload schedule

Currently there is a concern for the air-gapped environments with the call-home request that OSIE does to validate the license.Implement an offline-style / JWT-based license that embeds all the details.

Offline licensing system for air-gapped environmensts

Add support in osie-notifier for: <ul><li>rabbitmq TLS connection</li><li>rabbitmq quorum queues</li></ul>

In Review

osie-notifier: support rabbitmq TLS + quorum queues

Add support for OpenStack Barbican key management service.

OpenStack Barbican

<h1>Summary</h1>Allow administrators to define approved metadata options that can be set on instances within OSIE, enabling users to select predefined metadata values when deploying or managing virtual machines.This would allow providers to drive automation, service configuration, and billing based on metadata applied to instances.<h1>Current Behaviour</h1>There is currently no mechanism for administrators to expose controlled metadata options to users within the OSIE interface.As a result:<ul><li>Users cannot easily set metadata during instance deployment</li><li>Metadata must be applied manually through external tools or APIs</li></ul><h1>Problem</h1>Service providers often rely on metadata or tags to drive automation and billing workflows across multiple systems.Without the ability to allow users to set controlled metadata values in OSIE, providers must rely on:<ul><li>manual classification of workloads</li><li>external automation</li><li>API-based workarounds</li></ul>This reduces the effectiveness of metadata-driven automation and increases operational overhead.<h1>Desired Behaviour</h1>Allow administrators to define custom OpenStack metadata options that can be applied to instances within OSIE.These options would appear as selectable fields when creating or managing instances.Example deployment options:Backup Yes / NoDisaster Recovery Yes / NoService Tier T1 / T2 / T3When selected, OSIE would apply metadata directly to the instance such as:<pre><code>backup=yes
dr=yes
tier=T2</code></pre>If no option is selected, OSIE would simply leave the metadata unset or retain any existing metadata already associated with the instance or source image.<h1>Example Use Cases</h1><h2>Backup Automation</h2><pre><code>backup=yes</code></pre>Automatically:<ul><li>include the instance in backup platform policies based on OpenStack instance metadata</li><li>apply backup-related billing (as referenced in the previous feature request)</li></ul><h2>Disaster Recovery Services</h2><pre><code>dr=yes</code></pre>Used to automatically include instances in:<ul><li>DR replication policies</li><li>DR orchestration workflows</li></ul><h1>Administrative Control</h1>Metadata options should be defined and controlled by administrators, ensuring consistency and preventing invalid values.Potential capabilities could include:<ul><li>defining allowed metadata keys and values</li><li>exposing options globally or per tenant</li><li>optionally restricting certain options to specific users or roles (this is very powerful)</li></ul><h1>Why This Matters</h1>Allowing controlled metadata selection within OSIE would enable providers to:<ul><li>automate service configuration across multiple platforms</li><li>enable tenant self-service for managed services</li><li>implement flexible metadata-driven billing</li><li>reduce manual operational overhead</li></ul>This feature would significantly improve OSIE's ability to support automation-driven cloud operations and service provider workflows.Thanks!

Admin-Defined Metadata Options for Instances

<h2>Summary</h2>Allow OSIE to reference instance and image metadata within billing rules, enabling providers to apply charges based on metadata values.This would allow service providers to automatically charge for certain workloads, appliances, or services without requiring manual classification.<div data-type="horizontalRule"><hr></div><h2>Current Behaviour</h2>Metadata cannot currently be referenced within billing logic, which limits the ability to automatically apply charges based on deployed workloads.As a result, providers must implement workarounds outside of OSIE to classify and charge for certain types of deployments.<h2>Problem</h2>Service providers often need to apply charges based on the type of workload deployed, not just the compute resources used.Examples include:<ul><li>Virtual firewall appliances</li><li>Operating system licensing</li><li>Managed service add-ons</li><li>Backup services</li></ul>Without the ability to reference metadata in billing logic, it becomes difficult to automatically apply these charges in a consistent and scalable way.<h2>Desired Behaviour</h2>Allow OSIE billing rules to reference metadata values associated with images or instances.Example workflow:<ol><li>An image contains metadata:</li></ol><pre><code>firewall=fortinet</code></pre><ol start="2"><li>When a VM is deployed from this image, the instance inherits the metadata.</li><li>OSIE billing rules can reference the metadata value:</li></ol><pre><code>if metadata.firewall = fortinet
→ apply monthly charge</code></pre>This allows automatic charging for workloads based on their metadata attributes.<h2>Example Use Cases</h2>This capability would allow providers to easily implement billing for services such as:<ul><li>Firewall appliances (e.g. Fortinet images)</li><li>Windows licensing (e.g. <code>os=windows</code>)</li><li>Managed backup services (e.g. <code>backup=yes</code>)</li></ul><h2>Why This Matters</h2>Metadata-driven billing would provide a flexible and scalable way for providers to:<ul><li>Automate service-based billing</li><li>Reduce manual classification of workloads</li><li>Build more advanced service offerings on top of the platform</li></ul>This capability would make OSIE significantly more powerful for service providers operating multi-tenant cloud environments.Thanks!

Planned

Metadata Billing

Could we have the ability to assign a custom reference to a billing profile?The use case is to link an order reference to a billing profile so that when the bill is generated we can associate it correctly with existing systems.

Custom reference on a billing profile

<ul><li>bill area<ul><li>bill gets finalized</li><li>bill gets created</li></ul></li></ul>

Webhooks

Is it possible to have the option to have the bill exported as a CSV as well as PDF?This would allow the end user to load it into a spreadsheet for comparison if they have a large number of resources.

CSV export of Customer Bill

Would it be possible to apply a savings plan to a customer via the API?Being able to do this would allow us to align the commitment contract with our existing systems.