Zuul FT has failed by multiple reasons,
A: devstack changes default ML2 Driver to OVN.
B: kuryr-kubernetes changes to use kubeadm.
This patch is just workaround for FT errors caused by above changes.
The formal fixes will be done separately.
[About A: devstack change]
Zuul FT has failed to build the environment with the following error:
'The q-agt/neutron-agt service must be disabled with OVN.'
The FT error is caused by a merged devstack patch [1],
[1] https://review.opendev.org/c/openstack/devstack/+/791436
This patch temporarily set ML2 driver to `openvswitch` that was used as
default value before merging [1] patch.
[About B: kuryr-kubernetes change]
Some nodes using the kuryr-kubernetes service will fail to build with
the error shown in the bug report [2].
[2] https://bugs.launchpad.net/bugs/1930368
Above error seems to be occured by kuryr-kubernetes patch [3] that
changes to use kubeadm for installing Kubernetes on devstack.
[3] https://review.opendev.org/c/openstack/kuryr-kubernetes/+/779250
This patch temporarily use kuryr-kubernetes stable/wallaby branch
for resolving FT error.
Change-Id: I7742c30ed6cb910d58183c18e859acac244ff3ae
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: Iffafed2f86ee857cdcb2bf8e5baf7e7054aa7ed4
Currently vnflcm api operations do not return host-path
in their output inside '_links' href field.
For ex,
"_links": {
"self": {
"href":
"/vnflcm/v1/vnf_instances/<vnf-instance>"
}
}
This patch updates '_links' href field in vnflcm api output
with host-path.
For ex,
"_links": {
"self": {
"href":
"http://localhost:9890/vnflcm/v1/vnf_instances/<vnf-instance>"
}
}
*here "http://localhost:9890/" is just an example of host-path.
Related operations:
1. Creates a new VNF instance.
2. Show VNF Instance.
3. List VNF Instances.
4. Show VNF LCM operation occurrence.
5. List VNF LCM operation occurrences.
Co-Authored-By: Navum Gupta <navum.gupta@india.nec.com>
Closes-Bug: #1923360
Change-Id: I245cd2626fac1112d6a9fef3c51bf5ef6b679e05
tacker-server has got two-stage process launcher since a long time ago.
While it doesn't matter if {api_workers} is set to one or unset, which
is the case by default on installation via devstack, it should have
resulted in an odd situation in other cases as follows:
1). surprisingly the number of workers was not {api_workers} but
{api_workers}*{api_workers}. Notice that the launcher processes are
also present so the resulting number of tacker-server processes was
1+{api_workers}*({api_workers}+1).
E.g., when {api_workers}=100, the number of tacker-server processes
is 10101.
2). GreenPool is per the second stage launcher. That means {api_workers}
number of workers, each of which is a green thread on a seperate
process (spawned by ProcessLauncher), share the same pool. It means
that the second stage launcher does not only fail to provide
performance scaling, but also more likely to unnecessarily keep some
workers starved due to a process which starts sleeping before
yielding.
This patch fixes it so that there is just a one-stage launcher.
[Before this patch]
master
├── worker#0 # second-stage launcher
│ ├── worker#0-0 (*1)
│ ├── worker#0-1 (*1)
│ :
│ └── worker#0-{api_workers-1} (*1)
├── worker#1 # second-stage launcher
:
└── worker#{api_workers-1}
:
└── worker#{api_workers-1}-{api_workers-1} (*1)
[After this patch]
master
├── worker#0 (*1)
├── worker#1 (*1)
:
└── worker#{api_workers-1} (*1)
(*1) spawns one green thread at the start.
Closes-Bug: #1923528
Change-Id: I2bf567a0367659c170af0b618374a51d0f13eece
This patch will fix the issue about the missing endpoint
information in the interfaceInfo of vimConnectionInfo.
Closes-Bug: #1923425
Change-Id: I364ab27ad14f0af06a1befed28196bd1b027e909
When running openstack vnflcm show command in CLI,
some over intended bugs and ip version error will happen.
This patch fixes vnfm/infra_driver/openstack.py
in order to fix these bugs.
Closes-Bug: #1922544
Change-Id: Ie3b95c3bf2c62056dfd6ac659e32825c75d21fac
In kubernetes_mgmt, it will find 'Install Failed!\n' in stdout
to judge raise a exception of script install failed.
However in recent fix, we changed error message from script,
thus kubernetes_mgmt cannot catch error msg from stdout,
exception will not be raised.
This patch will fix matching error message in kuberntes_mgmt.
Closes-Bug: #1922192
Change-Id: Iffb3e045cbe121aca0fc74621cc5b3b5daf69f5b
in vnflcm_drive._term_resource_update(),
it is checking if 'affected_vnfcs' is existing in
vnf_lcm_op_occs.resource_changes.
However, 'affected_vnfcs' may be None,
and cause an None type error in next line,
using len() for affect_vnfcs.
(same to other 2 variables below)
This patch is adding None judgement before
len()
Closes-Bug: #1922191
Change-Id: I19aedf0940d8b8d51fa5bd1d5c5092655d7970b0
2 new methods are added at last time merge of
Wallaby release in vnflcm_abstract_driver.py.
* change_external_connectivity_start()
* change_external_connectivity_end()
(tacker/vnfm/mgmt_drivers/vnflcm_abstract_driver.py#L88)
In kubernetes_mgmt.py,
(sample/mgmt_drivers/kubernetes_mgmt.py)
we inherited VnflcmAbstractDriver thus we also
needed to implements these 2 methods here.
Due to we don't have these interfaces here, I updated
empty methods for clear runtime error.
Change-Id: I9f918ceff9882da1bff4b1cc953602a3b84aec0c
For below VNFInstance's operations "Location header" will be present
1) heal
2) instantiate
3) terminate
Response header will contain the "Location" HTTP header field.
And this "Location" HTTP header will contain "vnfLcmOpOccId".
This patch changes notification parameter based on
SOL013 7.1.4 Type: NotificationLink.
As per SOL003, 5.5.2.17, VnfLcmOperationOccurrenceNotification
represents a VNF lifecycle management operation occurrence
notification, which informs the receiver of changes in the
VNF lifecycle caused by a VNF LCM operation occurrence.
This notification shall be triggered by the VNFM,
when there is a change in the state of a VNF LCM operation
occurrence that changes the VNF lifecycle, including:
• Instantiation of the VNF
• Scaling of the VNF instance (including auto-scaling)
• Healing of the VNF
and others.
URI of a resource referenced from a notification
should be an absolute URI if APIRoot is known.
Co-Authored-By: Sheel Rana <ranasheel2000@gmail.com>
Closes-Bug: #1915107
Closes-Bug: #1911625
Change-Id: I3a325634f88b9521d7fa2f524076934df315742d
While calling _get_by_name() in kubernetes_mgmt, it is passing
self + other 3 parameters.
However it is calling _get_by_name() by instance,
thus passing self is not needed and will cause an unmatch
parameters error during Terminate process
Closes-Bug: #1922194
Change-Id: Ic4601cb277c02b2d41263724bb2ce21e7d24cdbb
Grant for 3rd-party NFVO is improved. Process related to placement
constraints is supported. This enables interoperability with
3rd-party NFVO which enables them to deploy each VM in the VNF after
setting the zone information based on the grant response from NFVO.
Co-authored-By: Yasufumi Ogawa <yasufum.o@gmail.com>
Implements: blueprint support-placement-constraints
Change-Id: Ibd8c5cae985766d5bd5e73276920fd4c28d6e87f
There are so many warning messages appear while running tests. It's
because of a change in `oslo.policy` for notifying that some policy
rules are the same as default. So, this change removes duplicated
policies from policy file.
Closes-Bug: #1921981
Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
Change-Id: I8a75bac1659ceff2efbb5ae017b131506a689e29
An error occurs in tox due to an incorrect setting of
properties related to tosca.policies.tacker.Scaling.
Therefore, this patch fixes the related VNFDs.
The error is occurring in unittest and FT, so fix both.
At the same time, there was a problem with the version of
heat-translator, so modify the following files as well.
- lower-constraints.txt
- requirements.txt
Co-Authored-By: Yasufumi Ogawa <yasufum.o@gmail.com>
Change-Id: Iae2b25abe53eda483e811171306d3d375a7e1687
Closes-Bug: #1921996
This patch fixes some bugs related legacy cnf operations below:
* Delete the "unsupported key check" of policies in TOSCA template, to
resolve `openstack vnf create` command failure due to property
validation of policies.
* Change the branch condition of legacy/sol, to resolve the
`openstack vnf scale` command failure due to keyError.
* Add interval to each retry loops of delete_wait_legacy, to resolve
the `openstack vnf delete` command failure.
And this patch revises the documentation for legacy cnf operations to
work properly.
Closes-Bug: #1920085
Change-Id: If14b95b2f9dfafe994a5ebf4f447a2bf7d27981c
Add file to the reno documentation build to show release notes for
stable/wallaby.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/wallaby.
Sem-Ver: feature
Change-Id: I07255d22a0bcfcf9cd577e81bccf4b1bc9586b93
This update is to fix styles and revise some descriptions to be
concise in the second paragraph in draft verion of releasenote
for wallaby[1].
[1] https://docs.openstack.org/releasenotes/tacker/
Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
Change-Id: Iba1069db766770434dc9d126de33d646fc228485
- Added support for the following attributes:
*operationStates
*vnfInstanceSubscriptionFilter
- The filtering criteria is enhanced by adding the
above attributes to effectively send_notifications
- We also updated the following table in DB:
vnf_lcm_filters
Implements: blueprint support-fundamental-lcm
Spec: https://specs.openstack.org/openstack/tacker-specs/specs/wallaby/support-fundamental-vnf-lcm-based-on-ETSI-NFV.html
Change-Id: Iebe70c43ef1a5b653f8ec204b1b3a79ca882399f
Usage guide for ETSI Change external VNF connectivity is added in
user docs.
This patch describes the procedure for Change external VNF
connectivity operation.
Change-Id: I6f90d8b21f08e27bea60df66479e7951cbad7b5b
This feature will enable the client to use this API to initiate
retrying Change VNF External VNF Connectivity operation when it
fails.
It is based on the ETSI NFV specification that retry can be used
when a VNF lifecycle operation is in a FAILED_TEMP state.
Implements: blueprint support-change-external-connectivity
Spec: https://specs.openstack.org/openstack/tacker-specs/specs/wallaby/support-change-external-VNF-connectivity-operation.html
Change-Id: Ia1d907922cdb701586f15c4840848fa8402ded3b
Zuul
Ayumu Ueha
Yasufumi Ogawa
Sheel Rana
Akihiro Motoki
maaoyu
Koichiro Den
Aldinson Esto
LiangLu
spandit
OpenStack Release Bot
Hiroo Kitamura
Koichi Edagawa