nova/releasenotes/notes/optional_project_id-6aebf1cb394d498f.yaml

17 lines
551 B
YAML
Raw Normal View History

Make project_id optional in v2.1 urls This introduces microversion 2.18 which signals that the {project_id} is no longer required in URLs. It tests this with an additional scenario in api_samples which makes all the requests without the project_id in the url (using a different noauth middleware to accomplish this). Update the link fixer in the ApiSamples matching code to also update for optional project_id. This is the least worse approach here, because if we set request_api_version, then we have to duplicate the entire template tree as well, which we definitely don't want to do, as it now correctly handles either url form. This updates the auth tests to bifurcate with testscenarios instead of the subclass model, which makes for more consistent tests. In order to support adding routes without project_id we have to be able to restrict project_id something that doesn't match any of our top level routes. The default for this is [0-9a-f\-]+ which will match all of the following: - keystone default generated project_ids [0-9a-f]{32} - integer project_ids (\d+) - known in use by RAX - uuids with dashes (no known users, but suspect there might be) This can be overrided with the new (but already deprecated) ``project_id_regex`` config option. NOTE: we used this feature to expand the regex to match 'fake' and 'openstack' as valid project ids in tests. Those concepts are deeply embedded in our tests, and need to be unwound independently. APIImpact Implements bp:service-catalog-tng Co-Authored-By: Augustina Ragwitz <auggy@cpan.org> Change-Id: Id92251243d9e92f30e466419110fce5781304823
2016-01-15 07:46:41 -05:00
---
features:
- Provides API 2.18, which makes the use of project_ids in API urls
Make project_id optional in v2.1 urls This introduces microversion 2.18 which signals that the {project_id} is no longer required in URLs. It tests this with an additional scenario in api_samples which makes all the requests without the project_id in the url (using a different noauth middleware to accomplish this). Update the link fixer in the ApiSamples matching code to also update for optional project_id. This is the least worse approach here, because if we set request_api_version, then we have to duplicate the entire template tree as well, which we definitely don't want to do, as it now correctly handles either url form. This updates the auth tests to bifurcate with testscenarios instead of the subclass model, which makes for more consistent tests. In order to support adding routes without project_id we have to be able to restrict project_id something that doesn't match any of our top level routes. The default for this is [0-9a-f\-]+ which will match all of the following: - keystone default generated project_ids [0-9a-f]{32} - integer project_ids (\d+) - known in use by RAX - uuids with dashes (no known users, but suspect there might be) This can be overrided with the new (but already deprecated) ``project_id_regex`` config option. NOTE: we used this feature to expand the regex to match 'fake' and 'openstack' as valid project ids in tests. Those concepts are deeply embedded in our tests, and need to be unwound independently. APIImpact Implements bp:service-catalog-tng Co-Authored-By: Augustina Ragwitz <auggy@cpan.org> Change-Id: Id92251243d9e92f30e466419110fce5781304823
2016-01-15 07:46:41 -05:00
optional.
upgrade:
- In order to make project_id optional in urls, we must constrain
the set of allowed values for project_id in our urls. This
defaults to a regex of ``[0-9a-f\-]+``, which will match hex uuids
(with / without dashes), and integers. This covers all known
project_id formats in the wild.
If your site uses other values for project_id, you can set a site
specific validation with ``project_id_regex`` config variable.