# Tegile Driver

The Tegile Manila driver uses Tegile IntelliFlash Arrays to provide shared filesystems to OpenStack.

The Tegile Driver interfaces with a Tegile Array via the REST API.

## Requirements

- Tegile IntelliFlash version 3.5.1

- For using CIFS, Active Directory must be configured in the Tegile Array.

## Supported Operations

The following operations are supported on a Tegile Array:

- Create CIFS/NFS Share

- Delete CIFS/NFS Share

- Allow CIFS/NFS Share access

    - Only IP access type is supported for NFS

    - USER access type is supported for NFS and CIFS

    - RW and RO access supported

- Deny CIFS/NFS Share access

    - IP access type is supported for NFS

    - USER access type is supported for NFS and CIFS

- Create snapshot

- Delete snapshot

- Extend share

- Shrink share

- Create share from snapshot

## Backend Configuration

The following parameters need to be configured in the [DEFAULT] section of /etc/manila/manila.conf:

[DEFAULT]
Option | Description
enabled_share_backends | Name of the section on manila.conf used to specify a backend. E.g. enabled_share_backends = tegileNAS
enabled_share_protocols | Specify a list of protocols to be allowed for share creation. For Tegile driver this can be: NFS or CIFS or NFS, CIFS.

The following parameters need to be configured in the [backend] section of /etc/manila/manila.conf:

[tegileNAS]
Option | Description
share_backend_name | A name for the backend.
share_driver | Python module path. For Tegile driver this must be: manila.share.drivers.tegile.tegile.TegileShareDriver.
driver_handles_share_servers | DHSS, Driver working mode. For Tegile driver this must be: False.
tegile_nas_server | Tegile array IP to connect from the Manila node.
tegile_nas_login | This field is used to provide username credential to Tegile array.
tegile_nas_password | This field is used to provide password credential to Tegile array.
tegile_default_project | This field can be used to specify the default project in Tegile array where shares are created. This field is optional.

Below is an example of a valid configuration of Tegile driver:

`[DEFAULT]`
`enabled_share_backends = tegileNAS`
`enabled_share_protocols = NFS,CIFS`
`[tegileNAS]`
`driver_handles_share_servers = False`
`share_backend_name = tegileNAS`
`share_driver = manila.share.drivers.tegile.tegile.TegileShareDriver`
`tegile_nas_server = 10.12.14.16`
`tegile_nas_login = admin`
`tegile_nas_password = password`
`tegile_default_project = financeshares`

Restart of manila-share service is needed for the configuration changes to take effect.

## Restrictions

The Tegile driver has the following restrictions:

- IP access type is supported only for NFS.

- Only FLAT network is supported.

### The `manila.share.drivers.tegile.tegile` Module

Share driver for Tegile storage.

class TegileShareDriver(*args, **kwargs)

  Bases: `ShareDriver`

  Tegile NAS driver. Allows for NFS and CIFS NAS storage usage.

  create_share(**kwds)

    Is called to create share.

  create_share_from_snapshot(**kwds)

    Is called to create share from snapshot.

    Creating a share from snapshot can take longer than a simple clone operation if data copy is required from one host to another. For this reason driver will be able complete this creation asynchronously, by providing a ‘creating_from_snapshot’ status in the model update.

    When answering asynchronously, drivers must implement the call ‘get_share_status’ in order to provide updates for shares with ‘creating_from_snapshot’ status.

    It is expected that the driver returns a model update to the share manager that contains: share status and a list of export_locations. A list of ‘export_locations’ is mandatory only for share in ‘available’ status. The current supported status are ‘available’ and ‘creating_from_snapshot’.

    Parameters:

      - context – Current context

      - share – Share instance model with share data.

      - snapshot – Snapshot instance model .

      - share_server – Share server model or None.

      - parent_share – Share model from parent snapshot with share data and share server model.

    Returns:

      a dictionary of updates containing current share status and its export_location (if available).

      Example:

          {
              'status': 'available',
              'export_locations': [{...}, {...}],
          }

    Raises:

      ShareBackendException. A ShareBackendException in this method will set the instance to ‘error’ and the operation will end.

  create_snapshot(**kwds)

    Is called to create snapshot.

    Parameters:

      - context – Current context

      - snapshot – Snapshot model. Share model could be retrieved through snapshot[‘share’].

      - share_server – Share server model or None.

    Returns:

      None or a dictionary with key ‘export_locations’ containing a list of export locations, if snapshots can be mounted.

  delete_share(**kwds)

    Is called to remove share.

  delete_snapshot(**kwds)

    Is called to remove snapshot.

    Parameters:

      - context – Current context

      - snapshot – Snapshot model. Share model could be retrieved through snapshot[‘share’].

      - share_server – Share server model or None.

  ensure_share(**kwds)

    Invoked to ensure that share is exported.

    Driver can use this method to update the list of export locations of the share if it changes. To do that, you should return list with export locations.

    It is preferred if the driver implements “get_backend_info” and “ensure_shares” instead of this routine.

    Returns:

      None or list with export locations

  extend_share(**kwds)

    Extends size of existing share.

    Parameters:

      - share – Share model

      - new_size – New size of share (new_size > share[‘size’])

      - share_server – Optional – Share server model

  get_network_allocations_number(**kwds)

    Returns number of network allocations for creating VIFs.

    Drivers that use Nova for share servers should return zero (0) here same as Generic driver does. Because Nova will handle network resources allocation. Drivers that handle networking itself should calculate it according to their own requirements. It can have 1+ network interfaces.

  get_pool(**kwds)

    Return pool name where the share resides on.

    Parameters:

      share – The share hosted by the driver.

  shrink_share(**kwds)

    Shrinks size of existing share.

    If consumed space on share larger than new_size driver should raise ShareShrinkingPossibleDataLoss exception: raise ShareShrinkingPossibleDataLoss(share_id=share[‘id’])

    Parameters:

      - share – Share model

      - new_size – New size of share (new_size < share[‘size’])

      - share_server – Optional – Share server model

    :raises ShareShrinkingPossibleDataLoss, NotImplementedError

  update_access(**kwds)

    Update access rules for given share.

    `access_rules` contains all access_rules that need to be on the share. If the driver can make bulk access rule updates, it can safely ignore the `add_rules` and `delete_rules` parameters.

    If the driver cannot make bulk access rule changes, it can rely on new rules to be present in `add_rules` and rules that need to be removed to be present in `delete_rules`.

    When a rule in `delete_rules` was never applied, drivers must not raise an exception, or attempt to set the rule to `error` state.

    `add_rules` and `delete_rules` can be empty lists, in this situation, drivers should ensure that the rules present in `access_rules` are the same as those on the back end. One scenario where this situation is forced is when the access_level is changed for all existing rules (share migration and for readable replicas).

    Drivers must be mindful of this call for share replicas. When ‘update_access’ is called on one of the replicas, the call is likely propagated to all replicas belonging to the share, especially when individual rules are added or removed. If a particular access rule does not make sense to the driver in the context of a given replica, the driver should be careful to report a correct behavior, and take meaningful action. For example, if R/W access is requested on a replica that is part of a “readable” type replication; R/O access may be added by the driver instead of R/W. Note that raising an exception will result in the access_rules_status on the replica, and the share itself being “out_of_sync”. Drivers can sync on the valid access rules that are provided on the `create_replica` and `promote_replica` calls.

    Parameters:

      - context – Current context

      - share – Share model with share data.

      - access_rules – A list of access rules for given share

      - add_rules – Empty List or List of access rules which should be added. access_rules already contains these rules.

      - delete_rules – Empty List or List of access rules which should be removed. access_rules doesn’t contain these rules.

      - update_rules – Empty List or List of access rules which should be updated. access_rules already contains these rules.

      - share_server – None or Share server model

    Returns:

      None, or a dictionary of updates in the format:

          {

      > ‘09960614-8574-4e03-89cf-7cf267b0bd08’: {

      > > ‘access_key’: ‘alice31493e5441b8171d2310d80e37e’, ‘state’: ‘error’,

      > },

      > ’28f6eabb-4342-486a-a7f4-45688f0c0295’: {

      > > ‘access_key’: ‘bob0078aa042d5a7325480fd13228b’, ‘state’: ‘active’,

      > },

      }

    The top level keys are ‘access_id’ fields of the access rules that need to be updated. `access_key``s are credentials (str) of the entities granted access. Any rule in the ``access_rules` parameter can be updated.

    Important

    Raising an exception in this method will force all rules in ‘applying’ and ‘denying’ states to ‘error’.

    An access rule can be set to ‘error’ state, either explicitly via this return parameter or because of an exception raised in this method. Such an access rule will no longer be sent to the driver on subsequent access rule updates. When users deny that rule however, the driver will be asked to deny access to the client/s represented by the rule. We expect that a rule that was error-ed at the driver should never exist on the back end. So, do not fail the deletion request.

    Also, it is possible that the driver may receive a request to add a rule that is already present on the back end. This can happen if the share manager service goes down while the driver is committing access rule changes. Since we cannot determine if the rule was applied successfully by the driver before the disruption, we will treat all ‘applying’ transitional rules as new rules and repeat the request.

this page last updated: 2026-04-22 07:00:00

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug