[Yahoo-eng-team] [Bug 1704398] Re: Inheriting trunk subport segmentation details leaks information
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1704398 Title: Inheriting trunk subport segmentation details leaks information Status in neutron: Expired Status in OpenStack Security Advisory: Won't Fix Bug description: The following information is discoverable for non-admin users of neutron despite the policy: * the segmentation type and id of all vlan based networks * the segmentation type of all non-vlan based networks Reproduction: configuration) [[local|localrc]] enable_plugin neutron ... enable_service q-trunk versions) devstack b79531a9f96736225a8991052a0be5767c217377 neutron 3a894d0b9e8e71bf7ee7e42350685065df5a8b3c 1) for vlan networks source openrc admin demo openstack network create net0 --provider-network-type vlan --provider-physical-network test --provider-segment 100 openstack network create net1 --provider-network-type vlan --provider-physical-network test --provider-segment 101 source openrc demo demo openstack port create port0 --network net0 openstack port create port1 --network net1 openstack network trunk create trunk0 --parent-port port0 openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit # demo user has no right to see segmentation type and id of vlan provider net openstack network show net1 # but both the type and id are available in the subport list openstack network subport list --trunk trunk0 2) for other network types source openrc admin demo openstack network create net0 openstack network create net1 source openrc demo demo openstack port create port0 --network net0 openstack port create port1 --network net1 openstack network trunk create trunk0 --parent-port port0 # the type of net1 comes back in the error message (in my environment 'vxlan') openstack network trunk set trunk0 --subport port=port1,segmentation-type=inherit While according to the default policy this information should be admin-only. See around here: https://github.com/openstack/neutron/blob/93390579da5d044a4e725faafd2b1f1d2d072a2a/etc/policy.json#L45 This behavior was introduced in response to this rfe: https://bugs.launchpad.net/neutron/+bug/1648129 Actually sharing this information is the point of the rfe. IIRC the concern about the information leak was even raised during a review, but it seems it went unaddressed. (Yep, I found the comment again: https://review.openstack.org/436756 comment at 03-07 21:12) I'm not sure if the segmentation details should be considered sensitive information or not. But the current behavior (admin-only here, not admin-only there) is clearly inconsistent. We could probably solve this by just synchronizing the default policies of provider network get operation and subport segmentation detail inheritance. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1704398/+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 1717627] [NEW] permission denied when executing dhclient in Ec2 datasource
Public bug reported: in the ec2 datasource, cloud-init runs dhclient from a tmp file in order to avoid apparmor restrictions and side affects. In a change for bug 1707222 we started using /run/cloud-init for tmpfiles. /run is mounted noexec. See example: $ sudo /run/cloud-init/tmp/dhclient -1 -v -lf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhcp.leases -pf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhclient.pid eth0 -sf /bin/true sudo: unable to execute /run/cloud-init/tmp/dhclient: Permission denied So, we need a tmp file in a place that allows execution. ** Affects: cloud-init Importance: High Status: Confirmed ** Affects: cloud-init (Ubuntu) Importance: High Status: Confirmed ** Merge proposal linked: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330875 ** Changed in: cloud-init Status: New => Confirmed ** Changed in: cloud-init Importance: Undecided => High ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Status: New => Confirmed ** Changed in: cloud-init (Ubuntu) Importance: Undecided => High -- 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/1717627 Title: permission denied when executing dhclient in Ec2 datasource Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Bug description: in the ec2 datasource, cloud-init runs dhclient from a tmp file in order to avoid apparmor restrictions and side affects. In a change for bug 1707222 we started using /run/cloud-init for tmpfiles. /run is mounted noexec. See example: $ sudo /run/cloud-init/tmp/dhclient -1 -v -lf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhcp.leases -pf /run/cloud-init/tmp/cloud-init-dhcp-bs6g4xkw/dhclient.pid eth0 -sf /bin/true sudo: unable to execute /run/cloud-init/tmp/dhclient: Permission denied So, we need a tmp file in a place that allows execution. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1717627/+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 1717611] [NEW] Azure: Azure datasource needs to wait forever for SSH pubkey to be dropped by waagent
Public bug reported: In Azure SSH pubkeys are transported in a certificate through the wireserver protocol. When cloud-init is configured to use waagent, which is the current default, cloud-init will wait maxwait=60 seconds for waagent to drop the .crt files corresponding to the fingerprint that was mentioned in the ovf-env.xml. We've had a couple of cases where the wireserver was flaky from more than 1 minute during provisioning which yielded a user without password or keys. These VM's are not usable without further action, we would rather have cloud-init wait forever for these .crt files to be provided. Azure VM provisioning will timeout and kill the VM when provisioning takes too long. I'm working on a fix for this issue. ** 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/1717611 Title: Azure: Azure datasource needs to wait forever for SSH pubkey to be dropped by waagent Status in cloud-init: New Bug description: In Azure SSH pubkeys are transported in a certificate through the wireserver protocol. When cloud-init is configured to use waagent, which is the current default, cloud-init will wait maxwait=60 seconds for waagent to drop the .crt files corresponding to the fingerprint that was mentioned in the ovf-env.xml. We've had a couple of cases where the wireserver was flaky from more than 1 minute during provisioning which yielded a user without password or keys. These VM's are not usable without further action, we would rather have cloud-init wait forever for these .crt files to be provided. Azure VM provisioning will timeout and kill the VM when provisioning takes too long. I'm working on a fix for this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1717611/+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 1714311] Re: Incorrect stylesheet link for the serial_console template
Reviewed: https://review.openstack.org/499738 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=7c9758dcdccc5670174b2deeb91bd20932e4d8e1 Submitter: Jenkins Branch:master commit 7c9758dcdccc5670174b2deeb91bd20932e4d8e1 Author: Pierre Riteau Date: Thu Aug 31 18:04:42 2017 +0100 Fix link to serial console stylesheet The serial_console.css stylesheet was renamed to serial_console.scss in commit 09706c6e3754c218b00dcaf210629aa6970dc80a, but the link referencing it in the serial console template was not updated. As a result the serial console is displayed with a proportional font. This commit updates the stylesheet link and adds a compress block to compile it from SCSS to CSS. Change-Id: Ic8abc970e76cb67c79c2335370c63e235a23eb5a Closes-Bug: #1714311 ** 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/1714311 Title: Incorrect stylesheet link for the serial_console template Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The stylesheet referenced in openstack_dashboard/templates/serial_console.html is incorrect, as the CSS file has been changed to SCSS in I0d421d931d252d821a7ecf19a750f73b8241c249: Instead, the template needs to reference the SCSS file and compile it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1714311/+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 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck
This bug was fixed in the package cloud-init - 0.7.9-280-ge626966e- 0ubuntu1 --- cloud-init (0.7.9-280-ge626966e-0ubuntu1) artful; urgency=medium * debian/rules: install rsyslog file with 0644 mode instead of 0755. * debian/rules, debian/apport-launcher.py: add an apport hook. (LP: #1607345) * New upstream snapshot. - cmdline: add collect-logs subcommand. [Chad Smith] (LP: #1607345) - CloudStack: consider dhclient lease files named with a hyphen. (LP: #1717147) - resizefs: Drop check for read-only device file, do not warn on overlayroot. [Chad Smith] - Do not provide systemd-fsck drop-in which could cause ordering cycles. [Balint Reczey] (LP: #1717477) - tests: Enable the NoCloud KVM platform [Joshua Powers] - resizefs: pass mount point to xfs_growfs [Dusty Mabe] - vmware: Enable nics before sending the SUCCESS event. [Sankar Tanguturi] - cloud-config modules: honor distros definitions in each module [Chad Smith] (LP: #1715738, #1715690) - chef: Add option to pin chef omnibus install version [Ethan Apodaca] (LP: #1462693) - tests: execute: support command as string [Joshua Powers] - schema and docs: Add jsonschema to resizefs and bootcmd modules [Chad Smith] - tools: Add xkvm script, wrapper around qemu-system [Joshua Powers] - vmware customization: return network config format [Sankar Tanguturi] (LP: #1675063) -- Scott Moser Fri, 15 Sep 2017 16:09:07 -0400 ** Changed in: cloud-init (Ubuntu Artful) Status: In Progress => Fix Released -- 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/1717477 Title: cloud-init generates ordering cycle via After=cloud-init in systemd- fsck Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: In Progress Status in cloud-init source package in Zesty: In Progress Status in cloud-init source package in Artful: Fix Released Bug description: http://pad.lv/1717477 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1717477 === Begin SRU Template === [Impact] Cloud-init's inclusion of a systemd drop-in file /lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf Caused a regression on systems that had entries in /etc/fstab that were not authored by cloud-init (specifically that did not have something like 'x-systemd.requires=cloud-init.service' in their filesystem options. [Test Case] The test can be done on any cloud that has space to put a non-root filesystem. a.) launch instance b.) upgrade to cloud-init to -updates pocket c.) create a filesystem and put it in /etc/fstab bdev="/dev/sdb1" mkdir -p /mnt mkfs.ext4 -F "$bdev" echo "$bdev /mnt auto defaults 0 2" >> /etc/fstab reboot d.) see mention of 'ordering cycle' in journal $ journalctl -o short-precise | grep -i ordering.cycle Sep 15 14:08:48.331033 xenial-20170911-174122 systemd[1]: local-fs.target: Found ordering cycle on local-fs.target/start Sep 15 14:08:48.331097 xenial-20170911-174122 systemd[1]: local-fs.target: Breaking ordering cycle by deleting job mnt.mount/start Sep 15 14:08:48.331108 xenial-20170911-174122 systemd[1]: mnt.mount: Job mnt.mount/start deleted to break ordering cycle starting with local-fs.target/start e.) upgrade to proposed f.) reboot g.) expect no mention of ordering cycle as seen in 'd' $ journalctl -o short-precise | grep -i ordering.cycle || echo "no cycles" no cycles [Regression Potential] This change will mean that bug 1691489 is present again. That bug is much less severe and affects a much smaller set of users. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=a2f8ce9c80 === End SRU Template === We're running several machines with cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2 without problems. Just upgraded all machines to cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1 and rebooted them all. All machines report ordering cycles in their dmesg, resulting in systemd breaking the loop by NOT starting some important services, e.g. mouting local filesystems: Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering cycle on networking.service/start Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found dependency on local-fs.target/start Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found dependency on home.mount/start Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found dependency on cloud-init.service/start Sep 14 15:43:52.487982 noname systemd[1]: netw
[Yahoo-eng-team] [Bug 1520582] Re: Recent fix to integration tests didn't fix the intermittent test_dashboard_help_redirection failure
Marking as closed because the fix was merged.
** Changed in: horizon
Status: New => 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/1520582
Title:
Recent fix to integration tests didn't fix the intermittent
test_dashboard_help_redirection failure
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
A watchful reviewer may notice that sometimes
test_dashboard_help_redirection fails. Initially I thought that it was
caught by an increased network timeout from Jenkins worker node to
docs.openstack.org site. So I made a patch
https://github.com/openstack/horizon/commit/6474215840d4cdde3751c335f46f32cb317238c0
Recently I found that this intermittent failure still occurs. This
time I reproduced the network delay by means of script (run as root):
delay.sh
delay=$1
ip=$2
tc qdisc del dev eth0 root
if [ -n $delay ]; then
tc qdisc add dev eth0 root handle 1: prio
tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32
match ip dst $ip flowid 2:1
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay ${delay}ms
fi
I realized that first the window is opened, then it waits for the page
to become accessible, and if I set timeout large enough (say, 10
seconds), I get the following traceback:
Error
Traceback (most recent call last):
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/nose/case.py",
line 133, in run
self.runTest(result)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/nose/case.py",
line 151, in runTest
test(result)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/unittest2/case.py",
line 673, in __call__
return self.run(*args, **kwds)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
line 606, in run
return run_test.run(result)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/runtest.py",
line 80, in run
return self._run_one(actual_result)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/runtest.py",
line 94, in _run_one
return self._run_prepared_result(ExtendedToOriginalDecorator(result))
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/runtest.py",
line 108, in _run_prepared_result
self._run_core()
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/runtest.py",
line 149, in _run_core
self.case._run_teardown, self.result):
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/runtest.py",
line 193, in _run_user
return self._got_user_exception(sys.exc_info())
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/runtest.py",
line 213, in _got_user_exception
self.case.onException(exc_info, tb_label=tb_label)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
line 558, in onException
handler(exc_info)
File
"/home/timur/develop/horizon/openstack_dashboard/test/integration_tests/helpers.py",
line 132, in _save_screenshot
self.driver.get_screenshot_as_file(filename)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
line 758, in get_screenshot_as_file
png = self.get_screenshot_as_png()
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
line 777, in get_screenshot_as_png
return base64.b64decode(self.get_screenshot_as_base64().encode('ascii'))
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
line 787, in get_screenshot_as_base64
return self.execute(Command.SCREENSHOT)['value']
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
line 199, in execute
response = self.command_executor.execute(driver_command, params)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py",
line 395, in execute
return self._request(command_info[0], url, body=data)
File
"/home/timur/develop/horizon/.venv/local/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py",
line 425, in _request
self._conn.request(method, parsed_url.path, body, headers)
File "/usr/lib/python2.7/httplib.py", line 979, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python2.7/httplib.py", line 1013, in _send_request
self.endheaders(body)
File "/usr/lib/p
[Yahoo-eng-team] [Bug 1521912] Re: Filter instances by project name abnormally
This works correctly in Pike. Marking as invalid. If this issue still exists, please feel free to reopen it. ** Changed in: horizon Status: Confirmed => Invalid -- 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/1521912 Title: Filter instances by project name abnormally Status in OpenStack Dashboard (Horizon): Invalid Bug description: When i try to filter instances by image id, status, name or ip address and so on, it will works fine. But i first time try to filter instances by project name or filter instances by project name after filter it by other options, the result will not map my wanna and just redirect to 'admin/instances/'. Does this conform to the query logic? The source as follow: horizon/horizon/tables/views.py -> DataTableView.post def post(self, request, *args, **kwargs): # If the server side table filter changed then go back to the first # page of data. Otherwise GET and POST handling are the same. if self.handle_server_filter(request): return shortcuts.redirect(self.get_table().get_absolute_url()) return self.get(request, *args, **kwargs) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1521912/+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 1717597] [NEW] Bad arping call in DVR centralized floating IP code
Public bug reported: When the centralized floating IP code was added, the call to send_ip_addr_adv_notif() had an incorrect argument, leading to this failure in the l3-agent log: TypeError: range() integer end argument expected, got ConfigOpts. ** Affects: neutron Importance: High Assignee: Brian Haley (brian-haley) Status: In Progress ** Tags: l3-dvr-backlog -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1717597 Title: Bad arping call in DVR centralized floating IP code Status in neutron: In Progress Bug description: When the centralized floating IP code was added, the call to send_ip_addr_adv_notif() had an incorrect argument, leading to this failure in the l3-agent log: TypeError: range() integer end argument expected, got ConfigOpts. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1717597/+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 1505209] Re: Unable to grant role in project to user/group in latest DevStack
I cannot reproduce this bug with Pike devstack. This bug is nearly 2 years
old, so marking as Invalid. If this issue still exists, please feel free to
reopen it and provide additional details.
** Changed in: horizon
Status: New => Invalid
--
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/1505209
Title:
Unable to grant role in project to user/group in latest DevStack
Status in OpenStack Dashboard (Horizon):
Invalid
Bug description:
Git version of Horizon 8.0.0.0rc2 from branch stable/liberty
Steps:
1. Identity -> Projects
2. Select one of projects and edit its members
3. One can add user but no roles to select are shown. No errors in apache log
but in firebug console there is: TypeError: role_list is undefined
Some more informations from firebug console:
TypeError: role_list is undefined
http://myLocalIP/static/dashboard/js/a5878f7901a6.js
Line 3261
This is line 3261:
else{for(role in
membership){if(membership.hasOwnProperty(role)){horizon.membership.remove_member(step_slug,data_id,role,membership[role]);,add_member_to_role:function(step_slug,data_id,role_id){var
role_list=horizon.membership.current_membership[step_slug][role_id];role_list.push(data_id);horizon.membership.update_role_lists(step_slug,role_id,role_list);},update_member_role_dropdown:function(step_slug,data_id,role_ids,member_el){if(typeof(role_ids)==='undefined'){role_ids=horizon.membership.get_member_roles(step_slug,data_id);}
And that part of line is indicated:
current_membership[step_slug][role_id];role_list.push(data_id);horizon.membersh...
--^
I can easily list roles under url: /identity/roles/ and grant roles
from CLI level.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1505209/+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 1479930] Re: Project member role dropdown does not open on first click
This works fine in Pike. Marking as invalid. ** Changed in: horizon Status: New => Invalid -- 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/1479930 Title: Project member role dropdown does not open on first click Status in OpenStack Dashboard (Horizon): Invalid Bug description: 1. Go to the Identity > Projects page 2. Click the Manage Members action for a project 3. From the Project Members list on the right, click the role dropdown for a user The first click on the dropdown seems to only set focus but does not open the role list. Once the dropdown button has focus it will then work on each click. If you click somewhere else to move focus away from the dropdown this behavior is seen again when you click back on it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1479930/+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 1708465] Re: Neutron duplicated provider rule for ICMPv6 Router Advertisements
Reviewed: https://review.openstack.org/503779 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=0dcf3d20c2e5c2592e9674e7277acce4eff98341 Submitter: Jenkins Branch:master commit 0dcf3d20c2e5c2592e9674e7277acce4eff98341 Author: Sławek Kapłoński Date: Wed Sep 13 17:24:03 2017 + Remove duplicated ICMPv6 RA rule from iptables firewall Change Ibfbf011284cbde396f74db9d982993f994082731 moves generation of ICMPv6 RA rule from being hardcoded in iptables_firewall to being generated on server side and passed to agent. Unfortunatelly it wasn't removed from iptables_firewall and it was still added to rules which should be applied by firewall driver. That caused issue with warning message about duplicated rule. detected This patch removes this hardcoded rule to stop logging messages about duplicated rules. Change-Id: Ic5e95405d4dd8ffbe8ec5b053aed257aec91b1c8 Closes-Bug: #1708465 ** 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/1708465 Title: Neutron duplicated provider rule for ICMPv6 Router Advertisements Status in neutron: Fix Released Bug description: Change https://review.openstack.org/#/c/432506/ introduced new way of providing provider rules to sg agent. ICMPv6 RA rule generation has been moved to neutron/db/securitygroups_rpc_base.py, but its not removed from neutron/agent/linux/iptables_firewall.py. In result each time we update SG rule in neutron logs there is a warning about rules duplication: 2017-08-03 10:41:12.873 28184 WARNING neutron.agent.linux.iptables_manager [-] Duplicate iptables rule detected. This may indicate a bug in the the iptables rule generation code. Line: -A neutron-openvswi-PREROUTING -i gwbf6069f7-2cc -j CT === How to reproduce === 1. Spawn devstack. 2. Boot VM 3. Add new rule to SG which this VM uses. 4. Observe neutron-openvswitch-agent logs. === Environment === Upstream master devstack. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1708465/+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 1585532] Re: Mitaka Version, no statistics data shown on dashboard
Closing, since ceilometer has been removed from horizon ** Changed in: horizon Status: In Progress => Invalid -- 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/1585532 Title: Mitaka Version, no statistics data shown on dashboard Status in OpenStack Dashboard (Horizon): Invalid Bug description: I have installed Mitaka Version On Centos 7.2, while run ceilometer meter-list and ceilometer statistics -m cpu all have data shown on the linux Howerver On the dashboard when I click: System --> resource overview, Only instance and image and volumes.size have data, any other metric show No data available. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1585532/+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 1476775] Re: --compilemessages CommandError: Can't find msgfmt
As of Pike, run_tests.sh is gone, and `tox -e manage -- compilemessages` works correctly. Closing. ** Changed in: horizon Status: Confirmed => Invalid -- 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/1476775 Title: --compilemessages CommandError: Can't find msgfmt Status in OpenStack Dashboard (Horizon): Invalid Bug description: Attempting to rebuild message catalog for Horizon and hit the following: $ ./run_tests.sh --compilemessages Checking environment. Environment is up to date. CommandError: Can't find msgfmt. Make sure you have GNU gettext tools 0.15 or newer installed. Ideally this utility would be satisfied from the virtual environment, otherwise perhaps some documentation is necessary to describe how to setup a development environment. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1476775/+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 1376347] Re: styling: dropdowns in dialogs are rendered wrong in FireFox, IE
I cannot reproduce this problem in FF now, and it appears that others cannot reproduce this either. Since this bug has not been confirmed for years, marking as Invalid. If the issue still exists, please feel free to reopen it. ** Changed in: horizon Status: Confirmed => Invalid -- 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/1376347 Title: styling: dropdowns in dialogs are rendered wrong in FireFox, IE Status in OpenStack Dashboard (Horizon): Invalid Bug description: This happens, for example, in Admin->System->Networks->Create Network Chrome looks good. But FireFox ESR 31 cuts off the right side of the drop down lists. IE 11 renders these select boxes needlessly wide. Other dialogs seem to be affected in the same way. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1376347/+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 1689510] Re: Wrong DVR and HA properties reported to non-admin users
So this is a bug in openstacksdk and/or python-openstackclient code, by default it is showing both "distributed" and "ha" values (with defaults to False), even if they are not in the JSON body returned from neutron- server. I don't know of an easy way to fix that by specifying not to show it in that case. The python-neutronclient doesn't show the values unless they are in the JSON body, but of course it's being deprecated... I'll re-assign and maybe someone else has a thought on how to fix it. ** Changed in: neutron Status: New => Confirmed ** Changed in: neutron Importance: Undecided => Low ** Also affects: python-openstacksdk Importance: Undecided Status: New ** Also affects: python-openstackclient 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/1689510 Title: Wrong DVR and HA properties reported to non-admin users Status in neutron: Confirmed Status in python-openstackclient: New Status in OpenStack SDK: New Bug description: Our routers are HA-DVR by default. Executing "openstack router list" as user with admin privileges correctly returns Distributed=True, HA=True. The same command executed as a regular user returns Distributed=False, HA=False which is factually incorrect. Seems to me that regular users are being misinformed about the properties of their routers. Is this by design or is it a bug? If it is by design, what reason would we have to lie to our users? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1689510/+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 1236073] Re: Ceilometer test sometimes detects UnexpectedMethodCallError (Exception in thread)
Ceilometer code is no longer in horizon. Marking invalid ** Changed in: horizon Status: Confirmed => Invalid -- 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/1236073 Title: Ceilometer test sometimes detects UnexpectedMethodCallError (Exception in thread) Status in OpenStack Dashboard (Horizon): Invalid Bug description: Ceilometer test sometimes detects UnexpectedMethodCallError in thread. http://paste.openstack.org/show/48011/ I am not sure whether it is a bug or not. It does not always occurs. According to my tests, the error rate is 3/20. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1236073/+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 1365547] Re: install_venv_common.py fails when using pip 1.4
This bug and pip version are quite old. Setting to invalid as it no
longer appears relevant.
** Changed in: horizon
Status: New => Invalid
--
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/1365547
Title:
install_venv_common.py fails when using pip 1.4
Status in OpenStack Dashboard (Horizon):
Invalid
Bug description:
Currently, in install_venv_common.py, pip is upgraded like so:
self.pip_install('pip>=1.4')
Unfortunately, if any value of pip<1.5 is used, the pip install of
oslosphinx fails.
pip install --upgrade oslosphinx\>=2.2.0.0a2
Downloading/unpacking oslosphinx>=2.2.0.0a2
Could not find a version that satisfies the requirement
oslosphinx>=2.2.0.0a2 (from versions: 2.0, 2.1.0)
Cleaning up...
No distributions matching the version for oslosphinx>=2.2.0.0a2
Storing complete log in /Users/mwood/.pip/pip.log
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1365547/+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 1600080] Re: Do not allow "white space" as name field value in "Edit Flavor" form
I cannot reproduce this bug. The form complains that "Flavor name cannot be empty." when I try this. ** Changed in: horizon Status: New => Invalid -- 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/1600080 Title: Do not allow "white space" as name field value in "Edit Flavor" form Status in OpenStack Dashboard (Horizon): Invalid Bug description: Reproduce: 1 Open Admin/System/Flavor page 2 Click "Edit Flavor", 3 input "white space" in "Name" field. 4 Submit the form, there will cast error in the top of the right corner of the page: "Unable to edit flavor". So there should not allow input "white space" in the "Name" field. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1600080/+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 1271792] Re: make limit fields in Defaults editable
Marking as invalid, since the edit dialog for this ( Admin / System / Defaults > Update Defaults) is not overly long in Pike (it only has 11 fields on it). ** Changed in: horizon Status: Confirmed => Invalid -- 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/1271792 Title: make limit fields in Defaults editable Status in OpenStack Dashboard (Horizon): Invalid Bug description: Make the "Limit" column fields editable instead of through the 'Update Defaults' modal because the modal could get very long and is not user friendly. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1271792/+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 1476109] Re: Volume type description missing
Closing since this was already implemented in https://review.openstack.org/#/c/133872/ ** Changed in: horizon Status: In Progress => Invalid -- 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/1476109 Title: Volume type description missing Status in OpenStack Dashboard (Horizon): Invalid Bug description: In horizon, volume type description is missing. We can get this in CLI: $ cinder type-list +--+--+-+---+ | ID | Name | Description | Is_Public | +--+--+-+---+ | ab95f9b2-f76b-47b9-af9d-1359448c483e | ssd| ssd |True | | f3406818-007d-41f2-877e-8afc5c4b0bac | defaults | - |True | +--+--+-+---+ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1476109/+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 1461923] Re: Field 'gateway' not disabled when 'no gateway' selected in 'edit subnet'
I am unable to reproduce this in Pike, so marking as invalid. If you can reproduce this please update the bug and re-open it. ** Changed in: horizon Status: New => Invalid -- 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/1461923 Title: Field 'gateway' not disabled when 'no gateway' selected in 'edit subnet' Status in OpenStack Dashboard (Horizon): Invalid Bug description: Horizon: 2014.2.3 Steps to reproduce: 1. Create net 2. Create subnet with gateway 3. Open network details (click on network name) under admin section 4. Click 'edit subnet' 5. Click "Disable Gateway" Expected behavior: 1. Field 'gateway' disabled 2. IP address in 'gateway' cleared Actual behavior: 1. Field 'gateway' still active 2. There is an old IP address in gateway field. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1461923/+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 1717542] Re: Possible client side template injection in horizon login screen
** Project changed: horizon => openstack-secaudit ** Also affects: horizon Importance: Undecided Status: New ** Changed in: horizon Importance: Undecided => Critical -- 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/1717542 Title: Possible client side template injection in horizon login screen Status in OpenStack Dashboard (Horizon): New Status in openstack-secaudit: New Bug description: We got indication from security auditing scan, that login page (/dashboard/auth/login) is still vulnerable for below problem, reported on Horizon/ocata, version 10.0.0.0. Seems same as below bug, just it didn't fix the issue for the login screen. https://bugs.launchpad.net/horizon/+bug/1567673 More information for he problem: AngularJS client-side template injection vulnerability. http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html This web application is vulnerable to AngularJS client-side template injection vulnerability. AngularJS client-side template injection vulnerabilities occur when user-input is dynamically embedded on a page where AngularJS client-side templating is used. By using curly braces it's possible to inject AngularJS expressions in the AngularJS client-side template that is being used by the application.These expressions will be evaluated on the client-side by AngularJS and when combined with a sandbox escape they allow an attacker to execute arbitrary JavaScript code. An attacker can inject AngularJS expressions that will be evaluated on the client-side. Normally AngularJS expressions are not very dangerous, but when combined with a sandbox escape they allow an attacker to execute arbitrary JavaScript code. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1717542/+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 1714284] Re: Placement user doc: add link to API reference
** 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/1714284 Title: Placement user doc: add link to API reference Status in OpenStack Compute (nova): Fix Released Bug description: The Placement API user doc [1] says: API Reference A full API reference is forthcoming, but until then ... That reference has since been published [2]. [1] https://docs.openstack.org/nova/pike/user/placement.html#api-reference [2] https://developer.openstack.org/api-ref/placement/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1714284/+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 1717582] [NEW] fullstack job failing to create namespace because it's already exists
Public bug reported: In fullstack tests there is many times error with creating e.g. "host-" namespace. Error message tells that such namespace already exists and test is failing because of that. It looks that this is kind of race condition when ip.netns.exists() method return false but few miliseconds later namespace already exists and ip.netns.add() method fails. It is in method ensure_namespace() in https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_lib.py#L204 ** Affects: neutron Importance: Undecided Assignee: Slawek Kaplonski (slaweq) Status: In Progress ** Tags: fullstack -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1717582 Title: fullstack job failing to create namespace because it's already exists Status in neutron: In Progress Bug description: In fullstack tests there is many times error with creating e.g. "host-" namespace. Error message tells that such namespace already exists and test is failing because of that. It looks that this is kind of race condition when ip.netns.exists() method return false but few miliseconds later namespace already exists and ip.netns.add() method fails. It is in method ensure_namespace() in https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_lib.py#L204 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1717582/+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 1717575] [NEW] Likely mismatch between code and database schema
Public bug reported: Description of problem: Seeing several messages like this in neutron-server logs https://gist.github.com/smalleni/e0422a42881f015ce3436ce7d6ac1a30 (1054, u"Unknown column 'mtu' in 'field list'") seems to be the problem Looking at the table, there doesn't seem to be an mtu field MariaDB [ovs_neutron]> describe networks; +-+--+--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +-+--+--+-+-+---+ | project_id | varchar(255) | YES | MUL | NULL| | | id | varchar(36) | NO | PRI | NULL| | | name| varchar(255) | YES | | NULL| | | status | varchar(16) | YES | | NULL| | | admin_state_up | tinyint(1) | YES | | NULL| | | vlan_transparent| tinyint(1) | YES | | NULL| | | standard_attr_id| bigint(20) | NO | UNI | NULL| | | availability_zone_hints | varchar(255) | YES | | NULL| | +-+ Version-Release number of selected component (if applicable): OpenStack Pike puppet-neutron-11.3.0-0.20170805104936.743dde6.el7ost.noarch python-neutronclient-6.5.0-0.20170807200849.355983d.el7ost.noarch openstack-neutron-lbaas-11.0.0-0.20170807144457.c9adfd4.el7ost.noarch python-networking-l2gw-10.1.0-0.20170804100327.a8ae0e3.el7ost.noarch python-neutron-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-linuxbridge-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-common-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-ml2-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-openvswitch-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch python-neutron-lbaas-11.0.0-0.20170807144457.c9adfd4.el7ost.noarch python-networking-odl-11.0.0-0.20170806093629.2e78dca.el7ost.noarch python-networking-ovn-3.0.0-0.20170807061656.2425483.el7ost.noarch openstack-neutron-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch python-networking-bgpvpn-7.0.0-0.20170807233234.c54f55e.el7ost.noarch openstack-neutron-sriov-nic-agent-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch python-neutron-lib-1.9.1-0.20170731102145.0ef54c3.el7ost.noarch openstack-neutron-metering-agent-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch python-neutron-tests-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch ** 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/1717575 Title: Likely mismatch between code and database schema Status in neutron: New Bug description: Description of problem: Seeing several messages like this in neutron-server logs https://gist.github.com/smalleni/e0422a42881f015ce3436ce7d6ac1a30 (1054, u"Unknown column 'mtu' in 'field list'") seems to be the problem Looking at the table, there doesn't seem to be an mtu field MariaDB [ovs_neutron]> describe networks; +-+--+--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +-+--+--+-+-+---+ | project_id | varchar(255) | YES | MUL | NULL| | | id | varchar(36) | NO | PRI | NULL| | | name| varchar(255) | YES | | NULL| | | status | varchar(16) | YES | | NULL| | | admin_state_up | tinyint(1) | YES | | NULL| | | vlan_transparent| tinyint(1) | YES | | NULL| | | standard_attr_id| bigint(20) | NO | UNI | NULL| | | availability_zone_hints | varchar(255) | YES | | NULL| | +-+ Version-Release number of selected component (if applicable): OpenStack Pike puppet-neutron-11.3.0-0.20170805104936.743dde6.el7ost.noarch python-neutronclient-6.5.0-0.20170807200849.355983d.el7ost.noarch openstack-neutron-lbaas-11.0.0-0.20170807144457.c9adfd4.el7ost.noarch python-networking-l2gw-10.1.0-0.20170804100327.a8ae0e3.el7ost.noarch python-neutron-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-linuxbridge-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-common-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-ml2-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch openstack-neutron-openvswitch-11.0.1-0.20170913033853.6b26bc5.el7ost.noarch python-neutron-lbaas-11.0.0-0.20170807144457.c9adfd4.el7ost.noarch python-networking-odl-11.0.0-0.20170806093629.2e78dca.el7ost.noarch python-networking-ovn-3.0.0-0.20170807061656.2425483.el7ost.noarch openstack-n
[Yahoo-eng-team] [Bug 1716903] Re: Failed to live-migrate instance in cell with microversion >= 2.34
The reason the live migration CI job didn't catch this is that it doesn't test microversion >= 2.34 which changes to use the live_migrate_instance method. If the microversion < 2.34 it uses the migrate_server method which has the @targets_cell decorator. ** Summary changed: - Failed to live-migrate instance in cell. + Failed to live-migrate instance in cell with microversion >= 2.34 ** Changed in: nova Importance: Undecided => High ** Also affects: nova/pike Importance: Undecided Status: New ** Changed in: nova/pike Status: New => Confirmed ** Changed in: nova/pike Importance: Undecided => High ** Tags added: cells live-migration -- 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/1716903 Title: Failed to live-migrate instance in cell with microversion >= 2.34 Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) pike series: Confirmed Bug description: Step 1 create instance in cell1 +--++++-+-+ | ID | Name | Status | Task State | Power State | Networks| +--++++-+-+ | 84038890-8d70-45e1-8240-2303f4227e11 | yikun1 | ACTIVE | - | Running | public=2001:db8::a, 172.24.4.13 | +--++++-+-+ Step 2 live migrate instance nova live-migration 84038890-8d70-45e1-8240-2303f4227e11 Step 3 The instance will stuck in "MIGRATIING" state. +--++---++-+-+ | ID | Name | Status| Task State | Power State | Networks| +--++---++-+-+ | 84038890-8d70-45e1-8240-2303f4227e11 | yikun1 | MIGRATING | migrating | Running | public=2001:db8::a, 172.24.4.13 | +--++---++-+-+ It seems we need add @targets_cell decorator for **live_migrate_instance** methods in conductor: https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L378 ERROR LOG in super conductor: Exception during message handling: InstanceActionNotFound: Action for request_id req-5aa03558-ae14-458e-9c35-c3d377c7ce45 on instance 84038890-8d70-45e1-8240-2303f4227e11 not found Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 160, in _process_incoming res = self.dispatcher.dispatch(message) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 213, in dispatch return self._do_dispatch(endpoint, method, ctxt, args) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 183, in _do_dispatch result = func(ctxt, **new_args) File "/opt/stack/nova/nova/compute/utils.py", line 875, in decorated_function with EventReporter(context, event_name, instance_uuid): File "/opt/stack/nova/nova/compute/utils.py", line 846, in __enter__ self.context, uuid, self.event_name, want_result=False) File "/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 184, in wrapper result = fn(cls, context, *args, **kwargs) File "/opt/stack/nova/nova/objects/instance_action.py", line 169, in event_start db_event = db.action_event_start(context, values) File "/opt/stack/nova/nova/db/api.py", line 1957, in action_event_start return IMPL.action_event_start(context, values) File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 250, in wrapped return f(context, *args, **kwargs) File "/opt/stack/nova/nova/db/sqlalchemy/api.py", line 6155, in action_event_start instance_uuid=values['instance_uuid']) InstanceActionNotFound: Action for request_id req-5aa03558-ae14-458e-9c35-c3d377c7ce45 on instance 84038890-8d70-45e1-8240-2303f4227e11 not found To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1716903/+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 1401170] Re: 0-size images allow unprivileged user to deplete glance resources
** Changed in: glance
Status: In Progress => Won't Fix
** Changed in: glance
Importance: High => Wishlist
** Changed in: glance
Assignee: Stuart McLaren (stuart-mclaren) => (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1401170
Title:
0-size images allow unprivileged user to deplete glance resources
Status in Glance:
Won't Fix
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
Glance allows to create 0-size images ('glance image-create' without
parameters). Those images do not consume resources of storage backend
and do not hit any limits for size, but take up space in database.
Malicious user can cause database resource depletion with endless
flood of 'image-create' requests. Because an empty request is small
it will cause more strain on openstack than on the attacker.
RateLimit on API requests allows to delay consequences of attack, but
does not prevent it.
Here is simple script to run attack:
while true;do curl -i -X POST -H 'X-Auth-Token: ***'
http://glance-endpoint:9292/v1/images;done
My estimation for database growth is about 1Mb/minute (with extra-
slow shell-based attack, but a specially crafted script will allow to
run it with RateLimit speed).
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1401170/+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 1717560] [NEW] allow to have no default route in DHCP host routes
Public bug reported: When a user wants a VM with multiple interfaces, if DHCP gives a default route for all of the corresponding subnets, the actual interface that will actually be used as a default is not easily predictable (depends on the order in which interfaces are enabled in the VM, and on when DHCP offers are received and processed). A solution to this can be to *not* set a default gateway on the subnets which we don't want to use as a default, but it is only applicable if there is no need to use these interfaces to reach one or more (non default) prefixes. In the case where one interface needs to be the default and one or more other interfaces are used to reach other subnets via a router, what people most often do is have custom teaks via cloud-init that fix routing, but this is of course cumbersome. This is an RFE for introducing an API extension for a new 'default_route' attribute on the subnet resource, this attribute would default to true (current behavior), and that could be set to false by a user whenever there is a need to *not* have a default route on the router. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1717560 Title: allow to have no default route in DHCP host routes Status in neutron: New Bug description: When a user wants a VM with multiple interfaces, if DHCP gives a default route for all of the corresponding subnets, the actual interface that will actually be used as a default is not easily predictable (depends on the order in which interfaces are enabled in the VM, and on when DHCP offers are received and processed). A solution to this can be to *not* set a default gateway on the subnets which we don't want to use as a default, but it is only applicable if there is no need to use these interfaces to reach one or more (non default) prefixes. In the case where one interface needs to be the default and one or more other interfaces are used to reach other subnets via a router, what people most often do is have custom teaks via cloud-init that fix routing, but this is of course cumbersome. This is an RFE for introducing an API extension for a new 'default_route' attribute on the subnet resource, this attribute would default to true (current behavior), and that could be set to false by a user whenever there is a need to *not* have a default route on the router. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1717560/+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 1717559] [NEW] Error creating network - DBError Constraint Failed
Public bug reported:
Issue trying to create a network in a brand new Openstack Newton setup,
tried with horizon and with the cli and both fail with this error:
2017-09-15 16:49:09.827 142 ERROR neutron.pecan_wsgi.hooks.translation
DBError: (pymysql.err.InternalError) (4025, u'CONSTRAINT `CONSTRAINT_3`
failed for `neutron`.`networks`') [SQL: u'INSERT INTO networks
(project_id, id, name, status, admin_state_up, vlan_transparent,
availability_zone_hints, mtu, standard_attr_id) VALUES (%(project_id)s,
%(id)s, %(name)s, %(status)s, %(admin_state_up)s, %(vlan_transparent)s,
%(availability_zone_hints)s, %(mtu)s, %(standard_attr_id)s)']
[parameters: {'status': 'ACTIVE', 'availability_zone_hints': None,
'name': u'network0', 'admin_state_up': 1, 'mtu': 0, 'vlan_transparent':
None, 'standard_attr_id': 13, 'project_id':
u'f9ee32286b794ccba68cb0b2c2e943a6', 'id': '70acc814-6a93-495c-
8cc3-7fd02b85a3f7'}]
I've check the database and CONSTRAINT_3 is this one: CONSTRAINT
`CONSTRAINT_3` CHECK (`vlan_transparent` in (0,1))
Full Mysql Create:
mysql> SHOW CREATE TABLE networks;
| networks | CREATE TABLE `networks` (
`project_id` varchar(255) DEFAULT NULL,
`id` varchar(36) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`status` varchar(16) DEFAULT NULL,
`admin_state_up` tinyint(1) DEFAULT NULL,
`vlan_transparent` tinyint(1) DEFAULT NULL,
`standard_attr_id` bigint(20) NOT NULL,
`availability_zone_hints` varchar(255) DEFAULT NULL,
`mtu` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_networks0standard_attr_id` (`standard_attr_id`),
KEY `ix_networks_project_id` (`project_id`),
CONSTRAINT `networks_ibfk_1` FOREIGN KEY (`standard_attr_id`) REFERENCES
`standardattributes` (`id`) ON DELETE CASCADE,
CONSTRAINT `CONSTRAINT_1` CHECK (`admin_state_up` in (0,1)),
CONSTRAINT `CONSTRAINT_3` CHECK (`vlan_transparent` in (0,1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
- Ussue trying to create a network in Openstack Newton, tried with horizon
- and with the cli and both fail.
+ Issue trying to create a network in a brand new Openstack Newton setup,
+ tried with horizon and with the cli and both fail with this error:
2017-09-15 16:49:09.827 142 ERROR neutron.pecan_wsgi.hooks.translation
DBError: (pymysql.err.InternalError) (4025, u'CONSTRAINT `CONSTRAINT_3`
failed for `neutron`.`networks`') [SQL: u'INSERT INTO networks
(project_id, id, name, status, admin_state_up, vlan_transparent,
availability_zone_hints, mtu, standard_attr_id) VALUES (%(project_id)s,
%(id)s, %(name)s, %(status)s, %(admin_state_up)s, %(vlan_transparent)s,
%(availability_zone_hints)s, %(mtu)s, %(standard_attr_id)s)']
[parameters: {'status': 'ACTIVE', 'availability_zone_hints': None,
'name': u'network0', 'admin_state_up': 1, 'mtu': 0, 'vlan_transparent':
None, 'standard_attr_id': 13, 'project_id':
u'f9ee32286b794ccba68cb0b2c2e943a6', 'id': '70acc814-6a93-495c-
8cc3-7fd02b85a3f7'}]
-
- I've check the database and CONSTRAINT_3 is this one: CONSTRAINT
`CONSTRAINT_3` CHECK (`vlan_transparent` in (0,1))
+ I've check the database and CONSTRAINT_3 is this one: CONSTRAINT
+ `CONSTRAINT_3` CHECK (`vlan_transparent` in (0,1))
Full Mysql Create:
+ mysql> SHOW CREATE TABLE networks;
- mysql> SHOW CREATE TABLE networks;
-
- | networks | CREATE TABLE `networks` (
- `project_id` varchar(255) DEFAULT NULL,
- `id` varchar(36) NOT NULL,
- `name` varchar(255) DEFAULT NULL,
- `status` varchar(16) DEFAULT NULL,
- `admin_state_up` tinyint(1) DEFAULT NULL,
- `vlan_transparent` tinyint(1) DEFAULT NULL,
- `standard_attr_id` bigint(20) NOT NULL,
- `availability_zone_hints` varchar(255) DEFAULT NULL,
- `mtu` int(11) DEFAULT NULL,
- PRIMARY KEY (`id`),
- UNIQUE KEY `uniq_networks0standard_attr_id` (`standard_attr_id`),
- KEY `ix_networks_project_id` (`project_id`),
- CONSTRAINT `networks_ibfk_1` FOREIGN KEY (`standard_attr_id`) REFERENCES
`standardattributes` (`id`) ON DELETE CASCADE,
- CONSTRAINT `CONSTRAINT_1` CHECK (`admin_state_up` in (0,1)),
- CONSTRAINT `CONSTRAINT_3` CHECK (`vlan_transparent` in (0,1))
+ | networks | CREATE TABLE `networks` (
+ `project_id` varchar(255) DEFAULT NULL,
+ `id` varchar(36) NOT NULL,
+ `name` varchar(255) DEFAULT NULL,
+ `status` varchar(16) DEFAULT NULL,
+ `admin_state_up` tinyint(1) DEFAULT NULL,
+ `vlan_transparent` tinyint(1) DEFAULT NULL,
+ `standard_attr_id` bigint(20) NOT NULL,
+ `availability_zone_hints` varchar(255) DEFAULT NULL,
+ `mtu` int(11) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `uniq_networks0standard_attr_id` (`standard_attr_id`),
+ KEY `ix_
[Yahoo-eng-team] [Bug 1717547] [NEW] Creating snapshot fails when image metadata has version field
Public bug reported: Description: When creating a snapshot of a server using the nova API, failure occurs if the image contains the metadata property "version". It seems like image metadata is passed as an argument to _create_v2 (nova/image/glance.py) which is then passed to call (nova/image/glance.py) as kwargs. The function already takes in context, method, and version arguments, so it seems that any of these metadata properties would cause the snapshot to fail. OpenStack version : Pike Nova API version : 2.1 Steps to reporduce: 1. Create an image with metadata property "version" 2. Launch an server using this image 3. Try to create a server snapshot of the server you just launched image used: +--++ | Field| Value | +--++ | checksum | d19875d33815bd8c49fe39829b1df924 | | container_format | bare | | created_at | 2017-09-05T15:57:24Z | | disk_format | raw | | file | /v2/images/c7f76154-dd99-4102-afe2-662a4fcaba7b/file | | id | c7f76154-dd99-4102-afe2-662a4fcaba7b | | min_disk | 0 | | min_ram | 0 | | name | ubuntu-16.04-amd64_2 | | owner| 71cea55297f94953b33b2a2549d72a95 | | properties | architecture='amd64', direct_url='rbd://8838dc54-c385-4949-9624-1cf3911320 | | | 1d/images/c7f76154-dd99-4102-afe2-662a4fcaba7b/snap', | | | distribution='Ubuntu', family='Linux', username='ubuntu', version='16.04' | | protected| False | | schema | /v2/schemas/image | | size | 2361393152 | | status | active | | tags | | | updated_at | 2017-09-14T21:10:44Z | | virtual_size | None | | visibility | public | +--++ Expected result: succesfully create server snapshot Actual result: logs: 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions [req-eea1ec3c-a500-4006-ab4d-00a05a6b4f33 f25d972f420840e48163a55bf5713bf6 c657c15a0a13435bbe2c323c732d4e4f - 0e46d3ad069b4f0e85bf594de38fbe0e 0e46d3ad069b4f0e85bf594de38fbe0e] Unexpected exception in API method: TypeError: call() got multiple values for keyword argument 'version' 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 336, in wrapped 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/api/openstack/common.py", line 356, in inner 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 108, in wrapper 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-09-14 19:57:53.486 27 ERROR nova.api.openstack.extensions File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 999, in _acti
[Yahoo-eng-team] [Bug 1717542] [NEW] Possible client side template injection in horizon login screen
Public bug reported: We got indication from security auditing scan, that login page (/dashboard/auth/login) is still vulnerable for below problem, reported on Horizon/ocata, version 10.0.0.0. Seems same as below bug, just it didn't fix the issue for the login screen. https://bugs.launchpad.net/horizon/+bug/1567673 More information for he problem: AngularJS client-side template injection vulnerability. http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html This web application is vulnerable to AngularJS client-side template injection vulnerability. AngularJS client-side template injection vulnerabilities occur when user-input is dynamically embedded on a page where AngularJS client-side templating is used. By using curly braces it's possible to inject AngularJS expressions in the AngularJS client- side template that is being used by the application.These expressions will be evaluated on the client-side by AngularJS and when combined with a sandbox escape they allow an attacker to execute arbitrary JavaScript code. An attacker can inject AngularJS expressions that will be evaluated on the client-side. Normally AngularJS expressions are not very dangerous, but when combined with a sandbox escape they allow an attacker to execute arbitrary JavaScript code. ** 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/1717542 Title: Possible client side template injection in horizon login screen Status in OpenStack Dashboard (Horizon): New Bug description: We got indication from security auditing scan, that login page (/dashboard/auth/login) is still vulnerable for below problem, reported on Horizon/ocata, version 10.0.0.0. Seems same as below bug, just it didn't fix the issue for the login screen. https://bugs.launchpad.net/horizon/+bug/1567673 More information for he problem: AngularJS client-side template injection vulnerability. http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html This web application is vulnerable to AngularJS client-side template injection vulnerability. AngularJS client-side template injection vulnerabilities occur when user-input is dynamically embedded on a page where AngularJS client-side templating is used. By using curly braces it's possible to inject AngularJS expressions in the AngularJS client-side template that is being used by the application.These expressions will be evaluated on the client-side by AngularJS and when combined with a sandbox escape they allow an attacker to execute arbitrary JavaScript code. An attacker can inject AngularJS expressions that will be evaluated on the client-side. Normally AngularJS expressions are not very dangerous, but when combined with a sandbox escape they allow an attacker to execute arbitrary JavaScript code. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1717542/+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 1717533] [NEW] No rootwrap filter for chmod in libvirt/utils
Public bug reported: After https://review.openstack.org/459166 was applied, Virtuozzo-specific code became broken, which was noticed when we started running Tempest tests for ephemeral disk. n-cpu.service log: Sep 15 10:15:09.633992 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [None req-ff184083-1ba2-44ec-a961-111adafb4cbe service nova] [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] Instance failed to spawn: ProcessExecutionError: Unexpected error while running command. Sep 15 10:15:09.634505 localhost.localdomain nova-compute[67509]: Command: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod -R a+r /opt/stack/data/nova/instances/c9d08a85-4a46-4b34-b919-8c2cb283ecfc/disk.eph0 Sep 15 10:15:09.634683 localhost.localdomain nova-compute[67509]: Exit code: 99 Sep 15 10:15:09.634852 localhost.localdomain nova-compute[67509]: Stdout: u'' Sep 15 10:15:09.635244 localhost.localdomain nova-compute[67509]: Stderr: u'/usr/bin/nova-rootwrap: Unauthorized command: chmod -R a+r /opt/stack/data/nova/instances/c9d08a85-4a46-4b34-b919-8c2cb283ecfc/disk.eph0 (no filter matched)\n' Sep 15 10:15:09.635435 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] Traceback (most recent call last): Sep 15 10:15:09.635601 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/compute/manager.py", line 2162, in _build_resources Sep 15 10:15:09.635772 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] yield resources Sep 15 10:15:09.636252 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/compute/manager.py", line 1977, in _build_and_run_instance Sep 15 10:15:09.636523 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] block_device_info=block_device_info) Sep 15 10:15:09.636965 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 2797, in spawn Sep 15 10:15:09.637339 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] block_device_info=block_device_info) Sep 15 10:15:09.637582 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 3273, in _create_image Sep 15 10:15:09.637833 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] specified_fs=specified_fs) Sep 15 10:15:09.638079 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/virt/libvirt/imagebackend.py", line 242, in cache Sep 15 10:15:09.638483 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] *args, **kwargs) Sep 15 10:15:09.638733 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/virt/libvirt/imagebackend.py", line 1087, in create_image Sep 15 10:15:09.638973 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] prepare_template(target=self.path, *args, **kwargs) Sep 15 10:15:09.639245 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py", line 274, in inner Sep 15 10:15:09.639494 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] return f(*args, **kwargs) Sep 15 10:15:09.639732 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/virt/libvirt/imagebackend.py", line 238, in fetch_func_sync Sep 15 10:15:09.640069 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] fetch_func(target=target, *args, **kwargs) Sep 15 10:15:09.640367 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 3017, in _create_ephemeral Sep 15 10:15:09.640615 localhost.localdomain nova-compute[67509]: ERROR nova.compute.manager [instance: c9d08a85-4a46-4b34-b919-8c2cb283ecfc] specified_fs) Sep 15 10:15
[Yahoo-eng-team] [Bug 1715684] Re: password_regex option in keystone.conf not working
Since it was a containerized deployment, the keystone.conf file had to
be changed in a different location. Works as expected. Hence marking the
bug as invalid.
(overcloud) [heat-admin@controller-0 ~]$ openstack user create --project
members --password-prompt user3
User Password:abcd
Repeat User Password:abcd
The password does not match the requirements: None. (HTTP 400) (Request-ID:
req-8ee9bf87-76ef-4788-b6af-5dbba53e43a8)
** Changed in: tripleo
Status: New => Invalid
--
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/1715684
Title:
password_regex option in keystone.conf not working
Status in OpenStack Identity (keystone):
Invalid
Status in tripleo:
Invalid
Bug description:
Set password_regex to the pattern below (Note that this pattern is
from the note section in keystone.conf above 'password_regex' -
pattern for at least 1 letter, 1 digit, and have a minimum length of 7
characters)
**
STEPS TO REPRODUCE
***
$ sudo grep "password_regex" /etc/keystone/keystone.conf
password_regex = ^(?=.*\d)(?=.*[a-zA-Z]).{7,}$
2) Restart httpd
$ sudo service httpd restart
3) $ openstack user create --password-prompt panbalag
User Password:a
Repeat User Password:a
+--+--+
| Field| Value|
+--+--+
| email| None |
| enabled | True |
| id | 12665ec14f73478fa7acc74271f119bd |
| name | panbalag |
| options | {} |
| username | panbalag |
+--+--+
4) Step 3 must have returned an error message since password does not
match the requirements defined in password_regex
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1715684/+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 1713095] Re: Nova compute driver init happens before conductor is ready
** Also affects: nova/pike Importance: Undecided Status: New ** Tags added: ironic ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova/pike Importance: Undecided => Medium ** Changed in: nova/pike Status: New => In Progress ** Changed in: nova/pike Assignee: (unassigned) => Lee Yarwood (lyarwood) -- 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/1713095 Title: Nova compute driver init happens before conductor is ready Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) pike series: In Progress Bug description: In nova/service.py we poll for conductor readiness before we allow normal service startup behavior. The ironic driver does RPC to conductor in its _refresh_hash_ring() code, which may expect conductor be up before it's not. If so, we'll fail to start up because we called to conductor, waited a long time, and then timed out. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1713095/+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 1691489] Re: fstab entries written by cloud-config may not be mounted
** Changed in: cloud-init (Ubuntu Yakkety) Status: Confirmed => Won't Fix ** Description changed: === Begin SRU Template === [Impact] There is a race condition on a re-deployment of cloud-init on Azure where /mnt will not get properly formatted or mounted. This is due to "dirty" entries in /etc/fstab that cause a device to be busy when cloud-init goes to format it. This shows itself usually as 'mkfs' complaining that the device is busy. The cause is that systemd starts an fsck and collides with cloud-init re-formatting the disk. The problem can be seen other places but seemed to be most reproducible and originally found on Azure. [Test Case] 1.) Launch a Azure vm, ideally size L32S. 2.) Log in and verify the system properly mounted /mnt. 3.) Re-deploy the vm through the web ui and try again. [Regression Potential] - Worst case scenario, these changes unnecessarily slow down boot and + Worst case scenario, these changes unnecessarily slow down boot and do not fix the problem. + + [Regression] + This SRU change caused bug 1717477. [Other Info] Upstream commit at - https://git.launchpad.net/cloud-init/commit/?id=1f5489c258 + https://git.launchpad.net/cloud-init/commit/?id=1f5489c258 === End SRU Template === - - As reported in bug 1686514, sometimes /mnt will not get mounted when re-delpoying or stopping-then-starting a Azure vm of L32S. This is probably a more generic issue, I suspect shown due to the speed of disks on these systems. + As reported in bug 1686514, sometimes /mnt will not get mounted when re- + delpoying or stopping-then-starting a Azure vm of L32S. This is + probably a more generic issue, I suspect shown due to the speed of disks + on these systems. Related bugs: * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks + * bug 1717477: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck -- 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/1691489 Title: fstab entries written by cloud-config may not be mounted Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Won't Fix Status in cloud-init source package in Zesty: Fix Released Status in cloud-init source package in Artful: Fix Released Bug description: === Begin SRU Template === [Impact] There is a race condition on a re-deployment of cloud-init on Azure where /mnt will not get properly formatted or mounted. This is due to "dirty" entries in /etc/fstab that cause a device to be busy when cloud-init goes to format it. This shows itself usually as 'mkfs' complaining that the device is busy. The cause is that systemd starts an fsck and collides with cloud-init re-formatting the disk. The problem can be seen other places but seemed to be most reproducible and originally found on Azure. [Test Case] 1.) Launch a Azure vm, ideally size L32S. 2.) Log in and verify the system properly mounted /mnt. 3.) Re-deploy the vm through the web ui and try again. [Regression Potential] Worst case scenario, these changes unnecessarily slow down boot and do not fix the problem. [Regression] This SRU change caused bug 1717477. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=1f5489c258 === End SRU Template === As reported in bug 1686514, sometimes /mnt will not get mounted when re-delpoying or stopping-then-starting a Azure vm of L32S. This is probably a more generic issue, I suspect shown due to the speed of disks on these systems. Related bugs: * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks * bug 1717477: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1691489/+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 1717477] Re: cloud-init generates ordering cycle via After=cloud-init in systemd-fsck
** Attachment added: "journalctl -o short-precise after"
https://bugs.launchpad.net/cloud-init/+bug/1717477/+attachment/4950748/+files/journal-short-precise-after.txt
** Description changed:
We're running several machines with
- cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2
+ cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2
without problems.
Just upgraded all machines to
- cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1
+ cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1
and rebooted them all.
All machines report ordering cycles in their dmesg, resulting in systemd
breaking the
loop by NOT starting some important services, e.g. mouting local filesystems:
-
Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering
cycle on networking.service/start
Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found
dependency on local-fs.target/start
Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found
dependency on home.mount/start
Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found
dependency on cloud-init.service/start
Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found
dependency on networking.service/start
Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking
ordering cycle by deleting job local-fs.target/start
Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job
local-fs.target/start deleted to break ordering cycle starting with
networking.service/start
-
% cat /etc/fstab
LABEL=cloudimg-rootfs /ext4 defaults,discard0 1
LABEL=Home/homexfsdefaults,logbufs=8 0 2
-
- In this case /home isn't mounted as a result of systemd breaking the loop,
resulting in services depending on /home not being started.
+ In this case /home isn't mounted as a result of systemd breaking the
+ loop, resulting in services depending on /home not being started.
1. Tell us your cloud provider
AWS
2. dpkg-query -W -f='${Version}' cloud-init
0.7.9-233-ge586fe35-0ubuntu1~16.04.1
3. Any appropriate cloud-init configuration you can provide us
Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
all machines without hassle.
-
The problem is this change:
diff -uaNr 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
--- 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
1970-01-01 01:00:00.0 +0100
+++ 233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
2017-07-28 22:28:47.0 +0200
@@ -0,0 +1,2 @@
+[Unit]
+After=cloud-init.service
-
WORKAROUND
==
I just did a
- rm /lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
+ rm /lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
on all machines and rebooted them: no more dependency loops reported,
everything works again.
+
+ Related bugs:
+ * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition
ephemeral disks
+ * bug 1691489: fstab entries written by cloud-config may not be mounted
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => High
** Also affects: cloud-init (Ubuntu Artful)
Importance: High
Status: Confirmed
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Zesty)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Zesty)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: cloud-init (Ubuntu Zesty)
Importance: Undecided => High
** Tags added: regression-released
** Tags removed: regression-released
** Tags added: regression-release
--
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/1717477
Title:
cloud-init generates ordering cycle via After=cloud-init in systemd-
fsck
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in cloud-init source package in Xenial:
Confirmed
Status in cloud-init source package in Zesty:
Confirmed
Status in cloud-init source package in Artful:
Confirmed
Bug description:
We're running several machines with
cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2
without problems.
Just upgraded all machines to
cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1
and
[Yahoo-eng-team] [Bug 1266962] Re: Remove set_time_override in timeutils
** Also affects: heat Importance: Undecided Status: New ** Changed in: heat Status: New => In Progress ** Changed in: heat Assignee: (unassigned) => zhangyangyang (zhangyangyang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1266962 Title: Remove set_time_override in timeutils Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in gantt: New Status in Glance: Fix Released Status in OpenStack Heat: In Progress Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystonemiddleware: In Progress Status in Manila: Fix Released Status in neutron: In Progress Status in OpenStack Compute (nova): Fix Released Status in oslo.messaging: Fix Released Status in oslo.utils: New Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tuskar: Fix Released Status in zaqar: Fix Released Bug description: set_time_override was written as a helper function to mock utcnow in unittests. However we now use mock or fixture to mock our objects so set_time_override has become obsolete. We should first remove all usage of set_time_override from downstream projects before deleting it from oslo. List of attributes and functions to be removed from timeutils: * override_time * set_time_override() * clear_time_override() * advance_time_delta() * advance_time_seconds() To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1266962/+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 1717147] Re: cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack
** Bug watch added: Red Hat Bugzilla #1491932 https://bugzilla.redhat.com/show_bug.cgi?id=1491932 ** Also affects: cloud-init (CentOS) via https://bugzilla.redhat.com/show_bug.cgi?id=1491932 Importance: Unknown Status: Unknown -- 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/1717147 Title: cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack Status in cloud-init: New Status in cloud-init package in CentOS: Unknown Bug description: Environment: CentOS 7.4, cloud-init-0.7.9-9.el7.centos.2.x86_64 Problem (quick): CentOS 7.4 builds on Cloudstack 4.8 don't run cloud-init because the newer version of cloud-init doesn't appear to like the way the dhclient lease file is named. Problem (long): I've just built a CentOS 7.4 instance in one of my CloudStack 4.8 clusters. Unfortunately, cloud-init fails with the following in snippet in /var/log/cloud-init.log: 2017-09-13 18:53:00,118 - __init__.py[DEBUG]: Seeing if we can get any data from 2017-09-13 18:53:00,118 - DataSourceCloudStack.py[DEBUG]: Using /var/lib/dhclient lease directory 2017-09-13 18:53:00,118 - DataSourceCloudStack.py[DEBUG]: No lease file found, using default gateway Where it then tries to use the default route to download userdata. The problem is that we're not using the Cloudstack VR as a default router, so I expected it to parse /var/lib/dhclient/dhclient-- eth0.lease for the "dhcp-server-identifier" line. Theory as to cause: I believe that this change (https://github.com/cloud-init/cloud-init/commit/aee0edd93cb4d78b5e0d1aec71e977aabf31cdd0#diff-5bc9de2bb7889d66205845400c7cf99b) breaks cloud-init beyond the 7.3-distributed cloud-0.7.5 when 7.4 includes 0.7.9-9. Fix: Changing it from "dhclient." to "dhclient-" in /usr/lib/python2.7 /site-packages/cloudinit/sources/DataSourceCloudStack.py on the running box with an installed RPM did the trick theoretically (after removing the pyc and pyo files, of course). This *can* be patched around by RedHat/CentOS (and hopefully will), but I figure it might be better to take it straight upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1717147/+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 1717497] [NEW] fails to upload binaries/files to a VM on a compute node.
Public bug reported: Hi , I setup openstack newton using JUJU 2node(controller and compute) setup .I started launching two VMs on controller and compute respectively ; assigned floating IP , able to access flaoting IP from outside from a browser , the VM is having out own web applicaion which will able to upload binaries and do some functionality once upload successfully. Here am facing one issue like , when i upload binary on a VM launched at controller node , it is uploading successfully , but the same when i upload it to a VM launched at compute node, It is failing to upload ; If anyone aware of this please reply back ** 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/1717497 Title: fails to upload binaries/files to a VM on a compute node. Status in OpenStack Compute (nova): New Bug description: Hi , I setup openstack newton using JUJU 2node(controller and compute) setup .I started launching two VMs on controller and compute respectively ; assigned floating IP , able to access flaoting IP from outside from a browser , the VM is having out own web applicaion which will able to upload binaries and do some functionality once upload successfully. Here am facing one issue like , when i upload binary on a VM launched at controller node , it is uploading successfully , but the same when i upload it to a VM launched at compute node, It is failing to upload ; If anyone aware of this please reply back To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1717497/+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 1717493] [NEW] Error: Unable to get nova services list.
Public bug reported: (openstack) compute service list 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-5223852e-e20a-4c5d-be80-49c660f12e18) 2017-09-15 17:06:38.844 5052 ERROR nova.api.openstack.extensions 2017-09-15 17:06:38.848 5052 INFO nova.api.openstack.wsgi [req-32bef346-77d2-4687-b390-937afc7364c2 d726f2d8b7db4da0bd3581d54f21ad78 0eae9b82f05a4ba29330fd9674bf1a4d - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2017-09-15 17:06:38.850 5052 INFO nova.osapi_compute.wsgi.server [req-32bef346-77d2-4687-b390-937afc7364c2 d726f2d8b7db4da0bd3581d54f21ad78 0eae9b82f05a4ba29330fd9674bf1a4d - default default] 192.168.122.140 "GET /v2.1/0eae9b82f05a4ba29330fd9674bf1a4d/servers/detail?all_tenants=True HTTP/1.1" status: 500 len: 638 time: 0.6100490 ** 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/1717493 Title: Error: Unable to get nova services list. Status in OpenStack Compute (nova): New Bug description: (openstack) compute service list 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-5223852e-e20a-4c5d-be80-49c660f12e18) 2017-09-15 17:06:38.844 5052 ERROR nova.api.openstack.extensions 2017-09-15 17:06:38.848 5052 INFO nova.api.openstack.wsgi [req-32bef346-77d2-4687-b390-937afc7364c2 d726f2d8b7db4da0bd3581d54f21ad78 0eae9b82f05a4ba29330fd9674bf1a4d - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2017-09-15 17:06:38.850 5052 INFO nova.osapi_compute.wsgi.server [req-32bef346-77d2-4687-b390-937afc7364c2 d726f2d8b7db4da0bd3581d54f21ad78 0eae9b82f05a4ba29330fd9674bf1a4d - default default] 192.168.122.140 "GET /v2.1/0eae9b82f05a4ba29330fd9674bf1a4d/servers/detail?all_tenants=True HTTP/1.1" status: 500 len: 638 time: 0.6100490 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1717493/+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 1713590] Re: Plugging VFs no longer works without a readable phys_switch_id
Reviewed: https://review.openstack.org/499203
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=b184558ab6a61571160346818dcf220d925c5b30
Submitter: Jenkins
Branch:master
commit b184558ab6a61571160346818dcf220d925c5b30
Author: Moshe Levi
Date: Wed Aug 30 18:35:48 2017 +0300
ovs mech: bind only if user request switchdev
In I77650be5f04775a72e2bdf694f93988825a84b72 we added
vnic_type direct to the ovs mechanism drivers supported
vnic_types. This cause problems when working with ovs and sriovnicswitch
mechanism drivers in that order. In this case the ovs will bind
the direct port instead of the sriovnicswitch.
This change make ovs mech driver to bind the direct port only
if user requested --binding-profile '{"capabilities": ["switchdev"]}'
in the direct port if a user don't request this capability the SR-IOV
legacy NIC mode is used.
When enable-sriov-nic-features will be implemented in nova and
libvirt will expose the switchdev capability then nova will be
able to select a host which supports SR-IOV nic with switchdev
mode.
[1] -
https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst
[2] - https://www.redhat.com/archives/libvir-list/2017-August/msg00583.html
Closes-Bug: #1713590
Change-Id: I0b5f062bcbf02381bdf4f694fc039f9bb17a2db5
** 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/1713590
Title:
Plugging VFs no longer works without a readable phys_switch_id
Status in neutron:
Fix Released
Bug description:
Attempting to plug a VF fails with the following stack trace in the
nova compute logs:
2017-08-28 17:50:34.716 2843 ERROR os_vif
[req-9fe05e3e-f7ae-4b2d-be27-90d81fe0b9fd 66e36d5620c24020ac6fa6fb8e580b6c
df21f729c47347b299783a4c1f83e774 - default default] Failed to plug vif
VIFHostDevice(active=False,address=fa:16:3e:de:b2:7d,dev_address=:0b:11.0,dev_type='ethernet',has_traffic_filtering=True,id=b5858ca0-c315-4b2a-b1a9-82a5b508bf2f,network=Network(19c75cc1-a553-4d3d-9a1a-9ad010102e31),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True):
PciDeviceNotFoundById: PCI device :0b:11.0 not found
2017-08-28 17:50:34.716 2843 ERROR os_vif Traceback (most recent call last):
2017-08-28 17:50:34.716 2843 ERROR os_vif File
"/usr/lib/python2.7/site-packages/os_vif/__init__.py", line 77, in plug
2017-08-28 17:50:34.716 2843 ERROR os_vif plugin.plug(vif, instance_info)
2017-08-28 17:50:34.716 2843 ERROR os_vif File
"/usr/lib/python2.7/site-packages/vif_plug_ovs/ovs.py", line 191, in plug
2017-08-28 17:50:34.716 2843 ERROR os_vif self._plug_vf_passthrough(vif,
instance_info)
2017-08-28 17:50:34.716 2843 ERROR os_vif File
"/usr/lib/python2.7/site-packages/vif_plug_ovs/ovs.py", line 163, in
_plug_vf_passthrough
2017-08-28 17:50:34.716 2843 ERROR os_vif pci_slot, pf_interface=True,
switchdev=True)
2017-08-28 17:50:34.716 2843 ERROR os_vif File
"/usr/lib/python2.7/site-packages/vif_plug_ovs/linux_net.py", line 373, in
get_ifname_by_pci_address
2017-08-28 17:50:34.716 2843 ERROR os_vif raise
exception.PciDeviceNotFoundById(id=pci_addr)
2017-08-28 17:50:34.716 2843 ERROR os_vif PciDeviceNotFoundById: PCI device
:0b:11.0 not found
2017-08-28 17:50:34.716 2843 ERROR os_vif
It appears that patch https://review.openstack.org/#/c/484051/ altered
get_ifname_by_pci_address() always run a new helper function _is_switchdev()
(it appears that it is assumed that switchdev should always be True). This
causes plugging VFs on systems with drivers that do not support a readable
phys_switch_id to fail.
I ran the code interactively on the host system to determine the
actual exception:
>>> f = open('/sys/class/net/enp11s17/phys_switch_id', 'r')
>>> print f.readline()
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 95] Operation not supported
From what I can tell, this should also cause plugging to fail on
systems that have no phys_switch_id file at all.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1713590/+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 1717477] [NEW] cloud-init generates ordering cycle via After=cloud-init in systemd-fsck
Public bug reported:
We're running several machines with
cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2
without problems.
Just upgraded all machines to
cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1
and rebooted them all.
All machines report ordering cycles in their dmesg, resulting in systemd
breaking the
loop by NOT starting some important services, e.g. mouting local filesystems:
Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering
cycle on networking.service/start
Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found dependency
on local-fs.target/start
Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found dependency
on home.mount/start
Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found dependency
on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found dependency
on cloud-init.service/start
Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found dependency
on networking.service/start
Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking ordering
cycle by deleting job local-fs.target/start
Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job
local-fs.target/start deleted to break ordering cycle starting with
networking.service/start
% cat /etc/fstab
LABEL=cloudimg-rootfs /ext4 defaults,discard0 1
LABEL=Home /homexfsdefaults,logbufs=8 0 2
In this case /home isn't mounted as a result of systemd breaking the loop,
resulting in services depending on /home not being started.
1. Tell us your cloud provider
AWS
2. dpkg-query -W -f='${Version}' cloud-init
0.7.9-233-ge586fe35-0ubuntu1~16.04.1
3. Any appropriate cloud-init configuration you can provide us
Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
all machines without hassle.
The problem is this change:
diff -uaNr 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
--- 153/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
1970-01-01 01:00:00.0 +0100
+++ 233/lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
2017-07-28 22:28:47.0 +0200
@@ -0,0 +1,2 @@
+[Unit]
+After=cloud-init.service
WORKAROUND
==
I just did a
rm /lib/systemd/system/systemd-fsck@.service.d/cloud-init.conf
on all machines and rebooted them: no more dependency loops reported,
everything works again.
** Affects: cloud-init
Importance: Undecided
Status: New
** Tags: systemd
** Tags added: cycle ordering
** Tags removed: cycle ordering
** Tags added: systemd
--
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/1717477
Title:
cloud-init generates ordering cycle via After=cloud-init in systemd-
fsck
Status in cloud-init:
New
Bug description:
We're running several machines with
cloud-init_0.7.9-153-g16a7302f-0ubuntu1~16.04.2
without problems.
Just upgraded all machines to
cloud-init_0.7.9-233-ge586fe35-0ubuntu1~16.04.1
and rebooted them all.
All machines report ordering cycles in their dmesg, resulting in systemd
breaking the
loop by NOT starting some important services, e.g. mouting local filesystems:
Sep 14 15:43:52.487945 noname systemd[1]: networking.service: Found ordering
cycle on networking.service/start
Sep 14 15:43:52.487952 noname systemd[1]: networking.service: Found
dependency on local-fs.target/start
Sep 14 15:43:52.487960 noname systemd[1]: networking.service: Found
dependency on home.mount/start
Sep 14 15:43:52.487968 noname systemd[1]: networking.service: Found
dependency on systemd-fsck@dev-disk-by\x2dlabel-Home.service/start
Sep 14 15:43:52.487975 noname systemd[1]: networking.service: Found
dependency on cloud-init.service/start
Sep 14 15:43:52.487982 noname systemd[1]: networking.service: Found
dependency on networking.service/start
Sep 14 15:43:52.488297 noname systemd[1]: networking.service: Breaking
ordering cycle by deleting job local-fs.target/start
Sep 14 15:43:52.488306 noname systemd[1]: local-fs.target: Job
local-fs.target/start deleted to break ordering cycle starting with
networking.service/start
% cat /etc/fstab
LABEL=cloudimg-rootfs /ext4 defaults,discard0 1
LABEL=Home/homexfsdefaults,logbufs=8 0 2
In this case /home isn't mounted as a result of systemd breaking the loop,
resulting in services depending on /home not being started.
1. Tell us your cloud provider
AWS
2. dpkg-query -W -f='${Version}' cloud-init
0.7.9-233-ge586fe35-0ubuntu1~16.04.1
3. Any appropriate cloud-init configuration you can provide us
Nothing special - worked with 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 on
all machines with
[Yahoo-eng-team] [Bug 1717470] [NEW] cloud-init should show iproute2 output with MTU
Public bug reported: cloud-init should show output of $ ip address which includes mtu in the console.log ** Affects: cloud-init Importance: Undecided Status: New ** Tags: nplanfail ** Tags added: nplanfail -- 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/1717470 Title: cloud-init should show iproute2 output with MTU Status in cloud-init: New Bug description: cloud-init should show output of $ ip address which includes mtu in the console.log To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1717470/+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 1709077] Re: Login bug when changing from admin project to private project
Reviewed: https://review.openstack.org/491479 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=8f4e02c96d3bce9ed56ef2aec40f885951769d4e Submitter: Jenkins Branch:master commit 8f4e02c96d3bce9ed56ef2aec40f885951769d4e Author: Ivan Kolodyazhny Date: Mon Aug 7 15:43:38 2017 +0300 Show NotAuthorized error message on a separate page Change-Id: I02d9d610a0e5feff7da14f86d003ec21010ab26a Closes-Bug: #1709077 ** 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/1709077 Title: Login bug when changing from admin project to private project Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Steps to reproduce: 1) we have to login as admin(e.g. user with 'admin' login) to project 'admin' 2) go to admin/instances page 3) switch project to demo (current user shouldn't be an admin in 'demo') Actual results: User will be redirected to the login page. After login in as the same user, you will be redirected to the login page again. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1709077/+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
