[Yahoo-eng-team] [Bug 1845575] [NEW] Networking Option 1: Provider networks in neutron
Public bug reported: In part: Configure the server component¶ auth_uri = http://controller:5000 auth_url = http://controller:5000 The two sentences are the same. 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: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. 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: 12.1.1.dev43 on 2019-09-21 05:59 SHA: b3d3d6d64358f6e8340bf0dbdff716968bf0d92c Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-option1-ubuntu.rst URL: https://docs.openstack.org/neutron/queens/install/controller-install-option1-ubuntu.html ** Affects: neutron Importance: Undecided Status: New ** Tags: doc -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1845575 Title: Networking Option 1: Provider networks in neutron Status in neutron: New Bug description: In part: Configure the server component¶ auth_uri = http://controller:5000 auth_url = http://controller:5000 The two sentences are the same. 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: - [ ] This doc is inaccurate in this way: __ - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. 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: 12.1.1.dev43 on 2019-09-21 05:59 SHA: b3d3d6d64358f6e8340bf0dbdff716968bf0d92c Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-option1-ubuntu.rst URL: https://docs.openstack.org/neutron/queens/install/controller-install-option1-ubuntu.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1845575/+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 1805880] Re: Remove obsolete limit and registered limit policies from policy.v3cloudsample.json
Reviewed: https://review.opendev.org/621025 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5b995cc8fbf0bb654ed0f6a88091c48548f53f6e Submitter: Zuul Branch:master commit 5b995cc8fbf0bb654ed0f6a88091c48548f53f6e Author: Lance Bragstad Date: Thu Nov 29 21:30:06 2018 + Remove limit policies from policy.v3cloudsample.json By incorporating system-scope and default roles, we've effectively made these policies obsolete. We can simplify what we maintain and provide a more consistent, unified view of default limit behavior by removing them. Change-Id: Ie0f333a9e8b60154711a24ba7d9ade531217eb71 Closes-Bug: 1805880 ** Changed in: keystone Status: In Progress => Fix Released -- 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/1805880 Title: Remove obsolete limit and registered limit policies from policy.v3cloudsample.json Status in OpenStack Identity (keystone): Fix Released Bug description: Once support for scope types landed in the limit and registered limit API policies, the policies in policy.v3cloudsample.json became obsolete [0]. We should add formal protection for the policies with enforce_scope = True in keystone.tests.unit.protection.v3 and remove the old policies from the v3 sample policy file. This will reduce confusion by having a true default policy for limits and registered limits. [0] http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json?id=fb73912d87b61c419a86c0a9415ebdcf1e186927#n31 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1805880/+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 1845150] Re: [FT] "keepalived" needs network interfaces configured as in its own config
Reviewed: https://review.opendev.org/684249 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d8eb42f1eaaa3747691cbb91db49292c66732073 Submitter: Zuul Branch:master commit d8eb42f1eaaa3747691cbb91db49292c66732073 Author: Rodolfo Alonso Hernandez Date: Mon Sep 23 17:43:44 2019 + Configure keepalived interfaces according to config file "keepalived" process stops running if it does not find any of the tracked interfaces correctly configured. To prevent this in "KeepalivedManagerTestCase" test cases, "eth0" is set up and an IP address is assigned. Change-Id: Ibd4ef7b0db5b6830383fffcac685b9c709aae350 Closes-Bug: #1845150 Related-Bug: #1830232 ** 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/1845150 Title: [FT] "keepalived" needs network interfaces configured as in its own config Status in neutron: Fix Released Bug description: Related to https://bugs.launchpad.net/neutron/+bug/1830232. When "keepalived" is started with a config file but the interfaces do not have the same configuration (IP address), the process stops working, causing in some cases the failure of the test case. Log snippet: Sep 20 21:11:42 ubuntu-bionic-rax-iad-0011623950 Keepalived_vrrp[22546]: (VR_1): Cannot find an IP address to use for interface eth0 Sep 20 21:11:42 ubuntu-bionic-rax-iad-0011623950 Keepalived_vrrp[22546]: Stopped LOG FILE: https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_447/681671/8/check/neutron-functional-python27/4475c6d/controller/logs/journal_log.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1845150/+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 1818736] Re: The limit and registered limit APIs should account for different scopes
Reviewed: https://review.opendev.org/621024 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e938c496281daa6d1dab66d66bdb2d34abd5ddc3 Submitter: Zuul Branch:master commit e938c496281daa6d1dab66d66bdb2d34abd5ddc3 Author: Lance Bragstad Date: Thu Nov 29 21:22:10 2018 + Add tests for project users interacting with limits This commit introduces some tests that explicitly show how project users are expected to behave with the limits API. A subsequent patch will clean up the now obsolete policies in the policy.v3cloudsample.json policy file. Related-Bug: 1805880 Closes-Bug: 1818736 Change-Id: I12d1200d8a11cadcc4f7b2604d51d8e5c73ea4b7 ** Changed in: keystone Status: In Progress => Fix Released -- 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/1818736 Title: The limit and registered limit APIs should account for different scopes Status in OpenStack Identity (keystone): Fix Released Bug description: Keystone implemented scope_types for oslo.policy RuleDefault objects in the Queens release [0]. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the limit and registered limit APIs. This is because there are some limit and registered limit APIs that should be accessible to project users, domain users, and system users. System users should be able to manage limits and registered limits across the entire deployment. At this point, project and domain users shouldn't be able to manage limits and registered limits. At some point in the future, we might consider opening up the functionality to domain users to manage limits for projects within the domains they have authorization on. This bug report is strictly for tracking the ability to get information out of keystone regarding limits with system-scope, domain-scope, and project-scope. [0] https://review.openstack.org/#/c/525706/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1818736/+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 1845557] [NEW] DVR: FWaaS rules created for a router after the FIP and VM created, not applied to routers rfp port on router-update
Public bug reported: This was seen in Rocky. When network, subnet, router and a VM instance created with a FloatingIP before attaching FireWall rules to the router, causes the Firewall rules not to be applied to the 'rfp' port for north-south routing when using Firewall-as-Service in legacy 'iptables' mode. After applying the Firewall rules to the Router, it is expected that the router-update would trigger adding the Firewall rules to the existing routers, but the logic is not right. Any new VMs added to the subnet on a new compute host, gets the Firewall rules applied to the 'rfp' interface. So the only way to get around this problem is to restart the 'l3-agent'. Once the 'l3-agent' is restarted, the Firewall rules are applied again. This is also true when Firewall rules are removed after the VM and routers are in place, since the update is not handled properly, the firewall rules may stay there until we reboot the l3-agent. How to reproduce this problem: This is FWaaS v2 with legacy 'iptables': 1. Create a Network 2. Create a Subnet 3. Create a Router (DVR) 4. Attach the Subnet to the router. 5. Assign the gateway to the router. 6. Create a VM on the given private network. 7. Create a FloatingIP and associate the FloatingIP to the VM's private IP. 8. Now the VM, router, fipnamespace are all in place. 9. Now create Firwall rules neutron firewall-rule-create --protocol icmp --action allow --name allow-icmp neutron firewall-rule-create --protocol tcp --destination-port 80 --action deny --name deny-http neutron firewall-rule-create --protocol tcp --destination-port 22 --action allow --name allow-ssh 10. Then create firewall policy neutron firewall-policy-create --firewall-rules "allow-icmp deny-http allow-ssh" policy-fw 11. Create a firewall neutron firewall-create policy-fw --name user-fw 12. Check if the firewall was created: neutron firewall-show user-fw 13. If the firewall was created after the router have been created, based on the documentation you need to manually update the router. $ neutron firewall-update —router —router 14. After the update we would expect that all existing router-1 and router-2 to have the firewall rules. But we don't see if configured for the router-1 that was created before the firewall was created. And so the VM is not protected by the Firewall rules. ** Affects: neutron Importance: Undecided Assignee: Swaminathan Vasudevan (swaminathan-vasudevan) Status: Confirmed ** Tags: fwaas l3-dvr-backlog ** Changed in: neutron Assignee: (unassigned) => Swaminathan Vasudevan (swaminathan-vasudevan) ** Changed in: neutron Status: New => Confirmed ** Summary changed: - DVR: FWaaS rules created for a router after the FIP and VM created not applied to routers rfp port + DVR: FWaaS rules created for a router after the FIP and VM created, not applied to routers rfp port on router-update -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1845557 Title: DVR: FWaaS rules created for a router after the FIP and VM created, not applied to routers rfp port on router-update Status in neutron: Confirmed Bug description: This was seen in Rocky. When network, subnet, router and a VM instance created with a FloatingIP before attaching FireWall rules to the router, causes the Firewall rules not to be applied to the 'rfp' port for north-south routing when using Firewall-as-Service in legacy 'iptables' mode. After applying the Firewall rules to the Router, it is expected that the router-update would trigger adding the Firewall rules to the existing routers, but the logic is not right. Any new VMs added to the subnet on a new compute host, gets the Firewall rules applied to the 'rfp' interface. So the only way to get around this problem is to restart the 'l3-agent'. Once the 'l3-agent' is restarted, the Firewall rules are applied again. This is also true when Firewall rules are removed after the VM and routers are in place, since the update is not handled properly, the firewall rules may stay there until we reboot the l3-agent. How to reproduce this problem: This is FWaaS v2 with legacy 'iptables': 1. Create a Network 2. Create a Subnet 3. Create a Router (DVR) 4. Attach the Subnet to the router. 5. Assign the gateway to the router. 6. Create a VM on the given private network. 7. Create a FloatingIP and associate the FloatingIP to the VM's private IP. 8. Now the VM, router, fipnamespace are all in place. 9. Now create Firwall rules neutron firewall-rule-create --protocol icmp --action allow --name allow-icmp neutron firewall-rule-create --protocol tcp --destination-port 80 --action deny --name deny-http neutron firewall-rule-create --protocol tcp --destination-port 22 --action allow --name allow-ssh 10. Then create firewall policy neutron
[Yahoo-eng-team] [Bug 1843104] Re: KeyError: 'default_dns_nameservers' in Horizon
Reviewed: https://review.opendev.org/684792
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=ec970fd6e85b19126409ef39aefa013bac701503
Submitter: Zuul
Branch:master
commit ec970fd6e85b19126409ef39aefa013bac701503
Author: Akihiro Motoki
Date: Wed Sep 25 21:29:05 2019 +0900
Handle partial dict setting
In Train cycle, we moved the definition of default values
to openstack_dashboard/defaults.py. The current code accesses
a dict member using []. It requires operators to define a dict
setting with a full member.
This commit allows to use dict-type settings with partial members.
A new function is introduced to retrieve a dict-type setting
considering default values defined in
{openstack_dashboard,horizon,openstack_auth}/defaults.py
Change-Id: I7ff0ad4bca698aef9c0eba370b0570200a14367a
Closes-Bug: #1843104
** Changed in: horizon
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1843104
Title:
KeyError: 'default_dns_nameservers' in Horizon
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in kolla-ansible:
Triaged
Bug description:
With:
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "master"
and images built on 20190820
Trying to:
-> Create a network via Horizon (Create Network dialog)
I get:
-> Instant Horizon "Danger" error
-> "KeyError: 'default_dns_nameservers'" in
/var/log/kolla/horizon/horizon.log): http://paste.openstack.org/show/772115/
Right now I'm working around this by:
https://github.com/igordcard/homedc/blob/master/scripts/kolla/master/bionic
/fix-horizon-default_dns_nameservers-after.sh#L20
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1843104/+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 1845552] [NEW] ssh_util: fails to parse sshd_config when config contains an entry missing a value
Public bug reported:
# Overview
If the sshd_config contains keys with no values, cloud-init fails to
parse the config. This results in a system that is inaccessible over ssh
using pubkey authentication.
# Steps to reproduce:
1. Append the following content to /etc/ssh/sshd_config in a pristine
Ubuntu cloud image:
AllowUsers ubuntu
AllowGroups ubuntu
DenyUsers
DenyGroups
2. Boot the image with a cloud-config that injects an ssh key for the
ubuntu user.
3. Note the following error in the boot output:
util.py[WARNING]: Applying ssh credentials failed!
4. Attempt to login over ssh, note the pubkey authentication failure.
# Cause of the issue
In cloudinit/ssh_util.py, in parse_ssh_config_lines(), we attempt to
parse each line of sshd_config. This function expects each line to be
one of the following forms:
# comment
key value
key=value
If the line does not match one of these forms, we throw a ValueError.
Instead, we could ignore the offending line:
diff --git a/cloudinit/ssh_util.py b/cloudinit/ssh_util.py
index 3f99b58c..ec5ef9fb 100644
--- a/cloudinit/ssh_util.py
+++ b/cloudinit/ssh_util.py
@@ -304,7 +304,10 @@ def parse_ssh_config_lines(lines):
try:
key, val = line.split(None, 1)
except ValueError:
-key, val = line.split('=', 1)
+try:
+key, val = line.split('=', 1)
+except ValueError:
+continue
ret.append(SshdConfigLine(line, key, val))
return ret
# Notes about debugging
This issue was somewhat difficult to debug because the error message
produced by cloud-init was not very useful. To dig in and find the
actual issue, I modified cloudinit/config/cc_ssh.py to print the
traceback:
diff --git a/cloudinit/config/cc_ssh.py b/cloudinit/config/cc_ssh.py
index fdd8f4d3..2b356a4c 100755
--- a/cloudinit/config/cc_ssh.py
+++ b/cloudinit/config/cc_ssh.py
@@ -99,6 +99,7 @@ public keys.
import glob
import os
import sys
+import traceback
from cloudinit.distros import ug_util
from cloudinit import ssh_util
@@ -213,8 +214,9 @@ def handle(_name, cfg, cloud, log, _args):
keys.extend(cfgkeys)
apply_credentials(keys, user, disable_root, disable_root_opts)
-except Exception:
-util.logexc(log, "Applying ssh credentials failed!")
+except Exception as err:
+util.logexc(log, "Applying ssh credentials failed: {}".format(err))
+traceback.print_exc()
def apply_credentials(keys, user, disable_root, disable_root_opts):
** 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/1845552
Title:
ssh_util: fails to parse sshd_config when config contains an entry
missing a value
Status in cloud-init:
New
Bug description:
# Overview
If the sshd_config contains keys with no values, cloud-init fails to
parse the config. This results in a system that is inaccessible over
ssh using pubkey authentication.
# Steps to reproduce:
1. Append the following content to /etc/ssh/sshd_config in a pristine
Ubuntu cloud image:
AllowUsers ubuntu
AllowGroups ubuntu
DenyUsers
DenyGroups
2. Boot the image with a cloud-config that injects an ssh key for the
ubuntu user.
3. Note the following error in the boot output:
util.py[WARNING]: Applying ssh credentials failed!
4. Attempt to login over ssh, note the pubkey authentication failure.
# Cause of the issue
In cloudinit/ssh_util.py, in parse_ssh_config_lines(), we attempt to
parse each line of sshd_config. This function expects each line to be
one of the following forms:
# comment
key value
key=value
If the line does not match one of these forms, we throw a ValueError.
Instead, we could ignore the offending line:
diff --git a/cloudinit/ssh_util.py b/cloudinit/ssh_util.py
index 3f99b58c..ec5ef9fb 100644
--- a/cloudinit/ssh_util.py
+++ b/cloudinit/ssh_util.py
@@ -304,7 +304,10 @@ def parse_ssh_config_lines(lines):
try:
key, val = line.split(None, 1)
except ValueError:
-key, val = line.split('=', 1)
+try:
+key, val = line.split('=', 1)
+except ValueError:
+continue
ret.append(SshdConfigLine(line, key, val))
return ret
# Notes about debugging
This issue was somewhat difficult to debug because the error message
produced by cloud-init was not very useful. To dig in and find the
actual issue, I modified cloudinit/config/cc_ssh.py to print the
traceback:
diff --git a/cloudinit/config/cc_ssh.py b/cloudinit/config/cc_ssh.py
index fdd8f4d3..2b356a4c 100755
--- a/cloudinit/config/cc_ssh.py
+++ b/cloudinit/config/cc_ssh.py
@@ -99,6 +99,7 @@ public keys.
import
[Yahoo-eng-team] [Bug 1845523] Re: Horizon doesn't show UI when it can't read policy files
Reviewed: https://review.opendev.org/679665 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=f57b6ead5740d1c1b715cde15f7e5d4f303bdf93 Submitter: Zuul Branch:master commit f57b6ead5740d1c1b715cde15f7e5d4f303bdf93 Author: Ivan Kolodyazhny Date: Mon Sep 2 18:25:55 2019 +0300 Handle Permission Denied for policy files oslo.policy doesn't handle Permission Denied error during file parsing. This patch just ignores IOError exceptions to fallback to the default behaviour. Closes-Bug: #1845523 Change-Id: I87c2862e6e3a3f42d231552b00dc02364d6fa14f ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1845523 Title: Horizon doesn't show UI when it can't read policy files Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When horizon system user doesn't have permission to open policy files it doesn't render panels. It would be good to fall back to the default behaviour if policy files are not available To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1845523/+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 1840647] Re: EC2 API Auth Failure
As shown here:
https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_d9c/680481/1/check/ec2
-api-functional-neutron/d9c3627/logs/etc/keystone/keystone.conf.txt.gz
You are using 'backend = oslo_cache.dict' this is no way is
representative of any configuration that should be run in production.
The dict backend will have odd edge cases and potential problems such as
mutability of the cached data. The data is housed in-memory within the
process.
Use memcached.
This is not a bug. Marking as invalid.
** Changed in: keystone
Status: In Progress => Won't Fix
--
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/1840647
Title:
EC2 API Auth Failure
Status in ec2-api:
New
Status in OpenStack Identity (keystone):
Won't Fix
Bug description:
When trying to validate user token through Keystone an inconsistent behavior
is observed:
The very first request for a given user to Keystone is successful, while the
second and subsequent requests for the same user result in a Key Error in
Keystone _decrypt_credential method and thus auth failure (See the attached
traceback). The problem is observed by merely repeating the same aws-cli
commands for the same user 2 or more times.
After inserting some debug log messages in core.py the problem seem to
happen in _get_credential method in keystone.credential.core:
In first request to Keystone:
Aug 15 20:14:13 ubuntu-vm6 devstack@keystone.service[22678]: #033[00;36mINFO
keystone.credential.core [#033[01;36mNone
req-14485eaa-4172-4074-ac28-aa22fea7ce32 #033[00;36mNone None#033[00;36m]
#033[01;35m#033[00;36mcontents of credential after _get_credential are
user_id=u'4ad247ca077743078bf6109ff5c57dc1',
key_hash=u'716d67b1efbe8c7b46d13e6f4b5ccfbe095a3f73',
encrypted_blob=u'gABdVZLCpdDXGjdHk3kglftCMUDnxOKWNuLR6_6ZJtVTFt7VvJ-Y7VzyfxO6JwDv88OQtSMlJzbG8hUcfFftqhH6l5jpx6eNXdhTpO6_ZF57xyey1BmFI8JYh-PWdJkYtfDsOWJzCyWACQaUXU9N2J_r83xEYx691ToCwGCrkL-NgfFX-hVy3dYl9_4-5HcCOR4RoK2VXjLdvuAjWdvWCAxiVs-kxARpT0jkoZP1dnw-zs3pgDE=',
project_id=u'9be611818d0b4bac82ea0d468f91541b', type=u'ec2',
id=u'11755be627c5e6f22f3a31062afbd631bbe0f3176701ea23e5284920ded89e76'#033[00m#033[00m
In second request to Keystone:
Aug 15 20:14:43 ubuntu-vm6 devstack@keystone.service[22678]: #033[00;36mINFO
keystone.credential.core [#033[01;36mNone
req-4e4cc471-f9c7-461b-9245-65f8ac8c843b #033[00;36mNone None#033[00;36m]
#033[01;35m#033[00;36mcontents of credential after _get_credential are
user_id=u'4ad247ca077743078bf6109ff5c57dc1', blob=u'{"access":
"09b2bb6d93ff47098198ceaf060baa8a", "secret":
"d25c0c2c4ef542a29f84e7924ec89773", "trust_id": null}',
project_id=u'9be611818d0b4bac82ea0d468f91541b', type=u'ec2',
id=u'11755be627c5e6f22f3a31062afbd631bbe0f3176701ea23e5284920ded89e76'#033[00m#033[00m
=> Basically _get_credential method returns normal encrypted credential
(encrypted_blob) for the first call, and an unencrypted credential (blob) for
the second and subsequent calls by the same credential_id after 30 seconds.
After that, the already decrypted credential incorrectly returned by
_get_credential is passed to _decrypt_credential which fails because there is
no 'encrypted_blob' key in the dictionary. The stack trace for the second and
subsequent calls led to a package named 'dogpile' and some cache-related
methods inside it.
The problem seem to happen due to in-place modification of the
credential dictionary in _decrypt_credential method. During the first
request to Keystone the normal encrypted credential dictionary is
returned by _get_credential method and the returned result is cached.
However, after that the credential dictionary is modified in-place by
_decrypt_credential method. For the second and subsequent calls to the
_get_credential for the same user it tries to return the result from
cache. But the cached result has been modified by _decrypt_credential.
So, the already decrypted during first request credential is returned
and passed again to _decrypt_credential breaking it.
The solution is to modify a copy of the credential dictionary inside
_decrypt_credential method, not the original credential in-place (the
same approach as in _encrypt_credential where a copy is modified).
This way the encrypted value of the credential is cached and it does
not gets modified afterwards. So the normal encrypted credential is
returned from cache and passed to _decrypt_credential again and again
even for the same user which fixes the problem.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/1840647/+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 1845539] [NEW] Removed as of Ussuri
Public bug reported: This issue is for tracking removals during the Ussuri release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that remove deprecated items from keystone. This issue will be closed at the end of the cycle. ** Affects: keystone Importance: Low Status: Triaged -- 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/1845539 Title: Removed as of Ussuri Status in OpenStack Identity (keystone): Triaged Bug description: This issue is for tracking removals during the Ussuri release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that remove deprecated items from keystone. This issue will be closed at the end of the cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1845539/+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 1829454] Re: Deprecated as of Train
Closing with the release of RC1. ** Changed in: keystone Status: In Progress => Fix Released -- 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/1829454 Title: Deprecated as of Train Status in OpenStack Identity (keystone): Fix Released Bug description: This issue is for tracking deprecations during the Train release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that deprecate items in keystone. This issue will be closed at the end of the cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1829454/+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 1829453] Re: Removed as of Train
Closing with the release of RC1. ** Changed in: keystone Status: In Progress => Fix Released -- 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/1829453 Title: Removed as of Train Status in OpenStack Identity (keystone): Fix Released Bug description: This issue is for tracking removals during the Train release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that remove deprecated items from keystone. This issue will be closed at the end of the cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1829453/+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 1845540] [NEW] Deprecated as of Ussuri
Public bug reported: This issue is for tracking deprecations during the Ussuri release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that deprecate items in keystone. This issue will be closed at the end of the cycle. ** Affects: keystone Importance: Low Status: Triaged -- 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/1845540 Title: Deprecated as of Ussuri Status in OpenStack Identity (keystone): Triaged Bug description: This issue is for tracking deprecations during the Ussuri release. Use the "Related-bug" commit message tag and link to this issue from release notes for changes that deprecate items in keystone. This issue will be closed at the end of the cycle. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1845540/+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 1845530] [NEW] Versioned discovery endpoint should not require authentication
Public bug reported:
stack@nucle:/opt/stack/cyborg$ openstack endpoint list
+--+---+--++-+---+-+
| ID | Region| Service Name | Service Type
| Enabled | Interface | URL |
+--+---+--++-+---+-+
| 9d483c8a6162422282514191683751cb | RegionOne | nova | compute
| True| public| http://192.168.218.28/compute/v2.1 |
+--+---+--++-+---+-+
stack@nucle:/opt/stack/cyborg$ curl http://192.168.218.28/compute/v2.1
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
Discovery endpoints should not require authentication.
(I'm still looking for the doc that contains this edict; but ask mordred
or anyone on the api-sig.)
** 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/1845530
Title:
Versioned discovery endpoint should not require authentication
Status in OpenStack Compute (nova):
New
Bug description:
stack@nucle:/opt/stack/cyborg$ openstack endpoint list
+--+---+--++-+---+-+
| ID | Region| Service Name | Service Type
| Enabled | Interface | URL |
+--+---+--++-+---+-+
| 9d483c8a6162422282514191683751cb | RegionOne | nova | compute
| True| public| http://192.168.218.28/compute/v2.1 |
+--+---+--++-+---+-+
stack@nucle:/opt/stack/cyborg$ curl http://192.168.218.28/compute/v2.1
{"error": {"message": "The request you have made requires authentication.",
"code": 401, "title": "Unauthorized"}}
Discovery endpoints should not require authentication.
(I'm still looking for the doc that contains this edict; but ask
mordred or anyone on the api-sig.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1845530/+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 1842659] Re: Funtional tests of start and restart services failing 100% times
Reviewed: https://review.opendev.org/684977 Committed: https://git.openstack.org/cgit/openstack/networking-sfc/commit/?id=0644862c8beedd902a7d739be524699edc9b61d3 Submitter: Zuul Branch:master commit 0644862c8beedd902a7d739be524699edc9b61d3 Author: Slawek Kaplonski Date: Thu Sep 26 11:06:41 2019 +0200 [Functional tests] Fix SIGHUP handling tests Tests in networking_sfc.functional.test_server module are testing how service is handling SIGHUP signal. Recently this was changed in Oslo.service with [1] and our tests were failing because they were still expecting that after sending SIGHUP to the process, stop() and than start() method will be called. But as our services uses "mutate" as restart method, since [1] such process don't executes stop() and start() after SIGHUP. It now executes only reset() method. Similar change was recently done in Neutron's functional tests in [2]. This patch reflects that change in networking-sfc functional tests. [1] https://review.opendev.org/#/c/641907/ [2] https://review.opendev.org/#/c/680001/ Change-Id: I22629c59da983f47ef8b1862afb9a62bdfd78b02 Closes-Bug: #1842659 ** Changed in: networking-sfc 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/1842659 Title: Funtional tests of start and restart services failing 100% times Status in networking-sfc: Fix Released Status in neutron: Fix Released Bug description: Tests like: neutron.tests.functional.test_server.TestPluginWorker.test_start neutron.tests.functional.test_server.TestRPCServer.test_restart_rpc_on_sighup_multiple_workers neutron.tests.functional.test_server.TestWsgiServer.test_restart_wsgi_on_sighup_multiple_workers are now failing 100% of times since today. Example of failures: https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/logs_17/679917/1/check /neutron-functional-python27/caf3c2b/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1842659/+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 1845523] [NEW] Horizon doesn't show UI when it can't read policy files
Public bug reported: When horizon system user doesn't have permission to open policy files it doesn't render panels. It would be good to fall back to the default behaviour if policy files are not available ** Affects: horizon Importance: Undecided Assignee: Ivan Kolodyazhny (e0ne) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1845523 Title: Horizon doesn't show UI when it can't read policy files Status in OpenStack Dashboard (Horizon): In Progress Bug description: When horizon system user doesn't have permission to open policy files it doesn't render panels. It would be good to fall back to the default behaviour if policy files are not available To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1845523/+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 1843480] Re: Group names in Edit Project can get truncated when it is too long
Reviewed: https://review.opendev.org/681366
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=b635e625f75744938cde49fd250dd1a5f36ca1b7
Submitter: Zuul
Branch:master
commit b635e625f75744938cde49fd250dd1a5f36ca1b7
Author: Gloria Gu
Date: Tue Sep 10 19:54:56 2019 -0700
Updated max-width to be dynamic for .member class
When member name is longer than $members-list-item-width
(130px) in members list (for example, project group in Edit
Project), current text-overflow will put ... (ellipsis) at
the end of the name and name will be truncated.
Updated the styling of .member class to make max-width
dynamic 80% and wrap the name in case it is really long.
Change-Id: Ic295a9b1e7fd3525c633d51a60054e713da6a657
Closes-bug: #1843480
** Changed in: horizon
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1843480
Title:
Group names in Edit Project can get truncated when it is too long
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
Identity -> Projects, in Edit Project Dialog's Project Groups tab, if
the name of the project is very long, it could be displayed with ...
and there is no way to know what ... is there unless go to Identity ->
Groups
names with no space or _ will be truncated:
tesatetteateteateatteateteteetekekekekekekekekekekekekekekekekek
group_long_long_long_long_long_long_long_name
names with space or - will not be truncated:
group-long-long-long-long-long-long-long-long-name
it is a long long long long long long long long name
updated
openstack_dashboard/static/dashboard/scess/components/_membership.scss
.member {
padding: $nav-link-padding;
padding-right: 0;
padding-left:
$padding-base-vertical;
max-width: $members-list-item-width; <-- 130px cause problem
overflow-wrap: break-word; <-- added this
}
added overflow-wrap , the group name is not truncated...but not sure
about the side effect since this is the css for all the membership
related component.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1843480/+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 1845489] Re: Variable self-assignments causing pylint W0127 (self-assigning-variable)
This looks like an incorrect pylint warning to me. `schema` is in the module namespace in test_snap.py, but `schema = schema` binds the value of the module-level `schema` to `schema` on the test class. This is required because self.assertSchemaValid refers to `self.schema`. I'm going to look at finding/filing a pylint issue for this now, and will mark this as Invalid. ** Changed in: cloud-init Status: New => Invalid -- 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/1845489 Title: Variable self-assignments causing pylint W0127 (self-assigning- variable) Status in cloud-init: Invalid Bug description: The newly released pylint 2.4.0 detects variable self-assignments and throws a W0127 when one is found. There are four of these self- assignments in cloud-init, all in this form: @skipUnlessJsonSchema() class TestSchema(CiTestCase, SchemaTestCaseMixin): with_logs = True schema = schema ^^^ and all introduced by this commit: https://git.launchpad.net/cloud- init/commit/cloudinit/config/tests/test_snap.py?id=5037252ca5 I'd drop them, but it seems they have been introduced on purpose. Is there a good reason to keep them? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1845489/+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 1781439] Re: Test & document 1.28 (consumer gen) changes for /resource_providers/{u}/allocations
Create a bug in placement storyboard as placement bugs are handled there
https://storyboard.openstack.org/#!/story/2006620
** Changed in: nova
Status: New => Invalid
--
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/1781439
Title:
Test & document 1.28 (consumer gen) changes for
/resource_providers/{u}/allocations
Status in OpenStack Compute (nova):
Invalid
Bug description:
I978fdea51f2d6c2572498ef80640c92ab38afe65 /
https://review.openstack.org/#/c/565604/ added placement microversion
1.28, which made various API operations consumer generation-aware. One
of the affected routes was /resource_providers/{u}/allocations - but
this route wasn't covered in the gabbi tests or the API reference
documentation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1781439/+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 1845489] [NEW] Variable self-assignments causing pylint W0127 (self-assigning-variable)
Public bug reported: The newly released pylint 2.4.0 detects variable self-assignments and throws a W0127 when one is found. There are four of these self- assignments in cloud-init, all in this form: @skipUnlessJsonSchema() class TestSchema(CiTestCase, SchemaTestCaseMixin): with_logs = True schema = schema ^^^ and all introduced by this commit: https://git.launchpad.net/cloud- init/commit/cloudinit/config/tests/test_snap.py?id=5037252ca5 I'd drop them, but it seems they have been introduced on purpose. Is there a good reason to keep them? ** 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/1845489 Title: Variable self-assignments causing pylint W0127 (self-assigning- variable) Status in cloud-init: New Bug description: The newly released pylint 2.4.0 detects variable self-assignments and throws a W0127 when one is found. There are four of these self- assignments in cloud-init, all in this form: @skipUnlessJsonSchema() class TestSchema(CiTestCase, SchemaTestCaseMixin): with_logs = True schema = schema ^^^ and all introduced by this commit: https://git.launchpad.net/cloud- init/commit/cloudinit/config/tests/test_snap.py?id=5037252ca5 I'd drop them, but it seems they have been introduced on purpose. Is there a good reason to keep them? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1845489/+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 1843428] Re: List port by mac address is case sensitive
Reviewed: https://review.opendev.org/681390 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ffe5943e657ef32bf4c509a8965cf03a4703be1d Submitter: Zuul Branch:master commit ffe5943e657ef32bf4c509a8965cf03a4703be1d Author: mmidolesov Date: Wed Sep 11 00:09:45 2019 -0700 Make port list by mac case insesitive This fix removes the case sensitivity when performing port list by mac address criteria. Closes-Bug: #1843428 Change-Id: I7ab6934ea333467d2efc5da0471b1af82ebb44b8 ** 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/1843428 Title: List port by mac address is case sensitive Status in neutron: Fix Released Bug description: Searching for a MAC address in neutron should not be case-sensitive. For example in case of executing openstack port list --mac-address A:B:C should show results for a:b:c. This is found in queens release. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1843428/+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 1845324] Re: Openvswitch kernel module is sometimes not loaded running devstack
Reviewed: https://review.opendev.org/684745 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6b241bb13c400f28401605e05d66facf661460fb Submitter: Zuul Branch:master commit 6b241bb13c400f28401605e05d66facf661460fb Author: Brian Haley Date: Wed Sep 25 08:54:45 2019 -0400 Always make sure openvswitch kernel module is loaded In change https://review.opendev.org/#/c/661065/ we stopped compiling openvswitch from source, which was always doing a reload of the kernel module. We've seen in some cases the module isn't loaded, so change to always load the module unconditionally to avoid this. Change-Id: I2ac2aa4cc84d6f5ac62bc8c7aec67ac17d89c614 Closes-bug: #1845324 ** 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/1845324 Title: Openvswitch kernel module is sometimes not loaded running devstack Status in neutron: Fix Released Bug description: In change https://review.opendev.org/#/c/661065/ we stopped compiling openvswitch from source, which was always doing a reload of the kernel module. We've seen in some cases the module isn't loaded, we need to change to always load the module unconditionally to avoid this. I'm working on a patch already, and it will need to go to the stable branches as far as queens. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1845324/+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 1700034] Re: wrong list of attached vms are shown in manage volume attachments
Reviewed: https://review.opendev.org/678185 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=8051a2ca67edb4feda59103e38b1224ad4d959b2 Submitter: Zuul Branch:master commit 8051a2ca67edb4feda59103e38b1224ad4d959b2 Author: Ivan Kolodyazhny Date: Wed Sep 25 15:37:51 2019 +0300 Wrong list of attached vms are shown in manage volume attachments When user tries to attach a volume(multi-attach-volume) to multiple instances "Manage Attachments" table shows wrong data. This patch fix the issue. Closes-Bug: #1700034 Part of blueprint multi-attach-volume Co-Authored-By: Vishal Manchanda Change-Id: Ic84e3089c2c15e13dbdf89a38f867e3ddfed86d5 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1700034 Title: wrong list of attached vms are shown in manage volume attachments Status in OpenStack Dashboard (Horizon): Fix Released Bug description: 1. create instance 'vm1' and 'vm2' 2. create shared volume 'shared_volume' 3. attach shared_volume to botsh vm1 and vm2 navigate Admin - System - Volumes 4. navigate Admin - System - Volumes 5. click 'Manage Attachments' for shared_volume 6. check Instance column Current results: In 'Instance column', there are 2 rows for 'vm2' Expected result: In 'Instance column', there are 2 rows. One row is for 'vm1' and the other row for 'vm2' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1700034/+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 1842659] Re: Funtional tests of start and restart services failing 100% times
** Also affects: networking-sfc Importance: Undecided Status: New ** Changed in: networking-sfc Assignee: (unassigned) => Slawek Kaplonski (slaweq) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1842659 Title: Funtional tests of start and restart services failing 100% times Status in networking-sfc: In Progress Status in neutron: Fix Released Bug description: Tests like: neutron.tests.functional.test_server.TestPluginWorker.test_start neutron.tests.functional.test_server.TestRPCServer.test_restart_rpc_on_sighup_multiple_workers neutron.tests.functional.test_server.TestWsgiServer.test_restart_wsgi_on_sighup_multiple_workers are now failing 100% of times since today. Example of failures: https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/logs_17/679917/1/check /neutron-functional-python27/caf3c2b/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/networking-sfc/+bug/1842659/+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
