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
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
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
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
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
- 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
- Use '%' for variable substitution in the message used for logging a
call and throwing an exception.
- Use log marker functions(_LI(), _LW(), _LE(), and _LC()) to send
message directly to the log.
- Use ',' for variable subsitution in the message in a log marker
function.
Change-Id: Ib925014e79d2c380954d952f5dbc835971a0b320
Closes-Bug: #1439762
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
Module 'log' from oslo-incubator was removed after release of oslo_log library.
So, start using oslo_log, but keep oslo-incubator code yet other common modules
within Manila codebase use it.
Implements bp use-oslo-log-lib
Change-Id: I88224f7c2bd99adb78140dfc3fa73cea437f29cd
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
Several things are implemented:
- Allocation/deallocation now handled by drivers instead of share manager.
It provides flexibility for drivers.
- Network plugin interface was updated to support new approach for
configuration options setting.
Config opts for network plugin can be defined via three sources:
a) using separate config group
b) using config group of back end
c) using DEFAULT config group
Variants (a) and (b) are mutually exclusive, there are switched by
opt 'network_config_group' that belongs to share driver interface.
Implements bp network-helper
Change-Id: I3b05369f01777675c1b834af5ee076d8b7219a0f
LOG.warn etc. should be translated separately and thus messages need to
be marked with _LW for LOG.warn, _LI for LOG.info and _LE for LOG.errors
and LOG.exception.
Mark all LOG invocations with proper translation marker.
Use ',' instead of '%' when adding variables to log messages to allow
lazy evaluation.
Add new hacking checks for these.
Change-Id: I31d3ee50f30c63d7d647b1c2b1eae50bf96f0c74
oslo.i18n provides the i18n function that were provided by
oslo-incubator's gettextutils module
Import _ where needed, oslo.i18n deprecated the builtin method.
Closes-Bug: #1382187
Change-Id: I12aa1c725aa4bb52a9aa46e9c3d2b303839de48b
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
This patch adds basic support for glusterfs native protocol driver
that uses cert based access type.
A Manila share is a GlusterFS volume. Unlike the generic driver, this
does not use service VM approach. Instances directly talk with the
GlusterFS backend storage pool. Instance use the 'glusterfs' protocol
to mount the GlusterFS share. Access to the share is allowed via
SSL Certificates. Only the share which has the SSL trust established
with the GlusterFS backend can mount and hence use the share.
Establishing the SSL trust between the instance and backend is done
out of band of Manila.
Partially-implements blueprint cert-based-access-type
Change-Id: I229d481086478317f1c43635304a16794372f09d
Csaba Henk