Security Service Updates for In Use Share Networks

Manila security service is an entity that stores client configuration used for authentication and authorization. It abstracts a set of configuration data that can be used by back ends that support it, to configure a server that can join specific authentication domains.

Manila supports different types of security services such as LDAP, Kerberos and Microsoft Active Directory [1]. Users can create, update, view and delete security services, however, in order to apply its configuration, manila needs to maintain an association between security services and share networks. Although, there is no way of providing such association or update any of its parameters after a share network starts being used by a share server.

This spec proposes an improvement on both security service update and share network association with security services, that will allow users update their share networks to replace or to add new security services, which can reflect on modifications in all related share servers.

Problem Description

Security service has configurations that might change while it’s still associated to share servers, leaving the latter outdated and possibly with problems to authenticate within domains. Furthermore, users won’t be able to grant access to shares that live on these share servers, and Manila doesn’t provide an easy way of updating such configurations, since the current implementation only supports update of name and description attributes [2] since they do not affect share server’s configuration.

Likewise, share network association with security services can’t be changed after a share server has been provisioned, and new authentication server configurations can’t be added to the already deployed share servers. In this scenario, users can only create new share networks that will be used to create new share servers.

Use Cases

Security service attributes such as dns and password might change due to network changes or password update policies and hence affect one or more share servers. Users must be able to modify these attributes in all affected security services which must reflect such configuration change in all associated share servers. A security service is qualified to be updated only if all its associated share servers have support of such operation, otherwise it must be denied.

Moreover, new security services might need to be associated with in use share networks, in order to bring more flexibility to users that want to create new shares using different authentication methods. Users must be able to include new security service associations to their share networks, which must reflect on security service updates in all associated share servers. A new security service association is qualified to be configured only if all affected share servers support such capability.

This specification focuses on both scenarios where share networks are being used by share servers and an update or a new association of security service is requested by the user, which will end up with one or more share servers being updated in the back end storages.

Proposed Solution

To solve these use cases, the share network entity will need be improved to support updates and association of new security services, even when it is already in use. A new status field will be added to represent the current state of a share network. While under modification, the share network will stay in a maintenance mode, meaning that back end configurations are being changed. The update will finish when all affected resources finish their respective configurations. Users will be able to check the current status of a share network and will be blocked of requesting new operations that can be affected by the current modification in progress.

To have these new operations working, the following changes are being proposed:

  • Share network will have a new status attribute;

  • Share network API will be updated to allow association and update of security services for in use share networks. The API will also be improved to accept share network reset-status operation.

  • Update share server model to include a new capability, for supporting security service updates.

  • Add a new share server state, indicating that it’s under network modification.

  • New share network states will be added to cover all scenarios.

  • Add a new driver interface for share server update;

  • Add a new back end capability to identify drivers that support such functionality;

  • A new share network property will be added to indicate if it supports security service updates based on its share servers’ capabilities.

API Changes

When receiving a request for security service update or association, the API will check if there are share servers associated with the share network. If the list of share servers is not empty, the API will need to check the new share network’s property, security_service_update_support, to see if the request can be completed or not and fail earlier if doesn’t support it.

A new API will be create to handle security service update, which will allow the replacement of an already configured security service by another one, that should be of the same type.

The new share network’s status will need to be validated in many other resources’ operations, which end up on backend changes. These operations should wait until the associated share network become available again, in order to proceed with the new modifications.

Share API and Manager Changes

Share network updates can be an one-to-many operation, which might trigger multiple share server updates, for different back ends in different share services. To update a security service information associated with a share network, the share API will need to validate if all affected resources are healthy before proceeding with the request.

After that, both share network and share servers status will be updated to network_change, the share network and security service association in the database will be updated and the respective share services will be called to initiate back end updates.

The share manager will be responsible for updating share servers’ backend details, and for calling the driver’s interface with the corresponding network update. At the end of the share server update operation, the share server’s status will be updated accordingly, while the share network will be updated only if all share servers under modification already finished their configuration.

If the update ends up on a failure, the share server status will be set to error along with all affected shares access rules. The share server’s backend details will remain with the most recent security service information, but will be up to the administrator to check in the storage system if the configuration is correct, before reset the status back to active, using the share-server-reset-state API. The network status won’t be affected by errors raised by back end drivers, and will have its status updated to active again at the end of the security service update.

Scheduler Capability

Backends that support this functionality will be able to report the security_service_update_support capability as True to the scheduler, which can further be used to select backend pools that support it.

Manila Manage

By adding a new capability to the share server model, it’s important to consider that existing share servers will need to update this field in the future, based on driver’s support, to have this functionality enabled. This will be achieved by providing a new management command for manila-manage tool that will let administrators update their share servers accordingly.


Alternatively, the security service resource could handle the update operation and trigger back end modification for all share servers associated with the affected share networks. This alternative can lead to scenarios with lots of back end modification at once, and as possible result, many failed share servers if the new parameters or associations are invalid.


Data model impact

A new security_service_update_support capability field will be added to manila.db.sqlalchemy.models.ShareServer indicating if the driver and the back end where this share server resides support the new security service update operations. In database migration upgrade, the new column will be added with a default value set to False, meaning that all share servers already deployed won’t be able to update their security service configuration even if the driver supports it. In database migration downgrade the column will be dropped.

A new status field will be added to the manila.db.sqlalchemy.models.ShareNetwork to hold new states that will assist on different share network operations. At this moment, only three status could be assigned to share networks: active, error and network_change. The share network is considered healthy and is available to be used only if its status is active. The status network_change represents a share network that is under modification and can’t be changed or used until it becomes active again. For specific failure scenarios, that can’t be recovered without administrator intervention, the share network will receive an error status.

A new security_service_update_support property will be added to manila.db.sqlalchemy.models.ShareNetwork to indicate whether a share network supports or not the new security service update operations. This property will inherited its value from all current associated share servers. If all associated share servers support security_service_update_support, the share network property will be set to True, otherwise it will be set to False.

REST API impact

  • Both share server and share network view will include a new response parameter, the security_service_update_support that will indicate if the share server (or share network) is capable of updating security service configuration.

  • Share network view will include a new status parameter that will indicate its current status.

  • All share network dependant operations will be blocked in the API for share networks with status different from active, to avoid conflicting backend configurations.

  • Semantic changes are expected in the share network API. Associating new security services for in use share networks will require that all share servers affected by the change support such operation, or the API will will respond with 403 Forbidden. If the destination share service is unavailable, the API will respond with 409 Conflict.

  • New share network APIs will be added:

  1. share-network-security-service-update

    Updates an existing security service association:

    POST /v2/{project_id}/share-networks/{share_network_id}/action


      "update_security_service": {
        "current_service_id": "bab0debd-fa50-4ade-80c5-ce85e2fc2614",
        "new_service_id": "1ec35b2b-5d0c-4c46-a6ca-71f9eab49ce2"


    Code: 200 OK
      "name": "my_network",
      "id": "620a1050-1711-4961-908a-bd6f7c0b1d00",
      "project_id": "f227b9e2cbdc40e78ed761e5e22c5fb4",
      "description": "This is my share network",
      "created_at": "2020-11-27T11:26:10.000000"
      "updated_at": null,
      "status": "network_change",
      "security_service_update_support": true,
      "share_network_subnets": [
          "created_at": "2020-11-27T11:26:10.000000",
          "id": "aa7a1269-703b-4832-a3df-17ed954c276c",
          "availability_zone": null,
          "segmentation_id": null,
          "neutron_subnet_id": "12c1490a-e82c-4f5e-bcb1-fb267a58cf10",
          "updated_at": null,
          "neutron_net_id": "998b42ee-2cee-4d36-8b95-67b5ca1f2109",
          "ip_version": null,
          "cidr": null,
          "network_type": null,
          "gateway": null,
          "mtu": null

    If the provided new_service_id doesn’t have the same type as the current one, or one of the security services’ ID don’t exist, the API will respond with 400 Bad Request. If the provided share-network-id doesn’t exist, the API will respond with 404 Not Found. If at least one of the destinations share services is unavailable, the API will respond with 409 Conflict.

  2. share-network-reset-status:

    Reset the status of a share network:

    POST /v2/{project_id}/share-networks/{share_network_id}/action


      "reset_status": {
      "status": "active"

    If the provided share-network-id doesn’t exist, the API will respond with 404 Not Found. If the user doesn’t have permission to execute this operation, the API will respond 403 Forbidden.

Security impact


Notifications impact


Other end user impact


Performance impact


Other deployer impact

  • No new configurations are expected to be added.

  • The back end capability will help deployers to identify pools that support new security service association.

  • All existing share servers will have their security_service_update_support set to False, even if the driver supports it. New share servers will have the correspondent capability set according to the back end capability reported by the drivers. Administrators will need to manually update share server’s capability using manila manage commands.

Developer impact


Driver impact

There is no impact for drivers that don’t want to support the proposed feature.

A new driver interface will be included to support share server security service update. Both share server and network info will be provided during this call. Drivers that want to support this operation will need to implement this call and report the capability security_service_update_support as True.



Primary assignee:

Work Items

  • Implement core changes that must include:

    • Add share network and share server model attributes;

    • Change API behavior when associating new security services with a share network;

    • Create new share network APIs to update security service and reset share network status;

    • New Share API interface for updating security service information;

    • New driver interface will be included to update share server network configuration;

    • New back end capability for supporting security service association will be added to share driver.

  • Implementation in a first party driver

  • Add new functional test in manila-tempest-plugin

  • Add new command to manila-manage for share server capability update

  • Update manila documentation




Unit test coverage will be added/maintained as per community standards. New tempest tests will be added to cover new security service association scenarios. The container or the dummy driver will be improved to properly configure security services and be used to validate the proposed changes.

Documentation Impact

The following OpenStack documentation will be updated to reflect this change:

  • Admin Guide: document the premises for having new security service association applied to share servers;

  • API Reference: include share server new status and new capability field;

  • Developer Reference: add information about how to implement and add support for this new functionality.