date:20170614

[Yahoo-eng-team] [Bug 1698058] [NEW] L3DvrTestCase.test_dvr_gateway_host_binding_is_set: MismatchError: u'host0' != u'standby'

2017-06-14 Thread IWAMOTO Toshihiro

Public bug reported:

L3DvrTestCase.test_dvr_gateway_host_binding_is_set is recently added in commit 
abe99383.
It seems to fail often with MismatchError: u'host0' != u'standby'.

Example:
http://logs.openstack.org/63/470063/5/check/gate-neutron-dsvm-functional-ubuntu-xenial/4063789/testr_results.html.gz

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: functional-tests gate-failure

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

Title:
  L3DvrTestCase.test_dvr_gateway_host_binding_is_set: MismatchError:
  u'host0' != u'standby'

Status in neutron:
  New

Bug description:
  L3DvrTestCase.test_dvr_gateway_host_binding_is_set is recently added in 
commit abe99383.
  It seems to fail often with MismatchError: u'host0' != u'standby'.

  Example:
  
http://logs.openstack.org/63/470063/5/check/gate-neutron-dsvm-functional-ubuntu-xenial/4063789/testr_results.html.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1698058/+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 1698046] [NEW] Add support for ingress bandwidth limit rules in ovs agent

2017-06-14 Thread OpenStack Infra

Public bug reported:

https://review.openstack.org/457816
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 2d0d1a2d76c3383bd1e2d14e8860824d843f5047
Author: Sławek Kapłoński 
Date:   Wed Apr 19 00:40:38 2017 +0200

Add support for ingress bandwidth limit rules in ovs agent

Add support for QoS ingress bandwidth limiting in
openvswitch agent.
It uses default ovs QoS policies on bandwidth limiting
mechanism.

DocImpact: Ingress bandwidth limit in QoS supported by
   Openvswitch agent

Change-Id: I9d94e27db5d574b61061689dc99f12f095625ca0
Partial-Bug: #1560961

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc neutron

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

Title:
  Add support for ingress bandwidth limit rules in ovs agent

Status in neutron:
  New

Bug description:
  https://review.openstack.org/457816
  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 2d0d1a2d76c3383bd1e2d14e8860824d843f5047
  Author: Sławek Kapłoński 
  Date:   Wed Apr 19 00:40:38 2017 +0200

  Add support for ingress bandwidth limit rules in ovs agent
  
  Add support for QoS ingress bandwidth limiting in
  openvswitch agent.
  It uses default ovs QoS policies on bandwidth limiting
  mechanism.
  
  DocImpact: Ingress bandwidth limit in QoS supported by
 Openvswitch agent
  
  Change-Id: I9d94e27db5d574b61061689dc99f12f095625ca0
  Partial-Bug: #1560961

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1698046/+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 1275967] Re: devstack leaves stale .pyc files around

2017-06-14 Thread Sean Dague

This devstack bug was last updated over 180 days ago, as devstack
is a fast moving project and we'd like to get the tracker down to
currently actionable bugs, this is getting marked as Invalid. If the
issue still exists, please feel free to reopen it.

** Changed in: devstack
   Status: New => Invalid

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

Title:
  devstack leaves stale .pyc files around

Status in devstack:
  Invalid
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  nova was recently ported to oslo.incubator.  This results in devstack
  raising an exception about duplicate rpc_backend options being
  registered.  The problem is that openstack/common/service.py was not
  updated as part of that work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1275967/+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 1277507] Re: "ImportError: No module named passlib.hash"; HTTP error 403 while getting ipaddr from googledrive.com

2017-06-14 Thread Sean Dague

This devstack bug was last updated over 180 days ago, as devstack
is a fast moving project and we'd like to get the tracker down to
currently actionable bugs, this is getting marked as Invalid. If the
issue still exists, please feel free to reopen it.

** Changed in: devstack
   Status: New => Invalid

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

Title:
  "ImportError: No module named passlib.hash"; HTTP error 403 while
  getting ipaddr from googledrive.com

Status in devstack:
  Invalid
Status in gantt:
  New
Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Core Infrastructure:
  Invalid
Status in oslo-incubator:
  Invalid
Status in python-keystoneclient:
  Invalid
Status in zaqar:
  Invalid

Bug description:
  Example from http://logs.openstack.org/99/69799/9/gate/gate-tempest-
  dsvm-full/ca0c1b3/console.html

  2014-02-06 20:20:45.531 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/bin/keystone-manage", line 37, in 
  2014-02-06 20:20:45.532 | 2014-02-06 20:20:45 from keystone import cli
  2014-02-06 20:20:45.534 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/keystone/cli.py", line 26, in 
  2014-02-06 20:20:45.535 | 2014-02-06 20:20:45 from keystone.common import 
openssl
  2014-02-06 20:20:45.537 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/keystone/common/openssl.py", line 21, in 
  2014-02-06 20:20:45.539 | 2014-02-06 20:20:45 from keystone.common import 
utils
  2014-02-06 20:20:45.540 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/keystone/common/utils.py", line 28, in 
  2014-02-06 20:20:45.543 | 2014-02-06 20:20:45 import passlib.hash
  2014-02-06 20:20:45.543 | 2014-02-06 20:20:45 ImportError: No module named 
passlib.hash
  2014-02-06 20:20:45.545 | 2014-02-06 20:20:45 + [[ PKI == \P\K\I ]]
  2014-02-06 20:20:45.571 | 2014-02-06 20:20:45 + rm -rf /etc/keystone/ssl
  2014-02-06 20:20:45.572 | 2014-02-06 20:20:45 + 
/opt/stack/new/keystone/bin/keystone-manage pki_setup
  2014-02-06 20:20:45.573 | 2014-02-06 20:20:45 Traceback (most recent call 
last):
  2014-02-06 20:20:45.573 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/bin/keystone-manage", line 37, in 
  2014-02-06 20:20:45.573 | 2014-02-06 20:20:45 from keystone import cli
  2014-02-06 20:20:45.574 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/keystone/cli.py", line 26, in 
  2014-02-06 20:20:45.574 | 2014-02-06 20:20:45 from keystone.common import 
openssl
  2014-02-06 20:20:45.574 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/keystone/common/openssl.py", line 21, in 
  2014-02-06 20:20:45.575 | 2014-02-06 20:20:45 from keystone.common import 
utils
  2014-02-06 20:20:45.577 | 2014-02-06 20:20:45   File 
"/opt/stack/new/keystone/keystone/common/utils.py", line 28, in 
  2014-02-06 20:20:45.577 | 2014-02-06 20:20:45 import passlib.hash
  2014-02-06 20:20:45.578 | 2014-02-06 20:20:45 ImportError: No module named 
passlib.hash

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1277507/+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 1695101] Re: DVR Router ports and gateway ports are not bound to any host and no snat namespace created

2017-06-14 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/470063
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=abe9938367f3f7cf21e5c0e42ee7b9b81b4960b0
Submitter: Jenkins
Branch:master

commit abe9938367f3f7cf21e5c0e42ee7b9b81b4960b0
Author: Swaminathan Vasudevan 
Date:   Thu Jun 1 15:49:38 2017 -0700

DVR: Fix DVR Router snat ports and gateway ports host binding issue

DVR snat ports and gateway ports are not bound to any host
and so we don't see the snat namespace getting created.

The issue is the _build_routers_list in l3_dvr_db.py is not called due
to the inheritance order.

Change-Id: I56f9de31524aeef262cf2a78be3abf8487c21a12
Closes-Bug: #1695101


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

Title:
  DVR Router ports and gateway ports are not bound to any host and no
  snat namespace created

Status in neutron:
  Fix Released

Bug description:
  In the Pike cycle there were some refactoring to the DVR db classes and 
resource handler mixin. 
  This lead to the regression where it was not creating the SNAT namespace for 
the DVR routers if it has gateway configured.

  The only namespace seen was the fipnamespace.

  This was the patch set that caused the regression.
  https://review.openstack.org/#/c/457592/5

  On further debugging it was found that the snat ports and the
  distributed router ports were not host bound. The neutron was trying
  to bind it to a 'null' host.

  The '_build_routers_list' function in the l3_dvr_db.py was not called
  and hence the host binding was missing.

  We have seen a similar issue a while back, #1369012 (Fix KeyError on
  missing gw_port_host for L3 agent in DVR mode

  The issue here is the order of inheritance of the classes. If the
  order of inheritance of the classes are messed up, then the functions
  that are over-ridden are not called in the right order or skipped.

  So with this we have seen the same problem, where the
  '_build_routers_list' in the l3_db_gwmode.py was called and not the
  one in the 'l3_dvr_db.py' file.

  This is the current order of inheritance.

  class L3_NAT_with_dvr_db_mixin(l3_db.L3_NAT_db_mixin,
 l3_attrs_db.ExtraAttributesMixin,
 DVRResourceOperationHandler,
_DVRAgentInterfaceMixin):

  If the order is shuffled, it works fine and here is the shuffled
  order.

  class L3_NAT_with_dvr_db_mixin(DVRResourceOperationHandler,
 _DVRAgentInterfaceMixin,
 l3_attrs_db.ExtraAttributesMixin,
 l3_db.L3_NAT_db_mixin):

  This seems to fix the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1695101/+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 1479962] Re: Use extras for deployment-specific package requirements

2017-06-14 Thread Sean Dague

This devstack bug was last updated over 180 days ago, as devstack
is a fast moving project and we'd like to get the tracker down to
currently actionable bugs, this is getting marked as Invalid. If the
issue still exists, please feel free to reopen it.

** Changed in: devstack
   Status: In Progress => Invalid

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

Title:
  Use extras for deployment-specific package requirements

Status in devstack:
  Invalid
Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  
  Keystone should use "extras" in setup.cfg for deployment-specific package 
requirements.

  One example is ldap.

  With this change, deployers can do something like `pip install
  keystone[ldap]` to install the packages required for ldap.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1479962/+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 1698010] [NEW] dhcp-domain is deprecated, but required for correct FQDN behavior

2017-06-14 Thread Ben Nemec

Public bug reported:

There seems to be an issue with how domains get assigned when booting
instances.  My understanding is that with neutron, the neutron
dns_domain option should be what determines the resulting domain name of
the instances.  However, when creating instances with the following
configuration:

(undercloud) [centos@undercloud-test ~]$ sudo grep dns_domain 
/etc/neutron/neutron.conf 
#dns_domain = openstacklocal
dns_domain=nemebean.com
(undercloud) [centos@undercloud-test ~]$ sudo grep dhcp_domain 
/etc/nova/nova.conf 
#dhcp_domain=novalocal
dhcp_domain=

I get the following in the instance:

[heat-admin@overcloud-controller-0 ~]$ sudo hostnamectl
   Static hostname: overcloud-controller-0.localdomain

It looks like this is being done by cloud-init:

Jun 14 21:07:34 host-9-1-1-12 cloud-init[1405]: [CLOUDINIT] 
cc_set_hostname.py[DEBUG]: Setting the hostname to 
overcloud-controller-0.localdomain (overcloud-controller-0)
Jun 14 21:07:34 host-9-1-1-12 cloud-init[1405]: [CLOUDINIT] util.py[DEBUG]: 
Running command ['hostnamectl', 'set-hostname', 
'overcloud-controller-0.localdomain'] with allowed return codes [0] 
(shell=False, capture=True)

So cloud-init is likely getting the host and domain name from Nova
metadata, even though Neutron is being used to manage networking.

If I also set dhcp_domain as follows:

(undercloud) [centos@undercloud-test ~]$ sudo grep dhcp_domain 
/etc/nova/nova.conf 
#dhcp_domain=novalocal
dhcp_domain=nemebean.com

Then I get the expected results:

[heat-admin@overcloud-controller-0 ~]$ sudo hostnamectl
   Static hostname: overcloud-controller-0.nemebean.com

These are obviously tripleo overcloud instances being deployed via
Ironic.  I'm using some recent RDO packages:

$ sudo rpm -qa | grep nova
openstack-nova-conductor-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
python-nova-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
puppet-nova-11.1.0-0.20170605232112.27baec7.el7.centos.noarch
openstack-nova-common-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
python2-novaclient-8.0.0-0.20170517113627.e1b9e76.el7.centos.noarch
openstack-nova-placement-api-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
openstack-nova-api-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
openstack-nova-scheduler-16.0.0-0.20170521033533.99bd334.el7.centos.noarch
openstack-nova-compute-16.0.0-0.20170521033533.99bd334.el7.centos.noarch

99bd334 is the short sha of the commit the packages were built against

$ sudo rpm -qa | grep neutron
python-neutron-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
openstack-neutron-ml2-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
python2-neutronclient-6.2.0-0.20170418195232.06d3dfd.el7.centos.noarch
openstack-neutron-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
openstack-neutron-openvswitch-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch
puppet-neutron-11.1.0-0.20170601210926.888c480.el7.centos.noarch
python-neutron-lib-1.6.0-0.20170503061451.449f079.el7.centos.noarch
openstack-neutron-common-11.0.0-0.20170521040619.3f2e22a.el7.centos.noarch

This is not ideal in any case, but it's particularly concerning since
according to the opt docs dhcp_domain is deprecated.

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  dhcp-domain is deprecated, but required for correct FQDN behavior

Status in OpenStack Compute (nova):
  New

Bug description:
  There seems to be an issue with how domains get assigned when booting
  instances.  My understanding is that with neutron, the neutron
  dns_domain option should be what determines the resulting domain name
  of the instances.  However, when creating instances with the following
  configuration:

  (undercloud) [centos@undercloud-test ~]$ sudo grep dns_domain 
/etc/neutron/neutron.conf 
  #dns_domain = openstacklocal
  dns_domain=nemebean.com
  (undercloud) [centos@undercloud-test ~]$ sudo grep dhcp_domain 
/etc/nova/nova.conf 
  #dhcp_domain=novalocal
  dhcp_domain=

  I get the following in the instance:

  [heat-admin@overcloud-controller-0 ~]$ sudo hostnamectl
 Static hostname: overcloud-controller-0.localdomain

  It looks like this is being done by cloud-init:

  Jun 14 21:07:34 host-9-1-1-12 cloud-init[1405]: [CLOUDINIT] 
cc_set_hostname.py[DEBUG]: Setting the hostname to 
overcloud-controller-0.localdomain (overcloud-controller-0)
  Jun 14 21:07:34 host-9-1-1-12 cloud-init[1405]: [CLOUDINIT] util.py[DEBUG]: 
Running command ['hostnamectl', 'set-hostname', 
'overcloud-controller-0.localdomain'] with allowed return codes [0] 
(shell=False, capture=True)

  So cloud-init is likely getting the host and domain name from Nova
  metadata, even though Neutron is being used to manage networking.

  If I also set dhcp_domain as follows:

  (undercloud) [centos@undercloud-test ~]$ sudo grep

[Yahoo-eng-team] [Bug 1345947] Re: DHCPNAK after neutron-dhcp-agent restart

2017-06-14 Thread Sean Dague

This grenade bug was last updated over 180 days ago, as grenade
is a fast moving project and we'd like to get the tracker down to
currently actionable bugs, this is getting marked as Invalid. If the
issue still exists, please feel free to reopen it.

** Changed in: grenade
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/1345947

Title:
DHCPNAK after neutron-dhcp-agent restart

Status in grenade:
Invalid
Status in neutron:
Fix Released
Status in neutron icehouse series:
Fix Released
Status in neutron juno series:
Fix Released

Bug description:
After rolling out a configuration change, we restarted neutron-dhcp-agent
service, and then dnsmasq logs start flooding: DHCPNAK ... lease not found.
DHCPNAK is replied by dnsmasq for all DHCPREQUEST renews from all VMs.
However the MAC and IP pairs exist in host files.
The log flooding increases when more and more VMs start renewing and they
keep retrying until IP expire and send DHCPDISCOVER and reinit the IP.
The log flooding gradually disappears when the VMs IP expire and send
DHCPDISCOVER, to which dnsmasq respond DHCPOFFER properly.

Analysis:
I noticed that option --leasefile-ro is used in dnsmasq command when started
by neutron dhcp-agent. According to dnsmasq manual, this option should be used
together with --dhcp-script to customize the lease database. However, the
option --dhcp-script was removed when fixing bug 1202392.
Because of this, dnsmasq will not save lease information in persistent
storage, and when it is restarted, lease information is lost.

Solution:
Simply replace --leasefile-ro by --dhcp-leasefile=/lease would solve the problem. (patch attached)

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

69 matches

Mail list logo