[Yahoo-eng-team] [Bug 1821764] Re: docs: JsonFilter query hint examples do not use valid json strings
Reviewed: https://review.openstack.org/647778
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=45cecbb427a82568ea25b4d6dbb2ab32518a9a9f
Submitter: Zuul
Branch:master
commit 45cecbb427a82568ea25b4d6dbb2ab32518a9a9f
Author: Matt Riedemann
Date: Tue Mar 26 11:37:27 2019 -0400
Fix JsonFilter query hint examples in docs
The API reference and part of the scheduler filter docs for
the JsonFilter query hint are using invalid json strings
in the examples.
This fixes both invalid locations using the same json string
used in the openstack server create command example in the
scheduler admin docs.
Change-Id: Iaab8608c7ffa6fbbea40a838dd02d8096f632f7a
Closes-Bug: #1821764
** 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/1821764
Title:
docs: JsonFilter query hint examples do not use valid json strings
Status in OpenStack Compute (nova):
Fix Released
Bug description:
This is wrong in a few places.
1. The server create API reference:
https://developer.openstack.org/api-ref/compute/?expanded=create-
server-detail#create-server
"query": "[=,$free_ram_mb,1024]"
>>> json.loads("[=,$free_ram_mb,1024]")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
2. The scheduler filter docs:
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#jsonfilter
The command line example is OK, but the API request is wrong:
>>> json.loads("[>=,$free_ram_mb,1024]")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
The docs should probably just be consistent and use the same example that
works from the openstack server create command example:
'[">=","$free_ram_mb",1024]'
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1821764/+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 1821836] [NEW] Confirmation message for RBAC policy deletion does not appear properly.
Public bug reported: 1. Click Admin -> Network -> RBAC Policies -> RBAC Policies screen 2. Select policy 3. Click DELETE RBAC POLICIES Confirmation window appears but selected policy ID is not shown (please see attached screenshot). This issue happens for all the languages. ** Affects: horizon Importance: Undecided Status: New ** Tags: i18n ** Attachment added: "Screenshot from 2019-03-27 12-24-02.png" https://bugs.launchpad.net/bugs/1821836/+attachment/5249641/+files/Screenshot%20from%202019-03-27%2012-24-02.png -- 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/1821836 Title: Confirmation message for RBAC policy deletion does not appear properly. Status in OpenStack Dashboard (Horizon): New Bug description: 1. Click Admin -> Network -> RBAC Policies -> RBAC Policies screen 2. Select policy 3. Click DELETE RBAC POLICIES Confirmation window appears but selected policy ID is not shown (please see attached screenshot). This issue happens for all the languages. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1821836/+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 1821835] [NEW] On the trunk Details page, after deleting the trunk, jump to a wrong page.
Public bug reported: On the trunk Details page, after deleting the trunk, jump to a wrong page. ** Affects: horizon Importance: Undecided Assignee: pengyuesheng (pengyuesheng) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => pengyuesheng (pengyuesheng) -- 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/1821835 Title: On the trunk Details page, after deleting the trunk, jump to a wrong page. Status in OpenStack Dashboard (Horizon): In Progress Bug description: On the trunk Details page, after deleting the trunk, jump to a wrong page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1821835/+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 1813007] Re: Unable to install new flows on compute nodes when having broken security group rules
Reviewed: https://review.openstack.org/640252 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=18c578aa10c19a6befdf1f1510645200f173eb44 Submitter: Zuul Branch:master commit 18c578aa10c19a6befdf1f1510645200f173eb44 Author: Brian Haley Date: Thu Feb 28 22:19:16 2019 -0500 Fix KeyError in OVS firewall When merging port ranges, the code never assumed the conjunction ID might not be present in the set due to already being removed. In this case there were two security groups, both using the same remote security group, but the first security group does not define a port range and the second one does. Or more generally, the first SG port range is a subset of the second, as no port-range means the full range. Change-Id: I17ab643abbd2ec21eda4ae1dfb9abf2d4b0657f2 Closes-bug: #1813007 ** 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/1813007 Title: Unable to install new flows on compute nodes when having broken security group rules Status in Ubuntu Cloud Archive: Triaged Status in Ubuntu Cloud Archive pike series: Triaged Status in Ubuntu Cloud Archive queens series: Triaged Status in Ubuntu Cloud Archive rocky series: Triaged Status in Ubuntu Cloud Archive stein series: Triaged Status in neutron: Fix Released Status in OpenStack Security Advisory: Incomplete Status in neutron package in Ubuntu: Triaged Status in neutron source package in Xenial: Triaged Status in neutron source package in Bionic: Triaged Status in neutron source package in Cosmic: Triaged Status in neutron source package in Disco: Triaged Bug description: It appears that we have found that neutron-openvswitch-agent appears to have a bug where two security group rules that have two different port ranges that overlap tied to the same parent security group will cause neutron to not be able to configure networks on the compute nodes where those security groups are present. Those are the broken security rules: https://pastebin.canonical.com/p/wSy8RSXt85/ Here is the log when we discovered the issue: https://pastebin.canonical.com/p/wvFKjNWydr/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1813007/+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 1821824] [NEW] Forbidden traits in flavor properties don't work
Public bug reported: Due to an error when implementing forbidden traits they are stripped off in the _clean_empties function in nova/scheduler/utils.py which only takes required_traits into account. This means that forbidden traits won't be acted upon and an instance started with a flavor with a forbidden trait still can end up on a resource provider with that trait set. ** 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/1821824 Title: Forbidden traits in flavor properties don't work Status in OpenStack Compute (nova): New Bug description: Due to an error when implementing forbidden traits they are stripped off in the _clean_empties function in nova/scheduler/utils.py which only takes required_traits into account. This means that forbidden traits won't be acted upon and an instance started with a flavor with a forbidden trait still can end up on a resource provider with that trait set. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1821824/+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 1821708] Re: neutron-server high cpu usage in host_routes_after_create
Reviewed: https://review.openstack.org/647703 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=04f23958e63a5c74134fd2e9376fa8ed00eabbb2 Submitter: Zuul Branch:master commit 04f23958e63a5c74134fd2e9376fa8ed00eabbb2 Author: Dirk Mueller Date: Tue Mar 26 11:18:51 2019 +0100 Avoid iterating over all of the segment data just for counting getting the full collection (which includes iterating over it and populating attributes) just to gather the count of it is wasteful. we can just use the count api. Change-Id: I1b216cb2c8c5b612f12554454d5721a14975f138 Closes-Bug: #1821708 ** Changed in: neutron Status: Triaged => 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/1821708 Title: neutron-server high cpu usage in host_routes_after_create Status in neutron: Fix Released Bug description: A lot of cpu (17%) of neutron-server is spent in a single function called host_routes_after_create. we should try to optimize this. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1821708/+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 1820870] Re: Fullstack tests are failing because async_process is not started properly
Reviewed: https://review.openstack.org/647605
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=cf13b2f0cc18fdb1d512ecfe9f2c65ad4bb284dd
Submitter: Zuul
Branch:master
commit cf13b2f0cc18fdb1d512ecfe9f2c65ad4bb284dd
Author: Slawek Kaplonski
Date: Mon Mar 25 21:54:52 2019 +0100
Check if process' cmdline is "space separarated"
According to proc man page process arguments in /proc/{pid}/cmdline
should be separated with '\0' char and that char was used in
neutron.agent.linux.utils.get_cmdline_from_pid function.
Recently in fullstack tests it was noticed that sometimes it may
happend that those arguments are separated with space char and this
caused failed test because async_process.AsyncProcess() was not able
to check that process is really active.
This patch adds attempt to split cmdline arguments with space in case
when split with '\0' returns only 1 element.
Change-Id: I35d4c0e2cf56fc3ff15cf307aaf11a8ad8489e1f
Closes-Bug: #1820870
** 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/1820870
Title:
Fullstack tests are failing because async_process is not started
properly
Status in neutron:
Fix Released
Bug description:
Various fullstack tests are failing because of some issues with
connection to rabbitmq.
Example of such failure: http://logs.openstack.org/86/643486/8/check
/neutron-fullstack/9fe648e/logs/testr_results.html.gz and log from
agents: http://logs.openstack.org/86/643486/8/check/neutron-
fullstack/9fe648e/logs/dsvm-fullstack-
logs/TestDscpMarkingQoSLinuxbridge.test_dscp_marking_clean_port_removed
/neutron-linuxbridge-agent--2019-03-19--
12-12-33-931856.txt.gz?level=ERROR
All agents in such case can't connect to rabbitmq, errors in logs are
like:
AMQP server on 240.44.122.1:5672 is unreachable: [Errno 101]
ENETUNREACH. Trying again in 4 seconds.: OSError: [Errno 101]
ENETUNREACH
Logstash query:
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ENETUNREACH%5C%22%20AND%20build_name%3A%5C
%22neutron-fullstack%5C%22
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1820870/+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 1820337] Re: test_bfv_quota_race_local_delete intermittently fails with testtools.matchers._impl.MismatchError: ['bfv'] != []
Reviewed: https://review.openstack.org/645546
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=64f6cbc9120e3c288f312eddc59452dee4998f93
Submitter: Zuul
Branch:master
commit 64f6cbc9120e3c288f312eddc59452dee4998f93
Author: Matthew Booth
Date: Fri Mar 22 11:47:32 2019 +
Fix incomplete instance data returned after build failure
This change fixes a race in _cleanup_build_artifacts. We were updating
the instance mapping to point at the cell in which the instance was
created before the instance record was complete, i.e. before the related
BDMs and tags were created in the cell DB. Updating the instance mapping
exposes the cell's version of the instance to the API. If the API happened
to fetch it before it was finished being created it would return
incomplete data.
Co-Authored-By: Matt Riedemann
Closes-Bug: #1820337
Change-Id: If966eb1161c842ff49aa530e4482dbca87b61a3e
** 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/1820337
Title:
test_bfv_quota_race_local_delete intermittently fails with
testtools.matchers._impl.MismatchError: ['bfv'] != []
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) pike series:
In Progress
Status in OpenStack Compute (nova) queens series:
In Progress
Status in OpenStack Compute (nova) rocky series:
In Progress
Status in OpenStack Compute (nova) stein series:
In Progress
Bug description:
Seen here:
http://logs.openstack.org/72/640772/1/gate/nova-tox-functional-
py35/44118f7/job-output.txt.gz#_2019-03-13_18_36_04_685027
2019-03-13 18:36:04.685027 | ubuntu-xenial | {2}
nova.tests.functional.regressions.test_bug_1806064.BootFromVolumeOverQuotaRaceDeleteTest.test_bfv_quota_race_local_delete
[2.015433s] ... FAILED
2019-03-13 18:36:04.685120 | ubuntu-xenial |
2019-03-13 18:36:04.685187 | ubuntu-xenial | Captured traceback:
2019-03-13 18:36:04.685251 | ubuntu-xenial | ~~~
2019-03-13 18:36:04.685350 | ubuntu-xenial | b'Traceback (most recent
call last):'
2019-03-13 18:36:04.685658 | ubuntu-xenial | b' File
"/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/functional/regressions/test_bug_1806064.py",
line 129, in test_bfv_quota_race_local_delete'
2019-03-13 18:36:04.685776 | ubuntu-xenial | b"
self.assertEqual(['bfv'], server['tags'])"
2019-03-13 18:36:04.686080 | ubuntu-xenial | b' File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/testtools/testcase.py",
line 411, in assertEqual'
2019-03-13 18:36:04.686207 | ubuntu-xenial | b'
self.assertThat(observed, matcher, message)'
2019-03-13 18:36:04.686487 | ubuntu-xenial | b' File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/testtools/testcase.py",
line 498, in assertThat'
2019-03-13 18:36:04.686569 | ubuntu-xenial | b'raise mismatch_error'
2019-03-13 18:36:04.686699 | ubuntu-xenial |
b"testtools.matchers._impl.MismatchError: ['bfv'] != []"
2019-03-13 18:36:04.686740 | ubuntu-xenial | b''
2019-03-13 18:36:04.686770 | ubuntu-xenial |
2019-03-13 18:36:04.686838 | ubuntu-xenial | Captured pythonlogging:
2019-03-13 18:36:04.686905 | ubuntu-xenial | ~~~
2019-03-13 18:36:04.695625 | ubuntu-xenial | b"2019-03-13 18:36:02,849
INFO [nova.api.openstack.placement.objects.resource_provider] Synced traits
from os_traits into API DB: {'HW_NIC_SRIOV_QOS_RX', 'HW_CPU_X86_SVM',
'HW_CPU_X86_AVX512VL', 'HW_GPU_API_DIRECT3D_V9_0', 'HW_NIC_OFFLOAD_SG',
'HW_NIC_OFFLOAD_TSO', 'HW_NIC_OFFLOAD_GSO', 'HW_GPU_API_CUDA_V2_0',
'HW_GPU_RESOLUTION_W3840H2160', 'HW_GPU_API_OPENGL_V1_2', 'HW_CPU_X86_AVX2',
'HW_GPU_API_CUDA_V7_0', 'HW_CPU_X86_AVX512BW', 'HW_CPU_HYPERTHREADING',
'HW_NIC_SRIOV_TRUSTED', 'HW_GPU_RESOLUTION_W2560H1600', 'HW_CPU_X86_TBM',
'HW_GPU_API_OPENGL_V4_2', 'HW_NIC_OFFLOAD_RX', 'HW_NIC_OFFLOAD_TXVLAN',
'HW_NIC_ACCEL_ECC', 'HW_CPU_X86_AVX512CD', 'HW_NIC_VMDQ',
'HW_GPU_MAX_DISPLAY_HEADS_1', 'HW_CPU_AARCH64_SHA512',
'HW_GPU_API_OPENGL_V3_3', 'HW_GPU_RESOLUTION_W800H600', 'HW_CPU_AARCH64_SM4',
'COMPUTE_VOLUME_ATTACH_WITH_TAG', 'HW_CPU_AARCH64_ASIMDHP',
'HW_CPU_AARCH64_DCPOP', 'HW_CPU_AARCH64_FCMA', 'HW_GPU_API_OPENCL_V2_0',
'HW_NIC_ACCEL_RSA', 'HW_GPU_API_VULKAN', 'HW_GPU_MAX_DISPLAY_HEADS_2',
'HW_NIC_DCB_PFC', 'HW_GPU_API_DIRECT3D_V9_0L', 'HW_NIC_MULTIQUEUE',
'HW_GPU_RESOLUTION_W1600H1200', 'HW_CPU_X86_CLMUL', 'HW_GPU_API_CUDA_V7_1',
'HW_CPU_AARCH64_FPHP', 'HW_GPU_RESOLUTION_W640H480', 'HW_CPU_AARCH64_PMULL',
'HW_NIC_OFFLOAD_TXUDP', 'HW_GPU_MAX_DISPLAY_HEADS_6', 'HW_NIC_ACCEL_SSL',
'HW_CPU_X86_3DNOW', 'STORAGE_DISK_SSD', 'HW_GPU_RESOLUTION_W1680H1050',
'HW_NIC_DCB_ETS', 'HW_CPU_X86_SSE2',
[Yahoo-eng-team] [Bug 1821815] [NEW] Gate jobs are failing for stable/ocata
Public bug reported: Some Gate jobs are failing for stable/ocata, is there any known issues with the stable/ocata branch. See the patch for details. https://review.openstack.org/#/c/640176/ https://review.openstack.org/#/c/642363/ ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1821815 Title: Gate jobs are failing for stable/ocata Status in neutron: New Bug description: Some Gate jobs are failing for stable/ocata, is there any known issues with the stable/ocata branch. See the patch for details. https://review.openstack.org/#/c/640176/ https://review.openstack.org/#/c/642363/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1821815/+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 1821798] [NEW] nova diagnostics command is not working with all interfaces
Public bug reported: When running nova diagnostics on instances with SR-IOV interfaces, we get: $ nova diagnostics iperf-server ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-ae9445f6-558c-45c3-bdb2-b9fe6bbf186c) ** Affects: nova Importance: Undecided Assignee: François Palin (francois.palin) 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/1821798 Title: nova diagnostics command is not working with all interfaces Status in OpenStack Compute (nova): New Bug description: When running nova diagnostics on instances with SR-IOV interfaces, we get: $ nova diagnostics iperf-server ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-ae9445f6-558c-45c3-bdb2-b9fe6bbf186c) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1821798/+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 1819794] Re: nova-next job fail on Ubuntu Bionic
The devstack change merged and console with TLS testing has been re- enabled in the nova-next job. ** Also affects: devstack Importance: Undecided Status: New ** Changed in: devstack Status: New => Fix Released ** Changed in: devstack Assignee: (unassigned) => melanie witt (melwitt) ** 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/1819794 Title: nova-next job fail on Ubuntu Bionic Status in devstack: Fix Released Status in OpenStack Compute (nova): Fix Released Bug description: OpenStack CI is moving to Ubuntu Bionic. All zuulv3 native jobs based on devstack job are already running on bionic but legacy jobs are still running on xenial. While migrating the legacy jobs to Bionic, nova-next job start failing - https://review.openstack.org/#/c/639017 The problem seems to be on TLS console proxy side. This is the only legacy job which enables tls-proxy service. libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-03-08T02:23:53.402326Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Mar 08 02:23:53.452557 ubuntu-bionic-rax-iad-0003574603 nova-compute[31993]: ERROR nova.virt.libvirt.driver [None req-a3dbdf7a-29cc-4e36-a760-2d92da2d13f0 tempest-DeleteServersAdminTestJSON-2130806780 tempest-DeleteServersAdminTestJSON-2130806780] [instance: 3b8927dd-fd26-4050-9428-d0db99856d60] Failed to start libvirt guest: libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-03-08T02:23:53.402326Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Complete logs http://logs.openstack.org/17/639017/4/check/nova- next/566ea7a/logs/screen-n-cpu.txt.gz#_Mar_08_02_23_53_452557 http://logs.openstack.org/17/639017/4/check/nova- next/566ea7a/logs/screen-n-cond-cell1.txt.gz#_Mar_08_02_23_54_553579 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1819794/+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 1821764] [NEW] docs: JsonFilter query hint examples do not use valid json strings
Public bug reported:
This is wrong in a few places.
1. The server create API reference:
https://developer.openstack.org/api-ref/compute/?expanded=create-server-
detail#create-server
"query": "[=,$free_ram_mb,1024]"
>>> json.loads("[=,$free_ram_mb,1024]")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
2. The scheduler filter docs:
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#jsonfilter
The command line example is OK, but the API request is wrong:
>>> json.loads("[>=,$free_ram_mb,1024]")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
The docs should probably just be consistent and use the same example that works
from the openstack server create command example:
'[">=","$free_ram_mb",1024]'
** Affects: nova
Importance: Medium
Assignee: Matt Riedemann (mriedem)
Status: In Progress
** Tags: api-ref docs scheduler
--
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/1821764
Title:
docs: JsonFilter query hint examples do not use valid json strings
Status in OpenStack Compute (nova):
In Progress
Bug description:
This is wrong in a few places.
1. The server create API reference:
https://developer.openstack.org/api-ref/compute/?expanded=create-
server-detail#create-server
"query": "[=,$free_ram_mb,1024]"
>>> json.loads("[=,$free_ram_mb,1024]")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
2. The scheduler filter docs:
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#jsonfilter
The command line example is OK, but the API request is wrong:
>>> json.loads("[>=,$free_ram_mb,1024]")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
The docs should probably just be consistent and use the same example that
works from the openstack server create command example:
'[">=","$free_ram_mb",1024]'
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1821764/+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 1820337] Re: test_bfv_quota_race_local_delete intermittently fails with testtools.matchers._impl.MismatchError: ['bfv'] != []
** Changed in: nova
Assignee: Matt Riedemann (mriedem) => Matthew Booth (mbooth-9)
** Also affects: nova/queens
Importance: Undecided
Status: New
** Also affects: nova/stein
Importance: Undecided
Status: New
** Also affects: nova/pike
Importance: Undecided
Status: New
** Also affects: nova/rocky
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/1820337
Title:
test_bfv_quota_race_local_delete intermittently fails with
testtools.matchers._impl.MismatchError: ['bfv'] != []
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Compute (nova) pike series:
New
Status in OpenStack Compute (nova) queens series:
New
Status in OpenStack Compute (nova) rocky series:
New
Status in OpenStack Compute (nova) stein series:
New
Bug description:
Seen here:
http://logs.openstack.org/72/640772/1/gate/nova-tox-functional-
py35/44118f7/job-output.txt.gz#_2019-03-13_18_36_04_685027
2019-03-13 18:36:04.685027 | ubuntu-xenial | {2}
nova.tests.functional.regressions.test_bug_1806064.BootFromVolumeOverQuotaRaceDeleteTest.test_bfv_quota_race_local_delete
[2.015433s] ... FAILED
2019-03-13 18:36:04.685120 | ubuntu-xenial |
2019-03-13 18:36:04.685187 | ubuntu-xenial | Captured traceback:
2019-03-13 18:36:04.685251 | ubuntu-xenial | ~~~
2019-03-13 18:36:04.685350 | ubuntu-xenial | b'Traceback (most recent
call last):'
2019-03-13 18:36:04.685658 | ubuntu-xenial | b' File
"/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/functional/regressions/test_bug_1806064.py",
line 129, in test_bfv_quota_race_local_delete'
2019-03-13 18:36:04.685776 | ubuntu-xenial | b"
self.assertEqual(['bfv'], server['tags'])"
2019-03-13 18:36:04.686080 | ubuntu-xenial | b' File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/testtools/testcase.py",
line 411, in assertEqual'
2019-03-13 18:36:04.686207 | ubuntu-xenial | b'
self.assertThat(observed, matcher, message)'
2019-03-13 18:36:04.686487 | ubuntu-xenial | b' File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/testtools/testcase.py",
line 498, in assertThat'
2019-03-13 18:36:04.686569 | ubuntu-xenial | b'raise mismatch_error'
2019-03-13 18:36:04.686699 | ubuntu-xenial |
b"testtools.matchers._impl.MismatchError: ['bfv'] != []"
2019-03-13 18:36:04.686740 | ubuntu-xenial | b''
2019-03-13 18:36:04.686770 | ubuntu-xenial |
2019-03-13 18:36:04.686838 | ubuntu-xenial | Captured pythonlogging:
2019-03-13 18:36:04.686905 | ubuntu-xenial | ~~~
2019-03-13 18:36:04.695625 | ubuntu-xenial | b"2019-03-13 18:36:02,849
INFO [nova.api.openstack.placement.objects.resource_provider] Synced traits
from os_traits into API DB: {'HW_NIC_SRIOV_QOS_RX', 'HW_CPU_X86_SVM',
'HW_CPU_X86_AVX512VL', 'HW_GPU_API_DIRECT3D_V9_0', 'HW_NIC_OFFLOAD_SG',
'HW_NIC_OFFLOAD_TSO', 'HW_NIC_OFFLOAD_GSO', 'HW_GPU_API_CUDA_V2_0',
'HW_GPU_RESOLUTION_W3840H2160', 'HW_GPU_API_OPENGL_V1_2', 'HW_CPU_X86_AVX2',
'HW_GPU_API_CUDA_V7_0', 'HW_CPU_X86_AVX512BW', 'HW_CPU_HYPERTHREADING',
'HW_NIC_SRIOV_TRUSTED', 'HW_GPU_RESOLUTION_W2560H1600', 'HW_CPU_X86_TBM',
'HW_GPU_API_OPENGL_V4_2', 'HW_NIC_OFFLOAD_RX', 'HW_NIC_OFFLOAD_TXVLAN',
'HW_NIC_ACCEL_ECC', 'HW_CPU_X86_AVX512CD', 'HW_NIC_VMDQ',
'HW_GPU_MAX_DISPLAY_HEADS_1', 'HW_CPU_AARCH64_SHA512',
'HW_GPU_API_OPENGL_V3_3', 'HW_GPU_RESOLUTION_W800H600', 'HW_CPU_AARCH64_SM4',
'COMPUTE_VOLUME_ATTACH_WITH_TAG', 'HW_CPU_AARCH64_ASIMDHP',
'HW_CPU_AARCH64_DCPOP', 'HW_CPU_AARCH64_FCMA', 'HW_GPU_API_OPENCL_V2_0',
'HW_NIC_ACCEL_RSA', 'HW_GPU_API_VULKAN', 'HW_GPU_MAX_DISPLAY_HEADS_2',
'HW_NIC_DCB_PFC', 'HW_GPU_API_DIRECT3D_V9_0L', 'HW_NIC_MULTIQUEUE',
'HW_GPU_RESOLUTION_W1600H1200', 'HW_CPU_X86_CLMUL', 'HW_GPU_API_CUDA_V7_1',
'HW_CPU_AARCH64_FPHP', 'HW_GPU_RESOLUTION_W640H480', 'HW_CPU_AARCH64_PMULL',
'HW_NIC_OFFLOAD_TXUDP', 'HW_GPU_MAX_DISPLAY_HEADS_6', 'HW_NIC_ACCEL_SSL',
'HW_CPU_X86_3DNOW', 'STORAGE_DISK_SSD', 'HW_GPU_RESOLUTION_W1680H1050',
'HW_NIC_DCB_ETS', 'HW_CPU_X86_SSE2', 'HW_NIC_OFFLOAD_RXHASH',
'HW_GPU_API_CUDA_V6_0', 'MISC_SHARES_VIA_AGGREGATE',
'HW_GPU_RESOLUTION_W1152H864', 'HW_CPU_X86_MPX', 'HW_GPU_RESOLUTION_W1360H768',
'HW_GPU_API_OPENGL_V1_5', 'HW_CPU_X86_F16C', 'HW_GPU_RESOLUTION_W1024H600',
'HW_CPU_X86_AVX512F', 'HW_GPU_API_DIRECT3D_V9_0B', 'HW_NIC_OFFLOAD_QINQ',
'HW_GPU_RESOLUTION_W1024H768', 'HW_GPU_API_OPENGL_V4_3',
'HW_GPU_API_OPENGL_V2_0', 'HW_GPU_API_DIRECT3D_V8_1', 'HW_NIC_OFFLOAD_GRO',
'HW_GPU_RESOLUTION_W1366H768', 'HW_CPU_X86_AVX512ER', 'HW_NIC_OFFLOAD_UFO',
'HW_CPU_AARCH64_SVE', 'HW_GPU_RESOLUTION_W1280H800', 'HW_NIC_ACCEL_LZS',
'COMPUTE_DEVICE_TAGGING', 'HW_CPU_AARCH64_ATOMICS', 'HW_NIC_OFFLOAD_RXVLAN',
[Yahoo-eng-team] [Bug 1821753] [NEW] openvswitch agent ofctl request errors: 'timed out' and 'Datapath Invalid'
Public bug reported:
Release: Queens, ovsdb_interface=native, of_request_timeout = 30
With number of OVS ports growing on the node following errors start to
occur (starting at ~1200 ports):
ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
[req-db47426c-1719-43dd-8ecf-4fb4bdcbc316 - - - - -] ofctl request
version=None,msg_type=None,msg_len=None,xid=None,OFPFlowMod(buffer_id=4294967295,command=0,cookie=5881109557449606263L,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionActions(actions=[OFPActionPopVlan(len=8,type=18),
OFPActionSetField(tunnel_id=725),
OFPActionOutput(len=16,max_len=0,port=1793,type=0),
OFPActionOutput(len=16,max_len=0,port=2,type=0)],type=4)],match=OFPMatch(oxm_fields={'vlan_vid':
4175}),out_group=0,out_port=0,priority=1,table_id=22) error Datapath Invalid
64183592930369: InvalidDatapath: Datapath Invalid
or
ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
[req-632b8ede-1234-4682-afe0-3aefb615b121 - - - - -] ofctl request
version=0x4,msg_type=0xe,msg_len=0x78,xid=0x73c67c07,OFPFlow
Mod(buffer_id=4294967295,command=0,cookie=5881109557449606263L,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionActions(actions=[OFPActionPopVlan(len=8,type=18),
OFPActionSetField(tunnel_id=666), OFPActionOu
tput(len=16,max_len=0,port=2,type=0)],len=48,type=4)],match=OFPMatch(oxm_fields={'eth_dst':
'fa:16:3e:4a:79:ce', 'vlan_vid':
6107}),out_group=0,out_port=0,priority=2,table_id=20) timed out: Timeout: 30
seconds
with corresponding errors is ovs-vswitchd logs:
|rconn|ERR|br-tun<->tcp:127.0.0.1:6633: no response to inactivity probe after 5
seconds, disconnecting
|rconn|ERR|br-floating<->tcp:127.0.0.1:6633: no response to inactivity probe
after 5 seconds, disconnecting
|rconn|ERR|br-int<->tcp:127.0.0.1:6633: no response to inactivity probe after 5
seconds, disconnecting
Setting inactivity_probe to a greater value helps:
#ovs-vsctl set controller br-int inactivity_probe=3
#ovs-vsctl set controller br-tun inactivity_probe=3
#ovs-vsctl set controller br-floating inactivity_probe=3
Should neutron allow setting inactivity_probe for controllers?
Should it correspond to of_request_timeout value?
** 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/1821753
Title:
openvswitch agent ofctl request errors: 'timed out' and 'Datapath
Invalid'
Status in neutron:
New
Bug description:
Release: Queens, ovsdb_interface=native, of_request_timeout = 30
With number of OVS ports growing on the node following errors start to
occur (starting at ~1200 ports):
ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
[req-db47426c-1719-43dd-8ecf-4fb4bdcbc316 - - - - -] ofctl request
version=None,msg_type=None,msg_len=None,xid=None,OFPFlowMod(buffer_id=4294967295,command=0,cookie=5881109557449606263L,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionActions(actions=[OFPActionPopVlan(len=8,type=18),
OFPActionSetField(tunnel_id=725),
OFPActionOutput(len=16,max_len=0,port=1793,type=0),
OFPActionOutput(len=16,max_len=0,port=2,type=0)],type=4)],match=OFPMatch(oxm_fields={'vlan_vid':
4175}),out_group=0,out_port=0,priority=1,table_id=22) error Datapath Invalid
64183592930369: InvalidDatapath: Datapath Invalid
or
ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
[req-632b8ede-1234-4682-afe0-3aefb615b121 - - - - -] ofctl request
version=0x4,msg_type=0xe,msg_len=0x78,xid=0x73c67c07,OFPFlow
Mod(buffer_id=4294967295,command=0,cookie=5881109557449606263L,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionActions(actions=[OFPActionPopVlan(len=8,type=18),
OFPActionSetField(tunnel_id=666), OFPActionOu
tput(len=16,max_len=0,port=2,type=0)],len=48,type=4)],match=OFPMatch(oxm_fields={'eth_dst':
'fa:16:3e:4a:79:ce', 'vlan_vid':
6107}),out_group=0,out_port=0,priority=2,table_id=20) timed out: Timeout: 30
seconds
with corresponding errors is ovs-vswitchd logs:
|rconn|ERR|br-tun<->tcp:127.0.0.1:6633: no response to inactivity probe after
5 seconds, disconnecting
|rconn|ERR|br-floating<->tcp:127.0.0.1:6633: no response to inactivity probe
after 5 seconds, disconnecting
|rconn|ERR|br-int<->tcp:127.0.0.1:6633: no response to inactivity probe after
5 seconds, disconnecting
Setting inactivity_probe to a greater value helps:
#ovs-vsctl set controller br-int inactivity_probe=3
#ovs-vsctl set controller br-tun inactivity_probe=3
#ovs-vsctl set controller br-floating inactivity_probe=3
Should neutron allow setting inactivity_probe for controllers?
Should it correspond to of_request_timeout value?
To manage notifications about this bug go to:
[Yahoo-eng-team] [Bug 1821755] [NEW] live migration break the anti-affinity policy of server group simultaneously
Public bug reported: Description === If we live migrate two instance simultaneously, the instances will break the instance group policy. Steps to reproduce == OpenStack env with three compute nodes(node1, node2 and node3). Then we create two VMs(vm1, vm2) with the anti-affinity policy. At last, we live migrate two VMs simultaneously. Before live-migration, the VMs are located as followed: node1 -> vm1 node2 -> vm2 node3 * nova live-migration vm1 * nova live-migration vm2 Expected result === Fail to live migrate vm1 and vm2. Actual result = node1 node2 node3 -> vm1,vm2 Environment === master branch of openstack As described above, the live migration could not check the in-progress live-migration and just select the host by scheduler filter. So that they are migrated to the same host. ** Affects: nova Importance: Undecided Status: New ** Description changed: Description === If we live migrate two instance simultaneously, the instances will break the instance group policy. - Steps to reproduce == - OpenStack env with three compute nodes(node1, node2 and node3). Then we create two VMs(vm1, vm2) - with the anti-affinity policy. + OpenStack env with three compute nodes(node1, node2 and node3). Then we create two VMs(vm1, vm2) with the anti-affinity policy. At last, we live migrate two VMs simultaneously. Before live-migration, the VMs are located as followed: node1 -> vm1 node2 -> vm2 node3 * nova live-migration vm1 * nova live-migration vm2 - Expected result === Fail to live migrate vm1 and vm2. - Actual result = node1 node2 node3 -> vm1,vm2 - Environment === master branch of openstack - - As described above, the live migration could not check the in-progress live-migration and just select the host by scheduler filter. So that they are migrated to the same host. + As described above, the live migration could not check the in-progress + live-migration and just select the host by scheduler filter. So that + they are migrated to the same host. -- 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/1821755 Title: live migration break the anti-affinity policy of server group simultaneously Status in OpenStack Compute (nova): New Bug description: Description === If we live migrate two instance simultaneously, the instances will break the instance group policy. Steps to reproduce == OpenStack env with three compute nodes(node1, node2 and node3). Then we create two VMs(vm1, vm2) with the anti-affinity policy. At last, we live migrate two VMs simultaneously. Before live-migration, the VMs are located as followed: node1 -> vm1 node2 -> vm2 node3 * nova live-migration vm1 * nova live-migration vm2 Expected result === Fail to live migrate vm1 and vm2. Actual result = node1 node2 node3 -> vm1,vm2 Environment === master branch of openstack As described above, the live migration could not check the in-progress live-migration and just select the host by scheduler filter. So that they are migrated to the same host. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1821755/+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 1798184] Re: [SRU] PY3: python3-ldap does not allow bytes for DN/RDN/field names
This is fixed in rocky with keystone version 2:14.0.1-0ubuntu3. ** Changed in: keystone/rocky Status: Fix Committed => 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/1798184 Title: [SRU] PY3: python3-ldap does not allow bytes for DN/RDN/field names Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive rocky series: Fix Released Status in Ubuntu Cloud Archive stein series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) rocky series: Fix Released Status in OpenStack Identity (keystone) stein series: Fix Released Status in ldappool: Fix Released Status in keystone package in Ubuntu: Fix Released Status in python-ldappool package in Ubuntu: Fix Released Status in keystone source package in Cosmic: Fix Committed Status in python-ldappool source package in Cosmic: Fix Committed Status in keystone source package in Disco: Fix Released Status in python-ldappool source package in Disco: Fix Released Bug description: [Impact] Keystone LDAP backend doesn't work for PY3. Under Python 2, python-ldap uses bytes by default. Under Python 3 this is removed and bytes aren't allowed for DN/RDN/field names. More details are here: http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode and here: https://github.com/python-ldap/python-ldap/blob/python-ldap-3.1.0/Lib/ldap/ldapobject.py#L111 == initial traceback == Here's the initial traceback from the failure: https://paste.ubuntu.com/p/67THZb2m5m/ The last bit of the error is: File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 314, in _ldap_call result = func(*args,**kwargs) TypeError: simple_bind() argument 1 must be str or None, not bytes A closer look at func shows: func= args=(b'cn=admin,dc=test,dc=com', b'crapper', None, None) == keystone ldap backend use of python-ldap == In simple_bind_s() of keystone's ldap backend, who and cred are encoded as byte strings: https://github.com/openstack/keystone/blob/14.0.0/keystone/identity/backends/ldap/common.py#L885 but that appears to no longer be valid use of python-ldap for py3. [Test Case] Run charm-keystone-ldap functional tests for OpenStack Rocky or above. [Regression Potential] The only regression potential would be for PY2 code paths. PY3 code paths never worked for keystone's LDAP backend. The approach to the patch have purposefully minimized amount of code required and therefore regression potential for PY2. Note that Rocky for Ubuntu supports PY2 but as of Stein Ubuntu has dropped PY2 support. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1798184/+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 1821654] Re: Neutron Installation Prerequisites. The mysql command cannot execute without parameters
Since we have two contradicting bug reports over the preferred form I'm marking this as Opinion. ** Changed in: neutron Status: New => Opinion ** Changed in: neutron Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1821654 Title: Neutron Installation Prerequisites. The mysql command cannot execute without parameters Status in neutron: Opinion Bug description: In the first step of the prerequisites (https://docs.openstack.org/neutron/rocky/install/controller-install-rdo.html#prerequisites) the first instruction is to connect to the DB Server. The documentation instructs to use command # mysql The command cannot be run as instructed, it should instruct the using of parameters like in the installation of other services e.g. identity, compute: # mysql -u root -p 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: The command will not execute as instructed - [ ] 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: 13.0.3.dev77 on 2019-03-22 23:34 SHA: cfb6e0eb72bcb12cdca76c0baf14df86bd95c272 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-rdo.rst URL: https://docs.openstack.org/neutron/rocky/install/controller-install-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1821654/+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 1821737] [NEW] simple_cell_setup reports "exiting" when it is not
Public bug reported: When running 'nova-manage simple_cell_setup ...' if hosts are already the _map_cell_and_hosts method prints a message of 'All hosts are already mapped to cell(s), exiting.' and then proceeds to map instances. It does not, in fact, exit. This isn't the end of the world, but is somewhat confusing. The easiest fix is probably to get rid of ', exiting'. Then in the multiple paths to the method, the printed message still makes sense and 'exiting' can be implicit. ** Affects: nova Importance: Undecided Status: New ** Tags: cells -- 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/1821737 Title: simple_cell_setup reports "exiting" when it is not Status in OpenStack Compute (nova): New Bug description: When running 'nova-manage simple_cell_setup ...' if hosts are already the _map_cell_and_hosts method prints a message of 'All hosts are already mapped to cell(s), exiting.' and then proceeds to map instances. It does not, in fact, exit. This isn't the end of the world, but is somewhat confusing. The easiest fix is probably to get rid of ', exiting'. Then in the multiple paths to the method, the printed message still makes sense and 'exiting' can be implicit. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1821737/+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 1821733] [NEW] Failed to compute_task_build_instances: local variable 'sibling_set' referenced before assignment
Public bug reported: Reproduced from rhbz#1686511 (https://bugzilla.redhat.com/show_bug.cgi?id=1686511) When spawning an Openstack instance, this error is received: 2019-03-07 08:07:38.499 3124 WARNING nova.scheduler.utils [req-e577cf31-7a58-420f-8ba5-3f962569ab08 0c90c8d8b42c42e883d2135cc733cac4 8b869a98a43e4fc48001e0ff6d149fe6 - - -] Failed to compute_task_build_instances: local variable 'sibling_set' referenced before assignment Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming res = self.dispatcher.dispatch(message) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch return self._do_dispatch(endpoint, method, ctxt, args) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch result = func(ctxt, **new_args) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 199, in inner return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 104, in select_destinations dests = self.driver.select_destinations(ctxt, spec_obj) File "/usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py", line 53, in select_destinations selected_hosts = self._schedule(context, spec_obj) File "/usr/lib/python2.7/site-packages/nova/scheduler/filter_scheduler.py", line 113, in _schedule spec_obj, index=num) File "/usr/lib/python2.7/site-packages/nova/scheduler/host_manager.py", line 576, in get_filtered_hosts hosts, spec_obj, index) File "/usr/lib/python2.7/site-packages/nova/filters.py", line 89, in get_filtered_objects list_objs = list(objs) File "/usr/lib/python2.7/site-packages/nova/filters.py", line 44, in filter_all if self._filter_one(obj, spec_obj): File "/usr/lib/python2.7/site-packages/nova/scheduler/filters/__init__.py", line 44, in _filter_one return self.host_passes(obj, spec) File "/usr/lib/python2.7/site-packages/nova/scheduler/filters/numa_topology_filter.py", line 123, in host_passes pci_stats=host_state.pci_stats)) File "/usr/lib/python2.7/site-packages/nova/virt/hardware.py", line 1297, in numa_fit_instance_to_host host_cell, instance_cell, limits) File "/usr/lib/python2.7/site-packages/nova/virt/hardware.py", line 906, in _numa_fit_instance_cell host_cell, instance_cell) File "/usr/lib/python2.7/site-packages/nova/virt/hardware.py", line 854, in _numa_fit_instance_cell_with_pinning max(map(len, host_cell.siblings))) File "/usr/lib/python2.7/site-packages/nova/virt/hardware.py", line 805, in _pack_instance_onto_cores itertools.chain(*sibling_set))) UnboundLocalError: local variable 'sibling_set' referenced before assignment 2019-03-07 08:07:38.500 3124 WARNING nova.scheduler.utils [req- e577cf31-7a58-420f-8ba5-3f962569ab08 0c90c8d8b42c42e883d2135cc733cac4 8b869a98a43e4fc48001e0ff6d149fe6 - - -] [instance: 5bca186a-5a36-4b0f- 8b7a-f2f3bc168b29] Setting instance to ERROR state. This issues appears to be because of: https://github.com/openstack/nova/blob/da9f9c962fe00dbfc9c8fe9c47e964816d67b773/nova/virt/hardware.py#L875 This works normally because of loop variables in Python are available outside of the scope of the loop: >>> for x in range(5): ... pass ... >>> print(x) 4 and because there's usually something in sibling_sets. However, this is presumably failing for this user because there are no free cores at all on the given host. This is likely the race condition between the nova- scheduler and nova-compute services. ** Affects: nova Importance: Undecided Status: New ** Description changed: - Reproduced from rhbz#1686511. + Reproduced from rhbz#1686511 + (https://bugzilla.redhat.com/show_bug.cgi?id=1686511) When spawning an Openstack instance, this error is received: + 2019-03-07 08:07:38.499 3124 WARNING nova.scheduler.utils [req-e577cf31-7a58-420f-8ba5-3f962569ab08 0c90c8d8b42c42e883d2135cc733cac4 8b869a98a43e4fc48001e0ff6d149fe6 - - -] Failed to compute_task_build_instances: local variable 'sibling_set' referenced before assignment + Traceback (most recent call last): - 2019-03-07 08:07:38.499 3124 WARNING nova.scheduler.utils [req-e577cf31-7a58-420f-8ba5-3f962569ab08 0c90c8d8b42c42e883d2135cc733cac4 8b869a98a43e4fc48001e0ff6d149fe6 - - -] Failed to compute_task_build_instances: local variable 'sibling_set' referenced before assignment - Traceback (most recent call last): + File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming + res = self.dispatcher.dispatch(message) - File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py",
[Yahoo-eng-team] [Bug 1821708] [NEW] neutron-server high cpu usage in host_routes_after_create
Public bug reported: A lot of cpu (17%) of neutron-server is spent in a single function called host_routes_after_create. we should try to optimize this. ** Affects: neutron Importance: Undecided Assignee: Dirk Mueller (dmllr) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1821708 Title: neutron-server high cpu usage in host_routes_after_create Status in neutron: In Progress Bug description: A lot of cpu (17%) of neutron-server is spent in a single function called host_routes_after_create. we should try to optimize this. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1821708/+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 1821288] Re: volume_groups view refers to consistency group index page incorrectly
Reviewed: https://review.openstack.org/645494 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=2d6dfd598c817fc591b463284f85cfa89f9e8f10 Submitter: Zuul Branch:master commit 2d6dfd598c817fc591b463284f85cfa89f9e8f10 Author: Akihiro Motoki Date: Fri Mar 22 16:55:44 2019 +0900 project volume group: Fix incorrect reference to cgroup panel Also fixes the success message of "Clone Group" form. Change-Id: I7ace2529b9fdfcbbd348f9b49f5d9e54497e9def Closes-Bug: #1821288 ** 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/1821288 Title: volume_groups view refers to consistency group index page incorrectly Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The volume_groups view refers to consistency group index page incorrectly. https://github.com/openstack/horizon/blob/1d2145b888af836f4aa69d0ed53c27d4864188de/openstack_dashboard/dashboards/project/volume_groups/views.py#L40 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1821288/+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] Re: Misleading log message "Booting with blank volume" in nova-compute when booting from real volume
Reviewed: https://review.openstack.org/638821 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=3c66b40dbd23e3f792a86da5a15c993c52c9b377 Submitter: Zuul Branch:master commit 3c66b40dbd23e3f792a86da5a15c993c52c9b377 Author: Takashi NATSUME Date: Sat Feb 23 00:56:23 2019 +0900 Override the 'get' method in DriverBlockDevice class The following methods are overridden in DriverBlockDevice class. * __getattr__ * __getitem__ The 'get' method is not overridden. The value cannot be got by the 'get' method though the value can be got by '__getattr__' (e.g. bdm.volumd_id) or '__getitem__' (e.g. bdm['volume_id']) method. So override the 'get' method to fix the issue. Change-Id: Ic665fc1956831110937d98553e526cb909e49997 Closes-Bug: #1816938 ** 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/1816938 Title: Misleading log message "Booting with blank volume" in nova-compute when booting from real volume Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) rocky series: In Progress Status in OpenStack Compute (nova) stein series: In Progress 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=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 1821696] [NEW] Failed to start instances with encrypted volumes
Public bug reported: Description === We hit this bug after doing a complete cluster shutdown due to server room maintenance. The bug is however more easily reproducible. When cold starting an instance with an encrypted volume attached, it fails so start with a VolumeEncryptionNotSupported error. https://github.com/openstack/os- brick/blob/stable/rocky/os_brick/encryptors/cryptsetup.py#L52 Steps to reproduce == * Deploy Openstack with Barbican support using Kolla. * Create an encrypted volume type * Create an encrypted volume * Create an instance and attach the encrypted folder * Enjoy your new instance and volume, install software and store data * In our case, we shut down the entire cluster and restarted it again. First all instances were stopped in Horizon using Shut down instance command. We use Ceph so we then stopped that using these procedures https://ceph.com/planet/how-to-do-a-ceph-cluster-maintenance-shutdown/ and then shut down the compute / storage nodes and then the controller nodes one by one. Then we started the cluster in the reverse order, verified all services were up and running, examined logs and then started the instances. Instances without encrypted volumes started fine. * Instances with encrypted volumes fail to start with VolumeEncryptionNotSupported. Note: It is possible to recreate the problem by using a Hard Reboot (possibly related https://bugs.launchpad.net/nova/+bug/1597234) or by shutting down instances and then restarting all Openstack services on that compute node. Expected results Instances with encrypted volumes should start fine, even after a Hard Reboot or a complete cluster shutdown. Actual results == Instances with encrypted volumes failed to start with VolumeEncryptionNotSupported https://pastebin.com/mvMbJQRb Environment === 1. Openstack version Environment is established by Kolla (Rocky release). 2. Hypervisor KVM on RHEL 3. Storage type Ceph using Kolla (Rocky release) Analysis There seems to be a problem related to this code not behaving as expected: https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/driver.py#L1049 It seems that it is expected that the exception should be ignored and logged, but for some reason, the `ctxt.reraise = False` does not work as expected: self.force_reraise() is called in https://github.com/openstack/oslo.utils/blob/stable/rocky/oslo_utils/excutils.py#L220 which it should not have hit since `reraise` is expected to be `False`. We did some hacking and just swallowed the exception by commenting out the `excutils.save_and_reraise_exception()` section and replacing it with a simple `pass`. Then the instance booted - but it could not boot from the image. But, it was then possible to remove the encrypted volume attachment, reboot the server and then reattach the encrypted volume. ** 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/1821696 Title: Failed to start instances with encrypted volumes Status in OpenStack Compute (nova): New Bug description: Description === We hit this bug after doing a complete cluster shutdown due to server room maintenance. The bug is however more easily reproducible. When cold starting an instance with an encrypted volume attached, it fails so start with a VolumeEncryptionNotSupported error. https://github.com/openstack/os- brick/blob/stable/rocky/os_brick/encryptors/cryptsetup.py#L52 Steps to reproduce == * Deploy Openstack with Barbican support using Kolla. * Create an encrypted volume type * Create an encrypted volume * Create an instance and attach the encrypted folder * Enjoy your new instance and volume, install software and store data * In our case, we shut down the entire cluster and restarted it again. First all instances were stopped in Horizon using Shut down instance command. We use Ceph so we then stopped that using these procedures https://ceph.com/planet/how-to-do-a-ceph-cluster-maintenance-shutdown/ and then shut down the compute / storage nodes and then the controller nodes one by one. Then we started the cluster in the reverse order, verified all services were up and running, examined logs and then started the instances. Instances without encrypted volumes started fine. * Instances with encrypted volumes fail to start with VolumeEncryptionNotSupported. Note: It is possible to recreate the problem by using a Hard Reboot (possibly related https://bugs.launchpad.net/nova/+bug/1597234) or by shutting down instances and then restarting all Openstack services on that compute node. Expected results Instances with encrypted volumes should start fine, even after a Hard Reboot or a complete
[Yahoo-eng-team] [Bug 1819430] Re: unnecessary placement call to fill group mapping during boot
Reviewed: https://review.openstack.org/638711 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=1a89c1d73b8230e437ed0e15656a2606a94926f8 Submitter: Zuul Branch:master commit 1a89c1d73b8230e437ed0e15656a2606a94926f8 Author: Balazs Gibizer Date: Fri Feb 22 11:34:31 2019 +0100 Use Selection object to fill request group mapping To fill the request group - resource provider mapping nova needs to look at the allocation that is made in placement as well as the traits of the used providers. So far these were explicit placement calls. However it turns out that the Selection object already contains the allocation data so one of the extra placement calls can be removed. This patch replaces the GET /allocations/ placement call from conductor build instance codepath with the usage of the Selection.allocation_request json blob. Closes-Bug: #1819430 Change-Id: Iecbee518444bd282ce5f6fd019db41a322f76a83 ** 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/1819430 Title: unnecessary placement call to fill group mapping during boot Status in OpenStack Compute (nova): Fix Released Bug description: To fill the request group - resource provider mapping nova needs to look at the allocation that is made in placement as well as the traits of the used providers. These are explicit placement calls today. However it turns out that the Selection object already contains the allocation data so one of the extra placement call can be removed. This change can lead to a bit better performance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1819430/+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 1750673] Re: The v3 role assignment API should account for different scopes
Reviewed: https://review.openstack.org/639718 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=954b97666937b8ef14fd1510636af4d8e456e918 Submitter: Zuul Branch:master commit 954b97666937b8ef14fd1510636af4d8e456e918 Author: Lance Bragstad Date: Wed Feb 27 15:47:58 2019 + Add role assignment testing for project users This commit adds some scaffolding for testing how user with project role assignments should behave with the role assignment API. Co-Authored-By: Vishakha Agarwal Closes-Bug: 1750673 Change-Id: Iec99b5d6b3aa3015d4410ce94fedc646bc4d6f74 ** 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/1750673 Title: The v3 role assignment API 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. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the user API. This is documented in each patch with FIXMEs [0]. The following acceptance criteria describes how the v3 role assignment API should behave with tokens from multiple scopes. GET /v3/role_assignments - Someone with a system role assignment that passes the check string should be able to list role assignments for any combination of entities in the deployment (system-scoped) - Someone with a domain role assignment that passes the check string should only be able to list role assignment for users and group in the domain they administer, or projects within that domain (domain-scoped) - Someone with a project role assignment that passes the check string should only be able to list role assignments for users and groups that have assignments on the project they administer (project-scoped) [0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/role_assignment.py#L21-L28 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1750673/+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 1817047] Re: 404 requested URL not found in Keystone User Guide
Reviewed: https://review.openstack.org/647606 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=285ad1370e46a9b094864f649824fc446c62f23f Submitter: Zuul Branch:master commit 285ad1370e46a9b094864f649824fc446c62f23f Author: Edgar Magana Date: Mon Mar 25 14:02:23 2019 -0700 Replace URL name to the correct one in Keystone Docs This URL was not updated before. Poiting to the manage-service that has been updated after Rocky. Change-Id: I20676205f93284eb43da6be967199a7c729edcce Closes-Bug: 1817047 ** 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/1817047 Title: 404 requested URL not found in Keystone User Guide Status in OpenStack Identity (keystone): 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: Link generates 404 error. Link text "OpenStack Administrator Guide" points to "https://docs.openstack.org/keystone/latest/admin/cli-keystone-manage- services.html" which doesn't exist any more. at url: https://docs.openstack.org/keystone/rocky/admin/identity- concepts.html Chapter: Identity concepts section: Service management what: the link [OpenStack Administrator Guide] generates a 404 error. --- Release: on 2019-01-07 15:31 SHA: 718f4a9c4c55f5766895eff94eda66d420451235 Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/admin/identity-concepts.rst URL: https://docs.openstack.org/keystone/rocky/admin/identity-concepts.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1817047/+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 1821679] [NEW] On the role page, when a role named admin exists, creating a role named ADMIN fails.
Public bug reported: On the role page, when a role named admin exists, creating a role named ADMIN fails. ** Affects: horizon Importance: Undecided Assignee: pengyuesheng (pengyuesheng) Status: New ** Changed in: horizon Assignee: (unassigned) => pengyuesheng (pengyuesheng) -- 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/1821679 Title: On the role page, when a role named admin exists, creating a role named ADMIN fails. Status in OpenStack Dashboard (Horizon): New Bug description: On the role page, when a role named admin exists, creating a role named ADMIN fails. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1821679/+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
