[Yahoo-eng-team] [Bug 1731889] Re: Nova logs adding security group to port when is actually removing a security group from a port
Reviewed: https://review.openstack.org/519313 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=01da04a0a7eff4c52bd0e35d404545f9a413b602 Submitter: Zuul Branch:master commit 01da04a0a7eff4c52bd0e35d404545f9a413b602 Author: Saverio Proto Date: Mon Nov 13 12:44:42 2017 +0100 Correct log message when removing a security group When a security group is removed from a port nova incorrectly logs this as a security group addition Change-Id: If525313c63c4553abe8bea6f2bfaf75431ed18ea Closes-bug: 1731889 ** 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/1731889 Title: Nova logs adding security group to port when is actually removing a security group from a port Status in OpenStack Compute (nova): Fix Released Bug description: This is a trivial bug, probably a cut and paste error. Not matter if you are adding a sec group to a port or of you are removing a sec group from a port. Nova will also log Adding security group to port. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731889/+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 1731250] Re: Neutron Exceptions when get neutron detailed quotas
i have resloved this bug, actually, maybe not a bug. It was my fault
when merge codes into my ocata release, sorry!
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1731250
Title:
Neutron Exceptions when get neutron detailed quotas
Status in neutron:
Invalid
Bug description:
The bug(1599488) was fixed on Jul 18, 2017, so i want to cherry-pick the
commit into my stable/ocata neutron branch,
and test the function using neutronclient with '--detail' param, but
exception was occured like this:
2017-11-09 20:16:36.357 20897 ERROR neutron.db.quota.driver
[req-0ad2b739-1e95-41b7-ab28-69a7081fdb5b - - - - -] SML key: firewall_policy
2017-11-09 20:16:36.357 20897 ERROR neutron.db.quota.driver
[req-0ad2b739-1e95-41b7-ab28-69a7081fdb5b - - - - -] SML plugins: {'FLAVORS':
, 'CORE': , 'network-ip-availability': , 'FIREWALL': , 'timestamp': , 'auto-allocated-topology':
, 'revision_plugin':
, 'TAG': , 'trunk': , 'L3_ROUTER_NAT': }
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
[req-0ad2b739-1e95-41b7-ab28-69a7081fdb5b - - - - -] details failed: No details.
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 79, in
resource
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/extensions/quotasv2_detail.py", line
56, in details
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
self._get_detailed_quotas(request, id)}
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/extensions/quotasv2_detail.py", line
46, in _get_detailed_quotas
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
resource_registry.get_all_resources(), tenant_id)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 166, in wrapped
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource return
method(*args, **kwargs)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 95, in wrapped
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource setattr(e,
'_RETRY_EXCEEDED', True)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
self.force_reraise()
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 91, in wrapped
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource return
f(*args, **kwargs)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 151, in wrapper
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource ectxt.value =
e.inner_exc
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
self.force_reraise()
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 139, in wrapper
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource return
f(*args, **kwargs)
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 131, in wrapped
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
traceback.format_exc())
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource
self.force_reraise()
2017-11-09 20:16:36.359 20897 ERROR neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils
[Yahoo-eng-team] [Bug 1732077] [NEW] Unreachable line need to be removed from stage() method of V2
Public bug reported: In stage() method of v2 api, _restore() is called after the raising Duplicate exception [1] which won't be reachable in any case after the exception is raised. _restore() changes the image_status from 'uploading' to 'queued' and data staging would start from the beginning after new stage call with same image-id even though staging data has already been loaded to store. Hence it seems there is no point in keeping that _restore() incase of Duplicate exception is raised. [1]: https://github.com/openstack/glance/blob/5d2ce20a9e31808d9e91dc5da4a124823f23ad09/glance/api/v2/image_data.py#L306 ** Affects: glance Importance: Undecided Assignee: Pranali Deore (pranali-deore) Status: In Progress ** Changed in: glance Assignee: (unassigned) => Pranali Deore (pranali-deore) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1732077 Title: Unreachable line need to be removed from stage() method of V2 Status in Glance: In Progress Bug description: In stage() method of v2 api, _restore() is called after the raising Duplicate exception [1] which won't be reachable in any case after the exception is raised. _restore() changes the image_status from 'uploading' to 'queued' and data staging would start from the beginning after new stage call with same image-id even though staging data has already been loaded to store. Hence it seems there is no point in keeping that _restore() incase of Duplicate exception is raised. [1]: https://github.com/openstack/glance/blob/5d2ce20a9e31808d9e91dc5da4a124823f23ad09/glance/api/v2/image_data.py#L306 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1732077/+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 1693689] Re: Could not determine host ip address
** Changed in: networking-bagpipe Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1693689 Title: Could not determine host ip address Status in Group Based Policy: Confirmed Status in BaGPipe: Fix Released Status in neutron: Fix Released Bug description: it seems affecting the following jobs. gate-neutron-dsvm-fullstack-ubuntu-xenial gate-neutron-dsvm-functional-ubuntu-xenial-nv gate-neutron-dsvm-functional-ubuntu-xenial gate-networking-bagpipe-dsvm-fullstack-ubuntu-xenial-nv to me it seems happening only on citycloud. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22Could%20not%20determine%20host%20ip%20address.%5C%22 eg. http://logs.openstack.org/75/437775/10/check/gate-neutron-dsvm- functional-ubuntu-xenial/22dbc16/ 2017-05-26 03:22:08.617415 | +++ functions-common:address_in_net:2286 : network=10.0.0.0 2017-05-26 03:22:08.618918 | +++ functions-common:address_in_net:2287 : local subnet 2017-05-26 03:22:08.620812 | + functions-common:address_in_net:2288 : cidr2netmask 22 2017-05-26 03:22:08.621827 | + functions-common:cidr2netmask:2304 : local 'maskpat=255 255 255 255' 2017-05-26 03:22:08.622784 | + functions-common:cidr2netmask:2305 : local 'maskdgt=254 252 248 240 224 192 128' 2017-05-26 03:22:08.623706 | + functions-common:cidr2netmask:2306 : set -- 255 255 252 2017-05-26 03:22:08.624637 | + functions-common:cidr2netmask:2307 : echo 255.255.252.0 2017-05-26 03:22:08.626091 | functions-common:address_in_net:2288 : maskip 10.0.1.215 255.255.252.0 2017-05-26 03:22:08.627654 | functions-common:maskip:2361 : local ip=10.0.1.215 2017-05-26 03:22:08.628849 | functions-common:maskip:2362 : local mask=255.255.252.0 2017-05-26 03:22:08.629910 | functions-common:maskip:2363 : local l=10.0.1 2017-05-26 03:22:08.631051 | functions-common:maskip:2363 : local r=0.1.215 2017-05-26 03:22:08.632372 | functions-common:maskip:2363 : local n=255.255.252 2017-05-26 03:22:08.633835 | functions-common:maskip:2363 : local m=255.252.0 2017-05-26 03:22:08.634883 | functions-common:maskip:2364 : local subnet 2017-05-26 03:22:08.636020 | functions-common:maskip:2365 : subnet=10.0.0.0 2017-05-26 03:22:08.637027 | functions-common:maskip:2366 : echo 10.0.0.0 2017-05-26 03:22:08.639064 | +++ functions-common:address_in_net:2288 : subnet=10.0.0.0 2017-05-26 03:22:08.640696 | +++ functions-common:address_in_net:2289 : [[ 10.0.0.0 == 10.0.0.0 ]] 2017-05-26 03:22:08.642357 | +++ functions-common:get_default_host_ip:684 : echo 2017-05-26 03:22:08.643625 | ++ stackrc:source:815 : HOST_IP= 2017-05-26 03:22:08.644779 | ++ stackrc:source:816 : '[' '' == '' ']' 2017-05-26 03:22:08.645754 | ++ stackrc:source:817 : die 817 'Could not determine host ip address. See local.conf for suggestions on setting HOST_IP.' 2017-05-26 03:22:08.646787 | ++ functions-common:die:186 : local exitcode=0 2017-05-26 03:22:08.647956 | ++ functions-common:die:187 : set +o xtrace 2017-05-26 03:22:08.648111 | [Call Trace] 2017-05-26 03:22:08.648178 | ./stack.sh:191:source 2017-05-26 03:22:08.648217 | /opt/stack/new/devstack/stackrc:817:die 2017-05-26 03:22:08.650467 | [ERROR] /opt/stack/new/devstack/stackrc:817 Could not determine host ip address. See local.conf for suggestions on setting HOST_IP. 2017-05-26 03:22:09.655121 | + /opt/stack/new/neutron/neutron/tests/contrib/gate_hook.sh:main:1 : rm -rf /tmp/tmp.nAvEK2rZvR 2017-05-26 03:22:09.657520 | ERROR: the main setup script run by this job failed - exit code: 1 2017-05-26 03:22:09.657561 | please look at the relevant log files to determine the root cause 2017-05-26 03:22:09.657575 | Running devstack worlddump.py 2017-05-26 03:22:09.866930 | Cleaning up host 2017-05-26 03:22:09.867026 | ... this takes 3 - 4 minutes (logs at logs/devstack-gate-cleanup-host.txt.gz) 2017-05-26 03:22:45.893523 | [WARNING]: No hosts matched, nothing to do 2017-05-26 03:22:46.763984 | Generating static files at /home/jenkins/workspace/gate-neutron-dsvm-functional-ubuntu-xenial/logs/ara... 2017-05-26 03:22:47.622857 | Done. 2017-05-26 03:22:49.039304 | *** FAILED with status: 1 2017-05-26 03:22:49.039942 | [Zuul] Task exit code: 1 2017-05-26 03:22:50.923786 | [Zuul] Job complete, result: FAILURE To manage notifications about this bug go to: https://bugs.launchpad.net/group-based-policy/+bug/1693689/+subscriptions -- Mailing lis
[Yahoo-eng-team] [Bug 1441155] Re: Get reservation_id when creating multiple instances
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete => Expired -- 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/1441155 Title: Get reservation_id when creating multiple instances Status in OpenStack Dashboard (Horizon): Expired Bug description: Nova client doesn't support parameter return_reservation_id when creating multiple instances to get all instances details. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1441155/+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 1427052] Re: Problems with 'Other' option in Daily Report page
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete => Expired -- 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/1427052 Title: Problems with 'Other' option in Daily Report page Status in OpenStack Dashboard (Horizon): Expired Bug description: The 'Other' option for Period field on the Admin -> Resource Usage -> Daily Report page has the following issue: When we try to generate a report for a selected period, it does not show the filtered information. It shows all the information available. Expected Behavior When a time period is selected, information corresponding to only that time period should be displayed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1427052/+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 1447976] Re: Overview usage does not include all active VMs
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete => Expired -- 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/1447976 Title: Overview usage does not include all active VMs Status in OpenStack Dashboard (Horizon): Expired Bug description: Basically I have more than 12k of active VM's in my env. Horizon dashboard, Admin/System/Overview tab shows that there only 4089 of them and only 1Tb of RAM used. That isn't correct info about a cloud. When number of VMs was low that 4k I've constantly seen a bug https://bugs.launchpad.net/bugs/1278819 also. Assuming that stats aren't online I waited about 2 days but nothing was changed regarding that. Still 4089 VMs. But if you go to the project itself and open overview page with all usage statistics then it will show correct number of VMs, Cores, RAM for this project. So steps to reproduce: 1. Get cloud with at least 5k VMs (looks like). 2. Take a look on stats. Expected behavior: All VM's should be reflected in counters. Observed behavior: Not all of the VMs was taken into the consideration. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1447976/+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 1611632] Re: [RFE] neutron_dynamic_routing project is bound to rpc driver closely
[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/1611632 Title: [RFE] neutron_dynamic_routing project is bound to rpc driver closely Status in neutron: Expired Bug description: The interface https://github.com/openstack/neutron-dynamic- routing/blob/master/neutron_dynamic_routing/services/bgp/bgp_plugin.py is bound to rpc driver so closely, it is not suitable to extend the BGP driver which is agentless. So we need to do following steps: 1> Refactor the code to support agentless driver 2> Using service_providers method to load the different driver 3> Deliver an overall agent driver interface so that some agent driver such as quagga and ryu are easy to be load. For this refactor, I added followings in my patch https://review.openstack.org/#/c/349921/. 1> Add a new configuration file named neutron_dynamic_routing.conf to provider the service_providers configuration. 2> The neutron-bgp-dragent binary will invoke the neutron_dynamic_routing.conf file. 3> The default service_providers will be DYNAMIC_ROUTING:RPCDriver:neutron_dynamic_routing.services.bgp.service_drivers.rpc_bgp.BgpRpcPluginDriver:default 4> Now the bgp_plugin.py will be a unified the interface to invoking the dynamic routing, the rpc_bgp.py will be a agent driver and be responsible for interact with lower layer interface such as ryu/quagga. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611632/+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 1732067] [NEW] openvswitch firewall flows cause flooding on integration bridge
Public bug reported: Environment: OpenStack Newton Driver: ML2 w/ OVS Firewall: openvswitch In this environment, we have observed OVS flooding network traffic across all ports in a given VLAN on the integration bridge due to the lack of a FDB entry for the destination MAC address. Across the large fleet of 240+ nodes, this is causing a considerable amount of noise on any given node. In this test, we have 3 machines: Client: fa:16:3e:e8:59:00 (10.10.60.2) Server: fa:16:3e:80:cb:0a (10.10.60.9) Bystander: fa:16:3e:a0:ee:02 (10.10.60.10) The server is running a web server using netcat: while true ; do sudo nc -l -p 80 < index.html ; done Client requests page using curl: ip netns exec qdhcp-b07e6cb3-0943-45a2-b5ff-efb7e99e4d3d curl http://10.10.60.9/ We should expect to see the communication limited to the client and server. However, the captures below reflect the server->client responses being broadcast out all tap interfaces connected to br-int in the same local vlan: root@osa-newton-ovs-compute01:~# tcpdump -i tap5f03424d-1c -ne port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap5f03424d-1c, link-type EN10MB (Ethernet), capture size 262144 bytes 02:20:30.190675 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 74: 10.10.60.2.54796 > 10.10.60.9.80: Flags [S], seq 213484442, win 29200, options [mss 1460,sackOK,TS val 140883559 ecr 0,nop,wscale 7], length 0 02:20:30.191926 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 74: 10.10.60.9.80 > 10.10.60.2.54796: Flags [S.], seq 90006557, ack 213484443, win 14480, options [mss 1460,sackOK,TS val 95716 ecr 140883559,nop,wscale 4], length 0 02:20:30.192837 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 66: 10.10.60.2.54796 > 10.10.60.9.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 140883560 ecr 95716], length 0 02:20:30.192986 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 140: 10.10.60.2.54796 > 10.10.60.9.80: Flags [P.], seq 1:75, ack 1, win 229, options [nop,nop,TS val 140883560 ecr 95716], length 74: HTTP: GET / HTTP/1.1 02:20:30.195806 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 79: 10.10.60.9.80 > 10.10.60.2.54796: Flags [P.], seq 1:14, ack 1, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 13: HTTP 02:20:30.196207 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 66: 10.10.60.2.54796 > 10.10.60.9.80: Flags [.], ack 14, win 229, options [nop,nop,TS val 140883561 ecr 95717], length 0 02:20:30.197481 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 66: 10.10.60.9.80 > 10.10.60.2.54796: Flags [.], ack 75, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 0 ^^^ On the server tap we see the bi-directional traffic root@osa-newton-ovs-compute01:/home/ubuntu# tcpdump -i tapb8051da9-60 -ne port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tapb8051da9-60, link-type EN10MB (Ethernet), capture size 262144 bytes 02:20:30.192165 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 74: 10.10.60.9.80 > 10.10.60.2.54796: Flags [S.], seq 90006557, ack 213484443, win 14480, options [mss 1460,sackOK,TS val 95716 ecr 140883559,nop,wscale 4], length 0 02:20:30.195827 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 79: 10.10.60.9.80 > 10.10.60.2.54796: Flags [P.], seq 1:14, ack 1, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 13: HTTP 02:20:30.197500 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 66: 10.10.60.9.80 > 10.10.60.2.54796: Flags [.], ack 75, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 0 ^^^ On the bystander tap we see the flooded traffic The FDB tables reflect the lack of CAM entry for the client on br-int bridge. I would expect to see the MAC address on the patch uplink: root@osa-newton-ovs-compute01:/home/ubuntu# ovs-appctl fdb/show br-int | grep 'fa:16:3e:e8:59:00' root@osa-newton-ovs-compute01:/home/ubuntu# ovs-appctl fdb/show br-provider | grep 'fa:16:3e:e8:59:00' 2 850 fa:16:3e:e8:59:003 Sources[1] point to the fact that an 'output' action negates the MAC learning mechanism in OVS. Related Table 82 entries are below, and code is here[2]: cookie=0x94ebb7913c37a0ec, duration=415.490s, table=82, n_packets=5, n_bytes=424, idle_age=31, priority=70,ct_state=+est-rel-rpl,tcp,reg5=0xd,dl_dst=fa:16:3e:80:cb:0a,tp_dst=80 actions=strip_vlan,output:13 cookie=0x94ebb7913c37a0ec, duration=415.489s, table=82, n_packets=354, n_bytes=35229, idle_age=154, priority=70,ct_state=+est-rel-rpl,tcp,reg5=0xd,dl_dst=fa:16:3e:80:cb:0a,tp_dst=22 actions=strip_vlan,output:13 cookie=0x94ebb7913c37a0ec, duration=415.489s, table=82, n_packets=1, n_bytes=78, idle_age=154, priority=70,ct_state=+new-est,tcp,reg5=0xd,dl_dst=fa:16:3e:80:cb:0a,tp_dst=80
[Yahoo-eng-team] [Bug 1732064] [NEW] growpart + resizefs doesn't work on non-root partions
Public bug reported: Image is ubuntu 16.04, cloud-init version is 0.7.9 and platform is openstack The volume has three partitions /dev/vda1 / /dev/vda2 swap /dev/vda3 /var I'm using cloud-init growpart config as follows: growpart: mode: auto devices: ["/var"] ignore_growroot_disabled:true after boot, check the partition with fdisk -l /dev/vda3 shows the part is extended as expected, but the df -lh shows that the fs size is still old size and not extended. after manually execute resize2fs /dev/vda3, the output of df matched with fdisk。 ** 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/1732064 Title: growpart + resizefs doesn't work on non-root partions Status in cloud-init: New Bug description: Image is ubuntu 16.04, cloud-init version is 0.7.9 and platform is openstack The volume has three partitions /dev/vda1 / /dev/vda2 swap /dev/vda3 /var I'm using cloud-init growpart config as follows: growpart: mode: auto devices: ["/var"] ignore_growroot_disabled:true after boot, check the partition with fdisk -l /dev/vda3 shows the part is extended as expected, but the df -lh shows that the fs size is still old size and not extended. after manually execute resize2fs /dev/vda3, the output of df matched with fdisk。 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1732064/+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 1730959] Re: [RFE] Add timestamp to LBaaS resources
Marked invalid in Octavia: https://storyboard.openstack.org/#!/story/2001277 ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1730959 Title: [RFE] Add timestamp to LBaaS resources Status in neutron: Invalid Bug description: Currently most of Neutron resources are support timestamp (like create_at, update_at). This is also useful for LBaaS related resources, for the sake of monitoring resources or querying. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1730959/+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 1732024] [NEW] docs: unit tests doc links to hacking repo docs which isn't particularly helpful
Public bug reported: This page: https://docs.openstack.org/nova/latest/contributor/testing.html#unit- tests Links to: https://docs.openstack.org/hacking/latest/user/hacking.html#creating- unit-tests Which is specific to writing unit tests for the hacking repo, not nova. The nova docs should probably point at the nova hacking docs instead: https://github.com/openstack/nova/blob/master/HACKING.rst#creating-unit- tests ** Affects: nova Importance: Medium Status: Triaged ** Tags: docs ** Changed in: nova Status: New => Triaged -- 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/1732024 Title: docs: unit tests doc links to hacking repo docs which isn't particularly helpful Status in OpenStack Compute (nova): Triaged Bug description: This page: https://docs.openstack.org/nova/latest/contributor/testing.html#unit- tests Links to: https://docs.openstack.org/hacking/latest/user/hacking.html#creating- unit-tests Which is specific to writing unit tests for the hacking repo, not nova. The nova docs should probably point at the nova hacking docs instead: https://github.com/openstack/nova/blob/master/HACKING.rst#creating- unit-tests To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1732024/+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 1700651] Re: Neutron fails to initialize with a core plugin not based on the Neutron DB model
Reviewed: https://review.openstack.org/518788 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=69d0047cfe969da02d44c036fc3c97a1bfdffc19 Submitter: Zuul Branch:master commit 69d0047cfe969da02d44c036fc3c97a1bfdffc19 Author: Armando Migliaccio Date: Thu Nov 9 12:24:04 2017 -0800 Do not load default service plugins if core plugin is not DB based Some service plugins make the assumption that Neutron is running with a datastore (e.g. revision and timestamps). As the datastore setup is a responsibility of the Neutron core plugin, checking that this is indeed true avoids errors for those plugins that do not implement any DB backend (e.g. monolithic OpenContrail plugin). Change-Id: I872fa6e3c3925e521150d79bba864101d9a5f648 Closes-bug: #1700651 ** 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/1700651 Title: Neutron fails to initialize with a core plugin not based on the Neutron DB model Status in neutron: Fix Released Bug description: Since patch [1], Neutron server load a default service plugins list which all of them depends on the Neutron DB model. So for a core plugin which implements only the NeutronPluginBaseV2 interface [2] and not the NeutronDbPluginV2 interface [3], most of the service plugins of that list will be initialized without any errors (only the timestamp plugin fails to initialize because it tries to do DB stuff in its constructor [4] on master (future Pike release)). And all API extensions of that service plugins are listed as supported but none of them works. Resources are not extended (tag, revision, auto-allocate) or some API extensions returns 404 (network-ip-availability or flavors). [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce [2] https://github.com/openstack/neutron/blob/master/neutron/neutron_plugin_base_v2.py#L30 [3] https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L124 [4] https://github.com/openstack/neutron/blob/master/neutron/services/timestamp/timestamp_plugin.py#L32 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1700651/+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 1731986] Re: nova snapshot_volume_backed failure does not thaw filesystems
** Also affects: nova/ocata Importance: Undecided Status: New ** Also affects: nova/pike 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/1731986 Title: nova snapshot_volume_backed failure does not thaw filesystems Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) ocata series: New Status in OpenStack Compute (nova) pike series: New Bug description: Noticed in OpenStack Mitaka (commit 9825c80), but the function (snapshot_volume_backed) is unchanged as of commit a4fc1bcd. backends: Libvirt + Ceph. When Nova attempts to create an image / snapshot of a volume-backed instance it first quiesces the instance in `snapshot_volume_backed()`. It then loops over all of the block devices associated with that instance. However, there is no exception handling in the for loop and any failures on the part of Cinder are bubbled up and through the `snapshot_volume_backed()` function. This causes the needed `unquiesce()` to never be called on the instance, leaving it in an inconsistent (read-only) state. This can cause operational errors in the instance leaving it unusable. In my case, the steps for reproduction are: 1) nova create image / ( "create snapshot" via horizon ) 2) nova/compute/api snapshot_volume_backed() calls quiesce 3) "qemu-ga: info: guest-fsfreeze called" is seen in instance 4) cinder fails snapshot of volume due to OverLimit 5) cinder raises OverLimit 6) snapshot_volume_backed() never finishes due to OverLimit 7) filesystem is never thawed 8) instance unusable I am in the process of writing and testing a patch and will have a review for it soon. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731986/+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 1732000] [NEW] nova-api does not log config options when run in wsgi mode
Public bug reported: The ServiceLauncher/ProcessLauncher code in oslo.services will check a 'log_options' option on start of the service/process and if True (the default) it will log the config option values. The nova-api service used to run with eventlet only via oslo.service, but since Pike we can run nova-api using wsgi (uwsgi, mod_wsgi, etc). However, the wsgi app doesn't log the config options. Compare to this ocata nova-api log: http://logs.openstack.org/59/509659/1/check/legacy-tempest-dsvm-neutron- full/d84ca9f/logs/screen-n-api.txt.gz To master (queens): http://logs.openstack.org/04/514904/20/check/legacy-tempest-dsvm- neutron-full/0cd3ce7/logs/screen-n-api.txt.gz The placement-api wsgi app does log the options, but uses different logic (it doesn't honor the log_options option): http://logs.openstack.org/04/514904/20/check/legacy-tempest-dsvm- neutron-full/0cd3ce7/logs/screen-placement- api.txt.gz#_Nov_10_06_47_27_532714 https://github.com/openstack/nova/blob/16.0.0/nova/api/openstack/placement/wsgi.py#L59 So there are two things to fix here: 1. nova-api should log config options on startup when running under wsgi. 2. placement-api should check the log_options option rather than the debug option. ** Affects: nova Importance: Medium Assignee: Matt Riedemann (mriedem) Status: Triaged ** Affects: nova/pike Importance: Undecided Status: New ** Tags: api placement ** Also affects: nova/pike 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/1732000 Title: nova-api does not log config options when run in wsgi mode Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) pike series: New Bug description: The ServiceLauncher/ProcessLauncher code in oslo.services will check a 'log_options' option on start of the service/process and if True (the default) it will log the config option values. The nova-api service used to run with eventlet only via oslo.service, but since Pike we can run nova-api using wsgi (uwsgi, mod_wsgi, etc). However, the wsgi app doesn't log the config options. Compare to this ocata nova-api log: http://logs.openstack.org/59/509659/1/check/legacy-tempest-dsvm- neutron-full/d84ca9f/logs/screen-n-api.txt.gz To master (queens): http://logs.openstack.org/04/514904/20/check/legacy-tempest-dsvm- neutron-full/0cd3ce7/logs/screen-n-api.txt.gz The placement-api wsgi app does log the options, but uses different logic (it doesn't honor the log_options option): http://logs.openstack.org/04/514904/20/check/legacy-tempest-dsvm- neutron-full/0cd3ce7/logs/screen-placement- api.txt.gz#_Nov_10_06_47_27_532714 https://github.com/openstack/nova/blob/16.0.0/nova/api/openstack/placement/wsgi.py#L59 So there are two things to fix here: 1. nova-api should log config options on startup when running under wsgi. 2. placement-api should check the log_options option rather than the debug option. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1732000/+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 1728884] Re: A missing versioned notification sample
Reviewed: https://review.openstack.org/516582 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=97eb86661975cd371a821858be10f8eac144fca4 Submitter: Zuul Branch:master commit 97eb86661975cd371a821858be10f8eac144fca4 Author: Takashi NATSUME Date: Tue Oct 31 19:14:20 2017 +0900 Fix missing versioned notification sample Add the 'instance-interface_attach-error' notification sample to the nova document. Change-Id: Ife45fd30fd723675b45c7170e02358ab352e05e0 CLoses-Bug: #1728884 ** 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/1728884 Title: A missing versioned notification sample Status in OpenStack Compute (nova): Fix Released Bug description: In versioned notification samples(*1), a sample of 'instance- interface_attach-error' is missing. *1: https://docs.openstack.org/nova/latest/reference/notifications.html #versioned-notification-samples To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1728884/+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 1731986] [NEW] nova snapshot_volume_backed failure does not thaw filesystems
Public bug reported: Noticed in OpenStack Mitaka (commit 9825c80), but the function (snapshot_volume_backed) is unchanged as of commit a4fc1bcd. backends: Libvirt + Ceph. When Nova attempts to create an image / snapshot of a volume-backed instance it first quiesces the instance in `snapshot_volume_backed()`. It then loops over all of the block devices associated with that instance. However, there is no exception handling in the for loop and any failures on the part of Cinder are bubbled up and through the `snapshot_volume_backed()` function. This causes the needed `unquiesce()` to never be called on the instance, leaving it in an inconsistent (read-only) state. This can cause operational errors in the instance leaving it unusable. In my case, the steps for reproduction are: 1) nova create image / ( "create snapshot" via horizon ) 2) nova/compute/api snapshot_volume_backed() calls quiesce 3) "qemu-ga: info: guest-fsfreeze called" is seen in instance 4) cinder fails snapshot of volume due to OverLimit 5) cinder raises OverLimit 6) snapshot_volume_backed() never finishes due to OverLimit 7) filesystem is never thawed 8) instance unusable I am in the process of writing and testing a patch and will have a review for it soon. ** Affects: nova Importance: High Assignee: Eric M Gonzalez (egrh3) Status: Triaged ** Tags: api volumes -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1731986 Title: nova snapshot_volume_backed failure does not thaw filesystems Status in OpenStack Compute (nova): Triaged Bug description: Noticed in OpenStack Mitaka (commit 9825c80), but the function (snapshot_volume_backed) is unchanged as of commit a4fc1bcd. backends: Libvirt + Ceph. When Nova attempts to create an image / snapshot of a volume-backed instance it first quiesces the instance in `snapshot_volume_backed()`. It then loops over all of the block devices associated with that instance. However, there is no exception handling in the for loop and any failures on the part of Cinder are bubbled up and through the `snapshot_volume_backed()` function. This causes the needed `unquiesce()` to never be called on the instance, leaving it in an inconsistent (read-only) state. This can cause operational errors in the instance leaving it unusable. In my case, the steps for reproduction are: 1) nova create image / ( "create snapshot" via horizon ) 2) nova/compute/api snapshot_volume_backed() calls quiesce 3) "qemu-ga: info: guest-fsfreeze called" is seen in instance 4) cinder fails snapshot of volume due to OverLimit 5) cinder raises OverLimit 6) snapshot_volume_backed() never finishes due to OverLimit 7) filesystem is never thawed 8) instance unusable I am in the process of writing and testing a patch and will have a review for it soon. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731986/+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 1731980] [NEW] Redirect to login after Authentication completed. without explanation
Public bug reported:
Using current master and a Newton Keystone v3 Horizon is stuck on login
page.
LOGGING set to debug:
2017-11-13 16:54:01,304 DEBUG openstack_auth.backend backend: Beginning user
authentication
2017-11-13 16:54:01,305 DEBUG openstack_auth.plugin.password password:
Attempting to authenticate for cloud_admin
2017-11-13 16:54:01,947 DEBUG openstack_auth.backend backend: Authentication
completed.
2017-11-13 16:54:01,948 INFO openstack_auth.forms forms: Login successful for
user "cloud_admin", remote address 127.0.0.1.
2017-11-13 16:54:01,951 INFO horizon.operation_log operation_log: [127.0.0.1]
[None] [None] [cloud_admin] [a5fd590f97ed41bebd2250973b12f49a] [cloud_admin]
[x] [https] [/auth/login/] [/auth/login/] [None] [POST] [302]
[{"fake_email": "", "username": "cloud_admin", "domain": "cloud_admin",
"fake_password": "", "region": "http://172.29.236.9:35357/v3";, "next": "/",
"csrfmiddlewaretoken": "xxxyy", "password": ""}]
** 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/1731980
Title:
Redirect to login after Authentication completed. without explanation
Status in OpenStack Dashboard (Horizon):
New
Bug description:
Using current master and a Newton Keystone v3 Horizon is stuck on
login page.
LOGGING set to debug:
2017-11-13 16:54:01,304 DEBUG openstack_auth.backend backend: Beginning user
authentication
2017-11-13 16:54:01,305 DEBUG openstack_auth.plugin.password password:
Attempting to authenticate for cloud_admin
2017-11-13 16:54:01,947 DEBUG openstack_auth.backend backend: Authentication
completed.
2017-11-13 16:54:01,948 INFO openstack_auth.forms forms: Login successful for
user "cloud_admin", remote address 127.0.0.1.
2017-11-13 16:54:01,951 INFO horizon.operation_log operation_log: [127.0.0.1]
[None] [None] [cloud_admin] [a5fd590f97ed41bebd2250973b12f49a] [cloud_admin]
[x] [https] [/auth/login/] [/auth/login/] [None] [POST] [302]
[{"fake_email": "", "username": "cloud_admin", "domain": "cloud_admin",
"fake_password": "", "region": "http://172.29.236.9:35357/v3";, "next": "/",
"csrfmiddlewaretoken": "xxxyy", "password": ""}]
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1731980/+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 1575146] Re: [RFE] ovs port status should the same as physnet.
** 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/1575146 Title: [RFE] ovs port status should the same as physnet. Status in neutron: Fix Released Bug description: In some case， when physnet is down. VM should know the status of it. But now we don't. So mybe we will add a function of this. Maybe we should add a configure option. When 'True', the port in VM should be down when the physnet in host is down. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1575146/+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 1727988] Re: _setUpExtension signature change breaking unit tests
** Changed in: bgpvpn 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/1727988 Title: _setUpExtension signature change breaking unit tests Status in networking-bgpvpn: Fix Released Status in networking-sfc: New Status in neutron: Fix Released Bug description: https://review.openstack.org/#/c/514470/ changed the signature for _setUpExtension which breaks many unit tests for API extensions in neutron-related projects. TypeError: _setUpExtension() got multiple values for keyword argument 'plural_mappings' http://logs.openstack.org/70/513670/7/check/openstack-tox- py27/59ddc66/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1727988/+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 1731953] [NEW] Modifying security groups when using openvswitch firewall causes existing connections to drop
Public bug reported:
Environment: OpenStack Newton
Driver: ML2 w/ OVS
Firewall: openvswitch
Clients using an OpenStack cloud based on the Newton release are facing
network issues when updating security groups/rules. We are able to
replicate the issue by modifying security group rules in an existing
security group applied to a port.
Test scenario:
--
1. Built a test instance. Example:
root@osctrl-utility-container-8ad9622f:~# openstack server show
rackspace-jamesdenton-01
WARNING: openstackclient.common.utils is deprecated and will be removed after
Jun 2017. Please use osc_lib.utils
+--++
| Field| Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | oscomp-h126
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | oscomp-h126
|
| OS-EXT-SRV-ATTR:instance_name| instance-00014fed
|
| OS-EXT-STS:power_state | Running
|
| OS-EXT-STS:task_state| None
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2017-11-13T14:57:09.00
|
| OS-SRV-USG:terminated_at | None
|
| accessIPv4 |
|
| accessIPv6 |
|
| addresses|
Public=2001::::f816:3eff:fef2:457a, 192.168.2.200 |
| config_drive |
|
| created | 2017-11-13T14:56:54Z
|
| flavor | m1.medium (103)
|
| hostId |
1599f0caa6bb0775a5b8b2b4ee76a23a9135e9d84e7844c53543541f |
| id | 5d5afb5b-778c-46fc-8dbb-31c62a4e45d5
|
| image| Ubuntu-Trusty-20170310
(80267974-d0fc-4016-9338-3a057671782a) |
| key_name | rpc_support
|
| name | rackspace-jamesdenton-01
|
| os-extended-volumes:volumes_attached | []
|
| progress | 0
|
| project_id | 723cdf11c4dd41ca9eeb47cb0576eb71
|
| properties |
|
| security_groups | [{u'name': u'rpc-support'}]
|
| status | ACTIVE
|
| updated | 2017-11-13T14:57:10Z
|
| user_id | 74cebd9525a843fcb374af1ea3a91fea
|
+--++
2. Initiate a 4G image download from the VM
# wget -4 -O /dev/null
http://centos.mirror.constant.com/7.4.1708/isos/x86_64/CentOS-7-x86_64-DVD-1708.iso
--2017-11-13 15:00:59--
http://centos.mirror.constant.com/7.4.1708/isos/x86_64/CentOS-7-x86_64-DVD-1708.iso
Resolving centos.mirror.constant.com (centos.mirror.constant.com)... 108.61.5.83
Connecting to centos.mirror.constant.com
(centos.mirror.constant.com)|108.61.5.83|:80... connected.
HTTP request sent, awa
[Yahoo-eng-team] [Bug 1731948] [NEW] Wrong OVO classes registered in some cases
Public bug reported: When patch https://review.openstack.org/#/c/321001 was merged some UT in projects like networking-midonet started failing. It is reported on https://bugs.launchpad.net/networking-midonet/+bug/1731623 It looks that reason of this problem is that wrong OVO classes are registered in case when e.g. 2 different projects uses same names of OVO objects. I checked it little bit and it looks that neutron.objects.subnet.Subnet has got registered os_vif.objects.route.Route object instead of neutron.objects.subnet.Route, see my logs from one exampled test: http://paste.openstack.org/show/626170/ ** Affects: neutron Importance: Medium Status: New ** Project changed: networking-midonet => neutron ** Changed in: neutron Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1731948 Title: Wrong OVO classes registered in some cases Status in neutron: New Bug description: When patch https://review.openstack.org/#/c/321001 was merged some UT in projects like networking-midonet started failing. It is reported on https://bugs.launchpad.net/networking-midonet/+bug/1731623 It looks that reason of this problem is that wrong OVO classes are registered in case when e.g. 2 different projects uses same names of OVO objects. I checked it little bit and it looks that neutron.objects.subnet.Subnet has got registered os_vif.objects.route.Route object instead of neutron.objects.subnet.Route, see my logs from one exampled test: http://paste.openstack.org/show/626170/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1731948/+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 1731948] [NEW] Wrong OVO classes registered in some cases
You have been subscribed to a public bug: When patch https://review.openstack.org/#/c/321001 was merged some UT in projects like networking-midonet started failing. It is reported on https://bugs.launchpad.net/networking-midonet/+bug/1731623 It looks that reason of this problem is that wrong OVO classes are registered in case when e.g. 2 different projects uses same names of OVO objects. I checked it little bit and it looks that neutron.objects.subnet.Subnet has got registered os_vif.objects.route.Route object instead of neutron.objects.subnet.Route, see my logs from one exampled test: http://paste.openstack.org/show/626170/ ** Affects: neutron Importance: Undecided Status: New -- Wrong OVO classes registered in some cases https://bugs.launchpad.net/bugs/1731948 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. -- 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 1731936] [NEW] Nova returns a 500 error when changes-since filter is poorly formatted
Public bug reported: Description === When running tempest, we are seeing failures in nova-api. The test test_get_servers_allows_changes_since_bad_value (https://github.com/openstack/nova/blob/stable/pike/nova/tests/unit/api/openstack/compute/test_serversV21.py#L1186) causes nova to return a 500 error. The core of the issue is that when passing a "changes-since" filter to nova in a poor format, oslo_utils.timeutils raises an error that isn't being caught. This appears to be due to a recent commit which added whitelisting to nova, but seems to have over-zealously removed a try/except that was catching the error. Steps to reproduce == Run tempest's nova tests. Expected result === Nova-api should be returning a 400 code when given a bad changes-since filter, as defined by https://developer.openstack.org/api-ref/compute/#list-servers. Actual result = We're seeing a 500 error in nova-api logs. Environment === Currently seeing this in Ocata, but it looks like it should be happening in anything Ocata+. This is a pretty simple/basic install with kvm HVs and a ceph backend. Logs & Configs == 2017-11-08 15:46:38.271 2640892 INFO nova.osapi_compute.wsgi.server [req-0fb396b8-98b8-4edf-b5d8-d1fcaa381171 7be9f09f79e44d80b213b516abaa0a4e f7ba36851c724e939369cda1731c9a41 - - -] 10.6.30.3,10.6.8.56 "GET /v2/f7ba36851c724e939369cda1731 c9a41/servers?changes-since=2051-01-01T12%3A34%3A00Z HTTP/1.1" status: 200 len: 206 time: 0.0878329 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions [req-6e521f71-8526-4671-9c06-384eec3d0b8d 7be9f09f79e44d80b213b516abaa0a4e f7ba36851c724e939369cda1731c9a41 - - -] Unexpected exception in API method 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions File "/opt/nova/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 338, in wrapped 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions File "/opt/nova/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 181, in wrapper 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions File "/opt/nova/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 181, in wrapper 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions File "/opt/nova/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 201, in index 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions servers = self._get_servers(req, is_detail=False) 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions File "/opt/nova/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 260, in _get_servers 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions search_opts['changes-since']) 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions File "/opt/nova/lib/python2.7/site-packages/oslo_utils/timeutils.py", line 67, in parse_isotime 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions raise ValueError(six.text_type(e)) 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions ValueError: Unable to parse date string u'2011/01/01' 2017-11-08 15:46:38.315 2640894 ERROR nova.api.openstack.extensions 2017-11-08 15:46:38.317 2640894 INFO nova.api.openstack.wsgi [req-6e521f71-8526-4671-9c06-384eec3d0b8d 7be9f09f79e44d80b213b516abaa0a4e f7ba36851c724e939369cda1731c9a41 - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2017-11-08 15:46:38.318 2640894 INFO nova.osapi_compute.wsgi.server [req-6e521f71-8526-4671-9c06-384eec3d0b8d 7be9f09f79e44d80b213b516abaa0a4e f7ba36851c724e939369cda1731c9a41 - - -] 10.6.30.3,10.6.8.56 "GET /v2/f7ba36851c724e939369cda1731 c9a41/servers?changes-since=2011%2F01%2F01 HTTP/1.1" status: 500 len: 420 time: 0.0323260 ** Affects: nova Importance: Undecided Assignee: David-wahlstrom (david-wahlstrom) Status: In Progress -- 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/1731936 Title: Nova returns a 500 error when changes-since filter is poorly formatted Status in OpenStack Compute (nova): In Progress Bug description: Description === When running tempest, we are seeing failures in nova-api. The test test_get_servers_allows_changes_since_bad_value (https://github.com/o
[Yahoo-eng-team] [Bug 1731623] Re: many UT cases are broken due to "AttributeError: type object 'Route' has no attribute 'foreign_keys'"
Reviewed: https://review.openstack.org/519017
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=1470baf02beb6e9f732129edc4c8979881ddea8f
Submitter: Zuul
Branch:master
commit 1470baf02beb6e9f732129edc4c8979881ddea8f
Author: YAMAMOTO Takashi
Date: Sat Nov 11 13:16:43 2017 +
Revert "objects: get, update and delete converted to Subnet OVO usage"
This reverts commit 32c757babd1622b72fa15a8f5fb1248ff9e45ddf.
Closes-Bug: #1731623
Change-Id: Ie5c773165948d6db55f1b7ba3b7e312a5bb1318b
** 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/1731623
Title:
many UT cases are broken due to "AttributeError: type object 'Route'
has no attribute 'foreign_keys'"
Status in networking-midonet:
New
Status in neutron:
Fix Released
Bug description:
eg. http://logs.openstack.org/24/518824/1/gate/openstack-tox-
py27/6ea4c06/job-output.txt.gz
2017-11-11 07:19:32.914772 | ubuntu-xenial | {2}
midonet.neutron.tests.unit.test_extension_taas.TestMidonetTaasCaseML2.test_delete_tap_service_error_delete_neutron_resource
[0.865560s] ... ok
2017-11-11 07:19:32.931319 | ubuntu-xenial | INFO
[alembic.runtime.migration] Running upgrade 24f28869838b -> 41b509d10b5e,
VPNaaS endpoint groups
2017-11-11 07:19:32.947636 | ubuntu-xenial | add_router_interface failed: No
details.
2017-11-11 07:19:32.947704 | ubuntu-xenial | Traceback (most recent call
last):
2017-11-11 07:19:32.947748 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/api/v2/resource.py",
line 98, in resource
2017-11-11 07:19:32.947775 | ubuntu-xenial | result =
method(request=request, **args)
2017-11-11 07:19:32.947812 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line
92, in wrapped
2017-11-11 07:19:32.947837 | ubuntu-xenial | setattr(e,
'_RETRY_EXCEEDED', True)
2017-11-11 07:19:32.947889 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-11-11 07:19:32.947946 | ubuntu-xenial | self.force_reraise()
2017-11-11 07:19:32.948002 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
2017-11-11 07:19:32.948029 | ubuntu-xenial | six.reraise(self.type_,
self.value, self.tb)
2017-11-11 07:19:32.948086 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line
88, in wrapped
2017-11-11 07:19:32.948117 | ubuntu-xenial | return f(*args, **kwargs)
2017-11-11 07:19:32.948169 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py",
line 150, in wrapper
2017-11-11 07:19:32.948191 | ubuntu-xenial | ectxt.value = e.inner_exc
2017-11-11 07:19:32.948259 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-11-11 07:19:32.948291 | ubuntu-xenial | self.force_reraise()
2017-11-11 07:19:32.948363 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
2017-11-11 07:19:32.948393 | ubuntu-xenial | six.reraise(self.type_,
self.value, self.tb)
2017-11-11 07:19:32.948444 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py",
line 138, in wrapper
2017-11-11 07:19:32.948466 | ubuntu-xenial | return f(*args, **kwargs)
2017-11-11 07:19:32.948504 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/neutron/neutron/db/api.py", line
127, in wrapped
2017-11-11 07:19:32.948533 | ubuntu-xenial | LOG.debug("Retry wrapper got
retriable exception: %s", e)
2017-11-11 07:19:32.948586 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-11-11 07:19:32.948607 | ubuntu-xenial | self.force_reraise()
2017-11-11 07:19:32.948659 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/openstack/networking-midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
2017-11-11 07:19:32.948686 | ubuntu-xenial | six.reraise(self.type_,
self.value, self.tb)
2017-11-11 07:19:32.948723 | ubuntu-xenial | File
"/home/zuul/src/git.openstack.org/opens
[Yahoo-eng-team] [Bug 1731889] [NEW] Nova logs adding security group to port when is actually removing a security group from a port
Public bug reported: This is a trivial bug, probably a cut and paste error. Not matter if you are adding a sec group to a port or of you are removing a sec group from a port. Nova will also log Adding security group to port. ** Affects: nova Importance: Undecided Assignee: Saverio Proto (zioproto) Status: In Progress -- 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/1731889 Title: Nova logs adding security group to port when is actually removing a security group from a port Status in OpenStack Compute (nova): In Progress Bug description: This is a trivial bug, probably a cut and paste error. Not matter if you are adding a sec group to a port or of you are removing a sec group from a port. Nova will also log Adding security group to port. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731889/+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 1731884] [NEW] Image metadata button doesn't work if only one item is available
Public bug reported: If we have only one metadata item assigned, toggle button look confusing. Steps to reproduce: 1. Create signed Glance image. 2. Open Admin -> System -> Images 3. click on "Image Signature Verification" button for a signed Image. Actual: Nothing happens ** Affects: horizon Importance: Undecided Assignee: Ivan Kolodyazhny (e0ne) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1731884 Title: Image metadata button doesn't work if only one item is available Status in OpenStack Dashboard (Horizon): In Progress Bug description: If we have only one metadata item assigned, toggle button look confusing. Steps to reproduce: 1. Create signed Glance image. 2. Open Admin -> System -> Images 3. click on "Image Signature Verification" button for a signed Image. Actual: Nothing happens To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1731884/+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 1682796] Re: release note entries included for wrong release
Reviewed: https://review.openstack.org/518961
Committed:
https://git.openstack.org/cgit/openstack/reno/commit/?id=bcc65c9e846c829158671ccfbcd0308284f2092a
Submitter: Zuul
Branch:master
commit bcc65c9e846c829158671ccfbcd0308284f2092a
Author: Doug Hellmann
Date: Thu Nov 9 20:08:07 2017 +1100
ignore changes until the file is added within the scanned range
Ignore changes to a note file until the scanner encounters the git
operation that adds the file. This ensures that if a file is modified
on master when it should be modified on another branch the note is not
incorporated into the notes for the next release from master.
Change-Id: I4e41c482695e93ebb5a73866c432636201a7534f
Fixes-Bug: #1682796
Signed-off-by: Doug Hellmann
** Changed in: reno
Status: Confirmed => 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/1682796
Title:
release note entries included for wrong release
Status in neutron:
In Progress
Status in reno:
Fix Released
Bug description:
ocata release note [1] has an entry for mitaka. [2]
it seems the file has been updated in ocata cycle. [3]
[1] https://docs.openstack.org/releasenotes/neutron/ocata.html
[2] hyperv-neutron-agent-decomposition-ae6a052aeb48c6ac.yaml
("Hyper-V Neutron Agent has been fully decomposed from Neutron.")
[3] Iec8494b40fed2d427c1edf4609f8b3dd8c770dce
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1682796/+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 1483917] Re: 'make test' command fails because 'test' isnt defined in Makefile
** Changed in: horizon Milestone: next => None ** Changed in: horizon Status: Confirmed => Won't Fix -- 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/1483917 Title: 'make test' command fails because 'test' isnt defined in Makefile Status in OpenStack Dashboard (Horizon): Won't Fix Bug description: the Makefile suggests that in order to run tests, use 'make test' command but it fails and since looking into source code , there is no test defined https://github.com/openstack/horizon/blob/master/Makefile To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1483917/+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 1729741] Re: os-security-groups api call creates api call explosion to neutron
Re-opened this bug: I am not sure the fix did anything. I applied the fix and still see the exact same thing in the neutron logs, e.g.: 2017-11-13 09:55:49,914.914 10778 INFO neutron.wsgi [req-4c18bd00-48c2-498f-92ee-824e215b83b9 c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:49] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.062934 2017-11-13 09:55:49,982.982 10778 INFO neutron.wsgi [req-f69f7d30-6121-456e-8dec-4c142965e91c c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:49] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.055435 2017-11-13 09:55:50,054.054 10778 INFO neutron.wsgi [req-4a389783-31b1-421e-a0f9-b31e419bc5df c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.058556 2017-11-13 09:55:50,119.119 10778 INFO neutron.wsgi [req-3dffc0a6-5f14-400f-8b4c-02555d2e262d c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.052321 2017-11-13 09:55:50,198.198 10778 INFO neutron.wsgi [req-007398bc-72e9-4858-8b04-f49face2304d c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.066602 2017-11-13 09:55:50,270.270 10778 INFO neutron.wsgi [req-092f3234-926b-4f2c-8626-1b3e7f1203dd c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.059341 2017-11-13 09:55:50,334.334 10778 INFO neutron.wsgi [req-20f45327-9d24-482c-b648-176e85d46a81 c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.051137 2017-11-13 09:55:50,397.397 10778 INFO neutron.wsgi [req-0fa86b48-59a0-460c-829e-ea008a442ed0 c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.050534 2017-11-13 09:55:50,459.459 10778 INFO neutron.wsgi [req-8bb7bfdc-b12a-46b3-a76d-7ba299d45a84 c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.048582 2017-11-13 09:55:50,527.527 10778 INFO neutron.wsgi [req-f19d8910-967c-4236-91d3-a59852482383 c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.054999 2017-11-13 09:55:50,596.596 10778 INFO neutron.wsgi [req-f21e1335-ddd7-49b0-9f2b-da9d37e48c8b c70f3fc161e04718a108cf8192d0816e d2930aef1c824f048b8e1301b3ded161 - - -] 10.41.0.33 - - [13/Nov/2017 09:55:50] "GET /v2.0/security-groups/d2770f7f-8695-48de-806b-e690189e25a8 HTTP/1.1" 200 41170 0.056300 ** Changed in: nova Status: Fix Released => Confirmed -- 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/1729741 Title: os-security-groups api call creates api call explosion to neutron Status in OpenStack Compute (nova): Confirmed Status in OpenStack Compute (nova) pike series: Confirmed Bug description: 1) create a security group 2) create a bunch of security group rules which reference a security group instead of a CIDR e.g. openstack security group rule create --remote-group x-1123--xxx-x When querying nova api /os-security-groups there will be an API call to neutron for each rule that has a remote group attached. In the logs you will seee GET /v2.0/security-groups/x-1123--xxx-x Creating rules with a CIDR do not have this issue. As you can imagine this will quickly get very slow. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1729741/+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 1731865] [NEW] Use defusedxml function instead of lxml.etree.parse
Public bug reported: Due to https://docs.openstack.org/bandit/latest/blacklists/blacklist_calls.html#b313-b320-xml, we should use defusedxml function instead of lxml.etree.parse to prevent XML attacks. ** Affects: nova Importance: Undecided Assignee: Spencer Yu (yushb) Status: New ** Changed in: nova Assignee: (unassigned) => Spencer Yu (yushb) -- 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/1731865 Title: Use defusedxml function instead of lxml.etree.parse Status in OpenStack Compute (nova): New Bug description: Due to https://docs.openstack.org/bandit/latest/blacklists/blacklist_calls.html#b313-b320-xml, we should use defusedxml function instead of lxml.etree.parse to prevent XML attacks. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731865/+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 1731857] [NEW] DVR scenario tests fail in default deployment
Public bug reported: neutron.tests.tempest.scenario.test_dvr.NetworkDvrTest.test_vm_reachable_through_compute [220.774590s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVRHA.test_from_dvr_ha_to_dvr [319.845960s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVR.test_from_dvr_to_dvr_ha [319.645897s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVRHA.test_from_dvr_ha_to_ha [318.106647s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVR.test_from_dvr_to_ha [318.342858s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVRHA.test_from_dvr_ha_to_legacy [318.466020s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVR.test_from_dvr_to_legacy [319.457491s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromHA.test_from_ha_to_dvr [344.150677s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromLegacy.test_from_legacy_to_dvr [339.829603s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromHA.test_from_ha_to_dvr_ha [339.848078s] ... FAILED The reason seems to be an inconsistency in these default config values: enable_dvr = True agent_mode = legacy For consistency, either DVR should be disabled by default or the default agent_mode should support DVR, so a default of dvr_snat would seem to be the best solution. ** 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/1731857 Title: DVR scenario tests fail in default deployment Status in neutron: New Bug description: neutron.tests.tempest.scenario.test_dvr.NetworkDvrTest.test_vm_reachable_through_compute [220.774590s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVRHA.test_from_dvr_ha_to_dvr [319.845960s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVR.test_from_dvr_to_dvr_ha [319.645897s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVRHA.test_from_dvr_ha_to_ha [318.106647s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVR.test_from_dvr_to_ha [318.342858s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVRHA.test_from_dvr_ha_to_legacy [318.466020s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromDVR.test_from_dvr_to_legacy [319.457491s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromHA.test_from_ha_to_dvr [344.150677s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromLegacy.test_from_legacy_to_dvr [339.829603s] ... FAILED neutron.tests.tempest.scenario.test_migration.NetworkMigrationFromHA.test_from_ha_to_dvr_ha [339.848078s] ... FAILED The reason seems to be an inconsistency in these default config values: enable_dvr = True agent_mode = legacy For consistency, either DVR should be disabled by default or the default agent_mode should support DVR, so a default of dvr_snat would seem to be the best solution. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1731857/+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 1731853] [NEW] Deprecation of password_autocomplete
Public bug reported: Currently, Horizon tries to prevent browsers' username/password auto-completion by default. https://github.com/openstack/horizon/blob/9adb63643778a779c571b4898b315b582bf8fba8/openstack_dashboard/local/local_settings.py.example#L130-L132 However, modern browsers have become more eager to auto-fill forms as a net gain[1] while preventing users' secret from filled in insecure forms[2]. In the circumstances, blocking auto-filling does not offer much security gains. It's time to deprecate the "password_autocomplete" switch or at least flip the default value? To address the point in the security guide[3], the flaw described there exists regardless of the value of password_autocomplete. Because, password_autocomplete just hides the fake form with CSS, but the password is already filled by a browser on the HTML level. The assumed another user already has the same privilege to see the saved password since the password is already saved regardless of the value of password_autocomplete. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields > Even without a master password, in-browser password management is generally > seen as a net gain for security. Since users do not have to remember > passwords that the browser stores for them, they are able to choose stronger > passwords than they would otherwise. > > For this reason, many modern browsers do not support autocomplete="off" for > login fields [2] https://developer.mozilla.org/en-US/Firefox/Releases/52#Security > Autofill is also disabled on insecure login forms [3] https://docs.openstack.org/security-guide/dashboard/checklist.html#check-dashboard-07-is-password-autocomplete-set-to-false > it introduces a flaw, as the user account becomes easily accessible to anyone > that uses the same account on the client machine ** Affects: horizon Importance: Undecided Status: New ** Affects: ossp-security-documentation Importance: Undecided Status: New ** Also affects: ossp-security-documentation 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/1731853 Title: Deprecation of password_autocomplete Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Guide Documentation: New Bug description: Currently, Horizon tries to prevent browsers' username/password auto-completion by default. https://github.com/openstack/horizon/blob/9adb63643778a779c571b4898b315b582bf8fba8/openstack_dashboard/local/local_settings.py.example#L130-L132 However, modern browsers have become more eager to auto-fill forms as a net gain[1] while preventing users' secret from filled in insecure forms[2]. In the circumstances, blocking auto-filling does not offer much security gains. It's time to deprecate the "password_autocomplete" switch or at least flip the default value? To address the point in the security guide[3], the flaw described there exists regardless of the value of password_autocomplete. Because, password_autocomplete just hides the fake form with CSS, but the password is already filled by a browser on the HTML level. The assumed another user already has the same privilege to see the saved password since the password is already saved regardless of the value of password_autocomplete. [1] https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields > Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise. > > For this reason, many modern browsers do not support autocomplete="off" for login fields [2] https://developer.mozilla.org/en-US/Firefox/Releases/52#Security > Autofill is also disabled on insecure login forms [3] https://docs.openstack.org/security-guide/dashboard/checklist.html#check-dashboard-07-is-password-autocomplete-set-to-false > it introduces a flaw, as the user account becomes easily accessible to anyone that uses the same account on the client machine To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1731853/+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 1731849] [NEW] cli 'nova-manage db sync' can't upgrage cell1
Public bug reported: # NOTE(mdoff): Multiple cells not yet implemented. Currently # fanout only looks for cell0. https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L721 ** Affects: nova Importance: Undecided Assignee: licanwei (li-canwei2) Status: New ** Changed in: nova Assignee: (unassigned) => licanwei (li-canwei2) -- 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/1731849 Title: cli 'nova-manage db sync' can't upgrage cell1 Status in OpenStack Compute (nova): New Bug description: # NOTE(mdoff): Multiple cells not yet implemented. Currently # fanout only looks for cell0. https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L721 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731849/+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 1731850] [NEW] Use safer ast.literal_eval instead of eval
Public bug reported: Due to https://docs.openstack.org/bandit/latest/blacklists/blacklist_calls.html#b307-eval, we shoud use safer ast.literal_eval instead of eval. ** Affects: nova Importance: Undecided Assignee: Spencer Yu (yushb) Status: New ** Changed in: nova Assignee: (unassigned) => Spencer Yu (yushb) -- 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/1731850 Title: Use safer ast.literal_eval instead of eval Status in OpenStack Compute (nova): New Bug description: Due to https://docs.openstack.org/bandit/latest/blacklists/blacklist_calls.html#b307-eval, we shoud use safer ast.literal_eval instead of eval. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1731850/+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
