5c17e4c7ef
Instead of a default policy.json file, policy defaults are now defined in code. An operator need not supply policy.json data except to the extent they want to override the defaults. Currently an empty policy.json is still shipped because it is expected by devstack, but this can be removed later. A sample policy.yaml file can be generated using the genpolicy tox environment. This partly fulfils the requirements of the policy in code goal[1]. However, because policies don't map 1:1 with APIs, it will not be possible to fully document the policies until changes are made in how policies are applied as proposed in https://review.opendev.org/528021 Due to the fact that existing policy files may rely on a rule named "default" to specifiy policies not explicitly listed in the policy.json file, all policies that are not admin-only by default now default to "rule:default", so that the "default" rule will continue to apply to those policies that are not listed in policy.json. To ensure that this yields the expected policy in a standard policy-in-code config file, the default value of the "default" rule is now the empty string "". This is a change; between the Queens release and now the default was set to "role:admin" to match the value specified in the default policy.json file. An installation relying on both the "default" rule for some policies and the default value of the default rule may end up with a more permissive policy after upgrading. It's likely that no such policies exist in the wild, because prior to the Queens release the default value for the "default" rule was "@" (allow all requests), so anybody relying on this rule will surely have specified it explicitly in their policy.json. Policies whose default is "role:admin" no longer use the "default" rule. Therefore existing policy.json files that rely on the "default" rule for those policies, and who have specified a value for the "default" rule that is more permissive, will result in a more restrictive policy after upgrading. It is unlikely that any of these policies exist in the wild either. [1] https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.html Change-Id: I8d1ccf5844078cc0b1652fb1130794daf07cedbc
OpenStack Glance
Glance is an OpenStack project that provides services and associated libraries to store, browse, share, distribute and manage bootable disk images, other data closely associated with initializing compute resources, and metadata definitions.
Use the following resources to learn more:
API
To learn how to use Glance's API, consult the documentation available online at:
Developers
For information on how to contribute to Glance, please see the contents of the CONTRIBUTING.rst in this repository.
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.
Further developer focused documentation is available at:
Operators
To learn how to deploy and configure OpenStack Glance, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. You can raise bugs here:
Release notes
To learn more about Glance's new features, optimizations, and changes between versions, consult the release notes online at:
Other Information
During each design summit, we agree on what the whole community wants to focus on for the upcoming release. You can see image service plans:
For more information about the Glance project please see: