from:"Andreas Scheuring"

[Yahoo-eng-team] [Bug 1745159] [NEW] macvtap agent: wrong vif details when instance is launched on vlan and flat network

2018-01-24 Thread Andreas Scheuring

Public bug reported:

It's bug in the macvtap mechanism driver.

If multiple network types are used with the macvtap driver, e.g. flat
and vlan, the vif_details can contain an invalid vif_detail attribute
'vlan'. This leads to nova configuring the macvtap with a vlan, even
though flat should be used!


The reason for this is, that the vif_details are supposed to be the same for 
all ports managed by a mechanism driver. Due to that they are stored as 
instance variables. However they are not with macvtap. In the vlan case, the 
vlan, which is stored in the vif_details, of course depends on the network. It 
might be a different for port A than for port B. The problem is, that the 
driver is always updating the global vif_dict, but instead of it should operate 
on a local copy. Now if first a vlan port is processed and after that a flat 
port, the vlan vif_detail is still stored in the mechanism drivers global 
vif_details. A flat port becomes a vlan port.

** 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/1745159

Title:
  macvtap agent: wrong vif details when instance is launched on vlan and
  flat network

Status in neutron:
  New

Bug description:
  It's bug in the macvtap mechanism driver.

  If multiple network types are used with the macvtap driver, e.g. flat
  and vlan, the vif_details can contain an invalid vif_detail attribute
  'vlan'. This leads to nova configuring the macvtap with a vlan, even
  though flat should be used!

  
  The reason for this is, that the vif_details are supposed to be the same for 
all ports managed by a mechanism driver. Due to that they are stored as 
instance variables. However they are not with macvtap. In the vlan case, the 
vlan, which is stored in the vif_details, of course depends on the network. It 
might be a different for port A than for port B. The problem is, that the 
driver is always updating the global vif_dict, but instead of it should operate 
on a local copy. Now if first a vlan port is processed and after that a flat 
port, the vlan vif_detail is still stored in the mechanism drivers global 
vif_details. A flat port becomes a vlan port.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1745159/+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 1689623] [NEW] ds-identify: disable ec-strict for s390x in yaketty

2017-05-09 Thread Andreas Scheuring

Public bug reported:

DS-identify runs with DI_EC2_STRICT_ID_DEFAULT="warn" on s390x using
yakkety. With zesty EC2_STRICT is set to "true".

Having it set to "true" is important, as on s390x the OpenStack
datasource cannot be detected. Each ds-identify run results in ec2-maybe
(if no other detectable ds is present). This could cause problems in
OpenStack environments where only the Openstack metadata service is
available (without ec2 support). In this special case it's important
that the good all "try out everything" algorithm gets enabled. Therefore
the request is to set DI_EC2_STRICT_ID_DEFAULT="true" for yakkety as
well!


# apt install cloud-init
Reading package lists... Done
Building dependency tree   
Reading state information... Done
cloud-init is already the newest version (0.7.9-90-g61eb03fe-0ubuntu1~16.10.1).


# apt-cache show cloud-init
Package: cloud-init
Priority: extra
Section: admin
Installed-Size: 1455
Maintainer: Scott Moser 
Architecture: all
Version: 0.7.9-90-g61eb03fe-0ubuntu1~16.10.1
Depends: cloud-guest-utils | cloud-utils, ifupdown (>= 0.6.10ubuntu5), procps, 
python3 (>= 3.2), python3-requests (>= 0.8.2), python3-serial, debconf (>= 0.5) 
| debconf-2.0, init-system-helpers (>= 1.18~), python3-configobj, 
python3-jinja2, python3-jsonpatch, python3-oauthlib, python3-prettytable, 
python3-six, python3-yaml, python3:any (>= 3.3.2-2~)
Recommends: eatmydata, gdisk, software-properties-common
Filename: 
pool/main/c/cloud-init/cloud-init_0.7.9-90-g61eb03fe-0ubuntu1~16.10.1_all.deb
Size: 307142
MD5sum: 85dac3c31c9dc1085f814acd2d46b56c
SHA1: a333708d949fa05f296356877a8b7f0ae88da4e6
SHA256: 6051cf4897c1268dbce3c41909734bb54958bfe2fd0e48960cedad92be5599eb
Description-en: Init scripts for cloud instances
 Cloud instances need special scripts to run during initialisation
 to retrieve and install ssh keys and to let the user run various scripts.
Description-md5: 8719ef0e4178017b7147590b1fde082e
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 9m
Task: ubuntu-core, cloud-image, ubuntu-core

Package: cloud-init
Priority: extra
Section: admin
Installed-Size: 1413
Maintainer: Scott Moser 
Architecture: all
Version: 0.7.8-15-g6e45ffb-0ubuntu1
Depends: cloud-guest-utils | cloud-utils, ifupdown (>= 0.6.10ubuntu5), procps, 
python3 (>= 3.2), python3-requests (>= 0.8.2), python3-serial, debconf (>= 0.5) 
| debconf-2.0, init-system-helpers (>= 1.18~), python3-configobj, 
python3-jinja2, python3-jsonpatch, python3-oauthlib, python3-prettytable, 
python3-six, python3-yaml, python3:any (>= 3.3.2-2~)
Recommends: eatmydata, gdisk, software-properties-common
Filename: pool/main/c/cloud-init/cloud-init_0.7.8-15-g6e45ffb-0ubuntu1_all.deb
Size: 281760
MD5sum: 8bd4212c57d3e731c1d93372c2cf13ec
SHA1: 3801b47c2e8afb7a721c9394d7658a7621efd66f
SHA256: f2b87a3db886fb41cb4000f23e88a54b04e5eca890eb3a682c8b154970b838d9
Description-en: Init scripts for cloud instances
 Cloud instances need special scripts to run during initialisation
 to retrieve and install ssh keys and to let the user run various scripts.
Description-md5: 8719ef0e4178017b7147590b1fde082e
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 9m
Task: ubuntu-core, cloud-image, ubuntu-core


# uname -a
Linux your-host-name 4.8.0-51-generic #54-Ubuntu SMP Tue Apr 25 16:33:55 UTC 
2017 s390x s390x s390x GNU/Linux

# cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.10
DISTRIB_CODENAME=yakkety
DISTRIB_DESCRIPTION="Ubuntu 16.10"
NAME="Ubuntu"
VERSION="16.10 (Yakkety Yak)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.10"
VERSION_ID="16.10"
HOME_URL="http://www.ubuntu.com/;
SUPPORT_URL="http://help.ubuntu.com/;
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="http://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
VERSION_CODENAME=yakkety
UBUNTU_CODENAME=yakkety

** 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/1689623

Title:
  ds-identify: disable ec-strict for s390x in yaketty

Status in cloud-init:
  New

Bug description:
  DS-identify runs with DI_EC2_STRICT_ID_DEFAULT="warn" on s390x using
  yakkety. With zesty EC2_STRICT is set to "true".

  Having it set to "true" is important, as on s390x the OpenStack
  datasource cannot be detected. Each ds-identify run results in
  ec2-maybe (if no other detectable ds is present). This could cause
  problems in OpenStack environments where only the Openstack metadata
  service is available (without ec2 support). In this special case it's
  important that the good all "try out everything" algorithm gets
  enabled. Therefore the request is to set
  DI_EC2_STRICT_ID_DEFAULT="true" for yakkety as well!

  
  # apt install cloud-init
  Reading package lists... Done
  Building dependency tree   
  Reading state

[Yahoo-eng-team] [Bug 1662542] [NEW] Rhel7 set_hostname not working due to cyclic dependency

2017-02-07 Thread Andreas Scheuring

Public bug reported:

Using version 0.7.9
Cloud-init.service fails setting the hostname on a rhel7 with the error

  ProcessExecutionError: Unexpected error while running command.
  Command: ['hostnamectl', 'set-hostname', 'foo']
  Exit code: 1
  Reason: -
  Stdout: -
  Stderr: Failed to create bus connection: No such file or directory

The issue seems to be, that the rhel distro file is implementing
set_hostname via hostnamectl, which requires systemd-hostnamed.service
to be running (as far as I could figure out).

Now the default cloud-init.service is configured with
   Before=sysinit.target
But the systemd-hostenamed.service uses the default dependencies, which means 
it is started after sysinit.target.

If I add "Requires=Requires=systemd-hostnamed.service" to cloud-
init.service, of course I get the following on "systemd-analyze verify
cloud-init.service":

systemd-analyze verify /var/lib/systemd/system/cloud-init.service
Found ordering cycle on sysinit.target/start
Found dependency on cloud-init.service/start
Found dependency on systemd-hostnamed.service/start
Found dependency on basic.target/start
Found dependency on sysinit.target/start
Unable to break cycle
Requested transaction contains an unfixable cyclic ordering dependency: 
Transaction order is cyclic. See system logs for details.
Error: org.freedesktop.systemd1.TransactionOrderIsCyclic: Transaction order is 
cyclic. See system logs for details.
Failed to create cloud-init.service/start: Resource deadlock avoided

** Affects: cloud-init
 Importance: Undecided
 Status: New

** Description changed:

+ Using version 0.7.9
  Cloud-init.service fails setting the hostname on a rhel7 with the error
  
-   ProcessExecutionError: Unexpected error while running command.
-   Command: ['hostnamectl', 'set-hostname', 'foo']
-   Exit code: 1
-   Reason: -
-   Stdout: -
-   Stderr: Failed to create bus connection: No such file or directory
+   ProcessExecutionError: Unexpected error while running command.
+   Command: ['hostnamectl', 'set-hostname', 'foo']
+   Exit code: 1
+   Reason: -
+   Stdout: -
+   Stderr: Failed to create bus connection: No such file or directory
  
  The issue seems to be, that the rhel distro file is implementing
  set_hostname via hostnamectl, which requires systemd-hostnamed.service
  to be running (as far as I could figure out).
  
- Now the default cloud-init.service is configured with 
-Before=sysinit.target
- But the systemd-hostenamed.service uses the default dependencies, which means 
it is started after sysinit.target. 
+ Now the default cloud-init.service is configured with
+    Before=sysinit.target
+ But the systemd-hostenamed.service uses the default dependencies, which means 
it is started after sysinit.target.
  
  If I add "Requires=Requires=systemd-hostnamed.service" to cloud-
  init.service, of course I get the following on "systemd-analyze verify
  cloud-init.service":
  
  systemd-analyze verify /var/lib/systemd/system/cloud-init.service
  Found ordering cycle on sysinit.target/start
  Found dependency on cloud-init.service/start
  Found dependency on systemd-hostnamed.service/start
  Found dependency on basic.target/start
  Found dependency on sysinit.target/start
  Unable to break cycle
  Requested transaction contains an unfixable cyclic ordering dependency: 
Transaction order is cyclic. See system logs for details.
  Error: org.freedesktop.systemd1.TransactionOrderIsCyclic: Transaction order 
is cyclic. See system logs for details.
  Failed to create cloud-init.service/start: Resource deadlock avoided

-- 
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/1662542

Title:
  Rhel7 set_hostname not working due to cyclic dependency

Status in cloud-init:
  New

Bug description:
  Using version 0.7.9
  Cloud-init.service fails setting the hostname on a rhel7 with the error

    ProcessExecutionError: Unexpected error while running command.
    Command: ['hostnamectl', 'set-hostname', 'foo']
    Exit code: 1
    Reason: -
    Stdout: -
    Stderr: Failed to create bus connection: No such file or directory

  The issue seems to be, that the rhel distro file is implementing
  set_hostname via hostnamectl, which requires systemd-hostnamed.service
  to be running (as far as I could figure out).

  Now the default cloud-init.service is configured with
     Before=sysinit.target
  But the systemd-hostenamed.service uses the default dependencies, which means 
it is started after sysinit.target.

  If I add "Requires=Requires=systemd-hostnamed.service" to cloud-
  init.service, of course I get the following on "systemd-analyze verify
  cloud-init.service":

  systemd-analyze verify /var/lib/systemd/system/cloud-init.service
  Found ordering cycle on sysinit.target/start
  Found dependency on cloud-init.service/start
  Found dependency on systemd-hostnamed.service/start
  Found dependency on

[Yahoo-eng-team] [Bug 1641837] Re: neutron-openvswitch-agent failed to add default table

2016-11-14 Thread Andreas Scheuring

Along yesterday Neutron meeting [1]:

21:05:22  when reviewing stable patches or triaging bug reports
21:05:34  please take into account of the fact that mitaka is security 
fixes only

-> This is not a security issue IMO, so setting it to "won't fix".


[1] 
http://eavesdrop.openstack.org/meetings/networking/2016/networking.2016-11-14-21.00.log.html

** Tags added: ovs

** Changed in: neutron
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1641837

Title:
  neutron-openvswitch-agent failed to add default table

Status in neutron:
  Won't Fix

Bug description:
  Problem

  
  After power down and power off the host, the tenant network is not available.

  The cause is that default flow tables of br-int is not setup
  successfully when neutron-openvswitch-agent.starts:

  1) The neutron-openvswitch-agent fails to add the flow table 0 but
  adds the flow table 23 successfully in setup_default_table(). The
  flows look like as follows:

  cookie=0x8f4c30f934586d9c, duration=617166.781s, table=0, 
n_packets=31822416, n_bytes=2976996304, idle_age=0, hard_age=65534, 
priority=2,in_port=1 actions=drop
  cookie=0x8f4c30f934586d9c, duration=617167.023s, table=23, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop
  cookie=0x8f4c30f934586d9c, duration=617167.007s, table=24, n_packets=0, 
n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

  2) In the rpc_roop, the neutron-openvswitch-agent will check the
  ovs status by checking the flow table 23, and the flow table 23
  exists. The neutron-openvswitch-agent thinks the ovs is normal, but
  the flow table 0 does not exist and the network connection is not
  availble.

  Affected Neutron version:
  kilo mitaka

  Possible Solution:
  Check the default table 0 or check all the default flow tables in 
check_ovs_status().
  Or add the default flow table 23 first and then add the default table 0 in 
setup_default_table()

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1641837/+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 1641433] Re: Deprecate SR-IOV 'physical_device_mappings' config option

2016-11-13 Thread Andreas Scheuring

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** 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/1641433

Title:
  Deprecate SR-IOV 'physical_device_mappings' config option

Status in neutron:
  Invalid
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/395044
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 03b84bc920b5499e1fef23c646268fffa1d859d7
  Author: Edan David 
  Date:   Tue Nov 8 10:30:45 2016 -0500

  Deprecate SR-IOV 'physical_device_mappings' config option
  
  The device to physnet validation is made in Nova by pci_whitelist config 
option.
  Therefore it is redundant to validate it in Neutron with 
physical_device_mappings
  config option.
  
  Closes-Bug: #1640220
  DocImpact
  
  Change-Id: I5f363347b327212a49a9b78a7164c11d9e457b10

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1641433/+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 1640835] Re: neutron doesn't report invalid values passed to it

2016-11-13 Thread Andreas Scheuring

Got your point. I'll close this bug as the issue seems to be fixed!
Thanks for finding out!

** Changed in: neutron
   Status: Incomplete => 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/1640835

Title:
  neutron doesn't report invalid values passed to it

Status in neutron:
  Invalid

Bug description:
  [stack@undercloud ~]$ neutron port-list | grep 
699107e1-bdf7-4044-83fc-65201fb28f57
  | 699107e1-bdf7-4044-83fc-65201fb28f57 |   | 
00:6e:03:64:5d:ad | {"subnet_id": "06e61421-520b-4afb-ad15-1e31e1503e44", 
"ip_address": "192.0.2.9"} |

  [stack@undercloud ~]$ nova list
  
+--++++-++
  | ID   | Name   | Status | 
Task State | Power State | Networks   |
  
+--++++-++
  | 9751809b-5033-43ca-bc8d-334e9acf2d4e | overcloud-controller-0 | ACTIVE | -  
| Running | ctlplane=192.0.2.9 |
  | 74a6b21a-db53-492d-bb36-9d05a70ef8d2 | overcloud-controller-2 | ACTIVE | -  
| Running | ctlplane=192.0.2.6 |
  
+--++++-++

  [stack@undercloud ~]$ nova stop 9751809b-5033-43ca-bc8d-334e9acf2d4e
  Request to stop server 9751809b-5033-43ca-bc8d-334e9acf2d4e has been accepted.

  [stack@undercloud ~]$ nova list
  
+--++-++-++
  | ID   | Name   | Status  | 
Task State | Power State | Networks   |
  
+--++-++-++
  | 9751809b-5033-43ca-bc8d-334e9acf2d4e | overcloud-controller-0 | SHUTOFF | - 
 | Shutdown| ctlplane=192.0.2.9 |
  | 74a6b21a-db53-492d-bb36-9d05a70ef8d2 | overcloud-controller-2 | ACTIVE  | - 
 | Running | ctlplane=192.0.2.6 |
  
+--++-++-++

  [stack@undercloud ~]$ neutron port-update --fixed-ip 
subnet_id=06e61421-520b-4afb-ad15-1e31e1503e44,ip=192.0.2.26 
699107e1-bdf7-4044-83fc-65201fb28f57
  Updated port: 699107e1-bdf7-4044-83fc-65201fb28f57

  [stack@undercloud ~]$ nova start 9751809b-5033-43ca-bc8d-334e9acf2d4e
  Request to start server 9751809b-5033-43ca-bc8d-334e9acf2d4e has been 
accepted.
  [stack@undercloud ~]$ nova list
  
+--++++-+-+
  | ID   | Name   | Status | 
Task State | Power State | Networks|
  
+--++++-+-+
  | 9751809b-5033-43ca-bc8d-334e9acf2d4e | overcloud-controller-0 | ACTIVE | -  
| Running | ctlplane=192.0.2.10 |
  | 74a6b21a-db53-492d-bb36-9d05a70ef8d2 | overcloud-controller-2 | ACTIVE | -  
| Running | ctlplane=192.0.2.6  |
  
+--++++-+-+

  - If used with ip=192.0.2.26 it won't report any issues, but will
  automatically +1 on the IP from the pool.

  Would be nice if the neutron has some input checks on whether the
  value is one of the known ones.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640835/+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 1640461] Re: docs: sql parameters missing in config reference

2016-11-10 Thread Andreas Scheuring

ah makes sense. Thanks!

** Changed in: openstack-manuals
   Status: Confirmed => Invalid

** 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/1640461

Title:
  docs: sql parameters missing in config reference

Status in neutron:
  Invalid
Status in openstack-manuals:
  Invalid

Bug description:
  The sample config file [1] shows varies sql alchemy config parameters like
  - max_pool_size
  - max_retries
  -...

  But those do not exist in the Neutron Config Reference [2]

  
  [1] 
http://docs.openstack.org/newton/config-reference/networking/samples/neutron.conf.html
  [2] 
http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640461/+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 1640437] Re: FWAAS Firewall Groups API missing in API docs

2016-11-10 Thread Andreas Scheuring

Cool, thanks for the update!

** Changed in: neutron
   Status: Confirmed => 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/1640437

Title:
  FWAAS Firewall Groups API missing in API docs

Status in neutron:
  Invalid
Status in openstack-api-site:
  Invalid

Bug description:
  The concept of Firewall Groups got introduced with [1]. The API doc
  does not mention this API at all. [2]


  [1] 
https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/fwaas-api-2.0.html#firewall-groups
  [2] 
http://developer.openstack.org/api-ref/networking/v2/index.html#fwaas-v1-0-current-fw-firewalls-firewall-policies-firewall-rules

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640437/+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 1640461] [NEW] docs: sql parameters missing in config reference

2016-11-09 Thread Andreas Scheuring

Public bug reported:

The sample config file [1] shows varies sql alchemy config parameters like
- max_pool_size
- max_retries
-...

But those do not exist in the Neutron Config Reference [2]


[1] 
http://docs.openstack.org/newton/config-reference/networking/samples/neutron.conf.html
[2] 
http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html

** Affects: neutron
 Importance: Undecided
 Status: New

** Affects: openstack-manuals
 Importance: Undecided
 Status: Confirmed


** Tags: doc

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: openstack-manuals
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1640461

Title:
  docs: sql parameters missing in config reference

Status in neutron:
  New
Status in openstack-manuals:
  Confirmed

Bug description:
  The sample config file [1] shows varies sql alchemy config parameters like
  - max_pool_size
  - max_retries
  -...

  But those do not exist in the Neutron Config Reference [2]

  
  [1] 
http://docs.openstack.org/newton/config-reference/networking/samples/neutron.conf.html
  [2] 
http://docs.openstack.org/newton/config-reference/networking/networking_options_reference.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640461/+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 1640029] Re: [stable/newton] Deleting heat stack failed due to error "QueuePool limit of size 50 overflow 50 reached, connection timed out, timeout 30"

2016-11-09 Thread Andreas Scheuring

Hi Sujai, thanks for reporting this. The issue is not yet clear to me. 
Can you please provide: 
- max_pool_size, retry_interval, max_overflow settings of your first run
- the nova error message of the first and the second run
- the neutron error message of the first and second run
At the moment you provided a neutron message for the first run and a nova 
message for the second. So I can't see what changed after updating the 
settings. In general it looks like that for deleting 500 instances in parallel 
a lot of sql queries are required. It seems like for such a use case you need 
to tune your parameters..

But let's compare your error message of the first and second run first.
If they are equal, I tend to set this to invalid

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: nova
   Status: New => Incomplete

** Changed in: neutron
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1640029

Title:
  [stable/newton] Deleting heat stack failed due to error "QueuePool
  limit of size 50 overflow 50 reached, connection timed out, timeout
  30"

Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Incomplete

Bug description:
  In my CH + stable/newton setup, I brought up 5 heat stacks each having 100 
nova instances in the same /16 network.
  Deleting those heat stacks failed due to the below error.

  "
  2016-11-03 17:27:34.146 2399 ERROR nova.api.openstack.extensions 
TimeoutError: QueuePool limit of size 50 overflow 50 reached, connection timed 
out, timeout 30
  "

  Because of this error, out of 500 instances, deletion of about 67 instances 
got failed.
  With default parameters in neutron.conf, I'm getting the below neutron error.

  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource 
[req-a0022887-cc01-4f2e-980d-490136524363 admin -] delete failed: No details.
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 79, in resource
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 555, in delete
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource return 
self._delete(request, id, **kwargs)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 88, in wrapped
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource setattr(e, 
'_RETRY_EXCEEDED', True)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 84, in wrapped
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource ectxt.value = 
e.inner_exc
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 124, in wrapped
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource 
traceback.format_exc())
  2016-11-02 20:42:06.557 18058 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-11-02 20:42:06.557 18058 ERROR

[Yahoo-eng-team] [Bug 1640437] Re: FWAAS Firewall Groups API missing in API docs

2016-11-09 Thread Andreas Scheuring

** Changed in: openstack-api-site
   Status: New => Invalid

** Changed in: neutron
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1640437

Title:
  FWAAS Firewall Groups API missing in API docs

Status in neutron:
  Confirmed
Status in openstack-api-site:
  Invalid

Bug description:
  The concept of Firewall Groups got introduced with [1]. The API doc
  does not mention this API at all. [2]


  [1] 
https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/fwaas-api-2.0.html#firewall-groups
  [2] 
http://developer.openstack.org/api-ref/networking/v2/index.html#fwaas-v1-0-current-fw-firewalls-firewall-policies-firewall-rules

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640437/+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 1640437] [NEW] FWAAS Firewall Groups API missing in API docs

2016-11-09 Thread Andreas Scheuring

Public bug reported:

The concept of Firewall Groups got introduced with [1]. The API doc does
not mention this API at all. [2]


[1] 
https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/fwaas-api-2.0.html#firewall-groups
[2] 
http://developer.openstack.org/api-ref/networking/v2/index.html#fwaas-v1-0-current-fw-firewalls-firewall-policies-firewall-rules

** Affects: neutron
 Importance: Undecided
 Status: New

** Affects: openstack-api-site
 Importance: Undecided
 Status: New


** Tags: doc fwaas

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** Tags added: fwaas

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1640437

Title:
  FWAAS Firewall Groups API missing in API docs

Status in neutron:
  New
Status in openstack-api-site:
  New

Bug description:
  The concept of Firewall Groups got introduced with [1]. The API doc
  does not mention this API at all. [2]


  [1] 
https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/fwaas-api-2.0.html#firewall-groups
  [2] 
http://developer.openstack.org/api-ref/networking/v2/index.html#fwaas-v1-0-current-fw-firewalls-firewall-policies-firewall-rules

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640437/+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 1640221] Re: Can't create floatingip with specified uuid

2016-11-09 Thread Andreas Scheuring

Hi Stefan, I would rather tackle the root causes that you described with
"some error in a specific L3 service implementation". Can you elaborate
more on that? Ideally you would directly open a bug for those issues
providing the relevant information!

I'll set this to invalid. I'm not aware of any Neutron resource that
allows specifying a UUID. And I don't see the use case. If you have a
use case that is not related to buggy code, please elaborate here.

Thanks!

** 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/1640221

Title:
  Can't create floatingip with specified uuid

Status in neutron:
  Invalid

Bug description:
  There are some cases in which we need to a rollback a delete
  floatingip action (e.g. some error in a specific L3 service
  implementation) and for that we basically require creating the old
  floatingip, including the uuid. The current L3_NAT_dbonly_mixin
  implementation generates the uuid every time create_floatingip is
  called so there's no way of re-creating a floatingip.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1640221/+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 1595250] [NEW] ml2 Use None for portbinding.host instead of an empty String

2016-06-22 Thread Andreas Scheuring

Public bug reported:

Seems like ML2 portbinding uses '' for indicating that the port is bound
to no host, while in times before ml2 "None" was used. This leads to
some strange checks in the code like [1]

This bug is to clean this up internally. The API still should take both
values, an empty string and none, but some code at the api layer should
normalize that to None. In addition the values in the ml2_portbinding
(and dvr portbinding) table need to be migrated.


Another related patch that introduced None values for ml2 portbiding as well 
was : https://review.openstack.org/#/c/181867/


[1]
https://review.openstack.org/#/c/320657/1/neutron/db/ipam_backend_mixin.py

** 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/1595250

Title:
  ml2 Use None for portbinding.host instead of an empty String

Status in neutron:
  New

Bug description:
  Seems like ML2 portbinding uses '' for indicating that the port is
  bound to no host, while in times before ml2 "None" was used. This
  leads to some strange checks in the code like [1]

  This bug is to clean this up internally. The API still should take
  both values, an empty string and none, but some code at the api layer
  should normalize that to None. In addition the values in the
  ml2_portbinding (and dvr portbinding) table need to be migrated.

  
  Another related patch that introduced None values for ml2 portbiding as well 
was : https://review.openstack.org/#/c/181867/


  
  [1] https://review.openstack.org/#/c/320657/1/neutron/db/ipam_backend_mixin.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1595250/+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 1587498] [NEW] macvtap agent does terminates when NoopFWDriver is specified via "noop" alias

2016-05-31 Thread Andreas Scheuring

Public bug reported:

The macvtap agent only works with the NoopFWDriver. If another driver is
configured it terminates. Now there are two ways in configuring the
NoopFWDriver

1) directly: neutron.agent.firewall.NoopFirewallDriver
2) via the alias: noop

Today only the direct way is supporte, although the alias way is also
valid.

** Affects: neutron
 Importance: Undecided
 Assignee: Andreas Scheuring (andreas-scheuring)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1587498

Title:
  macvtap agent does terminates when NoopFWDriver is specified via
  "noop" alias

Status in neutron:
  In Progress

Bug description:
  The macvtap agent only works with the NoopFWDriver. If another driver
  is configured it terminates. Now there are two ways in configuring the
  NoopFWDriver

  1) directly: neutron.agent.firewall.NoopFirewallDriver
  2) via the alias: noop

  Today only the direct way is supporte, although the alias way is also
  valid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1587498/+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 1587444] [NEW] macvtap: agent starts although no interface_mapping is provided

2016-05-31 Thread Andreas Scheuring

Public bug reported:

As the macvtap agent does only support flat and vlan networks, the
physical_interface_mappings prameter must contain at least one mapping.
Without a mapping, no networkconnectivity can be provided by this agent.

Ideally the agent would terminate with an appropriate error message
pointing the operator to this issue.

** 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/1587444

Title:
  macvtap: agent starts although no interface_mapping is provided

Status in neutron:
  New

Bug description:
  As the macvtap agent does only support flat and vlan networks, the
  physical_interface_mappings prameter must contain at least one
  mapping. Without a mapping, no networkconnectivity can be provided by
  this agent.

  Ideally the agent would terminate with an appropriate error message
  pointing the operator to this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1587444/+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 1585983] Re: horizon issue with connection to keystone

2016-05-30 Thread Andreas Scheuring

** Also affects: horizon
   Importance: Undecided
   Status: New

** Also affects: keystone
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1585983

Title:
  horizon issue with connection to keystone

Status in devstack:
  New
Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  New

Bug description:
  Hello.

  I have fresh installation by devstack. 
  When I try to access the Users or Projects panels I get an error:

  Error: Unable to retrieve project list.

  I've in local_settings.py:

  OPENSTACK_API_VERSIONS={"identity":3}
  OPENSTACK_KEYSTONE_URL="http://192.168.100.56/identity/v3;

  I tried to change:

  OPENSTACK_API_VERSIONS={"identity":2}
  OPENSTACK_KEYSTONE_URL="http://192.168.100.56/identity/v2;

  or:
  OPENSTACK_API_VERSIONS={"identity":3}
  OPENSTACK_KEYSTONE_URL = "http://192.168.100.56:35357/v3;

  but all time getting same error in horizon.log:

  2016-05-26 10:10:10.271844 DEBUG:keystoneauth.session:REQ: curl -g -i -X GET 
http://192.168.100.56/identity/users/12d3903866c04c03867014b46405549b/projects 
-H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}3a82a8e5488a184982dda25814ae171bb25c4382"
  2016-05-26 10:10:10.275675 DEBUG:keystoneauth.session:RESP: [404] Date: Thu, 
26 May 2016 10:10:10 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips 
mod_wsgi/3.4 Python/2.7.5 Vary: X-Auth-Token Content-Length: 93 Keep-Alive: 
timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json 
  2016-05-26 10:10:10.275699 RESP BODY: {"error": {"message": "The resource 
could not be found.", "code": 404, "title": "Not Found"}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1585983/+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 1580898] [NEW] [RFE] Network node support and improved testing for macvtap agent

2016-05-12 Thread Andreas Scheuring

Public bug reported:

Today, only unit & some basic functional tests are executed for the
macvtap agent.

The goal is to extend the macvtap agent to 
* support non-compute ports via macvlan (allows spawning a single node system 
with l3, dhcp and so on)
* Add a tempest test job for it
* enhance functional tests to also verify l2 connectivity (requires some code 
that can listen on a taps or macvtaps file descriptor and answer ping requests 
via it)

** 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/1580898

Title:
  [RFE] Network node support and improved testing for macvtap agent

Status in neutron:
  New

Bug description:
  Today, only unit & some basic functional tests are executed for the
  macvtap agent.

  The goal is to extend the macvtap agent to 
  * support non-compute ports via macvlan (allows spawning a single node system 
with l3, dhcp and so on)
  * Add a tempest test job for it
  * enhance functional tests to also verify l2 connectivity (requires some code 
that can listen on a taps or macvtaps file descriptor and answer ping requests 
via it)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1580898/+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 1580891] [NEW] [RFE] Move SR-IOV Agent to common agent framework

2016-05-12 Thread Andreas Scheuring

Public bug reported:

As the linuxbridge and the macvtap agent now share a lot of common code
via the common agent class, it's time to move the sr-iov agent there as
well!

This would be a 3 step approach:
#1 Refactor the common agent to match some sr-iov agent requirements
#2 Refactor the sr-iov agent to match the code structure of the common agent
#3 Bring both together

** 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/1580891

Title:
  [RFE] Move SR-IOV Agent to common agent framework

Status in neutron:
  New

Bug description:
  As the linuxbridge and the macvtap agent now share a lot of common
  code via the common agent class, it's time to move the sr-iov agent
  there as well!

  This would be a 3 step approach:
  #1 Refactor the common agent to match some sr-iov agent requirements
  #2 Refactor the sr-iov agent to match the code structure of the common agent
  #3 Bring both together

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1580891/+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 1580880] [NEW] [RFE] Distributed Portbinding for all port tpyes

2016-05-12 Thread Andreas Scheuring

Public bug reported:

Summary
===

Today only DVR ports can be bound to multiple hosts. But having a port bound to
multiple hosts does also make sense for a compute port during live migration.
For a certain period of time the port could be bound to the source and
target at the same time (Although only one is being used). The information of 
both bindings needs to be accessible from Nova via the ReST API.

Use Cases
=

* Instance in error state when portbinding fails

In the live migration process, port binding is triggered by Nova after
the migration already succeeded. If port binding fails, the instance is
stuck in error state. If portbinding for the target node would be done in
pre_live_migration, migration could be aborted on a binding failure and the
instance would still be active on the migration source host. But we
cannot just do so, as some TOR mech drivers would shut down the source
port after the binding has been updated, although the instance is still
active on the source. If we could bind a compute port to both hosts, such
drivers could keep the source port open, and already process the target
port in parallel.

* Live Migration between hosts running different l2 agents

Another use case is live migration between hosts that run different l2
agents. This requires that Nova updates the instance definition before
migration is executed (in case of libvirt, update the domain.xml with
target interface definition).

A specialized variant of this use case is the migration from an agent with
one firewall driver to another (e.g. from ovs hybrid-fw driver to new ovs
conntrackd firewall driver).

* Live migration with MacVTap agent when different physnet mappings is
used

The third use case is live migration with MacVTap agent. Today it has some
restrictions with live migration in some special scenarios [1]. It requires
an update on the instance definition (libvirt domain.xml) before the
migration started.

For updating the definition in time, a portbinding for the migration target
node is required even before the migration started. Along the argumentation
above, we need a compute port bound to multiple hosts.

Proposed Change
===

* A refactoring of the database is required to make a normal port a
special case of a distributed port. This was planned since a long time
but was never finished. The efforts are tracked via this bug [1]. The
patches still need to be rebased to get that going again.

* ReST API changes are required to externalize the bindings. To not
overload the port API, a new subresource "bindings" could be created
(like /ports/{port-id}/bindings) that holds the list of all bindings.
CREATE/DELETE/UPDATE must be supported. Not UUID or would be required
for this resource, as its identifier would be the host_id!


Nova Changes

* In pre_live_migration, nova would add a new binding for the migration target 
host to the port - this triggers portbinding in Neutron.
* Before migration starts, Nova would access the binding information for the 
target host. It would abort on "binding_failed" vif type. Otherwise it would 
modify the instance definition (e.g. domain.xml) for the migration target with 
this binding information.
* After live migration succeeded, Nova would remove the original port_binding. 
On Rollback, it would just remove the target port_binding.

Those changes are tracked via the following Nova blueprint [4]


Open Questions
==
* This RFE is based on bug [1]. How to track those dependencies? Or should the 
content of this bug become part of this effort?
* Similar with the macvtap live migration bug [3]
* How does this effort correlate to the the RFE for externalizing multi-segment 
networks [2]?


[1] https://bugs.launchpad.net/neutron/+bug/1367391
[2] https://bugs.launchpad.net/neutron/+bug/1573197
[3] https://bugs.launchpad.net/neutron/+bug/1550400
[4] https://blueprints.launchpad.net/nova/+spec/migration-use-target-vif

** 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/1580880

Title:
  [RFE] Distributed Portbinding for all port tpyes

Status in neutron:
  New

Bug description:
  Summary
  ===

  Today only DVR ports can be bound to multiple hosts. But having a port bound 
to
  multiple hosts does also make sense for a compute port during live migration.
  For a certain period of time the port could be bound to the source and
  target at the same time (Although only one is being used). The information of 
both bindings needs to be accessible from Nova via the ReST API.

  Use Cases
  =

  * Instance in error state when portbinding fails

  In the live migration process, port binding is triggered by Nova after
  the migration already

[Yahoo-eng-team] [Bug 1560957] [NEW] ovs mech_driver depends on neutron server firewall_driver option instead of the agent firewall_driver option to determine if hybrid plug can be used

2016-03-23 Thread Andreas Scheuring

Public bug reported:

The ovs mechanism driver determins if hybrid plug should be used along
the firewall_driver [1] setting that is made on the neutron server [2].

IPTABLES_FW_DRIVER_FULL = 
("neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver")
hybrid_plug_required = (cfg.CONF.SECURITYGROUP.firewall_driver in 
(IPTABLES_FW_DRIVER_FULL, 'iptables_hybrid'))

--> Only if the cfg.CONF.SECURITYGROUP.firewall_driver option is
configure to be hybrid, hybrid plug is enabled.


Let's assume you have a cloud, with a few nodes running lb and some other 
running ovs l2 agent. 
- neutron server: firewall_driver = 
neutron.agent.linux.iptables_firewall.IptablesFirewallDriver  (for lb)
- cpu node1: neutron-lb-agt: firewall_driver = 
neutron.agent.linux.iptables_firewall.IptablesFirewallDriver  (for lb)
- cpu node 2: neutron -ovs-agt: firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver (for ovs)


Expected behavior
==
ovs agent uses hybrid plug, as it is configured in its configuration

Actual result
==

You'll never get a hybrid plug, as the neutron server does only consider its 
own fw_driver option instead of the agent option
--> No Security Groups

I see two approaches that can be discussed
=


#1 allow listing of multiple fw drivers in the neutron server configuration file

#2 Determine the hybrid_plug_required variable along the fw_driver
configured in the l2 agent (agent can report this to the sever as part
of its regular state report and mech_driver can use this information to
set hybrid plug option correctly when port_binding is requested)


[1] 
http://docs.openstack.org/liberty/config-reference/content/networking-options-securitygroups.html
[2] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L49

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: ovs sg-fw

** Summary changed:

- ovs mech driver depends on neutron server firewall_driver option instead of 
the agent firewall driver to determine if hybrid plug can be used
+ ovs mech_driver depends on neutron server firewall_driver option instead of 
the agent firewall_driver option to determine if hybrid plug can be used

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1560957

Title:
  ovs mech_driver depends on neutron server firewall_driver option
  instead of the agent firewall_driver option to determine if hybrid
  plug can be used

Status in neutron:
  New

Bug description:
  The ovs mechanism driver determins if hybrid plug should be used along
  the firewall_driver [1] setting that is made on the neutron server
  [2].

  IPTABLES_FW_DRIVER_FULL = 
("neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver")
  hybrid_plug_required = (cfg.CONF.SECURITYGROUP.firewall_driver in 
(IPTABLES_FW_DRIVER_FULL, 'iptables_hybrid'))

  --> Only if the cfg.CONF.SECURITYGROUP.firewall_driver option is
  configure to be hybrid, hybrid plug is enabled.

  
  Let's assume you have a cloud, with a few nodes running lb and some other 
running ovs l2 agent. 
  - neutron server: firewall_driver = 
neutron.agent.linux.iptables_firewall.IptablesFirewallDriver  (for lb)
  - cpu node1: neutron-lb-agt: firewall_driver = 
neutron.agent.linux.iptables_firewall.IptablesFirewallDriver  (for lb)
  - cpu node 2: neutron -ovs-agt: firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver (for ovs)

  
  Expected behavior
  ==
  ovs agent uses hybrid plug, as it is configured in its configuration

  Actual result
  ==

  You'll never get a hybrid plug, as the neutron server does only consider its 
own fw_driver option instead of the agent option
  --> No Security Groups

  I see two approaches that can be discussed
  =

  
  #1 allow listing of multiple fw drivers in the neutron server configuration 
file

  #2 Determine the hybrid_plug_required variable along the fw_driver
  configured in the l2 agent (agent can report this to the sever as part
  of its regular state report and mech_driver can use this information
  to set hybrid plug option correctly when port_binding is requested)


  
  [1] 
http://docs.openstack.org/liberty/config-reference/content/networking-options-securitygroups.html
  [2] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L49

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1560957/+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   :

[Yahoo-eng-team] [Bug 1557407] [NEW] macvtap: add devstack support for macvtap agent

2016-03-15 Thread Andreas Scheuring

Public bug reported:

The Macvtap agent that was introduced in Mitaka [1] requires some devstack 
support. As only compute attachments are supported (at the moment), the 
devstack support will be restricted to
- Single Nodes without l3 & dhcp agent
- Multi Nodes running ovs or lb on the controller/network node


[1] https://bugs.launchpad.net/neutron/+bug/1480979

** 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/1557407

Title:
  macvtap: add devstack support for macvtap agent

Status in neutron:
  New

Bug description:
  The Macvtap agent that was introduced in Mitaka [1] requires some devstack 
support. As only compute attachments are supported (at the moment), the 
devstack support will be restricted to
  - Single Nodes without l3 & dhcp agent
  - Multi Nodes running ovs or lb on the controller/network node

  
  [1] https://bugs.launchpad.net/neutron/+bug/1480979

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1557407/+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 1554197] Re: Deleting router-gateway-port throws a DB foreign key error

2016-03-08 Thread Andreas Scheuring

*** This bug is a duplicate of bug 1535707 ***
https://bugs.launchpad.net/bugs/1535707

Marking this as duplicate, as the root cause of both is the same. I'll
expand the other bugs descirption to also cover this issue

** This bug has been marked a duplicate of bug 1535707
   Create router with external network attached doesn't notify l3 agent

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1554197

Title:
  Deleting router-gateway-port throws a DB foreign key error

Status in neutron:
  New

Bug description:
  1. High level description:

  Create a external network and associate to a router during creation using 
"--external_gateway_info type=dict network_id=" option.
  This creates a gateway-port. When you attempt to delete this gateway port you 
get a DB foreign key error as follows:

  "DBError: (IntegrityError) (1451, 'Cannot delete or update a pare
  nt row: a foreign key constraint fails (`neutron`.`routers`, CONSTRAINT 
`routers_ibfk_1` FOREIGN KEY (`gw_port_id`) REFERENC
  ES `ports` (`id`))') 'DELETE FROM ports WHERE ports.id = %s' 
('76573418-f9ff-4f2d-8ffb-d0a200f7f1ea',)"

  
  2. Pre-conditions: 

  All resources are created as a admin tenant

  
  3. Step-by-step reproduction steps:

  Steps and error message posted here:
  http://paste.openstack.org/show/489584/

  4. Expected output:

  If this action is not supported then an error message similar to
  following should be thrown:

  "More than one external network exists"

  
  5. Actual output:

  we get "Request Failed: internal server error while processing your
  request."

  With a DB trace on neutron logs

  6. Version:
  Master Branch (Mitaka) (also applicable in liberty/kilo)
  Devstack installation for Mitaka

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1554197/+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 1282956] Re: ML2 : hard reboot a VM after a compute crash

2016-03-07 Thread Andreas Scheuring

that worked! Additional queries to do:
use neutron
update ml2_port_bindings set host = 'new-host' where host = 'old-host';


update ml2_port_binding_levels set host = 'new-host' where host = 'old-host';


 Setting Neutron to won't fix and adding bug against docs + providing a fix.

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1282956

Title:
  ML2 : hard reboot a VM after a compute crash

Status in neutron:
  Won't Fix
Status in openstack-manuals:
  New

Bug description:
  I run in multi node setup with ML2, L2-population and Linuxbridge MD,
  and vxlan TypeDriver.

  I start two compute-nodes, I launch a VM, and I shutdown the compute-
  node which host the VM.

  I use this process to relaunch the VM on the other compute-node :

  http://docs.openstack.org/trunk/openstack-
  ops/content/maintenance.html#totle_compute_node_failure

  Once the VM is launched on the other compute node, fdb entries and
  neighbouring entries are no more populated on the network-node nor on
  the compute node

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1282956/+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 1553653] Re: Add a description field to all standard resources

2016-03-07 Thread Andreas Scheuring

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** 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/1553653

Title:
  Add a description field to all standard resources

Status in neutron:
  Invalid
Status in openstack-api-site:
  New

Bug description:
  https://review.openstack.org/269887
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 5dacbba701037200f9b0ae40c34981ecd941b41c
  Author: Kevin Benton 
  Date:   Wed Feb 10 17:00:21 2016 -0800

  Add a description field to all standard resources
  
  In order to give users and operators more flexibility in
  annotating the purpose of various Neutron resources, this patch
  adds a description field limited to 255 chars to all of the
  Neutron resources that reference the standard attribute table.
  The resource that reference the table are the following:
  security_group_rules, security_groups, ports, subnets,
  networks, routers, floatingips, subnetpools
  
  This patch adds a description table related to standard attributes
  and migrates over the existing security group description to the new
  table as well.
  
  Co-Authored-By: James Dempsey 
  
  APIImpact
  DocImpact: Adds a description field to all resources outline in
 commit message.
  Closes-Bug: #1483480
  Change-Id: I6e1ef53d7aae7d04a5485810cc1db0a8eb125953

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1553653/+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 1553128] Re: MOS8.0 (mirantis liberty) + neutron-lbaas-dashboard

2016-03-04 Thread Andreas Scheuring

** Also affects: horizon
   Importance: Undecided
   Status: New

** 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/1553128

Title:
  MOS8.0 (mirantis liberty) + neutron-lbaas-dashboard

Status in OpenStack Dashboard (Horizon):
  New
Status in neutron:
  Invalid

Bug description:
  When installing  neutron-lbaas-dashboard into Mirantis Openstack 8.0
  (based on Liberty), there is nothing on Project->Network->Load
  Balancers horizon's panels. No buttons, no menusnothing.

  Summary of steps followed:
  1. Install Openstack Liberty with Miratins FUEL 8.0 (deploys openstack with 
Ubuntu 14.04)
  2. git clone neutron-lbaas-dashboard 
  3. python setup.py install
  4. enable newproject panel ng_loadbalancersv2 with  "Copy 
_1481_project_ng_loadbalancersv2_panel.py in neutron_lbaas_dashboard/enabled 
directory to openstack_dashboard/local/enabled"
  5. /usr/share/openstack-dashboard/manage.py collectstatic
  6. /usr/share/openstack-dashboard/manage.py compress
  7. service apache2 restart

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1553128/+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 1552742] [NEW] macvtap: automatically generate example config file

2016-03-03 Thread Andreas Scheuring

Public bug reported:

For newly added macvtap agent, example configs are not getting
autogenerated like introduced with [1]


[1] https://review.openstack.org/#/c/204206/

** 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/1552742

Title:
  macvtap: automatically generate example config file

Status in neutron:
  New

Bug description:
  For newly added macvtap agent, example configs are not getting
  autogenerated like introduced with [1]



  [1] https://review.openstack.org/#/c/204206/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552742/+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 1551785] Re: macvtap: Macvtap L2 Agent

2016-03-03 Thread Andreas Scheuring

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: Confirmed => Invalid

** Changed in: openstack-manuals
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1551785

Title:
  macvtap: Macvtap L2 Agent

Status in neutron:
  Invalid
Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/275306
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 2e7eb09271912e9db1948b15ab3f8e184d4c324a
  Author: Andreas Scheuring <andreas.scheur...@de.ibm.com>
  Date:   Tue Feb 2 16:34:59 2016 +0100

  macvtap: Macvtap L2 Agent
  
  This agent is required by the macvtap ml2 driver to support
  macvtap attachments for libvirt qemu/kvm instances. It introduces
  a new configuration option MACVTAP.physical_interface_mappings.
  
  The review is submitted in three parts:
   - Part 1
  Common functions that are used by the ml2 driver and the agent
   - Part 2
   The Mechanism Driver to support port binding for macvtap attachments
   - Part 3 (this part)
  The Macvtap L2 Agent.
  
  DocImpact
  New ML2 mech driver + l2 agent
  New config option "macvtap.physical_interface_mappings"
  
  Change-Id: I219d80b4c704ac2f41edd3501f4b2198925778d6
  Closes-Bug: #1480979

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1551785/+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 1246525] Re: Horizon displays floating IPs to allocate from unreachable external networks of other tenants.

2016-03-03 Thread Andreas Scheuring

Setting to invalid along the comment of Akihiro.

** Changed in: neutron
   Status: Incomplete => 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/1246525

Title:
  Horizon displays floating IPs to allocate from unreachable external
  networks of other tenants.

Status in OpenStack Dashboard (Horizon):
  Expired
Status in neutron:
  Invalid

Bug description:
  Description of problem:
  ===
  Horizon displays floating IPs to allocate from unreachable external networks 
of other tenants.
  Those pools are not reachable and cannot be used by a non related tenant.

  Version-Release number of selected component (if applicable):
  =
  Grizzly, python-django-horizon-2013.1.4-1.el6ost.noarch

  How reproducible:
  =
  Always.

  Steps to Reproduce:
  ===
  1. Have two tenants (admin tenant, test tenant)
  2. Network for admin tenant:
     - Create network named: internal with the subnet 192.168.1.0/24
     - Create network named: external with the subnet 10.10.10.0/24 check 
External Network in Admin tab for this network.
     - Create Router named: Router1, Set gateway network: external
  3. Network for demo tenant:
     - Create network named: internal2 with the subnet 192.168.2.0/24
     - Create network named: external2 with the subnet 11.11.11.0/24 check 
External Network in Admin tab for this network.
     - Create Router named: Router2, Set gateway network: external2
  4. Launch an instance in admin tenant, attach the 'internal' network.
  5. Associate Floating IP to that instance.
  5. Click + and select the pool of the other tenant: external2.
  6. Click Associate

  Actual results:
  ===
  The IP address (11.11.11.x) suggested belongs to the other tenant pool: 
external2, which shouldn't be accessible.
  Association fails with the following error:

  Error: External network d1e2a98f-0ee6-4192-bdd4-eb759456f059 is not
  reachable from subnet 7e58ab9f-bac4-4544-af64-896c247542bd. Therefore,
  cannot associate Port 60550899-a94a-44e2-a231-fe344f1d1838 with a
  Floating IP.

  Error: Unable to associate IP address 11.11.11.3.

  Expected results:
  =
  Only IPs allocated to the current tenant should be listed.

  Additional Info:
  
  I've yet to test if this reproduces in Havana.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1246525/+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 1514548] Re: Cleanup linuxbridge_neutron_agent

2016-03-03 Thread Andreas Scheuring

** 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/1514548

Title:
  Cleanup linuxbridge_neutron_agent

Status in neutron:
  Fix Released

Bug description:
  Cleanup  linuxbridge_neutron_agent:

   * move bridge related features to bridge_lib
   * cleanup tests

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1514548/+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 1355153] Re: Inefficient implementation of Linuxbridge agent get_bridge_for_tap_device

2016-03-03 Thread Andreas Scheuring

already closed by

commit 459980f04a62e2ef15a2b8c91ac6c8d6ee484167
Author: Cedric Brandily 
Date:   Thu Nov 5 23:40:45 2015 +0100

Move LinuxBridge related features to bridge_lib

This change moves from linuxbridge agent[1] to bridge_lib[2] bridge only
related features and adds functional tests.


** Changed in: neutron
   Status: In Progress => 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/1355153

Title:
  Inefficient implementation of Linuxbridge agent
  get_bridge_for_tap_device

Status in neutron:
  Invalid

Bug description:
  The implementation of LinuxBridgeManager.get_bridge_for_tap_device
  uses an inefficient algorithm of repeatedly listing all bridges and
  their interfaces for each call.

  At scale, this implementation becomes very inefficient, causing the
  agent to become unresponsive in reporting interfaces as up to nova,
  leading to instance creation failure due to a timeout in
  LibvirtDriver._create_domain_and_network.

  This can be replaced with a constant-time implementation using the
  fact that the tap device's 'brport' directory contains a 'bridge'
  symlink to the bridge device, which carries the bridge name. The same
  symlink also exists as 'master' on the same level as 'brport'.

  The patch I propose also removes the single use of methods
  get_all_neutron_bridges and interface_exists_on_bridge. I left these
  methods in as their removal is not necessary for this bugfix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1355153/+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 1552631] Re: [RFE] Bulk Floating IP allocation

2016-03-03 Thread Andreas Scheuring

Hi Alex, thanks for reporting this new feature request. I wonder, is
this an action you would like to do via the GUI only, or also via the
Rest API?

** Summary changed:

- Multiple Floating IP allocation 
+ [RFE] Bulk Floating IP allocation

** Tags added: rfe

** Also affects: horizon
   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/1552631

Title:
  [RFE] Bulk Floating IP allocation

Status in OpenStack Dashboard (Horizon):
  New
Status in neutron:
  New

Bug description:
  I needed to allocate 2 floating IPs to my project.
  Via GUI: 
  access and security -> Floating IPs -> Allocate IP to project. 

  I noticed that in order to allocate 2 FIPs, I need to execute
  "Allocate IP to project" twice.

  The costumers have no option to allocate a  range of FIPs with one
  action. They need to do it one by one.

  BR
  Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1552631/+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 1552487] Re: Add tag mechanism for network resources

2016-03-02 Thread Andreas Scheuring

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** 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/1552487

Title:
  Add tag mechanism for network resources

Status in neutron:
  Invalid
Status in openstack-api-site:
  New
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/273881
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit ec1457dd7503626c917031ce4a16a366fe70c7bb
  Author: Hirofumi Ichihara 
  Date:   Tue Mar 1 11:05:56 2016 +0900

  Add tag mechanism for network resources
  
  Introduce a generic mechanism to allow the user to set tags
  on Neutron resources. This patch adds the function for "network"
  resource with tags.
  
  APIImpact
  DocImpact: allow users to set tags on network resources
  
  Partial-Implements: blueprint add-tags-to-core-resources
  Related-Bug: #1489291
  Change-Id: I4d9e80d2c46d07fc22de8015eac4bd3dacf4c03a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552487/+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 1552077] Re: Use network RBAC feature for external access

2016-03-02 Thread Andreas Scheuring

** Changed in: neutron
   Status: Confirmed => 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/1552077

Title:
  Use network RBAC feature for external access

Status in neutron:
  Invalid
Status in openstack-api-site:
  New

Bug description:
  https://review.openstack.org/282295
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 49b4dd3478d782aee4260033825aa6b47eaf644a
  Author: Kevin Benton 
  Date:   Fri Feb 19 03:34:27 2016 -0800

  Use network RBAC feature for external access
  
  This allows access to external networks to be controlled via the
  RBAC framework added during Liberty with a new 'access_as_external'
  action.
  
  A migration adds all current external networks to the RBAC policies
  table with a wildcard indicating that all tenants can access the network
  as RBAC.
  
  Unlike the conversion of shared networks to RBAC, the external table
  is left in the DB to avoid invasive changes throughout the codebase
  to calculate the flag relative to the caller. So the current 'external'
  flag is used throughout the code base as it previously was for wiring
  up floating IPs, router gateway ports, etc. Then the RBAC entries are
  only referenced when determining what networks to show the tenants.
  
  API Behavior:
   * Marking a network as 'external' will automatically create a wildcard
 entry that allows that network to be accessed by all tenants.
   * An external network may have all of its RBAC entries deleted and then
 only an admin will be able to attach to it.
   * An RBAC 'access_as_external' entry cannot be deleted if it is required
 for a tenant that currently has a router attached to that network.
   * Creating an 'access_as_external' RBAC entry will automatically convert
 the network into an external network. (This is to enable a workflow
 where a private external network is never visible to everyone.)
   * The default policy.json will prevent a non-admin from creating wildcard
 'access_as_external' RBAC entries to align with the current default 
policy
 we have on setting the 'external' field on the network to prevent 
poluting
 everyone else's network lists.
   * The default policy.json will allow a tenant to create an
 'access_as_external' RBAC entry to allow specific tenants
 (including itself) the ability to use its network as an external 
network.
  
  Closes-Bug: #1547985
  DocImpact: External networks can now have access restricted to small 
subsets
 of tenants
  APIImpact: 'access_as_external' will be allowed as an action in the RBAC
 API for networks
  Change-Id: I4d8ee78a9763c58884e4fd3d7b40133da659cd61

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552077/+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 1551907] Re: Add API extension for reporting IP availability usage statistics

2016-03-02 Thread Andreas Scheuring

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: Confirmed => 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/1551907

Title:
  Add API extension for reporting IP availability usage statistics

Status in neutron:
  Invalid
Status in openstack-api-site:
  New
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/212955
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 2f741ca5f9545c388270ddab774e9e030b006d8a
  Author: Mike Dorman 
  Date:   Thu Aug 13 21:24:58 2015 -0600

  Add API extension for reporting IP availability usage statistics
  
  Implements an API extension for reporting availibility of IP
  addresses on Neutron networks/subnets based on the blueprint
  proposed at https://review.openstack.org/#/c/180803/
  
  This provides an easy way for operators to count the number of
  used and total IP addresses on any or all networks and/or
  subnets.
  
  Co-Authored-By: David Bingham 
  Co-Authored-By: Craig Jellick 
  
  APIImpact
  DocImpact: As a new API, will need all new docs. See devref for details.
  
  Implements: blueprint network-ip-usage-api
  Closes-Bug: 1457986
  Change-Id: I81406054d46b2c0e0ffcd56e898e329f943ba46f

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1551907/+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 1552089] Re: Make agent interface plugging utilize network MTU

2016-03-02 Thread Andreas Scheuring

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: Confirmed => 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/1552089

Title:
  Make agent interface plugging utilize network MTU

Status in neutron:
  Invalid
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/283790
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 4df8d9a7016ab20fce235833d792b89309ec98a7
  Author: Kevin Benton 
  Date:   Mon Feb 22 16:41:45 2016 -0800

  Make agent interface plugging utilize network MTU
  
  This changes the 'plug' and 'plug_new' interfaces of the
  LinuxInterfaceDriver to accept an MTU argument. It then
  updates the dhcp agent and l3 agent to pass the MTU that
  is set on the network that the port belongs to. This allows
  it to take into account the overhead calculations that are
  done for encapsulation types.
  
  It's necessary for the L3 agent to have the MTU because it
  must recognize when fragmentation is needed so it can fragment
  or generate an ICMP error.
  
  It's necessary for the DHCP agent to have the MTU so it doesn't
  interfere when it plugs into a bridge with a larger than 1500
  MTU (the bridge would reduce its MTU to match the agent).
  
  If an operator sets 'network_device_mtu', the value of that
  will be used instead to preserve previous behavior.
  
  Closes-Bug: #1549470
  Closes-Bug: #1542108
  Closes-Bug: #1542475
  DocImpact: Neutron agents now support arbitrary MTU
 configurations on each network (including
 jumbo frames). This is accomplished by checking
 the MTU value defined for each network on which
 it is wiring VIFs.
  Co-Authored-By: Matt Kassawara 
  Change-Id: Ic091fa78dfd133179c71cbc847bf955a06cb248a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552089/+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 1552077] Re: Use network RBAC feature for external access

2016-03-02 Thread Andreas Scheuring

** Also affects: openstack-api-site
   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/1552077

Title:
  Use network RBAC feature for external access

Status in neutron:
  Invalid
Status in openstack-api-site:
  New

Bug description:
  https://review.openstack.org/282295
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 49b4dd3478d782aee4260033825aa6b47eaf644a
  Author: Kevin Benton 
  Date:   Fri Feb 19 03:34:27 2016 -0800

  Use network RBAC feature for external access
  
  This allows access to external networks to be controlled via the
  RBAC framework added during Liberty with a new 'access_as_external'
  action.
  
  A migration adds all current external networks to the RBAC policies
  table with a wildcard indicating that all tenants can access the network
  as RBAC.
  
  Unlike the conversion of shared networks to RBAC, the external table
  is left in the DB to avoid invasive changes throughout the codebase
  to calculate the flag relative to the caller. So the current 'external'
  flag is used throughout the code base as it previously was for wiring
  up floating IPs, router gateway ports, etc. Then the RBAC entries are
  only referenced when determining what networks to show the tenants.
  
  API Behavior:
   * Marking a network as 'external' will automatically create a wildcard
 entry that allows that network to be accessed by all tenants.
   * An external network may have all of its RBAC entries deleted and then
 only an admin will be able to attach to it.
   * An RBAC 'access_as_external' entry cannot be deleted if it is required
 for a tenant that currently has a router attached to that network.
   * Creating an 'access_as_external' RBAC entry will automatically convert
 the network into an external network. (This is to enable a workflow
 where a private external network is never visible to everyone.)
   * The default policy.json will prevent a non-admin from creating wildcard
 'access_as_external' RBAC entries to align with the current default 
policy
 we have on setting the 'external' field on the network to prevent 
poluting
 everyone else's network lists.
   * The default policy.json will allow a tenant to create an
 'access_as_external' RBAC entry to allow specific tenants
 (including itself) the ability to use its network as an external 
network.
  
  Closes-Bug: #1547985
  DocImpact: External networks can now have access restricted to small 
subsets
 of tenants
  APIImpact: 'access_as_external' will be allowed as an action in the RBAC
 API for networks
  Change-Id: I4d8ee78a9763c58884e4fd3d7b40133da659cd61

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552077/+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 1552085] Re: Router Interfaces Are Instantiated in Compute Nodes Which do not need them.

2016-03-02 Thread Andreas Scheuring

Hmmm, I think the nature that's how it should work, isn't it?

If you are connected to a router, my expectation would be that I could
ping all of the routers interfaces (e.g. for test purposes).  And what
if another vm on another subnet is spawned on another compute node,
would you expect that this interface is being added on your local
compute node?

I'm not a DVR expert, so setting this bug to opinion to get further
input from other memebers of the DVR team as well.

** Changed in: neutron
   Status: Confirmed => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1552085

Title:
  Router Interfaces Are Instantiated in Compute Nodes Which do not need
  them.

Status in neutron:
  Opinion

Bug description:
  Pre-Conditions: three node dvr topology created with devstack script
  from master branch

  step-by-step:
  as " source openrc admin admin"  (adminstrator)

  Dvr routers is created
  Three Subnets are attached to it.
  Only one vm is instantiated  and attach to only one subnet.

  Expected Output:
  The router is instantiated in the same compute node as the vm with only ONE 
qr- interface attached to BR-INT bridge

  Actual Output:
  The router is instantiated on the same compute node as the vm and THREE qr- 
interfaces are added to the BR-INT  bridge.
  One for each of the subnets attached to the router.

  Problem:
  Only one interface is needed on the BR-INT, the one for the subnet the vm is 
attached to.
  The other two are not doing anything except consuming resources.

  Version: Mitaka (master on March 1st, 2016)
   Ubuntu
  Perceived Severity:
     probably low. The presence of the other two unused interfaces does not 
affect functionality

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1552085/+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 1551219] [NEW] Remove hard coded "LinuxBridge" logs from common agent and make it variable

2016-02-29 Thread Andreas Scheuring

Public bug reported:

The Common Agent still has some hard coded "LinuxBridge" logs, although
it might be used by other agents (like macvtap agent) as well. Those
logs should reflect the agent type using the common agent.

** 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/1551219

Title:
  Remove hard coded "LinuxBridge" logs from common agent and make it
  variable

Status in neutron:
  New

Bug description:
  The Common Agent still has some hard coded "LinuxBridge" logs,
  although it might be used by other agents (like macvtap agent) as
  well. Those logs should reflect the agent type using the common agent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1551219/+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 1550400] [NEW] Macvtap driver/agent migrates instances on an invalid pyhsical network

2016-02-26 Thread Andreas Scheuring

Public bug reported:

More details to come soon

** 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/1550400

Title:
  Macvtap driver/agent migrates instances on an invalid pyhsical network

Status in neutron:
  New

Bug description:
  More details to come soon

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1550400/+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 1536942] [NEW] lb: "RTNETLINK answers: Transport endpoint is not connected" when setting vxlan device

2016-01-22 Thread Andreas Scheuring

Public bug reported:

Sometimes the following error appears in the linuxbridge q-agt log: [1]

Running command (rootwrap daemon): ['ip', 'link', 'set', 'vxlan-1066', 'up']
Exit code: 2; Stdin: ; Stdout: ; Stderr: RTNETLINK answers: Transport endpoint 
is not connected


This happens after a vxlan device has been created and should be set up. 
Interesting is, that it's always the first vxlan device that has been created 
(Had a look at 3 different logs). All vxlan devices that have been created 
after that could be set up fine.

After that a agent resync is triggered. The ensure_vxlan method detects,
that the interface is already there and does not create it again. But it
does not check if it is up as well - so it may still be in the down
state (don't know, can't locally reproduce it) and never put up. This
might be an issue.


Along logstash, the issue seemed to be occured the first time at January 13 [2].
The tests do not seem to fail due to this error, there are about as many 
succeeded runs as failed runs when this error shows up in the log. Probably 
that's because it's just a single node testing, and no package will ever leave 
the devstack node


A workaround could be to modify ensure_vxlan to add a check if it is up (and 
not just checking if it exists).

More details from [1]:
2016-01-20 16:44:35.226 DEBUG 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
[req-8731d5a6-8d07-4312-8d28-5746487f21cb None None] Creating vxlan interface 
vxlan-1066 for VNI 1066 ensure_vxlan 
/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:265
2016-01-20 16:44:35.228 DEBUG neutron.agent.linux.utils 
[req-8731d5a6-8d07-4312-8d28-5746487f21cb None None] Running command (rootwrap 
daemon): ['ip', 'link', 'add', 'vxlan-1066', 'type', 'vxlan', 'id', '1066', 
'group', '224.0.0.1', 'dev', 'eth0'] execute_rootwrap_daemon 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:100
2016-01-20 16:44:35.316 DEBUG neutron.agent.linux.utils 
[req-8731d5a6-8d07-4312-8d28-5746487f21cb None None] Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:142
2016-01-20 16:44:35.316 DEBUG neutron.agent.linux.utils 
[req-8731d5a6-8d07-4312-8d28-5746487f21cb None None] Running command (rootwrap 
daemon): ['ip', 'link', 'set', 'vxlan-1066', 'up'] execute_rootwrap_daemon 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:100
2016-01-20 16:44:35.329 ERROR neutron.agent.linux.utils 
[req-8731d5a6-8d07-4312-8d28-5746487f21cb None None] Exit code: 2; Stdin: ; 
Stdout: ; Stderr: RTNETLINK answers: Transport endpoint is not connected

2016-01-20 16:44:35.333 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
[req-8731d5a6-8d07-4312-8d28-5746487f21cb None None] Error in agent loop. 
Devices info: {'current': set(['tapce39edcc-d9']), 'removed': set([]), 'added': 
set(['tapce39edcc-d9']), 'updated': set([])}
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
Traceback (most recent call last):
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 1161, in daemon_loop
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
sync = self.process_network_devices(device_info)
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 967, in process_network_devices
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
resync_a = self.treat_devices_added_updated(devices_added_updated)
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 1001, in treat_devices_added_updated
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
device_details['port_id'], device_details['device_owner'])
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 473, in add_interface
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
tap_device_name, device_owner)
2016-01-20 16:44:35.333 23050 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 435, in

[Yahoo-eng-team] [Bug 1532171] [NEW] lb: hard reboot or destroy of vm can lead to error log and agent resync

2016-01-08 Thread Andreas Scheuring

Public bug reported:

A tap device can suddenly disappear e.g. due to instance destroy. If the
agent is in the midst of processing a a device update for this tap
device (e.g. due to a security group update), the agent logs the
following errors:

2016-01-07 17:43:52.225 DEBUG neutron.agent.linux.utils 
[req-07a4fb1d-88fe-40d7-b0fa-f93d1bac8a34 None None] Running command: ['ip', 
'-o', 'link', 'show', 'tapa0084edd-d4'] create_process 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:84
2016-01-07 17:43:52.230 DEBUG 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
[req-07a4fb1d-88fe-40d7-b0fa-f93d1bac8a34 None None] Tap device: tapa0084edd-d4 
does not exist on this host, skipped add_tap_interface 
/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:409
2016-01-07 17:43:52.230 DEBUG 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
[req-07a4fb1d-88fe-40d7-b0fa-f93d1bac8a34 None None] Setting admin_state_up to 
True for port a0084edd-d437-4ff0-b2e7-7cfd93ea34c4 ensure_port_admin_state 
/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py:686
2016-01-07 17:43:52.231 DEBUG neutron.agent.linux.utils 
[req-07a4fb1d-88fe-40d7-b0fa-f93d1bac8a34 None None] Running command (rootwrap 
daemon): ['ip', 'link', 'set', 'tapa0084edd-d4', 'up'] execute_rootwrap_daemon 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:100
2016-01-07 17:43:52.263 ERROR neutron.agent.linux.utils 
[req-07a4fb1d-88fe-40d7-b0fa-f93d1bac8a34 None None] Exit code: 1; Stdin: ; 
Stdout: ; Stderr: Cannot find device "tapa0084edd-d4"

2016-01-07 17:43:52.263 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
[req-07a4fb1d-88fe-40d7-b0fa-f93d1bac8a34 None None] Error in agent loop. 
Devices info: {'current': set(['tap3bbccdeb-0d', 'tap2cbadddb-48', 
'tap2ff01acc-16', 'tap92ccd364-e1', 'tap1b585b2d-f7', 'tap6838b208-7e', 
'tapf03a19db-48', 'tap294b5031-17', 'tapa0084edd-d4', 'tap6457a7f6-65', 
'tap91c29239-c1']), 'removed': set([]), 'added': set([]), 'updated': 
set([u'tapa0084edd-d4'])}
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
Traceback (most recent call last):
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 1191, in daemon_loop
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
sync = self.process_network_devices(device_info)
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 994, in process_network_devices
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
resync_a = self.treat_devices_added_updated(devices_added_updated)
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 1070, in treat_devices_added_updated
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
device_details['admin_state_up'])
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py",
 line 689, in ensure_port_admin_state
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
ip_lib.IPDevice(tap_name).link.set_up()
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 461, in set_up
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
return self._as_root([], ('set', self.name, 'up'))
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 321, in _as_root
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent 
use_root_namespace=use_root_namespace)
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 94, in _as_root
2016-01-07 17:43:52.263 23166 ERROR 
neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent

[Yahoo-eng-team] [Bug 1531862] [NEW] ServerPersonalityTestJSON:test_rebuild_server_with_personality fails intermittent

2016-01-07 Thread Andreas Scheuring

Public bug reported:

24 Hits in the last 30 days - all of them after the 31st of December!
[1]

2016-01-07 11:08:30.061 | Captured traceback:
2016-01-07 11:08:30.061 | ~~~
2016-01-07 11:08:30.061 | Traceback (most recent call last):
2016-01-07 11:08:30.062 |   File 
"tempest/api/compute/servers/test_server_personality.py", line 81, in 
test_rebuild_server_with_personality
2016-01-07 11:08:30.062 | waiters.wait_for_server_status(self.client, 
server_id, 'ACTIVE')
2016-01-07 11:08:30.062 |   File "tempest/common/waiters.py", line 95, in 
wait_for_server_status
2016-01-07 11:08:30.062 | raise exceptions.TimeoutException(message)
2016-01-07 11:08:30.062 | tempest.exceptions.TimeoutException: Request 
timed out
2016-01-07 11:08:30.062 | Details: 
(ServerPersonalityTestJSON:test_rebuild_server_with_personality) Server 
f22f189f-6fa2-4d6d-9a60-89ca045c6dbf failed to reach ACTIVE status and task 
state "None" within the required time (196 s). Current status: REBUILD. Current 
task state: rebuild_spawning.


Example Log: http://logs.openstack.org/18/246318/13/check/gate-tempest-
dsvm-neutron-linuxbridge/589bb9b/

[1]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ServerPersonalityTestJSON%3Atest_rebuild_server_with_personality)%20Server%5C%22

** 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/1531862

Title:
  ServerPersonalityTestJSON:test_rebuild_server_with_personality fails
  intermittent

Status in neutron:
  New

Bug description:
  24 Hits in the last 30 days - all of them after the 31st of December!
  [1]

  2016-01-07 11:08:30.061 | Captured traceback:
  2016-01-07 11:08:30.061 | ~~~
  2016-01-07 11:08:30.061 | Traceback (most recent call last):
  2016-01-07 11:08:30.062 |   File 
"tempest/api/compute/servers/test_server_personality.py", line 81, in 
test_rebuild_server_with_personality
  2016-01-07 11:08:30.062 | waiters.wait_for_server_status(self.client, 
server_id, 'ACTIVE')
  2016-01-07 11:08:30.062 |   File "tempest/common/waiters.py", line 95, in 
wait_for_server_status
  2016-01-07 11:08:30.062 | raise exceptions.TimeoutException(message)
  2016-01-07 11:08:30.062 | tempest.exceptions.TimeoutException: Request 
timed out
  2016-01-07 11:08:30.062 | Details: 
(ServerPersonalityTestJSON:test_rebuild_server_with_personality) Server 
f22f189f-6fa2-4d6d-9a60-89ca045c6dbf failed to reach ACTIVE status and task 
state "None" within the required time (196 s). Current status: REBUILD. Current 
task state: rebuild_spawning.


  
  Example Log: 
http://logs.openstack.org/18/246318/13/check/gate-tempest-dsvm-neutron-linuxbridge/589bb9b/

  [1]
  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ServerPersonalityTestJSON%3Atest_rebuild_server_with_personality)%20Server%5C%22

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1531862/+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 1522710] [NEW] Functional Test does not clean up ports when in default network namespace

2015-12-03 Thread Andreas Scheuring

Public bug reported:

The VethFixture in net_helpers.py does not clean up ports that were
created in the deafult network namespace. One exploiter is the
neutron/tests/functional/agent/linux/test_bridge_lib.py test. After one
test run, you have about 10 vethpairs, saying 20 new devices in your
default network namespace

** Affects: neutron
 Importance: Undecided
 Assignee: Andreas Scheuring (andreas-scheuring)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1522710

Title:
  Functional Test does not clean up ports when in default network
  namespace

Status in neutron:
  In Progress

Bug description:
  The VethFixture in net_helpers.py does not clean up ports that were
  created in the deafult network namespace. One exploiter is the
  neutron/tests/functional/agent/linux/test_bridge_lib.py test. After
  one test run, you have about 10 vethpairs, saying 20 new devices in
  your default network namespace

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1522710/+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 1520618] [NEW] Revert Disable IPV6 on bridge devices. It causes dhcp tap not plugged in bridge with vlan config

2015-11-27 Thread Andreas Scheuring

Public bug reported:

Commit [1] disables ipv6 on linuxbridges. On my linuxbridge vlan system,
this fix causes the code ensure_bridge() to return too early without
passing the bridge_name back.

The introduced method returns the output of the systcl -w call
+def disable_ipv6(self):
+cmd = 'net.ipv6.conf.%s.disable_ipv6=1' % self.name
+return self._sysctl([cmd])

The sysctl always outputs the config that has been set (at least on my ubuntu):
# sudo sysctl -w net.ipv6.conf.brq1192ca0d-a3.disable_ipv6=1
net.ipv6.conf.brq1192ca0d-a3.disable_ipv6 = 1

The check that has been introduced assumes that on successful executing, 
nothing (or return code 0) is returned - but the command always returns 
something!
+if bridge_device.disable_ipv6():
+return

The result is, that the tap device of the dhcp server is not plugged
into the bridge but instead still loosely hanging around.


Log from a lb tempest run [1]. after the sysctl command is executed, the method 
returns (the follow on call that sets the bridge up is missing):
2015-11-26 14:45:36.283 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:142
2015-11-26 14:45:36.284 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command (rootwrap 
daemon): ['sysctl', '-w', 'net.ipv6.conf.brq66379423-07.disable_ipv6=1'] 
execute_rootwrap_daemon /opt/stack/new/neutron/neutron/agent/linux/utils.py:100
2015-11-26 14:45:36.286 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:142
2015-11-26 14:45:36.286 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command: ['ip', 
'-o', 'link', 'show', 'vxlan-1009'] create_process 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:84
2015-11-26 14:45:36.294 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:142
2015-11-26 14:45:36.295 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command (rootwrap 
daemon): ['ip', 'link', 'set', 'tap35e6a6a9-ef', 'mtu', '1450'] 
execute_rootwrap_daemon 

[1] https://review.openstack.org/#/c/241076/
[2] 
http://logs.openstack.org/85/193485/21/check/gate-tempest-dsvm-neutron-linuxbridge/7341e9a/logs/screen-q-agt.txt.gz

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: linuxbridge

** Tags added: linuxbridge

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1520618

Title:
  Revert Disable IPV6 on bridge devices. It causes dhcp tap not plugged
  in bridge with vlan config

Status in neutron:
  New

Bug description:
  Commit [1] disables ipv6 on linuxbridges. On my linuxbridge vlan
  system, this fix causes the code ensure_bridge() to return too early
  without passing the bridge_name back.

  The introduced method returns the output of the systcl -w call
  +def disable_ipv6(self):
  +cmd = 'net.ipv6.conf.%s.disable_ipv6=1' % self.name
  +return self._sysctl([cmd])

  The sysctl always outputs the config that has been set (at least on my 
ubuntu):
  # sudo sysctl -w net.ipv6.conf.brq1192ca0d-a3.disable_ipv6=1
  net.ipv6.conf.brq1192ca0d-a3.disable_ipv6 = 1

  The check that has been introduced assumes that on successful executing, 
nothing (or return code 0) is returned - but the command always returns 
something!
  +if bridge_device.disable_ipv6():
  +return

  The result is, that the tap device of the dhcp server is not plugged
  into the bridge but instead still loosely hanging around.

  
  Log from a lb tempest run [1]. after the sysctl command is executed, the 
method returns (the follow on call that sets the bridge up is missing):
  2015-11-26 14:45:36.283 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:142
  2015-11-26 14:45:36.284 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command (rootwrap 
daemon): ['sysctl', '-w', 'net.ipv6.conf.brq66379423-07.disable_ipv6=1'] 
execute_rootwrap_daemon /opt/stack/new/neutron/neutron/agent/linux/utils.py:100
  2015-11-26 14:45:36.286 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:142
  2015-11-26 14:45:36.286 DEBUG neutron.agent.linux.utils 
[req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command: ['ip', 
'-o', 'link', 'show', 'vxlan-1009'] create_process

[Yahoo-eng-team] [Bug 1520255] [NEW] All linuxbridge agent tests executed with prevent_arp_spoofing=False

2015-11-26 Thread Andreas Scheuring

Public bug reported:

All testcases of the linuxbridge agent are executed with
prevent_arp_spoofing=False.

The solution is to add testcases that are executed with
prevent_arp_spoofing=True. arp_protect should be mocked and it should be
ensured, that it has been called.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: linuxbridge

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1520255

Title:
  All linuxbridge agent tests executed with prevent_arp_spoofing=False

Status in neutron:
  New

Bug description:
  All testcases of the linuxbridge agent are executed with
  prevent_arp_spoofing=False.

  The solution is to add testcases that are executed with
  prevent_arp_spoofing=True. arp_protect should be mocked and it should
  be ensured, that it has been called.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1520255/+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 1515906] Re: lb: TypeError: %d format: a number is required, not unicode found in linuxbridge agent log

2015-11-16 Thread Andreas Scheuring

Had a quick look at 2 other patchsets - Haven't found this message in
there. So probably related to my patchset?

I set to invalid - try to investigate and if still exists, open this bug
again. Sorry for the inconvenience!

** Changed in: neutron
   Status: Triaged => Invalid

** Changed in: oslo.log
   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/1515906

Title:
  lb: TypeError: %d format: a number is required, not unicode found in
  linuxbridge agent log

Status in neutron:
  Invalid
Status in oslo.log:
  Invalid

Bug description:
  Seems NOT to have any functional impact!

  The following message showed up during linuxbridge tempest runs in
  q-agt logfile [1]:

  2015-11-12 09:20:08.548 DEBUG neutron.agent.linux.utils 
[req-b7d3dcbb-0a93-4474-b4dc-d8bfea202fb3 None None] Running command (rootwrap 
daemon): ['ip', 'link', 'set', 'tap4d65ca18-97', 'mtu', '1450'] 
execute_rootwrap_daemon /opt/stack/new/neutron/neutron/agent/linux/utils.py:99
  2015-11-12 09:20:08.552 DEBUG neutron.agent.linux.utils 
[req-b7d3dcbb-0a93-4474-b4dc-d8bfea202fb3 None None] Command: ['ip', 'link', 
'set', u'tap4d65ca18-97', 'mtu', 1450]; Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:150
  Traceback (most recent call last):
File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
  msg = self.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line 
117, in format
  return logging.StreamHandler.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
  return fmt.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line 
236, in format
  return logging.Formatter.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
  record.message = record.getMessage()
File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
  msg = msg % self.args
  TypeError: %d format: a number is required, not unicode
  Logged from file linuxbridge_neutron_agent.py, line 458

  Line 458 in linuxbridge_neutron_agent.py is this line in the tested
  patchst:

bridge_name = self.get_bridge_name(network_id)

  [1] http://logs.openstack.org/85/193485/13/check/gate-tempest-dsvm-
  neutron-linuxbridge/079f108/logs/screen-q-agt.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1515906/+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 1515906] [NEW] lb: TypeError: %d format: a number is required, not unicode found in linuxbridge agent log

2015-11-13 Thread Andreas Scheuring

Public bug reported:

Seems NOT to have any functional impact!

The following message showed up during linuxbridge tempest runs in q-agt
logfile [1]:

2015-11-12 09:20:08.548 DEBUG neutron.agent.linux.utils 
[req-b7d3dcbb-0a93-4474-b4dc-d8bfea202fb3 None None] Running command (rootwrap 
daemon): ['ip', 'link', 'set', 'tap4d65ca18-97', 'mtu', '1450'] 
execute_rootwrap_daemon /opt/stack/new/neutron/neutron/agent/linux/utils.py:99
2015-11-12 09:20:08.552 DEBUG neutron.agent.linux.utils 
[req-b7d3dcbb-0a93-4474-b4dc-d8bfea202fb3 None None] Command: ['ip', 'link', 
'set', u'tap4d65ca18-97', 'mtu', 1450]; Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:150
Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
msg = self.format(record)
  File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line 117, 
in format
return logging.StreamHandler.format(self, record)
  File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
return fmt.format(record)
  File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line 
236, in format
return logging.Formatter.format(self, record)
  File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
record.message = record.getMessage()
  File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
msg = msg % self.args
TypeError: %d format: a number is required, not unicode
Logged from file linuxbridge_neutron_agent.py, line 458

Line 458 in linuxbridge_neutron_agent.py is this line in the tested
patchst:

  bridge_name = self.get_bridge_name(network_id)

[1] http://logs.openstack.org/85/193485/13/check/gate-tempest-dsvm-
neutron-linuxbridge/079f108/logs/screen-q-agt.txt.gz

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: linuxbridge

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1515906

Title:
  lb: TypeError: %d format: a number is required, not unicode found in
  linuxbridge agent log

Status in neutron:
  New

Bug description:
  Seems NOT to have any functional impact!

  The following message showed up during linuxbridge tempest runs in
  q-agt logfile [1]:

  2015-11-12 09:20:08.548 DEBUG neutron.agent.linux.utils 
[req-b7d3dcbb-0a93-4474-b4dc-d8bfea202fb3 None None] Running command (rootwrap 
daemon): ['ip', 'link', 'set', 'tap4d65ca18-97', 'mtu', '1450'] 
execute_rootwrap_daemon /opt/stack/new/neutron/neutron/agent/linux/utils.py:99
  2015-11-12 09:20:08.552 DEBUG neutron.agent.linux.utils 
[req-b7d3dcbb-0a93-4474-b4dc-d8bfea202fb3 None None] Command: ['ip', 'link', 
'set', u'tap4d65ca18-97', 'mtu', 1450]; Exit code: 0 execute 
/opt/stack/new/neutron/neutron/agent/linux/utils.py:150
  Traceback (most recent call last):
File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
  msg = self.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line 
117, in format
  return logging.StreamHandler.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
  return fmt.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line 
236, in format
  return logging.Formatter.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
  record.message = record.getMessage()
File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
  msg = msg % self.args
  TypeError: %d format: a number is required, not unicode
  Logged from file linuxbridge_neutron_agent.py, line 458

  Line 458 in linuxbridge_neutron_agent.py is this line in the tested
  patchst:

bridge_name = self.get_bridge_name(network_id)

  [1] http://logs.openstack.org/85/193485/13/check/gate-tempest-dsvm-
  neutron-linuxbridge/079f108/logs/screen-q-agt.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1515906/+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 1515311] [NEW] Instance scheduling based on Neutron properties

2015-11-11 Thread Andreas Scheuring

Public bug reported:

Add support to allow nova scheduler place instances along available
neutron properties.

Use case: 
- Scheduling along physical network: A certain network (e.g. your fast 100Gbit 
network) is only available to a subset of the nodes (e.g. per rack).
- Schedulding along QoS attributes: Schedule instances along available bandwidth

Proposal:
Integration might be challenging, as also nova needs to be enhanced with a new 
filter. Ihar talked to nova folks (Nikola Dipanov, Jay Pipes, Sylvain) but they 
seemed not to be interested in fulfilling this need right now. However they 
have a vague idea of a scheduler hook to influence scheduling decisions.

Alternative to nova scheduler hook:
Today scheduling decision is made on resource data reported from nova-cpu to 
nova scheduler via the message bus. What would be required is a similar 
reporting from neutron-agent to nova-scheduler. However such a private path 
might be against the decoupling of nova and neutron, introduce new message 
topics and so on. 


Note: This bug is intended to track all information from Neutron side. It's not 
meant as a requirement against nova.

** 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/1515311

Title:
  Instance scheduling based on Neutron properties

Status in neutron:
  New

Bug description:
  Add support to allow nova scheduler place instances along available
  neutron properties.

  Use case: 
  - Scheduling along physical network: A certain network (e.g. your fast 
100Gbit network) is only available to a subset of the nodes (e.g. per rack).
  - Schedulding along QoS attributes: Schedule instances along available 
bandwidth

  Proposal:
  Integration might be challenging, as also nova needs to be enhanced with a 
new filter. Ihar talked to nova folks (Nikola Dipanov, Jay Pipes, Sylvain) but 
they seemed not to be interested in fulfilling this need right now. However 
they have a vague idea of a scheduler hook to influence scheduling decisions.

  Alternative to nova scheduler hook:
  Today scheduling decision is made on resource data reported from nova-cpu to 
nova scheduler via the message bus. What would be required is a similar 
reporting from neutron-agent to nova-scheduler. However such a private path 
might be against the decoupling of nova and neutron, introduce new message 
topics and so on. 

  
  Note: This bug is intended to track all information from Neutron side. It's 
not meant as a requirement against nova.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1515311/+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 1496929] Re: instance launch failed: TooManyExternalNetworks: More than one external network exists

2015-09-18 Thread Andreas Scheuring

Looks like a configuration issue. Maybe one of the vmware neutron folks
can help out?

** Summary changed:

- instance luanch failed
+ instance launch failed: TooManyExternalNetworks: More than one external 
network exists

** Also 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/1496929

Title:
  instance launch failed: TooManyExternalNetworks: More than one
  external network exists

Status in neutron:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  Hello, I followed the documentation  " http://docs.openstack.org/kilo
  /config-reference/content/vmware.html " to connect ESXi with OpenStack
  Juno, i put the following configuration on the compute node, nova.conf
  file :

  [DEFAULT]
  compute_driver=vmwareapi.VMwareVCDriver
   
  [vmware]
  host_ip=
  host_username=
  host_password=
  cluster_name=
  datastore_regex=

  And in the nova-compute.conf :

  [DEFAULT]
  compute_driver=vmwareapi.VMwareVCDriver

  
  But in vain, on the juno OpenStack Dashboard when i whant to launch instance, 
i have error " Error: Failed to launch instance "Test": Please try again later 
[Error: No valid host was found. ]. ", plz there is an idea for launce instance 
in my ESXi.

  attached the logs on the controller and compute node:

  ==> nova-conductor

  ERROR nova.scheduler.utils [req-618d4ee3-c936-4249-9f8c-7c266d5f9264 None] 
[instance: 0c1ee287-edfe-4258-bb43-db23338bbe90] Error from last host: 
ComputeNode (node domain-c65(Compute)): [u'Traceback (most recent call 
last):\n', u'  File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", 
line 2054, in _do_build_and_run_instance\nfilter_properties)\n', u'  File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2185, in 
_build_and_run_instance\ninstance_uuid=instance.uuid, 
reason=six.text_type(e))\n', u'RescheduledException: Build of instance 
0c1ee287-edfe-4258-bb43-db23338bbe90 was re-scheduled: Network could not be 
found for bridge br-int\n']
  2015-09-17 15:31:34.921 2432 WARNING nova.scheduler.driver 
[req-618d4ee3-c936-4249-9f8c-7c266d5f9264 None] [instance: 
0c1ee287-edfe-4258-bb43-db23338bbe90] NoValidHost exception with message: 'No 
valid host was found.'

  
  => neutron 
  2015-09-17 12:36:09.398 1840 ERROR oslo.messaging._drivers.common 
[req-775407a3-d756-4677-bdb9-0ddfe2fac50c ] Returning exception More than one 
external network exists to caller
  2015-09-17 12:36:09.398 1840 ERROR oslo.messaging._drivers.common 
[req-775407a3-d756-4677-bdb9-0ddfe2fac50c ] ['Traceback (most recent call 
last):\n', '  File 
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 134, 
in _dispatch_and_reply\nincoming.message))\n', '  File 
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 177, 
in _dispatch\nreturn self._do_dispatch(endpoint, method, ctxt, args)\n', '  
File "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 
123, in _do_dispatch\nresult = getattr(endpoint, method)(ctxt, 
**new_args)\n', '  File 
"/usr/lib/python2.7/dist-packages/neutron/api/rpc/handlers/l3_rpc.py", line 
149, in get_external_network_id\nnet_id = 
self.plugin.get_external_network_id(context)\n', '  File 
"/usr/lib/python2.7/dist-packages/neutron/db/external_net_db.py", line 161, in 
get_external_network_id\nraise n_exc.TooManyExternalNetworks()\n', 
'TooManyExternalNetworks: More than one e
 xternal network exists\n']

  
  =>  compute Node / nova-compute

  2015-09-17 15:28:22.323 5944 ERROR oslo.vmware.common.loopingcall [-] in 
fixed duration looping call
  2015-09-17 15:31:33.550 5944 ERROR nova.compute.manager [-] [instance: 
0c1ee287-edfe-4258-bb43-db23338bbe90] Instance failed to spawn

  
  => nova-network / nova-compute

  2015-09-17 11:21:10.840 1363 ERROR oslo.messaging._drivers.impl_rabbit [-] 
AMQP server on ControllerNode01:5672 is unreachable: [Errno 111] ECONNREFUSED. 
Trying again in 3 seconds.
  2015-09-17 11:23:02.874 1363 ERROR nova.openstack.common.periodic_task [-] 
Error during VlanManager._disassociate_stale_fixed_ips: Timed out waiting for a 
reply to message ID b6d62061352e4590a37cbc0438ea3ef0

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496929/+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 1495960] [NEW] linuxbridge with vlan crashes when long device names used

2015-09-15 Thread Andreas Scheuring

Public bug reported:

The linuxbridge agent creates a linux vlan-device for each openstack vlan 
network that has been defined. Therefore the code uses the following naming 
scheme : .
Example: eth-dev-name: eth0, vlan-id: 1000 --> eth0.1000

This works fine, if eth-dev-name is a short name like "eth0". If there
is a long device name (e.g. long-device-name) this will cause trouble,
as the vlan device name "long-device-name.1000" exceeds the max length
of a linux network device, which is 15 chars.

Today the linuxbridge agent fails with

Command: ['ip', 'link', 'add', 'link', 'too_long_name', 'name', 
'too_long_name.1007', 'type', 'vlan', 'id', 1007]
Exit code: 255
Stderr: Error: argument "too_long_name.1007" is wrong: "name" too long

The same problem needs to be solved for the new macvtap agent that is
currently under development [1] as well


[1] https://bugs.launchpad.net/neutron/+bug/1480979

** 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/1495960

Title:
  linuxbridge with vlan crashes when long device names used

Status in neutron:
  New

Bug description:
  The linuxbridge agent creates a linux vlan-device for each openstack vlan 
network that has been defined. Therefore the code uses the following naming 
scheme : .
  Example: eth-dev-name: eth0, vlan-id: 1000 --> eth0.1000

  This works fine, if eth-dev-name is a short name like "eth0". If there
  is a long device name (e.g. long-device-name) this will cause trouble,
  as the vlan device name "long-device-name.1000" exceeds the max length
  of a linux network device, which is 15 chars.

  Today the linuxbridge agent fails with

  Command: ['ip', 'link', 'add', 'link', 'too_long_name', 'name', 
'too_long_name.1007', 'type', 'vlan', 'id', 1007]
  Exit code: 255
  Stderr: Error: argument "too_long_name.1007" is wrong: "name" too long

  The same problem needs to be solved for the new macvtap agent that is
  currently under development [1] as well

  
  [1] https://bugs.launchpad.net/neutron/+bug/1480979

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1495960/+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 1423484] Re: dhcpv6-stateful: error message in contradiction to spec

2015-07-31 Thread Andreas Scheuring

** Changed in: neutron
   Status: In Progress = 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/1423484

Title:
  dhcpv6-stateful: error message in contradiction to spec

Status in neutron:
  Invalid

Bug description:
  The spec [1] points out how a subnet configured with ipv6 address mode 
dhcpv6-stateful and ra mode none should behave:
  VM obtains IPv6 address and optional info from dnsmasq using DHCPv6 
stateful [1]

  Now creating such an subnet and adding it as routers interface resulted in 
the following error message:
  neutron subnet-create --name subnet_ipv6-network --enable-dhcp --ip-version 6 
--ipv6-address-mode dhcpv6-stateful ipv6-network 2003::/64
  Created a new subnet:
  
+---+--+
  | Field | Value   
 |
  
+---+--+
  | allocation_pools  | {start: 2003::2, end: 
2003:::::fffe} |
  | cidr  | 2003::/64   
 |
  | dns_nameservers   | 
 |
  | enable_dhcp   | True
 |
  | gateway_ip| 2003::1 
 |
  | host_routes   | 
 |
  | id| 4c3f8b16-633c-492c-964e-20cbd4f0b30a
 |
  | ip_version| 6   
 |
  | ipv6_address_mode | dhcpv6-stateful 
 |
  | ipv6_ra_mode  | 
 |
  | name  | subnet_ipv6-network 
 |
  | network_id| 2bbd0b0c-0809-43b8-a98f-4f552dcba4d3
 |
  | tenant_id | 3ccda9db620a4d13940f9e79f12d5940
 |
  
+---+--+
  neutron router-interface-add router1 subnet_ipv6-network
  Bad router request: IPv6 subnet 4c3f8b16-633c-492c-964e-20cbd4f0b30a 
configured to receive RAs from an external router cannot be added to Neutron 
Router.

  -- This seems to be in contradiction to what described in the spec!

  [1] https://review.openstack.org/#/c/101306/8/specs/juno/ipv6-radvd-
  ra.rst

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1423484/+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 1467919] Re: networking-macvtap ml2 driver and agent

2015-07-09 Thread Andreas Scheuring

Just set up my external repo along the guidlines and it's working
perfeclty without any fixes into Neutron. Great work!

** Changed in: neutron
   Status: Confirmed = 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/1467919

Title:
  networking-macvtap ml2 driver and agent

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  This defect is to  track the integration of the stackforge networking-
  macvtap ml2 plugin + agent [1] into neutron

  
  [1] https://review.openstack.org/#/c/189644/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1467919/+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 1467919] [NEW] netwokring-macvtap ml2 driver and agent

2015-06-23 Thread Andreas Scheuring

Public bug reported:

This defect is to  track the integration of the stackforge networking-
macvtap ml2 plugin + agent [1] into neutron


[1] https://review.openstack.org/#/c/189644/

** 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/1467919

Title:
  netwokring-macvtap ml2 driver and agent

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  This defect is to  track the integration of the stackforge networking-
  macvtap ml2 plugin + agent [1] into neutron

  
  [1] https://review.openstack.org/#/c/189644/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1467919/+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 1423484] [NEW] dhcpv6-stateful: error message in contradiction to spec

2015-02-19 Thread Andreas Scheuring

Public bug reported:

The spec [1] points out how a subnet configured with ipv6 address mode 
dhcpv6-stateful and ra mode none should behave:
VM obtains IPv6 address and optional info from dnsmasq using DHCPv6 stateful 
[1]

Now creating such an subnet and adding it as routers interface resulted in the 
following error message:
neutron subnet-create --name subnet_ipv6-network --enable-dhcp --ip-version 6 
--ipv6-address-mode dhcpv6-stateful ipv6-network 2003::/64
Created a new subnet:
+---+--+
| Field | Value|
+---+--+
| allocation_pools  | {start: 2003::2, end: 2003:::::fffe} |
| cidr  | 2003::/64|
| dns_nameservers   |  |
| enable_dhcp   | True |
| gateway_ip| 2003::1  |
| host_routes   |  |
| id| 4c3f8b16-633c-492c-964e-20cbd4f0b30a |
| ip_version| 6|
| ipv6_address_mode | dhcpv6-stateful  |
| ipv6_ra_mode  |  |
| name  | subnet_ipv6-network  |
| network_id| 2bbd0b0c-0809-43b8-a98f-4f552dcba4d3 |
| tenant_id | 3ccda9db620a4d13940f9e79f12d5940 |
+---+--+
neutron router-interface-add router1 subnet_ipv6-network
Bad router request: IPv6 subnet 4c3f8b16-633c-492c-964e-20cbd4f0b30a configured 
to receive RAs from an external router cannot be added to Neutron Router.

-- This seems to be in contradiction to what described in the spec!

[1] https://review.openstack.org/#/c/101306/8/specs/juno/ipv6-radvd-
ra.rst

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: ipv6

** Description changed:

  The spec [1] points out how a subnet configured with ipv6 address mode 
dhcpv6-stateful and ra mode none should behave:
  VM obtains IPv6 address and optional info from dnsmasq using DHCPv6 
stateful [1]
  
- No creating such an subnet and adding it as routers interface resulted in the 
following error message:
+ Now creating such an subnet and adding it as routers interface resulted in 
the following error message:
  neutron subnet-create --name subnet_ipv6-network --enable-dhcp --ip-version 6 
--ipv6-address-mode dhcpv6-stateful ipv6-network 2003::/64
  Created a new subnet:
  
+---+--+
  | Field | Value   
 |
  
+---+--+
  | allocation_pools  | {start: 2003::2, end: 
2003:::::fffe} |
  | cidr  | 2003::/64   
 |
  | dns_nameservers   | 
 |
  | enable_dhcp   | True
 |
  | gateway_ip| 2003::1 
 |
  | host_routes   | 
 |
  | id| 4c3f8b16-633c-492c-964e-20cbd4f0b30a
 |
  | ip_version| 6   
 |
  | ipv6_address_mode | dhcpv6-stateful 
 |
  | ipv6_ra_mode  | 
 |
  | name  | subnet_ipv6-network 
 |
  | network_id| 2bbd0b0c-0809-43b8-a98f-4f552dcba4d3
 |
  | tenant_id | 3ccda9db620a4d13940f9e79f12d5940
 |
  
+---+--+
  neutron router-interface-add router1 subnet_ipv6-network
  Bad router request: IPv6 subnet 4c3f8b16-633c-492c-964e-20cbd4f0b30a 
configured to receive RAs from an external router cannot be added to Neutron 
Router.
  
+ -- This seems to be in contradiction to what described in the spec!
  
- -- This seems to be in contradiction to what described in the spec! 
- 
- 
- 
- [1] https://review.openstack.org/#/c/101306/8/specs/juno/ipv6-radvd-ra.rst
+ [1] https://review.openstack.org/#/c/101306/8/specs/juno/ipv6-radvd-
+ ra.rst

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.

55 matches

Mail list logo