Add file to the reno documentation build to show release notes for
stable/2024.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.1.
Sem-Ver: feature
Change-Id: Ic3db90536b004fa0606cb3920212dcdaa04bb4b0
This patch is a sample of mgmt driver for vnflcm v2 API
which deploying Kubernetes cluster using cilium CNI.
Implements: blueprint intro-cilium
Change-Id: Ibfd6958048204b53da7ebc8dd1d1694dfb7ee8f1
Co-Author: Yasufumi Ogawa <yasufum.o@gmail.com>
This patch obsoletes Legacy APIs excluding VIM feature.
And this patch mainly contains the following changes:
* Drop the implementation/db of NS and VNFFG functions.
* Remove the implementation that was used only by Legacy VNFM features.
* Remove the following components used only by Legacy features.
* ceilometer
* fenix
* blazar
* Drop the functional test jobs for Legacy features.
* Delete the unnecessary files that were used in Legacy tests.
Implements: blueprint deprecate-legacy-apis
Change-Id: I76ba79f42cf7c3f04c48a87de4ae893f2d53e467
There are two corrections:
First, according to SOL003, "authentication" should not appear
in the PmJobModifications response.
Therefore, it has been removed from the output obtained
when running "openstack vnfpm job update".
Second, the data type of PmJob href, as defined in SOL003,
has been changed to match the format of the Uri and
Link href defined in SOL013. This adjustment ensures
that the endpoints will now be displayed correctly.
Closes-Bug: #2054420
Change-Id: Id79ed19090271de4e32742f37cf54b6853acba2e
Previously SOL v2 related APIs such as prometheus plugin APIs
use SOL v2 API framework but there are a lot of duplication.
This patch reduces duplicate codes under SOL v2 API framework.
This patch also fixes wrong media type
'application/mergepatch+json' to 'application/merge-patch+json'
correctly.
Change-Id: Ic64fb5c1c18977198a7ff2746bde45400632abef
Tacker v1 API policies adopted the RBAC new defaults and
this document try to explain the changes and how operator
can use those. Also, adding the migration plan to move
from old default to new default.
Adding release notes also.
Implement blueprint implement-project-personas
Change-Id: Ib37cf65b79451a98e58b470726214e69624751a3
This adds new defaults roles in vnf-package API policies.
Backward compatibility:
- Old Rules and Defaults will keep working as it is because they
are added as deprecated rules and not removed. They are enabled
by default. This means existing deployement will continue working
in same way till deprecated rules are there and enabled by default.
- Legacy/current admin stays same and no change in their access permission
- Deprecation warning is added for old defaults so that operators will
know that new defaults are available to opt-in.
New defaults(project personas):
- Add new defaults but they are disabled by defaults and operators can adopt them
by enabling the oslo.policy config option. Basically add below in tacker.conf
[oslo_policy]
enforce_new_defaults=True
- All GET (read only) APIs are default to PROJECT_READER_OR_ADMIN
- Rest other APIs (write operations) are default to PROJECT_MEMBER_OR_ADMIN
Adding tests also to check permissions of new defaults.
Partial implement blueprint implement-project-personas
Change-Id: Ic7f5a9cd5aa10d93dfa491e5e60befb1f4bf2fcd
oslo.policy introduced the scope_type feature which can
control the access level at system-level and project-level.
- https://docs.openstack.org/oslo.policy/latest/user/usage.html#setting-scope
As per the SRBAC design, OpenStack does not support system scope so
we need to make scope type of each policy rule to project.
- https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-1
The policy with 'project' scope means user with 'project-scoped'
token have permission to access which is nothing but the current
case so no change in permission level. By adding the scope_type
to project explicitly gives benefit of better error message. For
example, if any user with system scope token try to access tacker
APIs then oslo policy will fail early (instead of failing in lower
layer at DB or VIM level) and give clear error message of invalid
scope.
This commit adds project scope in VNF Package policies and its tests
also.
Partial implement blueprint implement-project-personas
Change-Id: I835817a87b6274662a9d612d9004eca1463bc586
This adds new defaults roles in vnf-lcm API policies.
Backward compatibility:
- Old Rules and Defaults will keep working as it is because they
are added as deprecated rules and not removed. They are enabled
by default. This means existing deployment will continue working
in same way till deprecated rules are there and enabled by default.
- Legacy/current admin stays same and no change in their access permission
- Deprecation warning is added for old defaults so that operators will
know that new defaults are available to opt-in.
New defaults(project personas):
- Add new defaults but they are disabled by defaults and operators can adopt them
by enabling the oslo.policy config option. Basically add below in tacker.conf
[oslo_policy]
enforce_new_defaults=True
- All GET (read only) APIs are default to PROJECT_READER_OR_ADMIN
- Rest other APIs (write operations) are default to PROJECT_MEMBER_OR_ADMIN
Adding tests also to check permissions of new defaults.
Partial implement blueprint implement-project-personas
Change-Id: Id4b4b9f2ed4029352ccd6564f757ec7f6a69419d
oslo.policy introduced the scope_type feature which can
control the access level at system-level and project-level.
- https://docs.openstack.org/oslo.policy/latest/user/usage.html#setting-scope
As per the SRBAC design, OpenStack does not support system scope so
we need to make scope type of each policy rule to project.
- https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-1
The policy with 'project' scope means user with 'project-scoped'
token have permission to access which is nothing but the current
case so no change in permission level. By adding the scope_type
to project explicitly gives benefit of better error message. For
example, if any user with system scope token try to access tacker
APIs then oslo policy will fail early (instead of failing in lower
layer at DB or VIM level) and give clear error message of invalid
scope.
This commit adds project scope in VNF LCM policies and its tests
also.
Partial implement blueprint implement-project-personas
Change-Id: Iead7f82b8c22c0c67981f5a7ae3a86016ee64734
We are introducing new default roles (project personas) in
Tacker policies. To reuse those new default roles among policies,
default base rules have been defined in base class.
Those are basically:
- admin: stay same
- project member or admin: this is replacement of admin-or-owner for write operations
- Project reader or admin: this is replacement of admin-or-owner for reader operations
Partial implement blueprint implement-project-personas
Change-Id: Id95d07e6f2bb66eddc4205c541d606af9271ef44
In tacker.policy.authorize() method, it convert the context
object to policy value by context.to_policy_values() and then
pass that into oslo.policy enforcer authorize() method.
This is fine till now and does not cause any issue but as per
SRABC, we need to set if token is system scope (for project
scope it is all fine) in oslo policy creds via key 'system'.
But context.to_policy_values() method does not set the 'system'
key in creds because there it is named as `system_scope`.
To fix that we need to explicitly set the 'system' key in creds.
Partial implement blueprint implement-project-personas
Change-Id: I65d28749a4584661f7f4f596c4d2c39a84730963
This patch separates the documents for v1 API and v2 API
that are described in the same document in UseCaseGuide.
Existing documents are modified for v1 API, and
v2 API documents are newly placed under `doc/source/user/v2`.
And some VNF Package samples have also been added.
Change-Id: I6d99a660df32b457ea70a64bfd153bc76ac2d9fe
Current tests do not have good test coverage of VNF LCM
APIs policies. Either tests for policies do not exist or
if they exist then they do not cover the actual negative
and positive testing.
Basically this commit does the following:
* Add RBAC tests:
As we are implementing the project personas (project member
and reader role) in policies, we need to have the enough
testing coverage of existing policy behavior and to know
that with new defaults how the access permissions will
looks like.
* Pass correct target to oslo policy:
Currently, APIs are not passing the right targets to oslo
policy, means VNF instance project_id was not passed as target.
We need to pass the project_id so that we can check the 'onwer'
permission correctly at RBAC level and RBAC checks pass and
request goes to fetch the data from DB where project_id
is checked. For example, GET VNF API requests by a non
admin user does not check if requester users is from same
project of requested VNF or not and request pass the oslo
policy checks and make DB request. Passing the right project_id
in oslo policy will return the request (if projectA request projectB
VNF) from policy checks itself. This can be seen in modified
test_controller.py tests.
Partial implement blueprint implement-project-personas
Change-Id: I1e8d98d6b94507783ba34d149642c019609247e6
Current tests do not have good test coverage of VNF LCM
APIs policies. Either tests for policies do not exist or
if they exist then they do not cover the actual negative
and positive testing.
Basically this commit does the following:
* Add RBAC tests:
As we are implementing the project personas (project member
and reader role) in policies, we need to have the enough
testing coverage of existing policy behavior and to know
that with new defaults how the access permissions will
looks like.
* Pass correct target to oslo policy:
Currently, APIs are not passing the right targets to oslo
policy, means VNF instance project_id was not passed as target.
We need to pass the project_id so that we can check the 'onwer'
permission correctly at RBAC level and RBAC checks pass and
request goes to fetch the data from DB where project_id
is checked. For example, GET VNF API requests by a non
admin user does not check if requester users is from same
project of requested VNF or not and request pass the oslo
policy checks and make DB request. Passing the right project_id
in oslo policy will return the request (if projectA request projectB
VNF) from policy checks itself. This can be seen in modified
test_controller.py tests.
Partial implement blueprint implement-project-personas
Change-Id: Ib022397f715c6aa08718a6867d2f2ea19c517c00
Current tests do not have good test coverage of existing
RBAC policies. Either tests for policies do not exist or
if they exist then they do not cover the actual negative
and positive testing.
Along with what all users have access, it is important to
test what all users does not have access.
For Example, if any policy with default rule as admin only then
test should verify:
- policy check pass with context having admin role
- policy check fail with context having non-admin role
As we are implementing the project personas (project member
and reader role) in policies, we need to have the enough
testing coverage of existing policy behavior and to know
that with new defaults how the access permissions will
looks like. These test coverage will be extended to adopt
the new changes and also make sure we do not break the
existing behavior.
This commit adds the testing framework for RBAC and implement
create VNF test as example. It will cover other APIs in further
changes in this series.
Partial implement blueprint implement-project-personas
Change-Id: I5b0d039c6aebda6ba0653032ac5a1963a704cb59
This patch fixes the problem that instantiating a vnf instance
succeeds wrongly when a resource made by another instance with
the same name exists.
This patch adds "tacker_vnf_instance_id" to metadata.labels
when creating kubernetes resources in CNF v2 API Instantiate,
and when creating or deleting resources, if the resource already
exists, it checks if it was created in own vnf instance by
metadata.labels.
Closes-Bug: #2053098
Change-Id: I4a22fc50706750f9689d89d24c1db28de8e2dc90
This patch fixes an issue where the filter attribute of vnflcm
subscription (v1 API) could not be retrieved because oslo.db version
was updated to 15.0.0 [1].
The reason of the issue was that obj's data type, which was obtained
when oslo.db was 14.1.0 and 15.0.0, was different as below:
* oslo.db==14.1.0: sqlalchemy.engine.row.LegacyRow
* oslo.db==15.0.0: sqlalchemy.engine.row.Row
This patch changes the existence validation of the filter key for
`vnf_lcm_subscription` in the `sqlalchemy.engine.row.Row` case.
[1] https://review.opendev.org/c/openstack/requirements/+/909930
[2] https://pydoc.dev/sqlalchemy/latest/sqlalchemy.engine.row.Row.html
Closes-Bug: #2055431
Change-Id: I8c1543bb724b6f2c4f3f4f7edecdfef063d3d9a4
This patch is to fix a lack of required packages for building devstack
environment and drop old focal support.
* Add pip installation of pbr for ovn-metadata agent and netaddr for
kuryr-kubernetes.
* Remove boxes and playbooks for focal.
Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
Change-Id: Ie345e50e09a3236d0c2ab9ff1494058bdc6c010b
Zuul
OpenStack Release Bot