Shared filesystem management project for OpenStack.
263d5438f0
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> |
||
|---|---|---|
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc | ||
| httpd | ||
| manila | ||
| playbooks/manila-tox-genconfig | ||
| rally-jobs | ||
| releasenotes | ||
| tools | ||
| zuul.d | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .pylintrc | ||
| .stestr.conf | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| lower-constraints.txt | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
Team and repository tags
MANILA
You have come across an OpenStack shared file system service. It has identified itself as "Manila." It was abstracted from the Cinder project.
- Wiki: https://wiki.openstack.org/wiki/Manila
- Developer docs: https://docs.openstack.org/manila/latest/
Getting Started
If you'd like to run from the master branch, you can clone the git repo:
git clone https://opendev.org/openstack/manila
For developer information please see HACKING.rst
You can raise bugs here https://bugs.launchpad.net/manila
Python client
https://opendev.org/openstack/python-manilaclient
- Documentation for the project can be found at:
https://docs.openstack.org/manila/latest/
- Release notes for the project can be found at:
https://docs.openstack.org/releasenotes/manila/
- Source for the project:
https://opendev.org/openstack/manila
- Bugs:
https://bugs.launchpad.net/manila
- Blueprints:
https://blueprints.launchpad.net/manila
- Design specifications are tracked at: