Allows set min/max share size that can be created in
extra_specs for each share_type.the share size will
be checked at API level as part of share create,
extend, shrink, migration_start. when manage share,
check it after get true size of share at manager layer.
new extra_specs keys are supported for set min/max
size of share.
'provisioning:max_share_size'
'provisioning:min_share_size'
Implements: blueprint share-size-limited-by-share-type
Change-Id: I5ce0fabf59bfca5ebaf0be5ffe9986e2b0480295
This commit updates the policies for share locations to understand scope
checking and account for a read-only role. This is part of a broader series of
changes across OpenStack to provide a consistent RBAC experience and improve
security.
Change-Id: Iaebbadea3ed153f19e7abb13d7d28ae3b6bb1fd9
This commit updates the policies for share
access rule metadata to understand scope
checking and account for a read-only role.
This is part of a broader series of
changes across OpenStack to provide a
consistent RBAC experience and improve
security.
Change-Id: Ie9fafd00f1a1888979fbce2a66af53613f8052c7
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
This commit updates the policies for share access rules to understand scope
checking and account for a read-only role. This is part of a broader series of
changes across OpenStack to provide a consistent RBAC experience and improve
security.
Change-Id: I12026c7874620abb076df979f0492f6d1b8563fd
This commit updates the policies for security services
to understand scope checking and account for a read-only
role. This is part of a broader series of changes across
OpenStack to provide a consistent RBAC experience and
improve security.
Change-Id: I399a61691dad3a80c289c9f3f99f3c48be07846f
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Non privileged users of unrelated projects
must not be able to retrieve details of an
access rule. We can add a further check to
/share-access-rules APIs to validate that
the caller has access to the share that these
rules pertain to.
Change-Id: I0009a3d682ee5d9a946821c3f82dfd90faa886aa
Closes-Bug: #1917417
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Manila's RequestContext base class was
recently refactored to allow arbitrary
keyword arguments to be passed on to the
base Context class in oslo_context. This
was done so that we don't have to maintain
every new addition to Context within manila
code since that layer may change as the
middleware components (keystonemiddleware, for
example) evolve outside of manila.
During this refactor, "system_scope" was
inadvertently added as a separate keyword
argument, and it wasn't being passed to the
base class, causing system scoped users to
not be represented correctly in the API.
We can drop this parameter and allow it to
flow transparently through "kwargs".
Change-Id: I88b664c631eddced4ee1fcdf34cf05222cb73662
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
The profiler integration with the shared file system service(Manila)
allows to trace commands issued using both manila-client and
openstack-client.
Note that osprofiler should be run from admin user name & tenant.
Closes-Bug: #1915116
Change-Id: Ic16bc3cb03b851003c189450b398f8dd5dde8160
*) Add osprofiler wsgi middleware
This middleware is used for 2 things:
1) It checks that person who want to trace is trusted and knows
secret HMAC key.
2) It start tracing in case of proper trace headers and add
first wsgi trace point, with info about HTTP request
*) Add initialization of osprofiler at start of serivce.
You should use python-manilaclient with this patch:
https://review.opendev.org/#/c/769731
Run any command with --profile SECRET_KEY
$ manila --profile SECRET_KEY create NFS 1 --name <share> \
--description <share_description> --share-network <network> \
--share-type default
# it will print <Trace ID>
Get pretty HTML with traces:
$ osprofiler trace show --html <Trace ID> --connection-string \
<connection_string> --out <output.html>
e.g. --connection-string can be redis://localhost:6379
Note that osprofiler should be run from admin user name & tenant.
Implements: blueprint manila-os-profiler
Change-Id: I3bce1f04d1cfebfacd78ed135a949a068c78987d
This patch fix a sqlalchemy object copy made in the driver
that can raise a 'DetachedInstanceError' exception, depending on
changes made in the DB model. A simple copy is being made instead, to
have a new share object with share server information inside it.
Change-Id: I5fef50a17bc72ba66a3a9d6f786742bcb5745d7b
Signed-off-by: Douglas Viroel <viroel@gmail.com>
These policies were deprecated in Stein and flagged
for removal in Train. Now that we're in the Wallaby
development cycle let's remove them.
Depends-On: I2a647fd5871ef6bb7d1ab45db893a44a560bed72
Change-Id: I6e7608be57de8987117f3f4ace018a7eb91c8bd2
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
python documentation recommends the
use of the requests package when performing
http requests. We could simplify our unit
test interface that performs HTTP requests
by replacing the use of http_client.HTTPConnection
with requests.
[1] https://docs.python.org/3/library/http.client.html
Change-Id: I3dd1f836a3cb2b4d36ff3fbe6f0258f4b0e0ba71
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
RequestContext has a helpful "from_environ"
method that can handle all possible combinations
of auth information users can send our way
when manila is deployed with its Keystone auth
middleware. We could switch to that, so that
we don't have to maintain support for the
full list of current and deprecated auth
configuration options in our auth
middleware.
While we're there, we can also update the
"to_dict" and "from_dict" methods in manila's
context class to match the information we need.
Change-Id: I5d554caf82a1fc4f1dcfede3ea61159ddaeb342e
Closes-Bug: #1602081
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
As of API version 2.60, a project_id is no
longer needed in the API URLs.
Fix the docs to indicate that.
Also fix up a few quota parameters that use
project_id in a different place in the API path.
Change-Id: I24b32c8521805a7d67d512d36d644c0f07c532ea
Implements: bp remove-project-id-from-urls
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
A few releases ago, service types were standardized
across OpenStack [1] and manila's service type was
recommended as "shared-file-system" [2]. Tools were
meant to look at the service-types-authority [3]
and os-service-types repository [4] to find a list
of standard service type names for various first
party OpenStack services.
The openstacksdk currently relies on the service
type to be "shared-file-system" [5], so let's set
one up in devstack, to aid contributors working on
openstacksdk.
It is desirable to have all clients to initially
look for the standard service type name in the
cloud's service catalog, and fall back to the
legacy name ("sharev2") in environments that
call the v2 API that.
[1] https://specs.openstack.org/openstack/service-types-authority/
[2] https://service-types.openstack.org/service-types.json
[3] https://opendev.org/openstack/service-types-authority
[4] https://opendev.org/openstack/os-service-types
[5] f4dd6fe5fd/openstack/_services_mixin.py (L71-L72)
Change-Id: I6a1ada102a40f3e83fe8e5287856d01dd137ea95
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
As of API version 2.60, a project_id is no
longer needed in the API URLs. We can stop
devstack from setting up an endpoint with
project_id in it.
Create a "sharev2_legacy" endpoint that
contains the project_id for testing the
compatibility with the older style of URLs.
Change-Id: I25aeb1b6dd1a4150c6e542e29b7d43e18d9ad94c
Implements: bp remove-project-id-from-urls
Depends-On: I5127e150e8a71e621890f30dba6720b3932cf583
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Manila APIs have had the requirement to include
project_id in the URLs since the very beginning.
This comes from an old assumption that our APIs
would be differentiated per-tenant on the cloud,
and we would allow different kinds of API endpoints
(public, admin, internal, etc). While it is possible
to set up different endpoints against the API
service, the same and complete API is exposed at
each of these endpoints.
We don't _need_ the project_id information that
we receive in the URL for any of our APIs to
function. We rather authorize tenants by gathering
information from the Identity service (Keystone)
and wrapping that into a RequestContext object
that we then rely on to ensure namespace isolation.
Removing the requirement for "project_id" simplifies
our API endpoint structure in the service catalog
as well as provides a way for system scoped users
to interact with manila without having to declare
their project.
In order to make project_id optional in urls, the
possible values of project_id have to be constrained.
This change introduces a new configuration option
so deployers may control that. This configuration
option defaults to accepting UUIDs with and without
dashes.
Since manila can be used in standalone deployments
without the need for Keystone, this change introduces
a noauth middleware that can work without project_id
in the URL paths.
The API version has been incremented to signal this
change to end users. When 2.60 is available, deployments
may drop "project_id" in the service catalog endpoint
for Manila and end users applications can stop needing
it as well (if they don't already rely on the service
catalog for this data).
APIImpact
Implements: bp remove-project-id-from-urls
Change-Id: I5127e150e8a71e621890f30dba6720b3932cf583
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
This change makes healtcheck middleware enabled by default, so that
operators can use the middleware to monitor service availability for
various purpose like healthcheck by load balancers.
Change-Id: I47e65d23ebfe310643896e1de3396cd627a3def3
Access rules added to CephFS shares can fail
at the driver, or by the ceph volume client library.
Since the share manager can supply rule changes to
the driver in batches, the driver has to gracefully
handle individual rule failures.
Further some of the causes of the access rule
failures can be remedied by end users, therefore
asynchronous user messages would be a good vehicle
to register user faults that can be examined and
corrected.
Related-Bug: #1904015
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-27781
Change-Id: I3882fe5b1ad4a6cc71c13ea70fd6aea10430c42e
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
remove usage of six library from the following directory:
1:common
2:data
3:db
4:message
5:network
6:scheduler
Change-Id: I9db0abf2b0847157074ca6ba84b5451bfe3f20d0
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
MANILA_MULTI_BACKEND has been deprecated for five years now, we should remove
it from our code base.
This variable was removed from the settings scripts along with:
MANILA_BACKEND1_CONFIG_GROUP_NAME and MANILA_SHARE_BACKEND1_NAME;
MANILA_BACKEND2_CONFIG_GROUP_NAME and MANILA_SHARE_BACKEND2_NAME.
Because they work in the same context.
Instead of them, the already implemented and in use,
MANILA_ENABLED_BACKENDS variable was placed to garantee the successful
back-end setup. The same replacement was made in the contribution
samples scripts.
Apart from this, we avoid configuring generic1 and generic2 if
another backend/s are selected.
Closes-Bug: #1898791
Closes-Bug: #1878477
Change-Id: I67036a65da9255694a00a9c8d56cfdefbdf23c05
