Q1 2026

Q2 2026

Q3 2026

Q4 2026

Quarterly Roadmap

It would be useful to have a logging interface within Osie that can expose changes made through a project.This would ideally expose who, what and when something was created/updated/deleted to allow customers to track down problems or events caused by change. It would also be useful to include login events.

Completed

Audit Logging

bens

Implement a RBAC system for the administrators dashboard.

RBAC system for Admins

Marius Leustean

It would be useful to have a company/organisation concept that would:<ul><li>Auto-assign users to a company. For example associate users with domain @<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://companydomain.com">companydomain.com</a> to the company automatically. This would allow users to join a company and not have to be manually added to every project.</li><li>Allow configuring the billing_profile of a user-created project at an organisation level (e.g. if the projects are created by a technical user but the company has a billing contact)</li></ul>

Organisation/Company Concept

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.

Planned

Offline licensing system for air-gapped environmensts

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

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

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!

In Progress

Storage Policies

<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

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

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.

Apply savings plan via the API

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