[Yahoo-eng-team] [Bug 1815478] Re: Error message 'Invalid protocol %(protocol)s for port range, only ...' is difficult to understand
Reviewed: https://review.openstack.org/636174
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=d8e8fe7db583d0a32b795c8be5ddfea1dc9ee97d
Submitter: Zuul
Branch:master
commit d8e8fe7db583d0a32b795c8be5ddfea1dc9ee97d
Author: Andreas Karis
Date: Mon Feb 11 12:04:20 2019 -0500
Improve invalid port ranges error message
Improve error message that is shown when
port ranges are specified for protocols that don't
support port ranges.
Change-Id: I70ad9bd01f986efaed6682928cc5579c75bd4f6e
Closes-Bug: #1815478
Signed-off-by: Andreas Karis
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1815478
Title:
Error message 'Invalid protocol %(protocol)s for port range, only ...'
is difficult to understand
Status in neutron:
Fix Released
Bug description:
Error message 'Invalid protocol %(protocol)s for port range, only ...' is
difficult to understand.
~~~
43 class SecurityGroupInvalidProtocolForPortRange(exceptions.InvalidInput):
44 message = _("Invalid protocol %(protocol)s for port range, only "
45 "supported for TCP, UDP, UDPLITE, SCTP and DCCP.")
~~~
Thinking about it logically, the port range is invalid for the
protocol, not the other way around.
The error message would be better as:
~~~
Invalid port range specified for protocol %(protocol)s. Do not specify a port
range. Port ranges are only supported for TCP, UDP, UDPLITE, SCTP and DCCP.
~~~
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1815478/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816967] [NEW] cc_rsyslog.py:205: FutureWarning: Possible nested set at position 23
Public bug reported:
With Python 3.7 this FutureWarning is seen e.g. in VM serial console:
[4.321959] cloud-init[728]:
/usr/lib/python3.7/site-packages/cloudinit/config/cc_rsyslog.py:205:
FutureWarning: Possible nested set at position 23
[4.323230] cloud-init[728]: r'^(?P[@]{0,2})'
I think it's fixable by changing [[] to [\[] in the HOST_PORT_RE regex
in cc_rsyslog.py.
https://docs.python.org/dev/whatsnew/3.7.html#re
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1816967
Title:
cc_rsyslog.py:205: FutureWarning: Possible nested set at position 23
Status in cloud-init:
New
Bug description:
With Python 3.7 this FutureWarning is seen e.g. in VM serial console:
[4.321959] cloud-init[728]:
/usr/lib/python3.7/site-packages/cloudinit/config/cc_rsyslog.py:205:
FutureWarning: Possible nested set at position 23
[4.323230] cloud-init[728]: r'^(?P[@]{0,2})'
I think it's fixable by changing [[] to [\[] in the HOST_PORT_RE regex
in cc_rsyslog.py.
https://docs.python.org/dev/whatsnew/3.7.html#re
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1816967/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1815609] Re: [fwaas] devstack plugin fails if ML2/OVS is not use
Reviewed: https://review.openstack.org/636340 Committed: https://git.openstack.org/cgit/openstack/neutron-fwaas/commit/?id=5694e2dbaf5e4e9d94da20d8773ad86e13ca575a Submitter: Zuul Branch:master commit 5694e2dbaf5e4e9d94da20d8773ad86e13ca575a Author: Édouard Thuleau Date: Tue Feb 12 15:06:02 2019 +0100 Add service checks before trying to configure it Validate the service/agent is enable before trying to set its configuration file. Certain deployment does not use OVS or l3 agents like Contrail. Change-Id: I8ad30f1754ca7560c341ff67fe2a446f1280e124 Closes-Bug: #1815609 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1815609 Title: [fwaas] devstack plugin fails if ML2/OVS is not use Status in neutron: Fix Released Bug description: When using the Contrail devstack plugin, the FWaaS devstack plugin fails as it tries to configure neutron agent configuration files which are not used by Contrail To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1815609/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816927] Re: Deployments with high churn are susceptible to false positives with token validation
Cloudnull and I discussed possible solutions in IRC [0]. There is a patch up, but it likely needs to get verified against the OSA project directly [1]. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2019-02-21.log.html#t2019-02-21T02:03:38 [1] https://review.openstack.org/#/c/638327/ ** Also affects: openstack-ansible Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1816927 Title: Deployments with high churn are susceptible to false positives with token validation Status in OpenStack Identity (keystone): New Status in openstack-ansible: New Bug description: The implementation for fernet tokens relies on symmetric encryption. This underpinning requires that each keystone API node "share" the same key repository, specifically in deployments where keystone servers need to validate tokens issued by one another (e.g., a cluster of keystone servers behind an HA proxy). Without getting into too much detail, each key repository consists of a set of files on disk. The naming of each file is crucial because it denotes the type of key it is (documented extensively [0]). Each file name corresponds to an integer. The file name with the highest index is used to encrypt new tokens, which is called the primary key. The file name with the lowest index, or 0, is known as a staged key and it is always promoted to be the primary key on the next rotation. Every other key in the repository is a secondary key and is only used to decrypt tokens. Each key on disk goes through a lifecycle, starting as a staged key, promoted to a primary key, eventually being demoted to a secondary key. Note that keystone does *not* handle key distribution between API servers. We recommend this be done using configuration management. The documentation suggests rsync as one possible utility to keep key repositories in sync. I'm opening this bug because it was brought to our attention that keystone servers may respond with a 401 Invalid Fernet token, in deployments with high churn, or high token load, across a cluster of keystone nodes. The issue is that in the process of key rotation, the staged key is promoted to be the primary key. As soon as this happens, any subsequent requests to create tokens will use the primary key to encrypt the token. It is assumed all other API servers have a copy of this key, because it's the staged key and also valid as a secondard key. A token encrypted with the new primary key should be validatable on other API servers if they have a copy of the staged key, which has the same key contents as the new primary key on the API server that initiated the token rotation. The rsync implementation deletes the contents of the key repository and rebuilds it, alphanumerically. This results in the staged key always being written by rsync first, because its file name is 0. The primary key is always written last, because its filename is the highest index of the key repository. A unique timing event where: - a token is created after key rotation, but before key distribution - key distribution is invoked using a mechanism like rsync - token validation is performed on the API server getting its key repository built by rsync - the token is validated before the new primary key is written to the key repository by rsync, and fails validation because the key repository doesn't contain the key used to encrypt the token A subsequent request to validate the token should succeed if rsync completes successfully. pas-ha brought this to the #openstack-keystone channel as an issue that was affecting an internal CI/CD deployment that has a lot of churn [1]. [0] https://docs.openstack.org/keystone/latest/admin/fernet-token-faq.html#what-are-the-different-types-of-keys [1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-02-20.log.html#t2019-02-20T20:11:12 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1816927/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816944] [NEW] fwaas - Failure UT on local environment due to neutron version
Public bug reported: When I tested UT in my local environment, following error occurred. However, now all UT has passed on gerrit using master branch of neutron. It maybe referring neutron version is a little old. Therefore, let's skip until new version of neutron has been released. [Error] 2019-02-20 03:12:11 neutron_fwaas.tests.unit.services.logapi.agents.l3.test_fwg_log.FWaaSL3LoggingExtensionInitializeTestCase.test_initialize_subscribed_to_rpc 2019-02-20 03:12:11 --- 2019-02-20 03:12:11 2019-02-20 03:12:11 Captured traceback: 2019-02-20 03:12:11 ~~~ 2019-02-20 03:12:11 b'Traceback (most recent call last):' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/neutron/tests/base.py", line 150, in func' 2019-02-20 03:12:11 b'return f(self, *args, **kwargs)' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/mock/mock.py", line 1305, in patched' 2019-02-20 03:12:11 b'return func(*args, **keywargs)' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/neutron_fwaas/tests/unit/services/logapi/agents/l3/test_fwg_log.py", line 41, in test_initialize_subscribed_to_rpc' 2019-02-20 03:12:11 b'self.connection, lib_const.L3_AGENT_MODE)' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/neutron_fwaas/services/logapi/agents/l3/fwg_log.py", line 35, in initialize' 2019-02-20 03:12:11 b'self._register_rpc_consumers()' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/neutron/services/logapi/agent/l3/base.py", line 50, in _register_rpc_consumers' 2019-02-20 03:12:11 b'self._connection = n_rpc.Connection()' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/neutron_lib/rpc.py", line 343, in __init__' 2019-02-20 03:12:11 b'super(Connection, self).__init__()' 2019-02-20 03:12:11 b'TypeError: super() argument 1 must be type, not MagicMock' 2019-02-20 03:12:11 b'' ** Affects: neutron Importance: Undecided Status: New ** Tags: fwaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1816944 Title: fwaas - Failure UT on local environment due to neutron version Status in neutron: New Bug description: When I tested UT in my local environment, following error occurred. However, now all UT has passed on gerrit using master branch of neutron. It maybe referring neutron version is a little old. Therefore, let's skip until new version of neutron has been released. [Error] 2019-02-20 03:12:11 neutron_fwaas.tests.unit.services.logapi.agents.l3.test_fwg_log.FWaaSL3LoggingExtensionInitializeTestCase.test_initialize_subscribed_to_rpc 2019-02-20 03:12:11 --- 2019-02-20 03:12:11 2019-02-20 03:12:11 Captured traceback: 2019-02-20 03:12:11 ~~~ 2019-02-20 03:12:11 b'Traceback (most recent call last):' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/neutron/tests/base.py", line 150, in func' 2019-02-20 03:12:11 b'return f(self, *args, **kwargs)' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/mock/mock.py", line 1305, in patched' 2019-02-20 03:12:11 b'return func(*args, **keywargs)' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/neutron_fwaas/tests/unit/services/logapi/agents/l3/test_fwg_log.py", line 41, in test_initialize_subscribed_to_rpc' 2019-02-20 03:12:11 b'self.connection, lib_const.L3_AGENT_MODE)' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/neutron_fwaas/services/logapi/agents/l3/fwg_log.py", line 35, in initialize' 2019-02-20 03:12:11 b'self._register_rpc_consumers()' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/neutron/services/logapi/agent/l3/base.py", line 50, in _register_rpc_consumers' 2019-02-20 03:12:11 b'self._connection = n_rpc.Connection()' 2019-02-20 03:12:11 b' File "/tmp/workspace/neutron-fwaas/.tox/py35/lib/python3.5/site-packages/neutron_lib/rpc.py", line 343, in __init__' 2019-02-20 03:12:11 b'super(Connection, self).__init__()' 2019-02-20 03:12:11 b'TypeError: super() argument 1 must be type, not MagicMock' 2019-02-20 03:12:11 b'' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1816944/+subscriptions -- Mailing list: https://launchpa
[Yahoo-eng-team] [Bug 1816831] Re: DOC: typo in add_initial_allocation_ratio releasenote
Reviewed: https://review.openstack.org/638245 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=945e7cb2a476258229ba94754c159ff966726459 Submitter: Zuul Branch:master commit 945e7cb2a476258229ba94754c159ff966726459 Author: Matt Riedemann Date: Wed Feb 20 14:35:01 2019 -0500 Fix typo in initial_disk_allocation_ratio release note Change-Id: Ib8becc39ce76847652d3538c3334cc3514ba7a33 Closes-Bug: #1816831 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1816831 Title: DOC: typo in add_initial_allocation_ratio releasenote Status in OpenStack Compute (nova): Fix Released Bug description: https://github.com/openstack/nova/blob/master/releasenotes/notes/add_initial_allocation_ratio-2d2666d62426a4bf.yaml - initial_cpu_allocation_ratio with default value 16.0 - initial_ram_allocation_ratio with default value 1.5 - initial_ram_allocation_ratio with default value 1.0 The third one should be "initial_disk_allocation_ratio". To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1816831/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1794827] Re: Queens openstack client does not support --block-device
Reviewed: https://review.openstack.org/607589 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=16027094ebabc5cd9f2e766431f18aadeff54a40 Submitter: Zuul Branch:master commit 16027094ebabc5cd9f2e766431f18aadeff54a40 Author: Matt Riedemann Date: Wed Oct 3 10:27:22 2018 -0400 doc: fix and clarify --block-device usage in user docs The docs on create a volume-backed server from the command line were wrong in a few ways: * The openstack server create command does not currently allow booting from a volume where a source image is provided and nova creates the volume from the image and uses that volume as the root disk. The nova boot command supports that, so the docs are updated to call out the nova boot command since that is the appropriate command in this case (even the syntax with the openstack server create --block-device was wrong). * When creating a server from a bootable volume with the OSC CLI, either the --volume or --block-device options should be used for a single volume, but not both. The docs were using both, so the latter is dropped and a note is added which links to the CLI documentation for more details on --block-device option usage. Change-Id: I985b870759d6c21ef9357b04f39099c02354f135 Closes-Bug: #1794827 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1794827 Title: Queens openstack client does not support --block-device Status in OpenStack Compute (nova): Fix Released Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: Anchor #create-volume-from-image-and-boot-instance describes the usage of option --block-device to generate a volume from an image and boot from there. That option is not implemented in the Queens openstack client, although it does exist in the nova client. I suggest substituting the openstack client syntax with the equivalent nova syntax. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 17.0.6.dev116 on 2018-09-22 00:26 SHA: 8157b16a65094035cbf0efc75e7bd6a2feee150f Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/user/launch-instance-from-volume.rst URL: https://docs.openstack.org/nova/queens/user/launch-instance-from-volume.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1794827/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816239] Re: Functional test test_router_processing_pool_size failing
Reviewed: https://review.openstack.org/637544 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a10281bf236aa47ee32f247e0aa79f5fdd42348b Submitter: Zuul Branch:master commit a10281bf236aa47ee32f247e0aa79f5fdd42348b Author: LIU Yulong Date: Mon Feb 18 21:33:32 2019 +0800 Call _safe_router_removed during pool resize testing Closes-Bug: #1816239 Change-Id: Ie93d17ff8b5825e401e342d215db4bcfd7b1cd3e ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1816239 Title: Functional test test_router_processing_pool_size failing Status in neutron: Fix Released Bug description: Functional test neutron.tests.functional.agent.l3.test_legacy_router.L3AgentTestCase.test_router_processing_pool_size is failing. Test was introduced recently with patch https://review.openstack.org/#/c/633869/ Example of failure http://logs.openstack.org/42/619742/52/check /neutron-functional-python27/21f0e48/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1816239/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816938] [NEW] Misleading log message "Booting with blank volume" in nova-compute when booting from real volume
Public bug reported: Something is broken here: https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/virt/block_device.py#L836 Because I'm seeing this getting logged: https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/virt/block_device.py#L855 When I know I'm booting from an existing volume. This is also all over the CI logs: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Booting%20with%20blank%20volume%20at%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d My guess is something with dict get() access changed on the DriverVolumeBlockDevice code with this change: https://github.com/openstack/nova/commit/b958bf1126aea8b88ccebb43a330fc1a44717145 #diff-40dadeaa854473fb72fa4bf3491a434f If I change the code to check: if bdm.volume_id: ... Then I get the expected log message but that is probably dangerous if we have a non-volume BDM. ** Affects: nova Importance: Medium Status: Confirmed ** Tags: compute serviceability volumes -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1816938 Title: Misleading log message "Booting with blank volume" in nova-compute when booting from real volume Status in OpenStack Compute (nova): Confirmed Bug description: Something is broken here: https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/virt/block_device.py#L836 Because I'm seeing this getting logged: https://github.com/openstack/nova/blob/af78b13c24d4abf393d17ac57e9135204ef12b73/nova/virt/block_device.py#L855 When I know I'm booting from an existing volume. This is also all over the CI logs: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Booting%20with%20blank%20volume%20at%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d My guess is something with dict get() access changed on the DriverVolumeBlockDevice code with this change: https://github.com/openstack/nova/commit/b958bf1126aea8b88ccebb43a330fc1a44717145 #diff-40dadeaa854473fb72fa4bf3491a434f If I change the code to check: if bdm.volume_id: ... Then I get the expected log message but that is probably dangerous if we have a non-volume BDM. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1816938/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816927] [NEW] Deployments with high churn are susceptible to false positives with token validation
Public bug reported: The implementation for fernet tokens relies on symmetric encryption. This underpinning requires that each keystone API node "share" the same key repository, specifically in deployments where keystone servers need to validate tokens issued by one another (e.g., a cluster of keystone servers behind an HA proxy). With getting into too much detail, each key repository consists of a set of files on disk. The naming of each file is crucial because it denotes the type of key it is (documented extensively [0]). Each file name corresponds to an integer. The file name with the highest index is used to encrypt new tokens, which is called the primary key. The file name with the lowest index, or 0, is known as a staged key and it is always promoted to be the primary key on the next rotation. Every other key in the repository is a secondary key and is only used to decrypt tokens. Each key on disk goes through a lifecycle, starting as a staged key, promoted to a primary key, eventually being demoted to a secondary key. Note that keystone does *not* handle token distribution between API servers. We recommend this be done using configuration management. The documentation suggests rsync as one possible utility to keep key repositories in sync. I'm opening this bug because it was brought to our attention that keystone servers may respond with a 401 Invalid Fernet token, in deployments with high churn, or high token load, across a cluster of keystone nodes. The issue is that in the process of key rotation, the staged key is promoted to be the primary key. As soon as this happens, any subsequent requests to create tokens will use the primary key to encrypt the token. It is assumed all other API servers have a copy of this key, because it's the staged key and also valid as a secondard key. A encrypted with the new primary key should be validatable on other API servers if they have a copy of the staged key, which has the same key contents as the new primary key on the API server that initiated the token rotation. The rsync implementation deletes the contents of the key repository and rebuilds it, alphanumerically. This results in the staged key always being written by rsync first, because its file name is 0. The primary key is always written last, because its filename is the highest index of the key repository. A unique timing event where: - a token is created after key rotation, but before key distribution - key distribution is invoked using a mechanism like rsync - token validation is performed on the API server getting its key repository built by rsync - the token is validated before the primary key is written to the key repository by rsync, and fails validation because the key repository doesn't contain the key used to encrypt the token A subsequent request to validate the token should succeed if rsync completes successfully. pas-ha brought this to the #openstack-keystone channel as an issue that was affecting an internal CI/CD deployment that has a lot of churn [1]. [0] https://docs.openstack.org/keystone/latest/admin/fernet-token-faq.html#what-are-the-different-types-of-keys [1] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-02-20.log.html#t2019-02-20T20:11:12 ** Affects: keystone Importance: Undecided Status: New ** Tags: fernet ** Tags added: fernet ** Summary changed: - Deployments with high churn as susceptible to false positives with token validation + Deployments with high churn are susceptible to false positives with token validation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1816927 Title: Deployments with high churn are susceptible to false positives with token validation Status in OpenStack Identity (keystone): New Bug description: The implementation for fernet tokens relies on symmetric encryption. This underpinning requires that each keystone API node "share" the same key repository, specifically in deployments where keystone servers need to validate tokens issued by one another (e.g., a cluster of keystone servers behind an HA proxy). With getting into too much detail, each key repository consists of a set of files on disk. The naming of each file is crucial because it denotes the type of key it is (documented extensively [0]). Each file name corresponds to an integer. The file name with the highest index is used to encrypt new tokens, which is called the primary key. The file name with the lowest index, or 0, is known as a staged key and it is always promoted to be the primary key on the next rotation. Every other key in the repository is a secondary key and is only used to decrypt tokens. Each key on disk goes through a lifecycle, starting as a staged key, promoted to a primary key, eventually being demoted to a secondary key. Note that
[Yahoo-eng-team] [Bug 1816874] [NEW] l3 agent using return value from methods with no return
Public bug reported: * Module neutron.agent.l3.dvr_local_router neutron/agent/l3/dvr_local_router.py:111:12: E: Assigning result of a function call, where the function has no return (assignment-from-no-return) * Module neutron.agent.l3.router_info neutron/agent/l3/router_info.py:380:16: E: Assigning result of a function call, where the function has no return (assignment-from-no-return) Note that the lines in those two files about pylint disable assignment- from-no-return, if still there, should be removed when this is fixed. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1816874 Title: l3 agent using return value from methods with no return Status in neutron: New Bug description: * Module neutron.agent.l3.dvr_local_router neutron/agent/l3/dvr_local_router.py:111:12: E: Assigning result of a function call, where the function has no return (assignment-from-no-return) * Module neutron.agent.l3.router_info neutron/agent/l3/router_info.py:380:16: E: Assigning result of a function call, where the function has no return (assignment-from-no-return) Note that the lines in those two files about pylint disable assignment-from-no-return, if still there, should be removed when this is fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1816874/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816859] [NEW] Server concepts in nova - automatic resize confirm is wrong in docs
Public bug reported: - [x] This doc is inaccurate in this way: The section on resize: https://developer.openstack.org/api-guide/compute/server_concepts.html #server-actions says: "All resizes are automatically confirmed after 24 hours if you do not confirm or revert them." This is not true because the automatic confirm is based on the "resize_confirm_window" configuration option which by default is disabled: https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.resize_confirm_window Since the guide already mentions this configuration option it's probably best to just remove the sentence about it. While we're fixing this, we should probably also avoid calling out the config option specifically since it's up to the operator / cloud and not the end user about whether or not the resized server is automatically confirmed and how long the window is. So we could just say, "The resized server may be automatically confirmed based on the administrator's configuration of the deployment". The place to mention automatically confirming a resized server should live in the admin docs: https://docs.openstack.org/nova/latest/admin/configuration/resize.html --- Release: 18.1.0.dev1308 on 2019-02-20 16:34:47.409737 SHA: af78b13c24d4abf393d17ac57e9135204ef12b73 Source: https://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/server_concepts.rst URL: https://developer.openstack.org/api-guide/compute/server_concepts.html ** Affects: nova Importance: Medium Status: Triaged ** Tags: api-guide docs low-hanging-fruit resize -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1816859 Title: Server concepts in nova - automatic resize confirm is wrong in docs Status in OpenStack Compute (nova): Triaged Bug description: - [x] This doc is inaccurate in this way: The section on resize: https://developer.openstack.org/api-guide/compute/server_concepts.html #server-actions says: "All resizes are automatically confirmed after 24 hours if you do not confirm or revert them." This is not true because the automatic confirm is based on the "resize_confirm_window" configuration option which by default is disabled: https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.resize_confirm_window Since the guide already mentions this configuration option it's probably best to just remove the sentence about it. While we're fixing this, we should probably also avoid calling out the config option specifically since it's up to the operator / cloud and not the end user about whether or not the resized server is automatically confirmed and how long the window is. So we could just say, "The resized server may be automatically confirmed based on the administrator's configuration of the deployment". The place to mention automatically confirming a resized server should live in the admin docs: https://docs.openstack.org/nova/latest/admin/configuration/resize.html --- Release: 18.1.0.dev1308 on 2019-02-20 16:34:47.409737 SHA: af78b13c24d4abf393d17ac57e9135204ef12b73 Source: https://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/server_concepts.rst URL: https://developer.openstack.org/api-guide/compute/server_concepts.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1816859/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816833] [NEW] Role assignment API doesn't use default roles
Public bug reported: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The role assignment API (/v3/role_assignments) doesn't incorporate these defaults into its default policies [1], but it should. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html [1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/role_assignment.py?id=fb73912d87b61c419a86c0a9415ebdcf1e186927 ** Affects: keystone Importance: High Status: Triaged ** Tags: default-roles policy ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1816833 Title: Role assignment API doesn't use default roles Status in OpenStack Identity (keystone): Triaged Bug description: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The role assignment API (/v3/role_assignments) doesn't incorporate these defaults into its default policies [1], but it should. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html [1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/role_assignment.py?id=fb73912d87b61c419a86c0a9415ebdcf1e186927 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1816833/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816831] [NEW] DOC: typo in add_initial_allocation_ratio releasenote
Public bug reported: https://github.com/openstack/nova/blob/master/releasenotes/notes/add_initial_allocation_ratio-2d2666d62426a4bf.yaml - initial_cpu_allocation_ratio with default value 16.0 - initial_ram_allocation_ratio with default value 1.5 - initial_ram_allocation_ratio with default value 1.0 The third one should be "initial_disk_allocation_ratio". ** Affects: nova Importance: Undecided Status: New ** Tags: doc releasenote -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1816831 Title: DOC: typo in add_initial_allocation_ratio releasenote Status in OpenStack Compute (nova): New Bug description: https://github.com/openstack/nova/blob/master/releasenotes/notes/add_initial_allocation_ratio-2d2666d62426a4bf.yaml - initial_cpu_allocation_ratio with default value 16.0 - initial_ram_allocation_ratio with default value 1.5 - initial_ram_allocation_ratio with default value 1.0 The third one should be "initial_disk_allocation_ratio". To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1816831/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816771] [NEW] Creation of router fails in devstack
Public bug reported: Router creation failed in http://logs.openstack.org/36/638136/1/check /openstacksdk-functional-devstack/1cdc712/job- output.txt.gz#_2019-02-20_12_04_53_592956 In neutron-server log there is error like: http://logs.openstack.org/36/638136/1/check/openstacksdk-functional- devstack/1cdc712/controller/logs/screen-q-svc.txt.gz#_Feb_20_12_04_53_392346 It is possible that this could be introduced somehow by https://review.openstack.org/#/c/635671/ but it is not sure for now. ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure l3-ha ** Tags removed: l3 ** Tags added: l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1816771 Title: Creation of router fails in devstack Status in neutron: New Bug description: Router creation failed in http://logs.openstack.org/36/638136/1/check /openstacksdk-functional-devstack/1cdc712/job- output.txt.gz#_2019-02-20_12_04_53_592956 In neutron-server log there is error like: http://logs.openstack.org/36/638136/1/check/openstacksdk-functional- devstack/1cdc712/controller/logs/screen-q-svc.txt.gz#_Feb_20_12_04_53_392346 It is possible that this could be introduced somehow by https://review.openstack.org/#/c/635671/ but it is not sure for now. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1816771/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816755] [NEW] When the flavor id is invalid, the message does not match the regular expression, missing the numbers from 0-9.
Public bug reported: When the flavor id is invalid, the message does not match the regular expression, missing the numbers from 0-9. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1816755 Title: When the flavor id is invalid, the message does not match the regular expression, missing the numbers from 0-9. Status in OpenStack Compute (nova): New Bug description: When the flavor id is invalid, the message does not match the regular expression, missing the numbers from 0-9. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1816755/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816747] [NEW] Neutron neutron-db-manage failures with openstack master/stein branch
Public bug reported:
Neutron plugin: NSX Policy Plugin
We are bringing up the NSX Policy plugin setup with master branch and as
part of Openstack installation, it failed with the error as mentioned
below:
changed: [osctrl01] => (item=nova-manage db sync)
failed: [osctrl01] (item=neutron-db-manage --config-file
/etc/neutron/neutron.conf --config-file /etc/neutron/plugins/vmware/nsx.ini
upgrade head) => {"changed": true, "cmd": ["neutron-db-manage",
"--config-file", "/etc/neutron/neutron.conf", "--config-file",
"/etc/neutron/plugins/vmware/nsx.ini", "upgrade", "head"], "delta":
"0:01:08.695483", "end": "2019-02-18 19:00:42.339996", "failed": true, "item":
"neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/vmware/nsx.ini upgrade head", "rc": 1, "start":
"2019-02-18 18:59:33.644513", "stderr":
"/opt/mhos/python/lib/python2.7/site-packages/psycopg2/__init__.py:144:
UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in
order to keep installing from binary please use \"pip install psycopg2-binary\"
instead. For details see:
.\n
\"\"\")\nINFO [alembic.runtime.migration] Context impl MySQLImpl.\nINFO
[alembic.runtime.migration] Will assume non-transactional DDL.\nINFO
[alembic.runtime.migration] Context impl MySQLImpl.\nINFO
[alembic.runtime.migration] Will assume non-transactional DDL.\nINFO
[alembic.runtime.migration] Running upgrade -> kilo\nINFO
[alembic.runtime.migration] Running upgrade kilo -> 354db87e3225\nINFO
[alembic.runtime.migration] Running upgrade 354db87e3225 -> 599c6a226151\nINFO
[alembic.runtime.migration] Running upgrade 599c6a226151 -> 52c5312f6baf\nINFO
[alembic.runtime.migration] Running upgrade 52c5312f6baf -> 313373c0ffee\nINFO
[alembic.runtime.migration] Running upgrade 313373c0ffee -> 8675309a5c4f\nINFO
[alembic.runtime.migration] Running upgrade 8675309a5c4f -> 45f955889773\nINFO
[alembic.runtime.migration] Running upgrade 45f955889773 -> 26c371498592\nINFO
[alembic.runtime.migration] Running upgrade 26c371498592 -> 1c844d1677f7\nINFO
[alembic.runtime.migration] Running upgrade 1c844d1677f7 -> 1b4c6e320f79\nINFO
[alembic.runtime.migration] Running upgrade 1b4c6e320f79 -> 48153cb5f051\nINFO
[alembic.runtime.migration] Running upgrade 48153cb5f051 -> 9859ac9c136\nINFO
[alembic.runtime.migration] Running upgrade 9859ac9c136 -> 34af2b5c5a59\nINFO
[alembic.runtime.migration] Running upgrade 34af2b5c5a59 -> 59cb5b6cf4d\nINFO
[alembic.runtime.migration] Running upgrade 59cb5b6cf4d -> 13cfb89f881a\nINFO
[alembic.runtime.migration] Running upgrade 13cfb89f881a -> 32e5974ada25\nINFO
[alembic.runtime.migration] Running upgrade 32e5974ada25 -> ec7fcfbf72ee\nINFO
[alembic.runtime.migration] Running upgrade ec7fcfbf72ee -> dce3ec7a25c9\nINFO
[alembic.runtime.migration] Running upgrade dce3ec7a25c9 -> c3a73f615e4\nINFO
[alembic.runtime.migration] Running upgrade c3a73f615e4 -> 659bf3d90664\nINFO
[alembic.runtime.migration] Running upgrade 659bf3d90664 -> 1df244e556f5\nINFO
[alembic.runtime.migration] Running upgrade 1df244e556f5 -> 19f26505c74f\nINFO
[alembic.runtime.migration] Running upgrade 19f26505c74f -> 15be73214821\nINFO
[alembic.runtime.migration] Running upgrade 15be73214821 -> b4caf27aae4\nINFO
[alembic.runtime.migration] Running upgrade b4caf27aae4 -> 15e43b934f81\nINFO
[alembic.runtime.migration] Running upgrade 15e43b934f81 -> 31ed664953e6\nINFO
[alembic.runtime.migration] Running upgrade 31ed664953e6 -> 2f9e956e7532\nINFO
[alembic.runtime.migration] Running upgrade 2f9e956e7532 -> 3894bccad37f\nINFO
[alembic.runtime.migration] Running upgrade 3894bccad37f -> 0e66c5227a8a\nINFO
[alembic.runtime.migration] Running upgrade 0e66c5227a8a -> 45f8dd33480b\nINFO
[alembic.runtime.migration] Running upgrade 45f8dd33480b -> 5abc0278ca73\nINFO
[alembic.runtime.migration] Running upgrade kilo -> 30018084ec99\nINFO
[alembic.runtime.migration] Running upgrade 30018084ec99 -> 4ffceebfada\nINFO
[alembic.runtime.migration] Running upgrade 4ffceebfada -> 5498d17be016\nINFO
[alembic.runtime.migration] Running upgrade 5498d17be016 -> 2a16083502f3\nINFO
[alembic.runtime.migration] Running upgrade 2a16083502f3 -> 2e5352a0ad4d\nINFO
[alembic.runtime.migration] Running upgrade 2e5352a0ad4d -> 11926bcfe72d\nINFO
[alembic.runtime.migration] Running upgrade 11926bcfe72d -> 4af11ca47297\nINFO
[alembic.runtime.migration] Running upgrade 4af11ca47297 -> 1b294093239c\nINFO
[alembic.runtime.migration] Running upgrade 1b294093239c -> 8a6d8bdae39\nINFO
[alembic.runtime.migration] Running upgrade 8a6d8bdae39 -> 2b4c2465d44b\nINFO
[alembic.runtime.migration] Running upgrade 2b4c2465d44b -> e3278ee65050\nINFO
[alembic.runtime.migration] Running upgrade e3278ee65050 -> c6c112992c9\nINFO
[alembic.runtime.migration] Running upgrade c6c112992c9 -> 5ffceebfada\nINFO
[alembic.runtime.mi
[Yahoo-eng-team] [Bug 1521489] Re: Support interchangeable datasource
Thanks James! ** Changed in: cloud-init Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1521489 Title: Support interchangeable datasource Status in cloud-init: Won't Fix Bug description: It would be highly valuable for a user to be able to run cloud-init with custom user-data using local datasource post deploy e.g: 1# juju deploy myservice 2# juju scp user-data.yaml myservice/0:/var/lib/cloud/seed/nocloud-net/user-data2 3# juju run --service myservice "/usr/bin/cloud-init --local -f /var/lib/cloud/seed/nocloud-net/user-data2" Support for something along these lines would allow for charming up cloud-init too, something I've been dreaming about for a while now! Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1521489/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1448594] Re: DuplicateError while parsing ifcfg-ethX
Thanks Roopak! ** Changed in: cloud-init Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1448594 Title: DuplicateError while parsing ifcfg-ethX Status in cloud-init: Won't Fix Bug description: I have a VirtualMachine image (Scientific Linux 6.4) which has a static IP address assigned to it. Using Openstack and using 'config-drive' we tried to boot a new VirtualMachine from that image, config-drive, the ISO contains a new 'static-ip' address. Cloud-init recognizes that and tries to read the existing /etc/sysconfig/network-scripts/ifcfg-eth0 and fails with the following error: --- Apr 24 18:04:13 rparikh-sl6-w-cloud-init [CLOUDINIT] util.py[DEBUG]: Getting data from failed#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/cloudinit/sources/__init__.py", line 243, in find_source#012if s.get_data():#012 File "/usr/lib/python2.6/site- packages/cloudinit/sources/DataSourceConfigDrive.py", line 212, in get_data#012self.helper.on_first_boot(results)#012 File "/usr/lib/python2.6/site- packages/cloudinit/sources/DataSourceConfigDrive.py", line 54, in on_first_boot#012 self.distro.apply_network(data['network_config'])#012 File "/usr/lib/python2.6/site-packages/cloudinit/distros/__init__.py", line 116, in apply_network#012dev_names = self._write_network(settings)#012 File "/usr/lib/python2.6/site- packages/cloudinit/distros/rhel.py", line 85, in _write_network#012 rhel_util.update_sysconfig_file(net_fn, net_cfg)#012 File "/usr/lib/python2.6/site-packages/cloudinit/distros/rhel_util.py", line 125, in update_sysconfig_file#012(exists, contents) = read_sysconfig_file(fn)#012 File "/usr/lib/python2.6/site- packages/cloudinit/distros/rhel_util.py", line 153, in read_sysconfig_file#012return (exists, SysConf(contents))#012 File "/usr/lib/python2.6/site- packages/cloudinit/distros/parsers/sys_conf.py", line 60, in __init__#012write_empty_values=True)#012 File "/usr/lib/python2.6 /site-packages/configobj.py", line 1219, in __init__#012 self._load(infile, configspec)#012 File "/usr/lib/python2.6/site- packages/configobj.py", line 1302, in _load#012raise error#012DuplicateError: Duplicate keyword name at line 24. - The problem seems to be duplicate keys in the ifcfg-eth0, we can try and fix this image, but there are probably others with the same settings and in general I would assume parsing should be resilient to these failures. In addition I am not sure if I understand the logic behind reading the current ifcfg and modifying it, we should be able to simplify it by overwriting (a backup can be taken for debugging purposes) the ifcfg file. Attached is a screenshot with contents of the ifcfg file. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1448594/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816740] [NEW] FWaaS v2 - incorrect shared rule check
Public bug reported: Reference: http://git.openstack.org/cgit/openstack/neutron- fwaas/tree/neutron_fwaas/db/firewall/v2/firewall_db_v2.py#n644 def _check_if_rules_shared_for_policy_shared(self, context, fwp_db, fwp): if fwp['shared']: rules_in_db = fwp_db.rule_associations for entry in rules_in_db: fwr_db = self._get_firewall_rule(context, entry.firewall_rule_id) if not fwp_db['shared']: raise f_exc.FirewallPolicySharingConflict( firewall_rule_id=fwr_db['id'], firewall_policy_id=fwp_db['id']) The logic above will always raise an exception if a policy is changed from not shared to shared. There is most likely a typo in: if not fwp_db['shared']: as it should be: if not fwr_db['shared']: ** Affects: neutron Importance: Undecided Assignee: Salvatore Orlando (salvatore-orlando) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1816740 Title: FWaaS v2 - incorrect shared rule check Status in neutron: New Bug description: Reference: http://git.openstack.org/cgit/openstack/neutron- fwaas/tree/neutron_fwaas/db/firewall/v2/firewall_db_v2.py#n644 def _check_if_rules_shared_for_policy_shared(self, context, fwp_db, fwp): if fwp['shared']: rules_in_db = fwp_db.rule_associations for entry in rules_in_db: fwr_db = self._get_firewall_rule(context, entry.firewall_rule_id) if not fwp_db['shared']: raise f_exc.FirewallPolicySharingConflict( firewall_rule_id=fwr_db['id'], firewall_policy_id=fwp_db['id']) The logic above will always raise an exception if a policy is changed from not shared to shared. There is most likely a typo in: if not fwp_db['shared']: as it should be: if not fwr_db['shared']: To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1816740/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1809238] Re: [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins
Reviewed: https://review.openstack.org/626561 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e8b7e768a2545621ee98511b8dd271c5117f76bd Submitter: Zuul Branch:master commit e8b7e768a2545621ee98511b8dd271c5117f76bd Author: LIU Yulong Date: Mon Dec 17 11:38:20 2018 +0800 Add dependency for service plugin Adds a required list 'required_service_plugins' to each service plugin, then we can initialize the service plugin with required dependency. And also adds the 'router' plugin to port forwarding service plugin required list. Closes-Bug: #1809238 Change-Id: I53fdaee0cd96a5315a7abc39799657d613eb3a2e ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1809238 Title: [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins Status in neutron: Fix Released Bug description: ENV: devstack master Exception: http://paste.openstack.org/show/737781/ How to reproduce: In neutron.conf just set `port_forwarding` plugin before l3 `router` plugin, and then create port forwarding, something like this: [DEFAULT] service_plugins = port_forwarding,router then you will get that exception in neutron server log. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1809238/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1816721] [NEW] Python3 librados incompatibility
Public bug reported: Hello, found a bug in glance. Glance is storing bad direct_url='rbd://b %27868c2b5d-12f1-4f3f-aa2a-5701a3bb1041%27/images/7b1f429e-ad2f-40b2 -be9e-8552edae8938/snap' in database. This is causing several problems, as in https://bugs.launchpad.net/cinder/+bug/1816468 root@openstack-controller:/tmp# openstack image create --container-format bare --disk-format raw --file cirros-0.3.4-x86_64-disk.img cirros-test-1 +--+-+ | Field| Value | +--+-+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2019-02-20T09:08:45Z | | disk_format | raw | | file | /v2/images/7b1f429e-ad2f-40b2-be9e-8552edae8938/file | | id | 7b1f429e-ad2f-40b2-be9e-8552edae8938 | | min_disk | 0 | | min_ram | 0 | | name | cirros-test-1 | | owner| ba5ef70fd99642fdb75c9307c88b1164 | | properties | direct_url='rbd://b%27868c2b5d-12f1-4f3f-aa2a-5701a3bb1041%27/images/7b1f429e-ad2f-40b2-be9e-8552edae8938/snap', os_hash_algo='sha512', os_hash_value='1b03ca1bc3fafe448b90583c12f367949f8b0e665685979d95b004e48574b953316799e23240f4f739d1b5eb4c4ca24d38fdc6f4f9d8247a2bc64db25d6bbdb2', os_hidden
[Yahoo-eng-team] [Bug 1810314] Re: neutron objects base get_values() fails with KeyError
** Changed in: tricircle Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1810314 Title: neutron objects base get_values() fails with KeyError Status in neutron: Won't Fix Status in Tricircle: Fix Released Bug description: As of December 20 2018 the python unit test jobs for the tricircle project have been failing [1]. After going through the tricircle/neutron commits since that date, it seems some changes went into neutron that caused the breakage. If I run tricircle python 3.5 unit test with neutron commit 55c5139d79ef09869eea1201c736eee8de3ec651 (the last commit on neutron from Dec 19, 2018) the unit tests all pass. If I run the same UTs with neutron (latest) master they fail with the same errors found in the results of [2]. While this is just a guess, I suspect that maybe neutron changes that landed on Dec 20 related to "Convert Subnet to OVO in ipam_pluggable_backend.py" [3] introduced the breakage. In any case, something landed in neutron around Dec 20, 2018 that has broken tricircle. [1] http://zuul.openstack.org/builds?branch=master&project=openstack%2Ftricircle&job_name=openstack-tox-py35 [2] https://review.openstack.org/#/c/627888/ [3] https://review.openstack.org/#/c/610184/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1810314/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1514095] Re: Fails to assign IP addresses if several networks specified
Thanks Fred! ** Changed in: cloud-init Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1514095 Title: Fails to assign IP addresses if several networks specified Status in cloud-init: Won't Fix Bug description: - Openstack Kilo - centos 7 qcow2 image from cloud.centos.org - Assign 2 networks to the machine and boot. - No IP gets assigned from neither. If I just boot with one network, it works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1514095/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
