Having a driver in the top level of the drivers
directory was against source tree placement
conventions. It was especially weird because
all other GlusterFS related code lived in
a dedicated subdirectory.
Partially implements bp gluster-code-cleanup
Change-Id: I52d717ab6396454c2e7a9b62aa00ea443b26d5cc
GlusterFS has two kind of options:
- regular ones, which are a hardcoded set, and option names
are verified in "gluster volume get"
- user ones, whose name matches user.* -- these are
arbitrarily named, are ignored by "gluster volume get" and
are listed in "gluster volume info" output
So far we used "gluster volume info" universally, but that,
apart from being cumbersome for regular options, is also
incorrect, as it can't distinguish an unset option name from
an undefined one (querying the former should be treated OK,
querying the second should be treated as error).
- implement querying of regular options with "gluster volume
get" (accepting empty response)
- implement querying of user options with searching "gluster vol
info" data
- verify operations on the XML tree, make tacit XML layout
assumptions explicit
- implement optional Boolean coercion of values
Partially implements bp gluster-code-cleanup
Change-Id: I9e0843b88cd1a1668fe48c6979029c012dcbaa13
Backends supporting replication of shares could be
limited by vendor or storage model or software. Cloud
administrators may also need to configure backends
outside of Manila to support replication between these
backends.
Hence, Manila should allow administrators to specify
'replication_domain's. This configuration is reported to the
scheduler as a backend capability as part of the
_update_share_stats() driver call. The scheduler
should acknowledge this 'capability' when scheduling
shares supporting replication and replicas themselves.
Introduce a new scheduler filter that uses a backend
reported "capability" called 'replication_domain'.
Implements bp: manila-dr-scheduler-enhancements
DocImpact
Change-Id: I194054a9a1071c2d577a588e3299ae81490cd0f8
GlusterManager:
- add various error policies to gluster_call
- add set_vol_option method, with optional error tolerance
(making use of the respective gluster call error policy),
with support for Boolean options
- rename get_gluster_vol_option method to get_vol_option
for uniform nomenclature and simplicity (the "gluster" in
the method name was redundant as the classname already
hints about the Gluster scope)
Partially implements bp gluster-code-cleanup
Change-Id: I02a1d591d36c6a64eea55ed64cf715f94c1fd1c8
So far, GlusterManager.gluster_call was directly calling
into the given execution function, of which the expected
error type is ProcessExecutionError; while practically in
all use cases we wanted to raise upwards a GlusterfsException,
so all use cases were individually coercing the
ProcessExecutionError into a GlusterfsException. This produced
a huge amount of excess boilerplate code.
Here we include the coercion in the definiton of gluster_call
and clean out the excess code.
Partially implements bp gluster-code-cleanup
Change-Id: I0ad0478393df2cbb6d077363ebd6b91ceed21679
QoS is a common attribute, so add the QoS
capability in common capabilities doc.
This is a simple first step towards what the
blueprints proposes.
Partially implements: bp manila-support-qos
Change-Id: I377bf0abcc62239c9a1a5ee5c28c336b2b6c410a
The full name of the 'dynamic-auth' GlusterFS option
is 'server.dynamic-auth'. When we started to make use
of it in https://review.openstack.org/229409, we just
used its short form, 'dynamic-auth'. That actually
*should* work but due to some weakness in the GlusterFS
instrumentation code, it doesn't.
Fix the situation for now by using the full option
name. We also take the opportunity to remove some
redundant checks from the respective option handling
code.
Change-Id: I6f30060cec38733afa1211cb8e7bc57b66dead34
Closes-Bug: #1506577
When handling create_share_from_snapshot with glusterfs
volume layout, we do a snapshot clone gluster operation
that gives us a new volume (which will be used to back
the new share). 'snapshot clone' does not start the
resultant volume, we have explicitly start it from Manila.
So far the volume layout code did not bother about it,
rather the 'vol start' was called from glusterfs-native
driver. That however broke all other volume layout based
configs (ie. glusterfs driver with vol layout).
Fix this now by doing the 'vol start' call in the vol
layout code.
Change-Id: I63c13ce468a3227f09e381814f55e8c914fbef95
Closes-Bug: #1499347
Currently, the glusterfs_native driver can support
create_share_from_snapshot API only if the Manila host's TLS
certificate's common name(CN) is prefixed by 'glusterfs-server'. This
constraint on the CN of the host is not acceptable. So fix this by
hardwiring a Manila host CN pattern that allows the Manila host CN
to have a more intuitive prefix, 'manila-host'.
Change-Id: Ibab27da4f9b28c6e7d2ef9c175d5decf5fa67ce4
Closes-Bug: #1496833
The basic problem is that determining the
export location of a share should happen in
driver scope (as it depends on available
export mechanims, which are implemented by
the driver) while the code did it in layout
scope in ad-hoc ways. Also in native driver
the export location was abused to store the
address of the backing GlusterFS resource.
Fix these by
- layout:
- GlusterfsShareDriverBase._setup_via_manager
(the layer -> driver reverse callback) will
provide the export location as return value
- the share object is also passed to
GlusterfsShareDriverBase._setup_via_manager
(besides the gluster manager), because some
driver configs will need it to specify the
export location
- glusterfs-native:
- free the code from using export location
(apart from composing it in _setup_via_manager);
store the address of backing resource in
private storage instead of the export location
field
- glusterfs:
- define the `get_export` method for the export
helpers that provide the export location
- _setup_via_manager determines export location
by calling the helper's get_export
Change-Id: Id02e4908a3e8e435c4c51ecacb6576785ac8afb6
Closes-Bug: #1476774
Closes-Bug: #1493080
Fix typo to enable GlusterFS protocol to be used by the
glusterfs_native driver.
Change-Id: I0003092333bb8dbbdc9e89d6b4eaa14de652d0e2
Closes-Bug: #1494177
The volume management done by gluster_native has
been isolated and captured in a separate layout class.
gluster_native implements only {allow,deny}_access,
for the rest it uses the layout code.
Semantics is preserved with one difference:
the Manila host now is assumed to be set up so that
it can mount the GlusterFS volumes without any
complications. Earlier we assumed to not have cert
based access from Manila host, and turned therefore
SSL off and on on the GlusterFS side. This does not
make sense for the separate, layout-agnostic logic.
(Nb. we already wanted to make the move to set this
assumption, regardless of the layout work.)
Partially implements bp modular-glusterfs-share-layouts
Change-Id: I3cbc55eed0f61fe4808873f78811b6c3fd1c66aa
Do not store superfluous mappings of urls to
GlusterManager instances (GlusterManager
instances are stateless and cheap, so they
are better to be produced on the fly).
Thus drop the `gluster_used_vols_dict` and
`glusterfs_servers` instance attributes of
GlusterfsNativeShareDriver; use instead,
respectively, the set reduct `glusterfs_used_vols`,
and the CONF provided `glusterfs_servers` list.
Also avoid direct dispatch on
`share['export_location']`, hide it into the utility
function `_share_manager`.
Partially implements bp modular-glusterfs-share-layouts
Change-Id: I9d9e76915d6fb6b56e1ef81a7de9e80eebbb5006
- separate basic uri attributes (components)
from derived ones
- components are directly taken from regex
match groupdict
- components are accessible either as
`gmgr.components["<comp>"]` or in sugared/backward compatible
format `gmgr.<comp>`
- derived attributes implemented as properties
- add a "path" component
- initialization can happen both with uri string or
component dict
This allows easy and correct cloning and changing
of GlusterManager objects.
Furthermore,
- the `has_volume` keyword argument has been replaced
by the `requires` keyword argument which can take
a component keyed dict as value; `has_volume=<value>`
is equivalent with `requires={'volume': <value>}`
- `remote_user` component has been renamed to `user`
- `management_address` derived attribute has been renamed to
`host_access`
- execf keyword argument is made optional
- relax default volume requirement
Partially implements bp modular-glusterfs-share-layouts
Change-Id: I5ce088c4ec39a403c9ded2aea1d3ca172e514a01
GlusterManager and a few standalone
management routines have been moved
to the newly created glusterfs/common.py;
both glusterfs and glusterfs_native drivers
import these from there. The obnoxious
import of glusterfs to glusterfs_native
has been eliminated.
Partially implements bp modular-glusterfs-share-layouts
Change-Id: I6a94f1056bd45187c0268d75fa854b127b2b562d
As was discussed on Liberty Mid-Cycle meetup
instances of "infinite" capacity should be replaced
with "unknown" and this capacity should be sorted
to the bottom in the capacity weigher.
Change-Id: I9b37a5ff9cceb35a964b2a0d243688eb73e5cadc
Closes-Bug: #1487478
Replace assertEqual(None, *) with assertIsNone in tests to have
more clear messages in case of failure.
Closes-Bug: #1280522
Change-Id: I2d5285add72678b5a61b4f66879c4d066afc34c7
Add the missing create share from snapshot feature in gluster_native
driver. The snapshot of a share/GlusterFS volume, is cloned to create
a new GlusterFS volume that is served as a new share.
Change-Id: I93208a844a18423e3ade6cfed0f34c8da3c1c598
On last midcycle meetup was decided to make snapshots optional feature.
Features:
- Add new boolean capability 'snapshot_support' to base share driver
so every existing share driver will inherit it. Make value of it be
calculated from the fact of redefinition of three main driver
methods for snapshots 'create_snapshot', 'delete_snapshot' and
'create_share_from_snapshot'.
- Set extra spec 'snapshot_support' with share type creation by default
to 'True'
- Restrict deletion of extra spec 'snapshot_support' that is expected
to exist
- Allow to redefine new extra spec 'snapshot_support'
- Restrict API 'snapshot create' for share created with
share type that has extra spec 'snapshot_support' equal to 'False'.
- Add migration where new extra spec 'snapshot_support' is added
to all share types that do not have it yet.
Partially implements bp snapshots-optional
Change-Id: I069d9e911c7d7a708fa518b38ed10572a45e5f42
Change iterators and 'dict_items' objects to list with additional 'list()' method
to avoid versions incompatibility
Partially-Implements: bp py3-compatibility
Change-Id: Ic6b437cd0d57ca3d4b343b590d11c4e53492d223
We need the so-called management address of a GlusterFS
volume (ssh address of its management node) at a few places
for bookkeping reasons (certain data like GlusterFS version
is stored in management address-keyed dicts).
So far it was available only through ad-hoc mangling of
various attributes of a GlusterManager instance that
represents the volume. Now we make it available
directly from GlusterManager as an attribute.
Also fix an occurrence of ad-hoc mangling going wrong,
ie. where a wrongly constructed address is attempted
to be used as dict key.
Change-Id: Ic5a96bc99943dda3592372512916257d53f61b80
Closes-Bug: #1476710
Due to change I40873208c7431e42885bee4db06d6229a202bad6,
we are free to change snapshot naming on the GlusterFS
side, as long as the Manila snap id occurs in it.
This is part of an effort to provide better
indication to the GlusterFS admin about the
origin of Manila created entities.
Partially implements bp manila-prefix-for-gluster-entities
Change-Id: Ie15e89cd49ab8450921ab08c78eb382096b57266
So far the delete_snapshot() logic assumed that a GlusterFS snapshot
exists with exactly the same name as the Manila snapshot id.
This was a fragile assumption -- both GlusterFS and Manila can
potentially change how the GlusterFS snapshots are named.
(And currently we have a problem as GlusterFS has actually changed
this -- see referred bug about details.)
Therefore from now on we'll use the weaker assumption that the
Manila snapshot id is a substring of the backing GlusterFS snapshot
name. (That's a robust assumption, unlikely to break in the future.)
The actual GlusterFS snapshot name is found by doing a
`gluster snapshot list` and grepping for the Manila snapshot id in
it.
Change-Id: I40873208c7431e42885bee4db06d6229a202bad6
Closes-Bug: #1473044
With GlusterFS 3.7.x versions, the delete share operation fails when
deleting the contents of a GlusterFS volume, a share. This is because
two directories are auto-created within a GlusterFS volume when it's
started and GlusterFS refuses to unlink their paths. Fix this issue, by
not trying to remove the two directory paths, but remove their contents
and the rest of the contents of the volume.
Change-Id: I1675bbf593bf578301d6899ee3f9860320080956
Closes-Bug: #1473324
After release of mock==1.1.0 lib some our tests became incompatible.
Newest 'mock' lib does not have silent errors anymore and now our such errors
are discovered. So, fix them.
Change-Id: Ibb0e03f3b86e25201b7a888560ff133ebc627722
Closes-Bug: #1473350
Manila scheduler needs information about relationship between
pools and share_servers to make Manila scheduling decisions smarter,
as it would be based on pool capacity/capability.
Add new share driver method called 'get_share_server_pools'
which takes a share server and returns a list of pools.
Share manager calls that method for every share server on every stats update
and adds mapping to share_stats.
Add new function 'share_server_get_all_by_host' to DB API.
Change-Id: I41041cc247da5e25383c2f3f827d7d96b4347427
We have several entities in Manila that do have statuses:
- Shares
- Snapshots
- Share Servers
- Share Access Rules
But some share and all share server statuses use uppercase for it.
Make all of them consistent and transform them to lowercase.
Add migrations for it.
Also, remove two unused statuses and reuse all statuses from common place.
Change-Id: I53e6a768c98977d3d94e761349b7446a9dfb4936
Closes-Bug: #1459598
- Remove passing DB reference to drivers in __init__() method
- Remove db reference from Generic driver and service_instance
- Remove db reference from Netapp share driver
- Remove db reference from Glusterfs share driver
- Remove db reference from Glusterfs_Native share driver
- Remove db reference from Quobyte share driver
- Remove db reference from IBM GPFS driver
- Remove db reference from HDS_SOP driver
- Remove db reference from HDFSNative driver
- Remove db reference from fake driver
- Remove db reference from unit tests.
Change-Id: I74a636a8897caa6fc4af833c1568471fe1cb0987
- Remove direct DB calls from methods create_snapshot() and
delete_snapshot().
- Move code from _update_gluster_vols_dict() method to
ensure_share() method.
Change-Id: I6c95f6d9361093d832a536971a460c3cdda44dcb
Partial-Bug: #1444914
In the delete_snapshot API, the Gluster command issued to delete the
snapshot ends up being run in the interactive mode of the
Gluster-CLI. So instead of an XML output, the command results in a
Gluster-CLI read error. Fix this by forcing the Gluster command to be
run in the script mode.
Change-Id: Ic09f59732bf08942a9d216f70f1fc969d9ae0a2d
Closes-Bug: #1442339
- add gluster_version method to GlusterManager class
- gluster: check if version of the GlusterFS server is at least 3.5
- gluster_native: check if version of the GlusterFS server is at least 3.6
- gluster_native: on snaphot creation failure, interpret errno only
for GlusterFS strictly later than 3.6
Change-Id: I242ea83c3a31670eb6a13c11e39d0c2228170c50
Closes-Bug: #1417352
With this patch the allow_access and deny_access methods of
glusterfs_native will keep preexisting common names in the
affected GlusterFS volume 'auth.ssl-allow' option.
Also check in _setup_gluster_vol if 'auth.ssl-allow' is
set to a non-empty value to avoid semantically problematic
(and from Manila POV, useless) edge cases.
Change-Id: I952049d694509a338c7f56b45c5ef0872c3e7d70
Closes-Bug: #1439198
So far glusterfs_native was able to create shares
from volumes listed in 'glusterfs_targets' config
option.
New behavior: a regexp pattern is to be provided
through the glusterfs_volume_pattern config option.
Upon share creation, grep gluster server's volumes
with this pattern and create the new share from
one among those.
Change-Id: I12ba0dbad0b1174c57e94acd5e7f6653f5bfaae8
Closes-Bug: #1437176
The Manila test module uses a class called StubOutForTesting, which
is an awkward holdover from when the unit tests were using Mox.
Alex wrote a more elegant and capable mocker method,
manila.test.TestCase.mock_object, in the Cinder project which we
have now added to Manila. So to remove the duplicate functionality
and legacy code, all references to self.stubs.Set() in the Manila
tests should be replaced with self.mock_object() and any related
dead code should be removed.
Resolves-bug: #1415602
Change-Id: Ie5f203c0b2cb57ad00d9ec8db0529075b6fef261
The oslo team is recommending everyone to switch to the
non-namespaced versions of libraries. Updating the hacking
rule to include a check to prevent oslo.* import from
creeping back in.
oslo.messaging is the only exception because this package doesn't
currently support non-namespaced imports.
Change-Id: I3987e651bc880c8ffa7c0105df0298679dcd3a43
- Refactor the main driver class, GlusterFSShareDriver, to make it
pluggable with different NAS helpers.
- Add GlusterNFS helper class to manage shares served by Gluster-NFS
server. The management of these share was earlier done within the
main driver class.
- Enhance the methods of the GlusterAddress class that would be used
by the main driver class and the helper classes. Rename the
GlusterAddress class to GlusterManager class. This class would
contain the methods to interface with the backend GlusterFS volumes.
- Retire GlusterAddress.make_gluster_args() in favor of
GlusterManager.make_gluster_call(). The make_gluster_call() method
implements a more correct approach to remote execution. It's
remote execution is based on processutils.ssh_execute. The
make_gluster_args() method that it replaces facilitated remote
execution by prefixing arguments with 'ssh'.
- Move the interface used to fetch the value of an option set on a
GlusterFS volume, from the main driver class to the GlusterManager
class.
Partially implements blueprint gateway-mediated-with-ganesha
Change-Id: I3cbeb49c26f5f24152b42b649ce3bc75451964ef
Due to unclear meanings of existing names for share drivers modes it was
decided to replace string driver modes with boolean value, since we have only
two possible values that will clearly say what it used for by name of opt.
This replacement includes following changes:
- String opt 'share_driver_mode' is replaced with
bool opt 'driver_handles_share_servers'. New bool opt does not have
default value and should be defined explicitly.
- Class ShareDriver (parent class for share drivers) now expects additional
argument 'driver_handles_share_servers' which is mandatory and should be
provided by child classes. Expected values are boolean or tuple/list/set of
booleans that says what modes are supported. Above new config opt will be
compared to these.
- Update interfaces 'setup_server' and 'teardown_server' of class ShareDriver.
These interfaces now consider driver modes and call new additional private
methods only when driver is enabled to mode with share servers handling.
These new private methods are '_setup_server' and '_teardown_server', they
should be redefined by child classes when share servers should be handled by
Manila.
- To get know current driver mode within child classes just call property
'driver_handles_share_servers'. It can not be changed by child classes and
returns value that is set by config opt with same name.
- Remove methods 'setup_server' and 'teardown_server' from all share drivers,
that do not support handling of share servers.
- Rename methods 'setup_server' and 'teardown_server' to appropriate
private methods for drivers that do support handling of share servers.
- Update unit tests related to all changed places.
- Make Devstack set new mandatory bool opt.
Implements bp rename-driver-modes
Change-Id: I33402959bc4bbc34cfd4d7308ad0a7bcff3669b5
Driver mode functionality was implemented to be able to specify how
driver should work and filter backends scheduling share creation based on this.
Add to all drivers update of attr 'mode' based on its current behavior.
Set 'share_driver_mode' extra spec to volume/share type with one of available
values. Scheduler will use it for host filtering.
Implements blueprint driver-modes-for-scheduler
Change-Id: Ida644f630ee07c51c02aea5d6280980b5d704c2f
This patch adds support for working with multiple glusterfs volumes
for the GlusterFS native protocol driver. Since the semantics and
mapping for native driver is different compared to GlusterFS NFS
driver, this patch refactors the native driver as a standalone
driver and fixes some flows to fit the native driver with the
Manila share flows.
A more recent version of glusterfs having SSL support is needed.
Change-Id: I567c7602e97c9d55551baa29f121c05da2985007
Closes-Bug: #1368669