These are in the cinder doc tree so of course they're block
storage-related.
Change-Id: Ic1950ff89021a89de397619eef17f8100eb3d847
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
As per the community goal of migrating the policy file
format from JSON to YAML[1], we need to do two things:
1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.
2. Deprecate the JSON formatted policy file on project side
via warning in doc and format releasenotes.
1st item if already done by cinder in Stein so this commit
only cover the 2nd item.
Since oslo.policy 3.6.0, by default oslo policy will
fallback to existing policy.json file to give operator some
time to migrate it to new default policy.yaml. But cinder
already changed the default value to policy.yaml long back
since Stein so no need to fallback to default JSON file. To
do that it disable this fallback via flag to oslo.policy.
Also convert the tests/unit/policy.json to policy.yaml file.
Additionally, made some corrections to outdated documentation
when removing references to a "policy.json" file.
[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Co-Authored-By: Brian Rosmaita <rosmaita.fossdev@gmail.com>
Change-Id: Iaf8a454e60d1e4b66981b61175f89203cc15e439
This flag has been deprecated since Queens and is beinge removed from
python-cinderclient. We should only now state the supported multiattach
configuration using volume type extra specs.
Change-Id: Ic0156dc5abb15a04ba5c6e0900177aa6c22d7940
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The in-tree driver support matrix supersedes the potentially
stale driver support matrix wiki, so this updates the admin
docs for multiattach to point at the former rather than the
latter.
Change-Id: I7bf909e68eb14de4d56d4ab62e5e48abf3d40616
Per change I613b48a9e89270b2f0266bffc5aeeefad37ce8fb encryption
is not supported with multiattach-capable volumes.
Change-Id: Ife204c380a9d3d12938a907dee6d93d01aaec0ce
Related-Bug: #1770689
After giving some love to the multi-attach section it hopefully captures
the main characteristics of the functionality that we usually include
in the Admin Guide, such as volume creation, policies, microversions,
and back end support.
Depends-On: I11f97cf79e0c947b42de69cf8a7f6c1dbdb943a1
Co-Authored-By: Ildiko Vancsa <ildiko.vancsa@gmail.com>
Change-Id: I77bb849e039e1b44964ac0f30d48b5c16ca41b44
This patch adds the ability to create multiple attachments
for a single volume. This change requires that a volume
either be created with a special volume-type that includes
extra-specs indicating the requirement for multiattach
capabilities from the backend:
`extra_specs: {'multiattach': '<is> True'}`
or that an available volume is retyped to the specified
multiattach type.
What the patch does is pretty simple:
1. On volume create
Inspect the associated volume-type to see if it includes
the multiattach capability, if it does and
scheduling/creation is succesful; then we set the
multiattach attribute on the volume to True
2. On volume retype
We verify that if the retype involves multiattach
capability that it's allowed and check policy.
After retype, again we set/update the multiattach
attribute of the volume appropriately to match
the newly specified type.
Note that we do NOT do anything to enforce the volume is
formatted with a shared filesystem! Attempting to use
this feature with a standard ext4 filesystem will lead to
one or more of your attachments erroring out and being
converted to read only mode.
blueprint: bp/multi-attach-v3-attach
Change-Id: Ic8a8ba2271d6ed672b694d3991dabd46bd9a69f4
Stephen Finucane