Schedule Backup and Snapshot
scheduling of snapshots in the openstack environment and backup of VM to a custom s3 endpoint. user will be able to take incremental backup of his VM to a custom endpoint or we can add our own s3 endpoint which is placed outside of the openstack environment and customer can take backup to the place which we have configured. it will be a good extra selling and sales point to us CSP
cloud About 8 hours ago
Enhancements
Schedule Backup and Snapshot
scheduling of snapshots in the openstack environment and backup of VM to a custom s3 endpoint. user will be able to take incremental backup of his VM to a custom endpoint or we can add our own s3 endpoint which is placed outside of the openstack environment and customer can take backup to the place which we have configured. it will be a good extra selling and sales point to us CSP
cloud About 8 hours ago
Enhancements
MongoDB logs are filling up very fast
MongoDB logs are filling up very fast. It creates aroud 50-60GB of log file in just a week or so. Logrotate isn’t applied efficiently
cloud About 8 hours ago
🐛 Issues
MongoDB logs are filling up very fast
MongoDB logs are filling up very fast. It creates aroud 50-60GB of log file in just a week or so. Logrotate isn’t applied efficiently
cloud About 8 hours ago
🐛 Issues
Auto-assign users to an Organization
Auto-assign users to a company. For example associate users with domain @companydomain.com to the company automatically. This would allow users to join a company and not have to be manually added to every project. follow up for @Organisation/Company Concept
Marius Leustean About 11 hours ago
🐛 Issues
Auto-assign users to an Organization
Auto-assign users to a company. For example associate users with domain @companydomain.com to the company automatically. This would allow users to join a company and not have to be manually added to every project. follow up for @Organisation/Company Concept
Marius Leustean About 11 hours ago
🐛 Issues
Bug in osie_admin
every time i open osie_admin portal, this pop up come by. making the admin portal slow fetching billing profiles/users etc
cloud 4 days ago
🐛 Issues
Bug in osie_admin
every time i open osie_admin portal, this pop up come by. making the admin portal slow fetching billing profiles/users etc
cloud 4 days ago
🐛 Issues
Planned
Disable Port Security
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. Current Limitations When creating a server in OSIE, interfaces are automatically created with port security enabled. There is no option in the UI to disable port security at the point of interface creation. If a port is created with port security enabled, it cannot be disabled afterwards via OSIE. The only current workaround is to pre-create a port with port security disabled and then attach it during server creation. Feature Request We would like the ability to: Disable port security when creating an interface in the OSIE UI (e.g. checkbox or toggle). Modify port security settings on an existing port via OSIE after creation. Thanks!
Kevin.Pannell 7 days ago
🐛 Issues
Planned
Disable Port Security
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. Current Limitations When creating a server in OSIE, interfaces are automatically created with port security enabled. There is no option in the UI to disable port security at the point of interface creation. If a port is created with port security enabled, it cannot be disabled afterwards via OSIE. The only current workaround is to pre-create a port with port security disabled and then attach it during server creation. Feature Request We would like the ability to: Disable port security when creating an interface in the OSIE UI (e.g. checkbox or toggle). Modify port security settings on an existing port via OSIE after creation. Thanks!
Kevin.Pannell 7 days ago
🐛 Issues
Reseller Support Without Requiring Separate Keystone Domains
Summary Enable the creation of reseller accounts within the default domain, avoiding the need to create and manage separate Keystone domains for each reseller. Background In our current understanding of OSIE’s tenancy model, resellers are implemented by creating a dedicated OpenStack Keystone domain, with customer projects created within that domain. While this provides a logical separation between resellers, it introduces additional operational overhead and complexity. Current Behaviour Creating a reseller requires provisioning a new Keystone domain Each domain operates with isolated identity management Shared resources such as images, flavours, and networking constructs require additional configuration to be made accessible across domains This leads to: Duplication of configuration Increased administrative overhead Risk of inconsistency between domains If this functionality already exists or can be achieved through an alternative design, we would appreciate any documentation or guidance on recommended best practices. Problem For service providers operating a multi-tenant platform, the requirement to create separate domains per reseller introduces unnecessary complexity when: The underlying infrastructure (compute, storage, networking) is shared Standardised offerings (flavours, images, policies) are centrally managed Operational consistency across all customers is required Managing multiple domains makes it harder to: Maintain a single catalogue of images and flavours Apply consistent policy and governance Streamline onboarding and automation workflows Desired Behaviour Allow resellers to be created within the default domain, using constructs such as: Project hierarchy (nested projects / parent-child relationships) RBAC and role-based delegation Scoped administrative permissions per reseller This would allow: Logical separation of resellers Delegated control to reseller administrators Continued use of centrally managed shared resources (images, flavours, etc.) Example Workflow A reseller is created as a top-level project (or organisational unit) within the default domain Customer projects are created beneath the reseller The reseller is granted administrative permissions scoped only to their projects Shared resources remain centrally managed and accessible without duplication Benefits Reduced operational overhead Simplified resource management Consistent service catalogue across all tenants Easier automation and onboarding Improved scalability of the platform Thanks!
Kevin.Pannell 11 days ago
🐛 Issues
Reseller Support Without Requiring Separate Keystone Domains
Summary Enable the creation of reseller accounts within the default domain, avoiding the need to create and manage separate Keystone domains for each reseller. Background In our current understanding of OSIE’s tenancy model, resellers are implemented by creating a dedicated OpenStack Keystone domain, with customer projects created within that domain. While this provides a logical separation between resellers, it introduces additional operational overhead and complexity. Current Behaviour Creating a reseller requires provisioning a new Keystone domain Each domain operates with isolated identity management Shared resources such as images, flavours, and networking constructs require additional configuration to be made accessible across domains This leads to: Duplication of configuration Increased administrative overhead Risk of inconsistency between domains If this functionality already exists or can be achieved through an alternative design, we would appreciate any documentation or guidance on recommended best practices. Problem For service providers operating a multi-tenant platform, the requirement to create separate domains per reseller introduces unnecessary complexity when: The underlying infrastructure (compute, storage, networking) is shared Standardised offerings (flavours, images, policies) are centrally managed Operational consistency across all customers is required Managing multiple domains makes it harder to: Maintain a single catalogue of images and flavours Apply consistent policy and governance Streamline onboarding and automation workflows Desired Behaviour Allow resellers to be created within the default domain, using constructs such as: Project hierarchy (nested projects / parent-child relationships) RBAC and role-based delegation Scoped administrative permissions per reseller This would allow: Logical separation of resellers Delegated control to reseller administrators Continued use of centrally managed shared resources (images, flavours, etc.) Example Workflow A reseller is created as a top-level project (or organisational unit) within the default domain Customer projects are created beneath the reseller The reseller is granted administrative permissions scoped only to their projects Shared resources remain centrally managed and accessible without duplication Benefits Reduced operational overhead Simplified resource management Consistent service catalogue across all tenants Easier automation and onboarding Improved scalability of the platform Thanks!
Kevin.Pannell 11 days ago
🐛 Issues
In Progress
Storage Policies
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!
Kevin.Pannell 13 days ago
Enhancements
In Progress
Storage Policies
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!
Kevin.Pannell 13 days ago
Enhancements
Planned
Admin-Defined Metadata Options for Instances
Summary 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. Current Behaviour There is currently no mechanism for administrators to expose controlled metadata options to users within the OSIE interface. As a result: Users cannot easily set metadata during instance deployment Metadata must be applied manually through external tools or APIs Problem 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: manual classification of workloads external automation API-based workarounds This reduces the effectiveness of metadata-driven automation and increases operational overhead. Desired Behaviour 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 / No Disaster Recovery Yes / No Service Tier T1 / T2 / T3 When selected, OSIE would apply metadata directly to the instance such as: backup=yes dr=yes tier=T2 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. Example Use Cases Backup Automation backup=yes Automatically: include the instance in backup platform policies based on OpenStack instance metadata apply backup-related billing (as referenced in the previous feature request) Disaster Recovery Services dr=yes Used to automatically include instances in: DR replication policies DR orchestration workflows Administrative Control Metadata options should be defined and controlled by administrators, ensuring consistency and preventing invalid values. Potential capabilities could include: defining allowed metadata keys and values exposing options globally or per tenant optionally restricting certain options to specific users or roles (this is very powerful) Why This Matters Allowing controlled metadata selection within OSIE would enable providers to: automate service configuration across multiple platforms enable tenant self-service for managed services implement flexible metadata-driven billing reduce manual operational overhead This feature would significantly improve OSIE's ability to support automation-driven cloud operations and service provider workflows. Thanks!
Kevin.Pannell 15 days ago
Enhancements
Planned
Admin-Defined Metadata Options for Instances
Summary 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. Current Behaviour There is currently no mechanism for administrators to expose controlled metadata options to users within the OSIE interface. As a result: Users cannot easily set metadata during instance deployment Metadata must be applied manually through external tools or APIs Problem 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: manual classification of workloads external automation API-based workarounds This reduces the effectiveness of metadata-driven automation and increases operational overhead. Desired Behaviour 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 / No Disaster Recovery Yes / No Service Tier T1 / T2 / T3 When selected, OSIE would apply metadata directly to the instance such as: backup=yes dr=yes tier=T2 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. Example Use Cases Backup Automation backup=yes Automatically: include the instance in backup platform policies based on OpenStack instance metadata apply backup-related billing (as referenced in the previous feature request) Disaster Recovery Services dr=yes Used to automatically include instances in: DR replication policies DR orchestration workflows Administrative Control Metadata options should be defined and controlled by administrators, ensuring consistency and preventing invalid values. Potential capabilities could include: defining allowed metadata keys and values exposing options globally or per tenant optionally restricting certain options to specific users or roles (this is very powerful) Why This Matters Allowing controlled metadata selection within OSIE would enable providers to: automate service configuration across multiple platforms enable tenant self-service for managed services implement flexible metadata-driven billing reduce manual operational overhead This feature would significantly improve OSIE's ability to support automation-driven cloud operations and service provider workflows. Thanks!
Kevin.Pannell 15 days ago
Enhancements
Metadata Billing
Summary 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. Current Behaviour 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. Problem Service providers often need to apply charges based on the type of workload deployed, not just the compute resources used. Examples include: Virtual firewall appliances Operating system licensing Managed service add-ons Backup services Without the ability to reference metadata in billing logic, it becomes difficult to automatically apply these charges in a consistent and scalable way. Desired Behaviour Allow OSIE billing rules to reference metadata values associated with images or instances. Example workflow: An image contains metadata: firewall=fortinet When a VM is deployed from this image, the instance inherits the metadata. OSIE billing rules can reference the metadata value: if metadata.firewall = fortinet → apply monthly charge This allows automatic charging for workloads based on their metadata attributes. Example Use Cases This capability would allow providers to easily implement billing for services such as: Firewall appliances (e.g. Fortinet images) Windows licensing (e.g. os=windows) Managed backup services (e.g. backup=yes) Why This Matters Metadata-driven billing would provide a flexible and scalable way for providers to: Automate service-based billing Reduce manual classification of workloads Build more advanced service offerings on top of the platform This capability would make OSIE significantly more powerful for service providers operating multi-tenant cloud environments. Thanks!
Kevin.Pannell 15 days ago
🐛 Issues
Metadata Billing
Summary 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. Current Behaviour 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. Problem Service providers often need to apply charges based on the type of workload deployed, not just the compute resources used. Examples include: Virtual firewall appliances Operating system licensing Managed service add-ons Backup services Without the ability to reference metadata in billing logic, it becomes difficult to automatically apply these charges in a consistent and scalable way. Desired Behaviour Allow OSIE billing rules to reference metadata values associated with images or instances. Example workflow: An image contains metadata: firewall=fortinet When a VM is deployed from this image, the instance inherits the metadata. OSIE billing rules can reference the metadata value: if metadata.firewall = fortinet → apply monthly charge This allows automatic charging for workloads based on their metadata attributes. Example Use Cases This capability would allow providers to easily implement billing for services such as: Firewall appliances (e.g. Fortinet images) Windows licensing (e.g. os=windows) Managed backup services (e.g. backup=yes) Why This Matters Metadata-driven billing would provide a flexible and scalable way for providers to: Automate service-based billing Reduce manual classification of workloads Build more advanced service offerings on top of the platform This capability would make OSIE significantly more powerful for service providers operating multi-tenant cloud environments. Thanks!
Kevin.Pannell 15 days ago
🐛 Issues
Configurable Default Network MTU in OSIE
Summary Allow administrators to configure the default MTU used when creating new networks in OSIE, while still supporting higher MTU values for environments that run jumbo frames in the backend. Current Behaviour In our RHOSO environment we run a 9000 MTU backend fabric (configured via global_physnet_mtu). Currently: OSIE does not allow MTU to be configured when creating a network When a network is created without specifying an MTU, it automatically inherits the maximum MTU (9000) from the backend This results in all newly created networks defaulting to jumbo frames. Problem Running jumbo frames by default can introduce unnecessary complexity and compatibility issues for tenants and more importantly, the user is not able to reduce the MTU. Many workloads and network integrations assume 1500 MTU. While jumbo frames are valuable in certain cases (storage networks, high-performance workloads, etc.), enabling them by default across all tenant networks can lead to issues. Desired Behaviour Allow cloud administrators to configure a default MTU value for networks created via OSIE. Example behaviour: Backend fabric MTU: 9000 Default network MTU (OSIE setting): 1500 Allowed MTU range: 1500 → 9000 When a user creates a network in OSIE: If no MTU is specified → network is created with 1500 MTU Admins (or optionally users) can increase MTU up to the backend maximum Optional Enhancement In addition to setting a default MTU, it would be useful to have a toggle to control whether tenants can modify MTU when creating networks. For example: Admin settings: Default network MTU: 1500 Allow tenant MTU override: Enabled / Disabled This would allow providers to: Maintain safe defaults Still allow advanced users to enable jumbo frames when required Thanks!
Kevin.Pannell 15 days ago
🐛 Issues
Configurable Default Network MTU in OSIE
Summary Allow administrators to configure the default MTU used when creating new networks in OSIE, while still supporting higher MTU values for environments that run jumbo frames in the backend. Current Behaviour In our RHOSO environment we run a 9000 MTU backend fabric (configured via global_physnet_mtu). Currently: OSIE does not allow MTU to be configured when creating a network When a network is created without specifying an MTU, it automatically inherits the maximum MTU (9000) from the backend This results in all newly created networks defaulting to jumbo frames. Problem Running jumbo frames by default can introduce unnecessary complexity and compatibility issues for tenants and more importantly, the user is not able to reduce the MTU. Many workloads and network integrations assume 1500 MTU. While jumbo frames are valuable in certain cases (storage networks, high-performance workloads, etc.), enabling them by default across all tenant networks can lead to issues. Desired Behaviour Allow cloud administrators to configure a default MTU value for networks created via OSIE. Example behaviour: Backend fabric MTU: 9000 Default network MTU (OSIE setting): 1500 Allowed MTU range: 1500 → 9000 When a user creates a network in OSIE: If no MTU is specified → network is created with 1500 MTU Admins (or optionally users) can increase MTU up to the backend maximum Optional Enhancement In addition to setting a default MTU, it would be useful to have a toggle to control whether tenants can modify MTU when creating networks. For example: Admin settings: Default network MTU: 1500 Allow tenant MTU override: Enabled / Disabled This would allow providers to: Maintain safe defaults Still allow advanced users to enable jumbo frames when required Thanks!
Kevin.Pannell 15 days ago
🐛 Issues
Unable to deploy 1. k8s cluster on VHI or Canonical Openstack 2. Object storage bucket on VHI
Issue #1: While attempting to deploy a Kubernetes cluster on Virtuozzo Hybrid Infrastructure (7.2) and also on Juju Charmed OpenStack (2025.1 edge), the deployment fails. In the OSIE GUI, the network I created under Cluster Network is visible, but it cannot be selected from the list. If I leave the field empty, the system automatically selects a default network as the external network, which results in an error during deployment. Even if i created a network dynamically from k8s provisioing wizard it lists the new network but doesnt allow to select. Issue #2: I am able to create an object storage bucket on the RegionOne environment running Juju Charmed OpenStack, but the same operation fails when performed on Virtuozzo.
Firoz Ahmed 22 days ago
🐛 Issues
Unable to deploy 1. k8s cluster on VHI or Canonical Openstack 2. Object storage bucket on VHI
Issue #1: While attempting to deploy a Kubernetes cluster on Virtuozzo Hybrid Infrastructure (7.2) and also on Juju Charmed OpenStack (2025.1 edge), the deployment fails. In the OSIE GUI, the network I created under Cluster Network is visible, but it cannot be selected from the list. If I leave the field empty, the system automatically selects a default network as the external network, which results in an error during deployment. Even if i created a network dynamically from k8s provisioing wizard it lists the new network but doesnt allow to select. Issue #2: I am able to create an object storage bucket on the RegionOne environment running Juju Charmed OpenStack, but the same operation fails when performed on Virtuozzo.
Firoz Ahmed 22 days ago
🐛 Issues
Budget alerts & quota controls
Can have an alert mechanism for the user to notify them based on quota or based on budget.
Radhe 26 days ago
Enhancements
Budget alerts & quota controls
Can have an alert mechanism for the user to notify them based on quota or based on budget.
Radhe 26 days ago
Enhancements
Planned
coupons facility while ordering service
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.
Radhe 26 days ago
Enhancements
Planned
coupons facility while ordering service
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.
Radhe 26 days ago
Enhancements
Invoice emails not reliably sent when multiple billing profiles share the same recipient address
When multiple billing profiles use the same recipient email address, the invoice sending process does not work reliably. In our case, we have three billing profiles with the same recipient email address. When invoices are sent, the expected behavior would be that each invoice is delivered correctly. However, the actual behavior is inconsistent. Observed behavior: Sometimes only one invoice email is delivered Sometimes two are delivered Sometimes none are delivered This makes the invoice delivery unreliable when multiple billing profiles share the same email address.
Marius Leustean 26 days ago
🐛 Issues
Invoice emails not reliably sent when multiple billing profiles share the same recipient address
When multiple billing profiles use the same recipient email address, the invoice sending process does not work reliably. In our case, we have three billing profiles with the same recipient email address. When invoices are sent, the expected behavior would be that each invoice is delivered correctly. However, the actual behavior is inconsistent. Observed behavior: Sometimes only one invoice email is delivered Sometimes two are delivered Sometimes none are delivered This makes the invoice delivery unreliable when multiple billing profiles share the same email address.
Marius Leustean 26 days ago
🐛 Issues
Completed
Invitation request returns error
POST /api-v1/project-invites/invite HTTP/2 returns 500. We are aware of the issue and working on it.
Marius Leustean 26 days ago
🐛 Issues
Completed
Invitation request returns error
POST /api-v1/project-invites/invite HTTP/2 returns 500. We are aware of the issue and working on it.
Marius Leustean 26 days ago
🐛 Issues
Planned
Offline licensing system for air-gapped environmensts
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.
Marius Leustean 29 days ago
Enhancements
Planned
Offline licensing system for air-gapped environmensts
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.
Marius Leustean 29 days ago
Enhancements
In Progress
Trilio integration
Add Trilio for OpenStack support. Trilio is an enterprise-grade backup as a service solution for OpenStack.
Marius Leustean 29 days ago
Enhancements
In Progress
Trilio integration
Add Trilio for OpenStack support. Trilio is an enterprise-grade backup as a service solution for OpenStack.
Marius Leustean 29 days ago
Enhancements
In Progress
OpenStack Connection Identity URL not saving in Admin UI
I am experiencing an issue where the Identity URL for our in-production OpenStack Connection in OSIE cannot be updated via the admin interface. When attempting to change the setting in `/osie_admin/system/settings/external/service/abcd123/openstack-connection`, the UI indicates that the connection was established and settings were saved after clicking `Reconnect` and `Save`. However, upon refreshing the page, the values revert to the old Identity URL. We managed to update it directly in OSIE's MongoDB using `db.externalService.updateOne( { _id: ObjectId('689de96f839204b017a4a694') }, { $set: { "config.identityUrl": "new-url" } } )`. I need to know if this direct database update is a sufficient and safe method.
Tonny Mihai 29 days ago
🐛 Issues
In Progress
OpenStack Connection Identity URL not saving in Admin UI
I am experiencing an issue where the Identity URL for our in-production OpenStack Connection in OSIE cannot be updated via the admin interface. When attempting to change the setting in `/osie_admin/system/settings/external/service/abcd123/openstack-connection`, the UI indicates that the connection was established and settings were saved after clicking `Reconnect` and `Save`. However, upon refreshing the page, the values revert to the old Identity URL. We managed to update it directly in OSIE's MongoDB using `db.externalService.updateOne( { _id: ObjectId('689de96f839204b017a4a694') }, { $set: { "config.identityUrl": "new-url" } } )`. I need to know if this direct database update is a sufficient and safe method.
Tonny Mihai 29 days ago
🐛 Issues