[Yahoo-eng-team] [Bug 1795548] [NEW] neutron.tests.functional.agent.l3.test_legacy_router.L3AgentTestCase.test_legacy_router_lifecycle* fail
Public bug reported:
I keep seeing these two tests fail:
http://logs.openstack.org/05/606205/2/check/neutron-
functional/66c9475/logs/testr_results.html.gz
Example stack trace:
Traceback (most recent call last):
File "neutron/tests/base.py", line 137, in func
return f(self, *args, **kwargs)
File "neutron/tests/functional/agent/l3/test_legacy_router.py", line 85, in
test_legacy_router_lifecycle
self._router_lifecycle(enable_ha=False, dual_stack=True)
File "neutron/tests/functional/agent/l3/framework.py", line 302, in
_router_lifecycle
self._assert_onlink_subnet_routes(router, ip_versions)
File "neutron/tests/functional/agent/l3/framework.py", line 526, in
_assert_onlink_subnet_routes
namespace=ns_name)
File "neutron/agent/linux/ip_lib.py", line 1030, in get_routing_table
return list(privileged.get_routing_table(ip_version, namespace))
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_privsep/priv_context.py",
line 207, in _wrap
return self.channel.remote_call(name, args, kwargs)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_privsep/daemon.py",
line 202, in remote_call
raise exc_type(*result[2])
KeyError
I think the problem is that in the privsep get_routing_table code, one
of the IPv6 routes does not have an integer in the route['oif'] element,
it is None, raising the KeyError.
For example, here is a list of IPv6 routes on my local system:
--> ip -6 r
2601:18f:700:c12d::/64 dev enp0s31f6 proto ra metric 100 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
default via fe80::9ade:d0ff:fe25:7710 dev enp0s31f6 proto static metric 100
pref medium
But a little test program I wrote shows iproute2 returns no 'oif':
dst: fe80::/64
gateway: None
oif: None
Traceback (most recent call last):
File "", line 1, in
File "./getroute.py", line 78, in foo
routes = list(get_routing_table(6))
File "./getroute.py", line 50, in get_routing_table
print 'interface: %s' % ipdb_interfaces[route['oif']]['ifname']
KeyError: None
Digging further, since there are two routes to fe80::/64, it's returned
differently from pyroute2:
{'metrics': {}, 'dst_len': 64, 'family': 10, 'proto': 2, 'tos': 0,
'dst': 'fe80::/64', 'pref': '00', 'ipdb_priority': 0, 'priority': 256,
'flags': 0, 'encap': {}, 'src_len': 0, 'table': 254, 'multipath':
({'oif': 2, 'family': 10}, {'oif': 6, 'dst_len': 64, 'family': 10,
'proto': 2, 'tos': 0, 'pref': '00', 'priority': 256, 'flags': 0,
'encap': {}, 'src_len': 0, 'table': 254, 'type': 1, 'scope': 0}),
'type': 1, 'scope': 0, 'ipdb_scope': 'system'}
So it looks like we need to parse this 'multipath' element, but there
are two items in the list, so we have to parse them both.
** Affects: neutron
Importance: High
Assignee: Brian Haley (brian-haley)
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/1795548
Title:
neutron.tests.functional.agent.l3.test_legacy_router.L3AgentTestCase.test_legacy_router_lifecycle*
fail
Status in neutron:
New
Bug description:
I keep seeing these two tests fail:
http://logs.openstack.org/05/606205/2/check/neutron-
functional/66c9475/logs/testr_results.html.gz
Example stack trace:
Traceback (most recent call last):
File "neutron/tests/base.py", line 137, in func
return f(self, *args, **kwargs)
File "neutron/tests/functional/agent/l3/test_legacy_router.py", line 85, in
test_legacy_router_lifecycle
self._router_lifecycle(enable_ha=False, dual_stack=True)
File "neutron/tests/functional/agent/l3/framework.py", line 302, in
_router_lifecycle
self._assert_onlink_subnet_routes(router, ip_versions)
File "neutron/tests/functional/agent/l3/framework.py", line 526, in
_assert_onlink_subnet_routes
namespace=ns_name)
File "neutron/agent/linux/ip_lib.py", line 1030, in get_routing_table
return list(privileged.get_routing_table(ip_version, namespace))
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_privsep/priv_context.py",
line 207, in _wrap
return self.channel.remote_call(name, args, kwargs)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_privsep/daemon.py",
line 202, in remote_call
raise exc_type(*result[2])
KeyError
I think the problem is that in the privsep get_routing_table code, one
of the IPv6 routes does not have an integer in the route['oif']
element, it is None, raising the KeyError.
For example, here is a list of IPv6 routes on my local system:
--> ip -6 r
2601:18f:700:c12d::/64 dev enp0s31f6 proto ra metric 100 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto
[Yahoo-eng-team] [Bug 1778771] Re: Backups panel is visible even if enable_backup is False
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Also affects: horizon (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: horizon (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: horizon (Ubuntu Bionic)
Status: New => Triaged
** Changed in: horizon (Ubuntu Cosmic)
Status: New => Triaged
** Changed in: horizon (Ubuntu Bionic)
Importance: Undecided => High
** Changed in: horizon (Ubuntu Cosmic)
Importance: Undecided => High
--
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/1778771
Title:
Backups panel is visible even if enable_backup is False
Status in OpenStack openstack-dashboard charm:
In Progress
Status in Ubuntu Cloud Archive:
Triaged
Status in Ubuntu Cloud Archive queens series:
Triaged
Status in Ubuntu Cloud Archive rocky series:
Triaged
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in horizon package in Ubuntu:
Triaged
Status in horizon source package in Bionic:
Triaged
Status in horizon source package in Cosmic:
Triaged
Bug description:
Hi,
Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
{'enable_backup': False} in local_settings.py
Meanwhile setting enable_backup to false removes an option to create
backup of a volume in the volume drop-down options. But panel with
backups itself stays visible for both admins and users.
As a work-around I use the following customization script:
import horizon
from django.conf import settings
if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
project = horizon.get_dashboard("project")
backup = project.get_panel("backups")
project.unregister(backup.__class__)
And for permanent fix I see the following decision. In
openstack_dashboard/dashboards/project/backups/panel.py make the following
changes:
...
+L16: from django.conf import settings
...
+L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
+L22: return False
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1778771/+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 1753585] Re: LDAP user name attribute is case sensitive
Reviewed: https://review.openstack.org/603345 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=816b472a9d20e4e7cfe33f2f40ef5daae590795e Submitter: Zuul Branch:master commit 816b472a9d20e4e7cfe33f2f40ef5daae590795e Author: Vishakha Agarwal Date: Tue Sep 18 15:17:07 2018 +0530 LDAP attribute names non-case-sensitive keystone was not able to find any users while the LDAP user name attribute was configured to "samaccountname", but could find users when reconfigured to use "sAMAccountName". LDAP is not supposed to be case-sensitive, so either should work. This patch addresses the above problem by making both the attributes into lower case. Also updated the ldap_result example supporting python3. Change-Id: I51813ac41489baed04f3cadbccd748e03025313e Closes-Bug: #1753585 ** 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/1753585 Title: LDAP user name attribute is case sensitive Status in OpenStack Identity (keystone): Fix Released Bug description: keystone was not able to find any users while the LDAP user name attribute was configured to "samaccountname", but could find users when reconfigured to use "sAMAccountName". LDAP is not supposed to be case-sensitive, so either should work. This appears to be a result of https://github.com/openstack/keystone/blob/12.0.0.0rc2/keystone/identity/backends/ldap/common.py#L1403 looking for that attribute in a case-sensitive manner, though there may be other places as well. found in: Pike To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1753585/+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 1795508] [NEW] cloud-init clean from within /var/lib/cloud-init/instance
Public bug reported:
Attempted to cloud-init clean from a directory clean will remove:
/var/lib/cloud/instance# cloud-init clean --logs --reboot
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 9, in
load_entry_point('cloud-init==18.3', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 904, in main
get_uptime=True, func=functor, args=(name, args))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2514, in
log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/clean.py", line 81, in
handle_clean_args
exit_code = remove_artifacts(args.remove_logs, args.remove_seed)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/clean.py", line 75, in
remove_artifacts
return 1
File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__
next(self.gen)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 832, in chdir
os.chdir(curr)
FileNotFoundError: [Errno 2] No such file or directory:
'/var/lib/cloud/instances/ce3aca12-4e37-4ef9-bc51-170db3d25881'
** 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/1795508
Title:
cloud-init clean from within /var/lib/cloud-init/instance
Status in cloud-init:
New
Bug description:
Attempted to cloud-init clean from a directory clean will remove:
/var/lib/cloud/instance# cloud-init clean --logs --reboot
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 9, in
load_entry_point('cloud-init==18.3', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 904, in
main
get_uptime=True, func=functor, args=(name, args))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2514, in
log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/clean.py", line 81, in
handle_clean_args
exit_code = remove_artifacts(args.remove_logs, args.remove_seed)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/clean.py", line 75, in
remove_artifacts
return 1
File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__
next(self.gen)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 832, in chdir
os.chdir(curr)
FileNotFoundError: [Errno 2] No such file or directory:
'/var/lib/cloud/instances/ce3aca12-4e37-4ef9-bc51-170db3d25881'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1795508/+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 1795502] [NEW] running nova-api-wsgi from the command line fails in python3.6
Public bug reported: The nova-api-wsgi script provides a quick and easy way to run the nova- api from the command line. In at least python3.6 it fails with: ERROR nova Traceback (most recent call last): ERROR nova File "/usr/local/bin/nova-api-wsgi", line 50, in ERROR nova server.serve_forever() ERROR nova File "/usr/lib/python3.6/socketserver.py", line 232, in serve_forever ERROR nova with _ServerSelector() as selector: ERROR nova File "/usr/lib/python3.6/selectors.py", line 348, in __init__ ERROR nova self._poll = select.poll() ERROR nova AttributeError: module 'select' has no attribute 'poll' ERROR nova this is because eventlet is being monkey patched too late, see https://stackoverflow.com/questions/51524589/attributeerror-module- select-has-no-attribute-poll importing eventlet at the top of the script fixes it. It's not clear this is necessarily worth fixing, as running nova-api this way is not really a thing. I only did because I was trying to confirm that a problem was not the result of uwsgi. But report it for sake of discussion. ** Affects: nova Importance: Undecided Status: New ** Tags: api -- 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/1795502 Title: running nova-api-wsgi from the command line fails in python3.6 Status in OpenStack Compute (nova): New Bug description: The nova-api-wsgi script provides a quick and easy way to run the nova-api from the command line. In at least python3.6 it fails with: ERROR nova Traceback (most recent call last): ERROR nova File "/usr/local/bin/nova-api-wsgi", line 50, in ERROR nova server.serve_forever() ERROR nova File "/usr/lib/python3.6/socketserver.py", line 232, in serve_forever ERROR nova with _ServerSelector() as selector: ERROR nova File "/usr/lib/python3.6/selectors.py", line 348, in __init__ ERROR nova self._poll = select.poll() ERROR nova AttributeError: module 'select' has no attribute 'poll' ERROR nova this is because eventlet is being monkey patched too late, see https://stackoverflow.com/questions/51524589/attributeerror-module- select-has-no-attribute-poll importing eventlet at the top of the script fixes it. It's not clear this is necessarily worth fixing, as running nova-api this way is not really a thing. I only did because I was trying to confirm that a problem was not the result of uwsgi. But report it for sake of discussion. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1795502/+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 1794919] Re: [RFE] To decide create port with specific IP version
I agree with Slaweq. According to the API guide:
If you specify only a subnet ID, OpenStack Networking allocates an
available IP from that subnet to the port.
This approach is more flexible, because it allows you to declare whether
you want IPv4, IPv6, or both depending on which you select.
Please let me know what functionality you find that is not satisfied by
this approach.
** Changed in: neutron
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1794919
Title:
[RFE] To decide create port with specific IP version
Status in neutron:
Opinion
Bug description:
Recently bug:
https://bugs.launchpad.net/neutron/+bug/1752903
and the fix https://review.openstack.org/#/c/599494/
are trying to create floating IP only including IPv4 version.
For now, if the public network has both IPv4 and IPv6 subnet
the floating IP (port) may have both v4 and v6 addresses.
Furthermore, not only the public network, for tenant network
the default behavior is also to create one port with both v4 and v6 IP addr.
Here are some test:
http://paste.openstack.org/show/731054/
So, this RFE raises a new approach to the port create API,
when user try to create the port, they can decide which IP version to use.
something like this:
curl POST http://neutron_url/ports -d
'{"port": {
"subnet_id": ,
"ip_version":
}
}'
So for the ml2 plugin, the IPAM can pick both/only v4/only v6 version
of subnet to use.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1794919/+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 1795487] [NEW] Warning Message in Logs about Region UUID
Public bug reported: When using a Region name on the CLI, Logs show: "UserWarning: Invalid uuid: RegionOne." As explained by cmurphy, this is because the UUID is looked for before looking for the name. Officially reporting bug for kmalloc ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1795487 Title: Warning Message in Logs about Region UUID Status in OpenStack Identity (keystone): New Bug description: When using a Region name on the CLI, Logs show: "UserWarning: Invalid uuid: RegionOne." As explained by cmurphy, this is because the UUID is looked for before looking for the name. Officially reporting bug for kmalloc To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1795487/+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 1795482] [NEW] Deleting network namespaces sometimes fails in check/gate queue with ENOENT
Public bug reported: I have seen the fullstack tests sometimes fail, complaining that the namespace doesn't exist. An example is here: http://logs.openstack.org/79/604179/1/check/neutron-fullstack- python36/9b41cd5/logs/testr_results.html.gz End of stack trace for reference: File "/opt/stack/new/neutron/neutron/tests/fullstack/resources/process.py", line 354, in clean_dhcp_namespaces ip_lib.delete_network_namespace(namespace) File "/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 1103, in delete_network_namespace privileged.remove_netns(namespace, **kwargs) File "/opt/stack/new/neutron/.tox/dsvm-fullstack-python35/lib/python3.5/site-packages/oslo_privsep/priv_context.py", line 207, in _wrap return self.channel.remote_call(name, args, kwargs) File "/opt/stack/new/neutron/.tox/dsvm-fullstack-python35/lib/python3.5/site-packages/oslo_privsep/daemon.py", line 202, in remote_call raise exc_type(*result[2]) FileNotFoundError: [Errno 2] No such file or directory While some callers check for RuntimeError, none check for this OSError errno.ENOENT case. In this case, I don't believe we should be returning an error at all, since an asynchronous event could have deleted the namespace, and since it's no longer there we are in the desired state. This will help with some of the recent issues we've had getting code merged. ** Affects: neutron Importance: High Assignee: Brian Haley (brian-haley) 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/1795482 Title: Deleting network namespaces sometimes fails in check/gate queue with ENOENT Status in neutron: In Progress Bug description: I have seen the fullstack tests sometimes fail, complaining that the namespace doesn't exist. An example is here: http://logs.openstack.org/79/604179/1/check/neutron-fullstack- python36/9b41cd5/logs/testr_results.html.gz End of stack trace for reference: File "/opt/stack/new/neutron/neutron/tests/fullstack/resources/process.py", line 354, in clean_dhcp_namespaces ip_lib.delete_network_namespace(namespace) File "/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 1103, in delete_network_namespace privileged.remove_netns(namespace, **kwargs) File "/opt/stack/new/neutron/.tox/dsvm-fullstack-python35/lib/python3.5/site-packages/oslo_privsep/priv_context.py", line 207, in _wrap return self.channel.remote_call(name, args, kwargs) File "/opt/stack/new/neutron/.tox/dsvm-fullstack-python35/lib/python3.5/site-packages/oslo_privsep/daemon.py", line 202, in remote_call raise exc_type(*result[2]) FileNotFoundError: [Errno 2] No such file or directory While some callers check for RuntimeError, none check for this OSError errno.ENOENT case. In this case, I don't believe we should be returning an error at all, since an asynchronous event could have deleted the namespace, and since it's no longer there we are in the desired state. This will help with some of the recent issues we've had getting code merged. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1795482/+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 1793193] Re: A locked user triggers an exception
wont fix upstream. based on Robert's aggrement. ** Changed in: cloud-init Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1793193 Title: A locked user triggers an exception Status in cloud-init: Won't Fix Bug description: When a user is already locked an exception is propagated and no further action is taken. However, if the user is already locked we have the condition we want and thus cloud-init should proceed. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1793193/+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 1795432] [NEW] neutron does not create the necessary iptables rules for dhcp agents when linuxbridge is used
Public bug reported: Reproduction: Create a enviroment with controller and compute in different hosts: controller: [root@controller1 ~]# brctl show bridge name bridge id STP enabled interfaces brq37841a31-d7 8000.0a7e069299a3 no tap80087b5b-33 tap94526e09-2c vxlan-46 brqbab8fb94-c8 8000.1275449f51ef no eth3 tap4baecbed-83 tap8924b588-55 [root@controller1 ~]# ip netns qrouter-bcb8c407-ab4c-4916-89a5-d1ba8ac786ae (id: 2) qdhcp-37841a31-d744-4c9f-b084-37cfaafe71ca (id: 1) qdhcp-bab8fb94-c849-4c6c-ada7-98ec9bc33b87 (id: 0) Compute host: [root@compute1 ~]# brctl show bridge name bridge id STP enabled interfaces brq37841a31-d7 8000.5e530dd5073b no tap171ccdb9-66 vxlan-46 brqbab8fb94-c8 8000.525400fec4c7 no eth3 tap80b3e489-a6 tapfec914c0-0e virbr0 8000.525400ed85d9 yes virbr0-nic [root@compute1 ~]# virsh list IdName State 28instance-002f running 39instance-0044 running 41instance-0047 running Then when dhcp namespace and vms are in different hosts, dhcp traffic(in provider and selfservice network mode) is dropped in the controller bridge. Because no rule for permiting that the dhcp reply goes out of the controller: Iptables: -A neutron-filter-top -j neutron-linuxbri-local -A neutron-linuxbri-FORWARD -m physdev --physdev-out tap4baecbed-83 --physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT -A neutron-linuxbri-FORWARD -m physdev --physdev-out tap80087b5b-33 --physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT -A neutron-linuxbri-FORWARD -m physdev --physdev-out tap94526e09-2c --physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT -A neutron-linuxbri-FORWARD -m physdev --physdev-out tap8924b588-55 --physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT interfaces: [root@controller1 ~]# ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:d6:e9:8f brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:7a:23:a5 brd ff:ff:ff:ff:ff:ff 4: eth2: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:5f:07:d9 brd ff:ff:ff:ff:ff:ff 28: eth3: mtu 1500 qdisc pfifo_fast master brqbab8fb94-c8 state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:b2:b7:bc brd ff:ff:ff:ff:ff:ff 30: tap4baecbed-83@if2: mtu 1500 qdisc noqueue master brqbab8fb94-c8 state UP mode DEFAULT group default qlen 1000 link/ether c6:e3:d5:e8:49:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0 31: brqbab8fb94-c8: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 12:75:44:9f:51:ef brd ff:ff:ff:ff:ff:ff 32: tap80087b5b-33@if2: mtu 1450 qdisc noqueue master brq37841a31-d7 state UP mode DEFAULT group default qlen 1000 link/ether 0a:7e:06:92:99:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 1 33: vxlan-46: mtu 1450 qdisc noqueue master brq37841a31-d7 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 92:6d:dd:cd:ab:43 brd ff:ff:ff:ff:ff:ff 34: brq37841a31-d7: mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 0a:7e:06:92:99:a3 brd ff:ff:ff:ff:ff:ff 35: tap94526e09-2c@if2: mtu 1450 qdisc noqueue master brq37841a31-d7 state UP mode DEFAULT group default qlen 1000 link/ether fe:a4:58:9e:52:2f brd ff:ff:ff:ff:ff:ff link-netnsid 2 36: tap8924b588-55@if3: mtu 1500 qdisc noqueue master brqbab8fb94-c8 state UP mode DEFAULT group default qlen 1000 link/ether 12:75:44:9f:51:ef brd ff:ff:ff:ff:ff:ff link-netnsid 2 Only rules for the tap ports. It is necessary add rules to permit dhcp traffic between hosts, for example permit dhcp ports as dev-in: -A neutron-linuxbri-FORWARD -m physdev --physdev-in tap4baecbed-83 --physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT -A neutron-linuxbri-FORWARD -m physdev --physdev-in tap80087b5b-33 --physdev-is-bridged -m comment --comment "Accept all packets when port
[Yahoo-eng-team] [Bug 1795415] Re: Verify operation in keystone
*** This bug is a duplicate of bug 1790148 *** https://bugs.launchpad.net/bugs/1790148 ** This bug has been marked a duplicate of bug 1790148 Verify operation in keystone (Documentation fault) -- 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/1795415 Title: Verify operation in keystone Status in OpenStack Identity (keystone): New Bug description: - [X] This doc is inaccurate in this way: In point 2, it is suggested to run openstack --os-auth-url http://controller:35357/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue However, the endpoint has been configured on port 5000 previously. This is a sort of garbage inherited from previous OpenStack versions where "keystone needed to be run on two separate ports to accomodate the Identity v2 API which ran a separate admin-only service commonly on port 35357." - [X] I have a fix to the document that I can paste below including example: Replace the previous command with openstack --os-auth-url http://controller:5000/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue Take care! Francesco --- Release: on 2018-09-10 22:19 SHA: c5930abc5aa06881f28baa697d8d43a1f25157b8 Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-rdo.rst URL: https://docs.openstack.org/keystone/rocky/install/keystone-verify-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1795415/+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 1795425] [NEW] create server api sends location header as bytestring in py3
Public bug reported: PEP points out that request and response headers, inside a WSGI application, should be native strings. That is: whatever `str` is in the version of Python being used: https://www.python.org/dev/peps/pep-/#a-note-on-string-types The create server api returns a location header which is encoded to UTF-8 in python, making it a bytestring in python3. This violates the spec but also leads to issues when testing nova under wsgi-intercept (which removes whatever normalisation most WSGI servers helpfully do for "bad" applications). The issues show up when concatenating the response header with other values, such as base URLs. ** Affects: nova Importance: Undecided Assignee: Chris Dent (cdent) Status: In Progress ** Tags: api -- 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/1795425 Title: create server api sends location header as bytestring in py3 Status in OpenStack Compute (nova): In Progress Bug description: PEP points out that request and response headers, inside a WSGI application, should be native strings. That is: whatever `str` is in the version of Python being used: https://www.python.org/dev/peps/pep-/#a-note-on-string-types The create server api returns a location header which is encoded to UTF-8 in python, making it a bytestring in python3. This violates the spec but also leads to issues when testing nova under wsgi-intercept (which removes whatever normalisation most WSGI servers helpfully do for "bad" applications). The issues show up when concatenating the response header with other values, such as base URLs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1795425/+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 1795415] [NEW] Verify operation in keystone
Public bug reported: - [X] This doc is inaccurate in this way: In point 2, it is suggested to run openstack --os-auth-url http://controller:35357/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue However, the endpoint has been configured on port 5000 previously. This is a sort of garbage inherited from previous OpenStack versions where "keystone needed to be run on two separate ports to accomodate the Identity v2 API which ran a separate admin-only service commonly on port 35357." - [X] I have a fix to the document that I can paste below including example: Replace the previous command with openstack --os-auth-url http://controller:5000/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue Take care! Francesco --- Release: on 2018-09-10 22:19 SHA: c5930abc5aa06881f28baa697d8d43a1f25157b8 Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-rdo.rst URL: https://docs.openstack.org/keystone/rocky/install/keystone-verify-rdo.html ** Affects: keystone Importance: Undecided Status: New ** Tags: doc -- 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/1795415 Title: Verify operation in keystone Status in OpenStack Identity (keystone): New Bug description: - [X] This doc is inaccurate in this way: In point 2, it is suggested to run openstack --os-auth-url http://controller:35357/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue However, the endpoint has been configured on port 5000 previously. This is a sort of garbage inherited from previous OpenStack versions where "keystone needed to be run on two separate ports to accomodate the Identity v2 API which ran a separate admin-only service commonly on port 35357." - [X] I have a fix to the document that I can paste below including example: Replace the previous command with openstack --os-auth-url http://controller:5000/v3 \ --os-project-domain-name Default --os-user-domain-name Default \ --os-project-name admin --os-username admin token issue Take care! Francesco --- Release: on 2018-09-10 22:19 SHA: c5930abc5aa06881f28baa697d8d43a1f25157b8 Source: https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-verify-rdo.rst URL: https://docs.openstack.org/keystone/rocky/install/keystone-verify-rdo.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1795415/+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 1713499] Re: Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU
** Also affects: cloud-archive/queens Importance: Undecided Status: New ** Also affects: cloud-archive/pike 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/1713499 Title: Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive pike series: New Status in Ubuntu Cloud Archive queens series: New Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Bionic: In Progress Bug description: Currently, the neutron API returns an error [1] when trying to delete a neutron network which has a higher MTU than the configured MTU[2][3]. This issue has been noticed in Pike. [1] Error: http://paste.openstack.org/show/619627/ [2] neutron.conf: http://paste.openstack.org/show/619629/ [3] ml2_conf.ini: http://paste.openstack.org/show/619630/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1713499/+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 1778771] Re: Backups panel is visible even if enable_backup is False
** Also affects: cloud-archive/queens
Importance: Undecided
Status: New
** Also affects: cloud-archive/rocky
Importance: Undecided
Status: New
--
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/1778771
Title:
Backups panel is visible even if enable_backup is False
Status in OpenStack openstack-dashboard charm:
In Progress
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive queens series:
New
Status in Ubuntu Cloud Archive rocky series:
New
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
Hi,
Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
{'enable_backup': False} in local_settings.py
Meanwhile setting enable_backup to false removes an option to create
backup of a volume in the volume drop-down options. But panel with
backups itself stays visible for both admins and users.
As a work-around I use the following customization script:
import horizon
from django.conf import settings
if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
project = horizon.get_dashboard("project")
backup = project.get_panel("backups")
project.unregister(backup.__class__)
And for permanent fix I see the following decision. In
openstack_dashboard/dashboards/project/backups/panel.py make the following
changes:
...
+L16: from django.conf import settings
...
+L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
+L22: return False
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1778771/+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 1713499] Re: Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU
** Changed in: cloud-archive Status: New => 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/1713499 Title: Cannot delete a neutron network, if the currently configured MTU is lower than the network's MTU Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive pike series: New Status in Ubuntu Cloud Archive queens series: New Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Bionic: In Progress Bug description: Currently, the neutron API returns an error [1] when trying to delete a neutron network which has a higher MTU than the configured MTU[2][3]. This issue has been noticed in Pike. [1] Error: http://paste.openstack.org/show/619627/ [2] neutron.conf: http://paste.openstack.org/show/619629/ [3] ml2_conf.ini: http://paste.openstack.org/show/619630/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1713499/+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 1761140] Re: [SRU] dpkg eror processing package nova-compute
Verified successfully on bionic-proposed: root@b1:~# sudo apt install nova-compute ... root@b1:~# apt policy nova-compute nova-compute: Installed: 2:17.0.5-0ubuntu2 Candidate: 2:17.0.5-0ubuntu2 Version table: *** 2:17.0.5-0ubuntu2 500 500 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 2:17.0.5-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 2:17.0.1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages ** Changed in: cloud-archive/rocky Status: Triaged => Fix Released ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1761140 Title: [SRU] dpkg eror processing package nova-compute Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive mitaka series: Fix Committed Status in Ubuntu Cloud Archive ocata series: Fix Released Status in Ubuntu Cloud Archive pike series: Fix Released Status in Ubuntu Cloud Archive queens series: Fix Committed Status in Ubuntu Cloud Archive rocky series: Fix Released Status in OpenStack Compute (nova): Invalid Status in nova package in Ubuntu: Fix Released Status in nova source package in Xenial: Fix Committed Status in nova source package in Bionic: Fix Committed Status in nova source package in Cosmic: Fix Released Bug description: [Impact] Hello! I've encountered the bug while installing Nova on compute nodes: ... Setting up qemu-system-x86 (1:2.11+dfsg-1ubuntu5~cloud0) ... Setting up qemu-kvm (1:2.11+dfsg-1ubuntu5~cloud0) ... Setting up qemu-utils (1:2.11+dfsg-1ubuntu5~cloud0) ... Setting up python-keystone (2:13.0.0-0ubuntu1~cloud0) ... Processing triggers for initramfs-tools (0.122ubuntu8.11) ... update-initramfs: Generating /boot/initrd.img-4.4.0-116-generic Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user `nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. dpkg: error processing package nova-compute-kvm (--configure): dependency problems - leaving unconfigured Setting up python-os-brick (2.3.0-0ubuntu1~cloud0) ... No apport report written because the error message indicates its a followup error from a previous failure. Setting up python-nova (2:17.0.1-0ubuntu1~cloud0) ... Setting up nova-common (2:17.0.1-0ubuntu1~cloud0) ... Setting up nova-compute (2:17.0.1-0ubuntu1~cloud0) ... Processing triggers for libc-bin (2.23-0ubuntu10) ... Processing triggers for systemd (229-4ubuntu21.2) ... Processing triggers for ureadahead (0.100.0-19) ... Processing triggers for dbus (1.10.6-1ubuntu3.3) ... Errors were encountered while processing: nova-compute-libvirt nova-compute-kvm ... Installation failed when executing 'post-installation script'. After some investigation I've found out that if I've create 'nova' user BEFORE running package installation, it's will be succeded. [Test Case] Steps to reproduce -- 1. Prepare the node for installing nova-compute packages 2. Run 'apt-get install nova-compute' Expected result -- Nova-compute installed successfully without errors Actual result -- Installation failed with dpkg error Workaround -- 1. Create system user: add to /etc/passwd nova:x:64060:64060::/var/lib/nova:/bin/false 2. Create system group: add to /etc/group nova:x:64060: 3. Run 'apt-get install nova-compute' My Environment -- Ubuntu 16.04.4 LTS, 4.4.0-116-generic Openstack Queens Release Nova 17.0.1-0ubuntu1 [Regression Potential] Should be very low. This is a very minor dependency chain to prevent a dependency circular loop. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1761140/+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 1795389] Re: The redirect for python-novaclient does not work well
This is something the nova team need to change in their repo if they want those redirects. ** Changed in: openstack-manuals Status: New => Won't Fix ** Also 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/1795389 Title: The redirect for python-novaclient does not work well Status in OpenStack Compute (nova): New Status in openstack-manuals: Won't Fix Bug description: In Pike release note (*1) for python-novaclient, there is the following URL. * https://docs.openstack.org/developer/python-novaclient/api.html (Expected) https://docs.openstack.org/developer/python-novaclient/api.html is redirect to https://docs.openstack.org/python-novaclient/latest/api.html . (Actual) https://docs.openstack.org/developer/python-novaclient/api.html is redirect to https://docs.openstack.org/python-novaclient/latest/ NOTE: https://docs.openstack.org/python-novaclient/latest/api.html is redirected to https://docs.openstack.org/python-novaclient/latest/reference/api/index.html because of the redirect settings in python-novaclient. *1: https://docs.openstack.org/releasenotes/python- novaclient/pike.html#relnotes-9-0-0-stable-pike To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1795389/+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 1661772] Re: nova placement problems with low compute node storage available
** Changed in: nova Status: Expired => 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/1661772 Title: nova placement problems with low compute node storage available Status in OpenStack nova-cloud-controller charm: Invalid Status in OpenStack Compute (nova): New Status in nova-cloud-controller package in Juju Charms Collection: Invalid Bug description: Nova-scheduler cannot identify placement host when raw image size is greater than available local storage, even when using raw image, show_image_direct_url=1, and ceph ephemeral storage, such that glance images would never land on local node storage. Have following configuration for glance: juju config glance api-config-flags='show_image_direct_url=true' juju config glance registry-config-flags='show_image_direct_url=true' Worked around issue by allowing storage over-commit using: juju config nova-cloud-controller config-flags="disk_allocation_ratio=5.0" This is workaround is not ideal when working with qcow images which will require local nova-compute node storage for raw conversion. nova-cloud-controller and nova-compute logs attached To manage notifications about this bug go to: https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1661772/+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 1778771] Re: Backups panel is visible even if enable_backup is False
** Also affects: cloud-archive
Importance: Undecided
Status: New
--
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/1778771
Title:
Backups panel is visible even if enable_backup is False
Status in OpenStack openstack-dashboard charm:
In Progress
Status in Ubuntu Cloud Archive:
New
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
Hi,
Volumes - Backup panel is visible even if OPENSTACK_CINDER_FEATURES =
{'enable_backup': False} in local_settings.py
Meanwhile setting enable_backup to false removes an option to create
backup of a volume in the volume drop-down options. But panel with
backups itself stays visible for both admins and users.
As a work-around I use the following customization script:
import horizon
from django.conf import settings
if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
project = horizon.get_dashboard("project")
backup = project.get_panel("backups")
project.unregister(backup.__class__)
And for permanent fix I see the following decision. In
openstack_dashboard/dashboards/project/backups/panel.py make the following
changes:
...
+L16: from django.conf import settings
...
+L21: if not getattr(settings, 'OPENSTACK_CINDER_FEATURES',
{}).get('enable_backup', False):
+L22: return False
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1778771/+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 1795320] [NEW] "Unable to retrieve list of volumes." and "Unable to retrieve volume snapshots."
Public bug reported: Horizon 14.0.0 When i try to create instance or volume in Horizon as regular user i get follow errors: "Unable to retrieve list of volumes." and "Unable to retrieve volume snapshots." Under admin user everything is fine. Developer tools in Chrome shows this: https://i.imgur.com/FzJCQrb.png https://i.imgur.com/FFFcwfN.png https://i.imgur.com/YbU0Pho.png In responce this - "Invalid filters bootable,status are found in query options. (HTTP 400)" and Invalid filters status are found in query options. (HTTP 400)" ** Affects: horizon Importance: Undecided Status: New ** Tags: cinder horizon -- 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/1795320 Title: "Unable to retrieve list of volumes." and "Unable to retrieve volume snapshots." Status in OpenStack Dashboard (Horizon): New Bug description: Horizon 14.0.0 When i try to create instance or volume in Horizon as regular user i get follow errors: "Unable to retrieve list of volumes." and "Unable to retrieve volume snapshots." Under admin user everything is fine. Developer tools in Chrome shows this: https://i.imgur.com/FzJCQrb.png https://i.imgur.com/FFFcwfN.png https://i.imgur.com/YbU0Pho.png In responce this - "Invalid filters bootable,status are found in query options. (HTTP 400)" and Invalid filters status are found in query options. (HTTP 400)" To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1795320/+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 1795309] [NEW] server group
Public bug reported: I was logged out after creating new server group in Horizon 14.0.0.0rc2.dev93 when number of instances and server gruop's quota was same as 10. ** Affects: horizon Importance: Undecided Status: New -- 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/1795309 Title: server group Status in OpenStack Dashboard (Horizon): New Bug description: I was logged out after creating new server group in Horizon 14.0.0.0rc2.dev93 when number of instances and server gruop's quota was same as 10. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1795309/+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
