[Yahoo-eng-team] [Bug 1526559] Re: L3 agent parallel configuration of routers might slow things down

2016-01-04 Thread Carl Baldwin
Interesting.  So, having multiple threads doesn't improve the execution
time at all?  That's different than I remember.

One thing that have some number of threads may do is possibly decrease
the latency to process a new request while some threads are working on
other routers.

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

Title:
  L3 agent parallel configuration of routers might slow things down

Status in neutron:
  Invalid

Bug description:
  In the L3 agent's _process_routers_loop method, it spawns a GreenPool
  with 8 eventlet threads. Those threads then take updates off the
  agent's queue and process router updates. Router updates are
  serialized by router_id so that two threads don't process the same
  router at any given time.

  In an environment running on a powerful baremetal server, on agent
  restart it was trying to sync roughly 600 routers. Around half were HA
  routers, and half were legacy routers. With the default GreenPool size
  of 8, the result was that the server ground to a halt as CPU usage
  skyrocketed to over 600%. The main offenders were ip, bash, keepalived
  and Python. This was on an environment without rootwrap daemon based
  off stable/juno. It took around 60 seconds to configure a single
  router. Changing the GreenPool size from 8 to 1, caused the agent to:

  1) Configure a router in 30 seconds, a 50% improvement.
  2) Reduce CPU load from 600% to 70%, freeing the machine to do other things.

  I'm filing this bug so that:

  1) Someone can confirm my personal experience in a more controlled way - For 
example, graph router configuration time and CPU load as a result of GreenPool 
size.
  2) If my findings are confirmed on master with rootwrap daemon, start 
considering alternatives like multiprocessing instead of eventlet 
multithreading, or at the very least optimize the GreenPool size.

  This was on RHEL 7.1:
  kernel-3.10.0-229.11.1.el7, iproute-3.10.0-21.el7

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526559/+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 1528455] Re: can launch an instance with fixed ipv4 address using v6-fixed-ip option

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/260901
Committed: 
https://git.openstack.org/cgit/openstack/python-novaclient/commit/?id=dd6b3cd3941e5af7fa24e0b6d5f45207bdfdd641
Submitter: Jenkins
Branch:master

commit dd6b3cd3941e5af7fa24e0b6d5f45207bdfdd641
Author: Zhihai Song 
Date:   Wed Dec 23 15:11:40 2015 +0800

Validate the fixed ip address passed with --nic

Currently fixed ip address passed with --nic is not validated.
This patch add the validation to the fixed address.

Change-Id: I032cc9ce9333b723d37e94b81d699cc0d78d36bf
Closes-Bug: #1528455


** Changed in: python-novaclient
   Status: In Progress => Fix Released

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

Title:
  can launch an instance with fixed ipv4 address using v6-fixed-ip
  option

Status in OpenStack Compute (nova):
  Won't Fix
Status in python-novaclient:
  Fix Released

Bug description:
  [Summary]
  can launch an instance with fixed ipv4 address using v6-fixed-ip option

  [Topo]
  devstack all-in-one node

  [Description and expect result]
  should return an error if launch an instance with fixed ipv4 address using 
v6-fixed-ip option

  [Reproduceable or not]
  reproduceable 

  [Recreate Steps]
  1) create a subnet :
  root@45-59:/opt/stack/devstack# nova  boot  --flavor 1 --image  
cirros-0.3.4-x86_64-uec  --availability-zone nova --nic 
net-id=1b72073d-e7c0-4bbd-b9f0-f834e5ff1fa7,v6-fixed-ip=1.0.0.100  instance-1
  
+--++
  | Property | Value
  |
  
+--++
  | OS-DCF:diskConfig| MANUAL   
  |
  | OS-EXT-AZ:availability_zone  | nova 
  |
  | OS-EXT-STS:power_state   | 0
  |
  | OS-EXT-STS:task_state| scheduling   
  |
  | OS-EXT-STS:vm_state  | building 
  |
  | OS-SRV-USG:launched_at   | -
  |
  | OS-SRV-USG:terminated_at | -
  |
  | accessIPv4   |  
  |
  | accessIPv6   |  
  |
  | adminPass| i8VQC4fZSsMp 
  |
  | config_drive |  
  |
  | created  | 2015-12-22T14:15:22Z 
  |
  | flavor   | m1.tiny (1)  
  |
  | hostId   |  
  |
  | id   | 03e248ee-821a-4b37-81e0-5692102956fb 
  |
  | image| cirros-0.3.4-x86_64-uec 
(e3e3fd4e-ea26-47d6-b442-76d36ff7d283) |
  | key_name | -
  |
  | metadata | {}   
  |
  | name | instance-1   
  |
  | os-extended-volumes:volumes_attached | []   
  |
  | progress | 0
  |
  | security_groups  | default  
  |
  | status   | BUILD
  |
  | tenant_id| fb3af4173e8e42bca61dca2175ec3774 
  |
  | updated  | 2015-12-22T14:15:23Z 
  |
  | user_id  | e266d2b5fd004f71b6ffadb37cc38813 
  |
  
+--++
  root@45-59:/opt/stack/devstack#

  root@45-59:/opt/stack/devstack# nova list
  

[Yahoo-eng-team] [Bug 1530952] [NEW] libvirt: should only lazy-load flavor from instance in get_disk_mapping if necessary

2016-01-04 Thread Matt Riedemann
Public bug reported:

Debugging a failure I see this several times in the logs:

http://logs.openstack.org/07/263207/1/check/gate-manila-tempest-dsvm-
neutron-no-share-servers-
multibackend/6717bb8/logs/screen-n-cpu.txt.gz#_2016-01-04_11_17_18_679

2016-01-04 11:17:18.679 DEBUG nova.objects.instance [req-
576413dd-8271-4110-995a-e6b828dc3035 nova service] Lazy-loading `flavor'
on Instance uuid b4e9b1a0-77c7-4bde-9413-e14dfe7e3601 obj_load_attr
/opt/stack/new/nova/nova/objects/instance.py:843

This is happening when attaching a volume to the instance and it's
trying to determine the device to use for the mountpoint.

The instance is retrieved in the API and by default it doesn't include
the flavor attribute (which is a join on another table).

This code is lazy-loading the flavor attribute on the instance, which
with remote conductor is a round trip over rpc to conductor to get the
flavor from the database and store it back on the instance:

https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L522

And this is only used if the block_device_info doesn't have any swap
information in it:

https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L579

So we should avoid the round-trip to conductor and not lazy-load the
flavor if we can, which means only getting it if that first condition
fails (no swap info in the block_device_info).

** Affects: nova
 Importance: Low
 Assignee: Matt Riedemann (mriedem)
 Status: Triaged


** Tags: libvirt volumes

** Changed in: nova
   Importance: Undecided => Low

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

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

Title:
  libvirt: should only lazy-load flavor from instance in
  get_disk_mapping if necessary

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  Debugging a failure I see this several times in the logs:

  http://logs.openstack.org/07/263207/1/check/gate-manila-tempest-dsvm-
  neutron-no-share-servers-
  multibackend/6717bb8/logs/screen-n-cpu.txt.gz#_2016-01-04_11_17_18_679

  2016-01-04 11:17:18.679 DEBUG nova.objects.instance [req-
  576413dd-8271-4110-995a-e6b828dc3035 nova service] Lazy-loading
  `flavor' on Instance uuid b4e9b1a0-77c7-4bde-9413-e14dfe7e3601
  obj_load_attr /opt/stack/new/nova/nova/objects/instance.py:843

  This is happening when attaching a volume to the instance and it's
  trying to determine the device to use for the mountpoint.

  The instance is retrieved in the API and by default it doesn't include
  the flavor attribute (which is a join on another table).

  This code is lazy-loading the flavor attribute on the instance, which
  with remote conductor is a round trip over rpc to conductor to get the
  flavor from the database and store it back on the instance:

  
https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L522

  And this is only used if the block_device_info doesn't have any swap
  information in it:

  
https://github.com/openstack/nova/blob/07ba7619f2d13c5ef6fe89252a7349acd84dcd9e/nova/virt/libvirt/blockinfo.py#L579

  So we should avoid the round-trip to conductor and not lazy-load the
  flavor if we can, which means only getting it if that first condition
  fails (no swap info in the block_device_info).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1530952/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/262692
Committed: 
https://git.openstack.org/cgit/openstack/congress/commit/?id=89b6fa066585e1d80a1b5203594f4b696446f62b
Submitter: Jenkins
Branch:master

commit 89b6fa066585e1d80a1b5203594f4b696446f62b
Author: Shuquan Huang 
Date:   Thu Dec 31 15:49:57 2015 +0800

Change assertTrue(isinstance()) by optimal assert

Some of tests use different method of assertTrue(isinstance(A, B)) or
assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
B) provided by testtools.

Change-Id: I17efd64bf4031788f03cf46468b77d7072981620
Closes-bug: #1268480


** Changed in: congress
   Status: In Progress => Fix Released

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

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in CloudRoast:
  New
Status in congress:
  Fix Released
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in OpenStack SDK:
  In Progress
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread OpenStack Infra
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

Reviewed:  https://review.openstack.org/263006
Committed: 
https://git.openstack.org/cgit/openstack/murano-dashboard/commit/?id=b3d5dfd3d92159e9e3f75fa9f6e69f751d87f0be
Submitter: Jenkins
Branch:master

commit b3d5dfd3d92159e9e3f75fa9f6e69f751d87f0be
Author: zhurong 
Date:   Tue Dec 22 07:46:45 2015 +0800

Change  LOG.warn to LOG.warning

Python 3 deprecated the logger.warn method, see:
https://docs.python.org/3/library/logging.html#logging.warning
so we prefer to use warning to avoid DeprecationWarning.

Closes-Bug: #1530742
Change-Id: I9f9f303d7482d0ecc44461bab5ed8f92926436f4


** Changed in: murano
   Status: In Progress => Fix Released

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  Fix Released
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  Fix Released
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tacker:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1290234] Re: do not use __builtin__ in Python3

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/262497
Committed: 
https://git.openstack.org/cgit/openstack/bandit/commit/?id=4498df19d3608e72855c156a050f47ef85aa2d72
Submitter: Jenkins
Branch:master

commit 4498df19d3608e72855c156a050f47ef85aa2d72
Author: Shuquan Huang 
Date:   Wed Dec 30 21:30:16 2015 +0800

use six.moves.builtins in python3

__builtin__ does not exist in Python 3, use
six.moves.builtins instead.

Change-Id: Ib38cc3bd25e1e6a1e6f5e2fcc7abcdba8e339a6e
closes-bug: #1290234


** Changed in: bandit
   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/1290234

Title:
  do not use __builtin__ in Python3

Status in Bandit:
  Fix Released
Status in Glance:
  Fix Released
Status in heat:
  Triaged
Status in Ironic:
  Fix Released
Status in OpenStack Identity (keystone):
  In Progress
Status in Magnum:
  Fix Released
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in octavia:
  In Progress
Status in Trove:
  In Progress
Status in tuskar:
  Fix Released

Bug description:
  __builtin__ does not exist in Python 3, use six.moves.builtins
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bandit/+bug/1290234/+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 1519493] Re: oslo_i18n cleanup needed

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/250992
Committed: 
https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=787ba9250b3dbdd9c0c1b8ee2a4211ba124ee479
Submitter: Jenkins
Branch:master

commit 787ba9250b3dbdd9c0c1b8ee2a4211ba124ee479
Author: Akihiro Motoki 
Date:   Sat Nov 28 09:16:42 2015 +0900

Use _i18n instead of i18n

It is suggested to use _i18n.py per oslo.i18n document.
http://docs.openstack.org/developer/oslo.i18n/usage.html

neutronclient.i18n is now a wrapper module which emits
the derecation warning. It is because might be used in
implementation of the client extensions in other repositories.

Closes-Bug: #1519493
Change-Id: I44969daeedc9a66dd9ad5bf80617516faf245ecc


** Changed in: python-neutronclient
   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/1519493

Title:
  oslo_i18n cleanup needed

Status in neutron:
  In Progress
Status in python-neutronclient:
  Fix Released

Bug description:
  As per the oslo_i18n documentation, neutron/i18n.py should be an
  internal only module, named _i18n.py. Stuff needed:

  - Rename file.
  - Add i18n.py with debtcollector references, warning that each repo needs its 
own, and to stop using.
  - Begin migrating subprojects away from shared module.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1519493/+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 1515506] Re: There is no facility to name LBaaS v2 Members and Health Monitors

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/246077
Committed: 
https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=b77985562983e41a2260f21169d8a6275a8c7dc5
Submitter: Jenkins
Branch:master

commit b77985562983e41a2260f21169d8a6275a8c7dc5
Author: Reedip Banerjee 
Date:   Tue Nov 17 07:11:22 2015 +0530

Support for Name field in Members and HMs

This patch adds support to enable naming LBaasV2 Members and Health
Monitors(HMs) in python-neutronclient.

Closes-Bug: #1515506
Change-Id: I27ac48953bb09841234fce6d852f062e2030284e


** Changed in: python-neutronclient
   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/1515506

Title:
  There is no facility to name LBaaS v2 Members and Health Monitors

Status in neutron:
  Fix Released
Status in python-neutronclient:
  Fix Released

Bug description:
  High Level Requirement: 
  Currently there is no facility to name LBaaS v2 Members and Health Monitors.
  Although optional, having  the NAME field allows the users to remember 
specific objects( in this case Health Monitors and Members) , so that any task 
related to these objects can be done easily , instead of retrieving the IDs of 
these objects everytime.

  The following issue is raised to allow a new parameter 'name' to be
  added to LBaaS Tables Health Monitors and Members, just like other
  LBaaS tables ( listener, loadbalancer, pool) have.

  Pre-Conditions:
  LBaaS v2 is enabled in the system.

  Version: 
  Git ID :321da8f6263d46bf059163bcf7fd005cf68601bd

  Environment:
  Ubuntu 14.04, with Devstack All In One, FWaaS , LBaaSv2 and Octavia enabled.

  Perceived Severity: Medium

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1515506/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread OpenStack Infra
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

Reviewed:  https://review.openstack.org/263008
Committed: 
https://git.openstack.org/cgit/openstack/python-muranoclient/commit/?id=d07c76b0ea83f9764f7eff75a818f728880e13ab
Submitter: Jenkins
Branch:master

commit d07c76b0ea83f9764f7eff75a818f728880e13ab
Author: zhurong 
Date:   Tue Dec 22 07:52:53 2015 +0800

Change LOG.warn to LOG.warning

Python 3 deprecated the logger.warn method, see:
https://docs.python.org/3/library/logging.html#logging.warning
so we prefer to use warning to avoid DeprecationWarning.

Closes-Bug: #1530742
Change-Id: Ifb5fba442ccaaf065f0959b2a19b625d07ab0c47


** Changed in: python-muranoclient
   Status: In Progress => Fix Released

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  Fix Released
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tacker:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1528420] Re: netowrk information missed in dashboard network column

2016-01-04 Thread linwei,wu
check again, after clear cache, it seems that we can't reproduce it

** Changed in: horizon
   Status: Incomplete => Invalid

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

Title:
  netowrk information missed in dashboard network column

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:

  setup inforamtion:
  devstack

  
  reproduce:
  yes

  
  steps:
  1.install one devstack.
  source accrc/admin/admin 

  2.check devstack default netowrk inforamtion by using command. we have two 
network.
  stack@45-59:~/devstack$ neutron net-list
  
+--+-+--+
  | id   | name| subnets
  |
  
+--+-+--+
  | b9cedb82-6835-499b-885d-7646416ac93f | public  | 
146a2d03-52e0-4c7d-ba77-a9a2df99da7f 2001:db8::/64   |
  |  | | 
aea6ea63-b70c-49fe-9bf5-3f593015a07d 172.24.4.0/24   |
  | 1931775c-4459-4c18-9910-53b1ffbe4d31 | private | 
9b1a99a3-e7ae-4a7d-b9d2-e035077d4e5e 10.0.0.0/24 |
  |  | | 
3ebaa37a-2b80-4186-9357-dd8b1202d542 fd7e:7e2b:56d0::/64 |
  
+--+-+--+

  
  3.we can create instance with these network by using command.

  
  4.check devstack dashboard gui. I find that we can't display private network. 
only public network is listed on the network column. but in admin column, we 
can see networks are all there.
 when try to launch a instance, we only can see  network named public 
listed to be chosen for instance.

  
  5.create a new private network by using command. we can see the created 
network linwwu. 
  (neutron) net-create --prefix 192.168.1.0/24 linwwu
  Created a new network:
  +---+--+
  | Field | Value|
  +---+--+
  | admin_state_up| True |
  | availability_zone_hints   | []   |
  | id| 000505b3-5498-4a9f-b269-5d165192474b |
  | mtu   | 0|
  | name  | linwwu   |
  | port_security_enabled | True |
  | provider:network_type | vxlan|
  | provider:physical_network |  |
  | provider:segmentation_id  | 1023 |
  | router:external   | False|
  | shared| False|
  | status| ACTIVE   |
  | subnets   |  |
  | tenant_id | 4d2c7b5c5e2d4d7584ec5dac8e49343d |
  +---+--+

  
  summary:
  we can't see default network named privated in dashboard gui, which should be 
displayed in network column. and when creating instance, we also can't see and 
choose the default private network.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1528420/+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 1526199] Re: volumes have no attribute tenant_name gives error

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/257734
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=3013b48f32eb67f5eb00ef5a55bb557da6868ea9
Submitter: Jenkins
Branch:master

commit 3013b48f32eb67f5eb00ef5a55bb557da6868ea9
Author: zhu.rong 
Date:   Tue Dec 15 16:40:08 2015 +0800

Fix volumes no attribute tenant_name error

Fix the volumes have no attribute tenant_name error,
when the volumes are in the creating/deleting/attaching status.

Closes-Bug: #1526199

Change-Id: I0085969bb8981e4ab50e4e45dbcddda19b95b6b7


** Changed in: horizon
   Status: In Progress => Fix Released

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

Title:
  volumes have no attribute tenant_name gives error

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Volumes have no attribute tenant_name, gives the error like:
  The attribute tenant_name doesn't exist on .

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1526199/+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 1530830] [NEW] Instance Console Crashes : Unable to enter credentials at Instance Console

2016-01-04 Thread Dibeyndu
Public bug reported:

Proof of Concept

After I spawn an instance I  click on the instance . Then I will click
the console tab . The  Instance Console loads and I get a shell prompt
asking for login/password .

After I enter few keystrokes it doesn't print anything in the login
prompt . After pressing some more keys constantly , it start showing
syslog messages and doesnt show the login prompt anymore

Please check the attachment

I am using chrome as a browser . This issue is also there when I tested
from firefox . Check the image attached

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: console horizon instance

** Attachment added: "instance_console_bug.PNG"
   
https://bugs.launchpad.net/bugs/1530830/+attachment/4543789/+files/instance_console_bug.PNG

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

Title:
  Instance Console Crashes : Unable to enter credentials at Instance
  Console

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Proof of Concept

  After I spawn an instance I  click on the instance . Then I will click
  the console tab . The  Instance Console loads and I get a shell prompt
  asking for login/password .

  After I enter few keystrokes it doesn't print anything in the login
  prompt . After pressing some more keys constantly , it start showing
  syslog messages and doesnt show the login prompt anymore

  Please check the attachment

  I am using chrome as a browser . This issue is also there when I
  tested from firefox . Check the image attached

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1530830/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread lei zhang
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

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

** Changed in: glance
 Assignee: (unassigned) => lei zhang (zhang-lei)

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

Title:
  Change LOG.warn to LOG.warning

Status in Evoque:
  In Progress
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/evoque/+bug/1530742/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread OpenStack Infra
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

Reviewed:  https://review.openstack.org/263105
Committed: 
https://git.openstack.org/cgit/openstack/evoque/commit/?id=8ca7ece349e6227dcde1a9fa3344500c4142d738
Submitter: Jenkins
Branch:master

commit 8ca7ece349e6227dcde1a9fa3344500c4142d738
Author: zhangguoqing 
Date:   Mon Jan 4 04:09:49 2016 +

Change LOG.warn to LOG.warning

Python 3 deprecated the logger.warn method, see:
https://docs.python.org/3/library/logging.html#logging.warning
so we prefer to use warning to avoid DeprecationWarning.

Change-Id: Ib88d6b3b5583c564ad2b43dab4a54da870753547
Closes-Bug: #1530742


** Changed in: evoque
   Status: In Progress => Fix Released

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

Title:
  Change LOG.warn to LOG.warning

Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/evoque/+bug/1530742/+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 1443421] Re: After VM migration, tunnels not getting removed with L2Pop ON, when using multiple api_workers in controller

2016-01-04 Thread venkata anil
I tried with one controller( and api workers =10) and two compute nodes,
with l2pop on all the three nodes.

With both "nova migrate" and "nova live-migration", I see l2pop working
properly(i.e tunnels are removed from old host after migration).

Note: "nova migrate" is a two step process.  So, only after "nova 
resize-confirm", l2pop is deleting tunnels from previous host.
http://osdir.com/ml/openstack-cloud-computing/2013-01/msg00522.html
  

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

Title:
  After VM migration, tunnels not getting removed with L2Pop ON, when
  using multiple api_workers in controller

Status in neutron:
  Invalid
Status in openstack-ansible:
  Confirmed
Status in openstack-ansible liberty series:
  Confirmed
Status in openstack-ansible trunk series:
  Confirmed

Bug description:

  Setup : Neutron server  HA (3 nodes).
  Hypervisor – ESX with OVsvapp
  l2 POP is on Network node and off on Ovsvapp.

  Condition:
  Make L2 pop on OVs agent, api workers =10 in the controller. 

  On network node,the VXLAN tunnel is created with ESX2 and the Tunnel
  with ESX1 is not removed after migrating VM from ESX1 to ESX2.

  Attaching the logs of servers and agent logs.

  stack@OSC-NS1:/opt/stack/logs/screen$ sudo ovs-vsctl show
  662d03fb-c784-498e-927c-410aa6788455
  Bridge br-ex
  Port phy-br-ex
  Interface phy-br-ex
  type: patch
  options: {peer=int-br-ex}
  Port "eth2"
  Interface "eth2"
  Port br-ex
  Interface br-ex
  type: internal
  Bridge br-tun
  Port patch-int
  Interface patch-int
  type: patch
  options: {peer=patch-tun}
  Port "vxlan-6447007a"
  Interface "vxlan-6447007a"
  type: vxlan
  options: {df_default="true", in_key=flow, 
local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.122"} 
This should have been deleted after MIGRATION.
  Port "vxlan-64470082"
  Interface "vxlan-64470082"
  type: vxlan
  options: {df_default="true", in_key=flow, 
local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.130"}
  Port br-tun
  Interface br-tun
  type: internal
  Port "vxlan-6447002a"
  Interface "vxlan-6447002a"
  type: vxlan
  options: {df_default="true", in_key=flow, 
local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.42"}
  Bridge "br-eth1"
  Port "br-eth1"
  Interface "br-eth1"
  type: internal
  Port "phy-br-eth1"
  Interface "phy-br-eth1"
  type: patch
  options: {peer="int-br-eth1"}
  Bridge br-int
  fail_mode: secure
  Port patch-tun
  Interface patch-tun
  type: patch
  options: {peer=patch-int}
  Port "int-br-eth1"
  Interface "int-br-eth1"
  type: patch
  options: {peer="phy-br-eth1"}
  Port br-int
  Interface br-int
  type: internal
  Port int-br-ex
  Interface int-br-ex
  type: patch
  options: {peer=phy-br-ex}
  Port "tap9515e5b3-ec"
  tag: 11
  Interface "tap9515e5b3-ec"
  type: internal
  ovs_version: "2.0.2"

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1443421/+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 1500337] Re: Rollback of live-migration fails in the case of cinder with the NFS driver

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/228351
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=f00f3bee239836b095e2c99c363586f17dae9b72
Submitter: Jenkins
Branch:master

commit f00f3bee239836b095e2c99c363586f17dae9b72
Author: Hiroyuki Eguchi 
Date:   Mon Sep 28 17:24:01 2015 +0900

Rollback of live-migration fails with the NFS driver

This error occurs when fail to live migrate before
destination host attach to the NFS server.
We should consider whether destination host has mounted to
NFS server or not when executing rollback of live-migration.

Closes-Bug: #1500337
Change-Id: Id6d0bfead0557e1dfe4aeee56a7d85adaf38549a


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  Rollback of live-migration fails in the case of cinder with the NFS
  driver

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  This error occurs under the following situations.

  - cinder is using the NFS driver.
  - cinder volume is attached to the instance.
  - fail to live migrate before destination host attach to the NFS server

  We should consider whether destination host has mounted to NFS server
  or not when executing rollback of live-migration.

  

  ProcessExecutionError: Unexpected error while running command.
  Command: sudo nova-rootwrap /etc/nova/rootwrap.conf umount 
/var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b
  Exit code: 32
  Stdout: u''
  Stderr: u'umount: /var/lib/nova/mnt/b5e2fcf5ad9470489747f7caa242747b: not 
mounted\n'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1500337/+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 1489059] Re: "db type could not be determined" running py34

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/262876
Committed: 
https://git.openstack.org/cgit/openstack/rally/commit/?id=e1d332bd5393c9c30aedeafa0073dca99feab322
Submitter: Jenkins
Branch:master

commit e1d332bd5393c9c30aedeafa0073dca99feab322
Author: LiuNanke 
Date:   Sat Jan 2 02:07:39 2016 +0800

Put py34 first in the env order of tox

To solve the problem of "db type could not be determined" on
py34 we have to run first the py34 env to, then, run py27.
This patch puts py34 first on the tox.ini list of envs to
avoid this problem to happen.

Change-Id: I7b8f5c27c1d1768f38869cf8c07792b9defb4186
Closes-bug: #1489059


** Changed in: rally
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  Fix Released
Status in Barbican:
  Fix Released
Status in cloudkitty:
  Fix Committed
Status in Glance:
  Fix Committed
Status in glance_store:
  Fix Committed
Status in hacking:
  Fix Released
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Committed
Status in Manila:
  Fix Released
Status in Murano:
  Fix Committed
Status in networking-midonet:
  Fix Released
Status in networking-ofagent:
  New
Status in neutron:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Committed
Status in python-muranoclient:
  Fix Released
Status in python-solumclient:
  In Progress
Status in Rally:
  Fix Released
Status in Sahara:
  Fix Released
Status in senlin:
  Fix Released
Status in tap-as-a-service:
  New
Status in tempest:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1528468] Re: can create a security group rule with icmp option while ipv6 ether type is set

2016-01-04 Thread ibm-cloud-qa
** 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/1528468

Title:
  can create a security group rule with icmp option while ipv6 ether
  type is set

Status in neutron:
  Invalid

Bug description:
  [Summary]
  can create a security group rule with icmp option while ipv6 ether type is set

  [Topo]
  devstack all-in-one

  [Description and expect result]
  should return an error if create a security group rule with icmp option
   while ipv6 ether type is set

  [Reproduceable or not]
  reproduceable 

  [Recreate Steps]
  1) create a security group rule as below:
  root@45-59:/opt/stack/devstack# neutron security-group-rule-create 
  --protocol icmp --ethertype ipv6 sg1
  Created a new security_group_rule:
  +---+--+
  | Field | Value|
  +---+--+
  | direction | ingress  |
  | ethertype | IPv6 |
  | id| 303c6aa8-0937-4ed9-89d5-2733febe72a0 |
  | port_range_max|  |
  | port_range_min|  |
  | protocol  | icmp |
  | remote_group_id   |  |
  | remote_ip_prefix  |  |
  | security_group_id | 4fd891e1-4de0-42aa-8fcd-3fd34a978d0e |
  | tenant_id | fb3af4173e8e42bca61dca2175ec3774 |
  +---+--+

  2)for reference, when create a security group rule with icmpv6 option 
  while ipv4 ether type is set, an error message returned:
  root@45-59:/opt/stack/devstack# neutron security-group-rule-create 
  --protocol icmpv6 --ethertype ipv4 sg1
  Invalid ethertype IPv4 for protocol icmpv6.
  root@45-59:/opt/stack/devstack# 

  [Configration]
  reproduceable bug, no need

  [logs]
  reproduceable bug, no need

  [Root cause anlyze or debug inf]
  reproduceable bug

  [Attachment]
  None

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1528468/+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 1531013] [NEW] Duplicate entries in FDB table

2016-01-04 Thread James Denton
Public bug reported:

Posting here, because I'm not sure of a better place at the moment.

Environment: Juno
OS: Ubuntu 14.04 LTS
Plugin: ML2/LinuxBridge

root@infra01_neutron_agents_container-4c850328:~# bridge -V
bridge utility, 0.0
root@infra01_neutron_agents_container-4c850328:~# ip -V
ip utility, iproute2-ss131122
root@infra01_neutron_agents_container-4c850328:~# uname -a
Linux infra01_neutron_agents_container-4c850328 3.13.0-46-generic #79-Ubuntu 
SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

We recently discovered that across the environment (5 controller, 50+
compute) there are (tens of) thousands of duplicate entries in the FDB
table, but only for the 00:00:00:00:00:00 broadcast entries. This is in
an environment of ~1600 instances, ~4,100 ports, and 80 networks.

In this example, the number of duplicate FDB entries for this particular
VTEP jumps wildly:

root@infra01_neutron_agents_container-4c850328:~# bridge fdb show | grep 
"00:00:00:00:00:00 dev vxlan-10 dst 172.29.243.157" | wc -l
1429
root@infra01_neutron_agents_container-4c850328:~# bridge fdb show | grep 
"00:00:00:00:00:00 dev vxlan-10 dst 172.29.243.157" | wc -l
81057
root@infra01_neutron_agents_container-4c850328:~# bridge fdb show | grep 
"00:00:00:00:00:00 dev vxlan-10 dst 172.29.243.157" | wc -l
25806
root@infra01_neutron_agents_container-4c850328:~# bridge fdb show | grep 
"00:00:00:00:00:00 dev vxlan-10 dst 172.29.243.157" | wc -l
473141
root@infra01_neutron_agents_container-4c850328:~# bridge fdb show | grep 
"00:00:00:00:00:00 dev vxlan-10 dst 172.29.243.157" | wc -l
225472

That behavior can be observed for all other VTEPs. We're seeing over 13
million total FDB entries on this node:

root@infra01_neutron_agents_container-4c850328:~# bridge fdb show >> 
james_fdb2.txt
root@infra01_neutron_agents_container-4c850328:~# cat james_fdb2.txt | wc -l
13554258

We're also seeing the wild counts on compute nodes. These were run
within 1 second of the previous completion:

root@compute032:~# bridge fdb show | wc -l
898981
root@compute032:~# bridge fdb show | wc -l
734916
root@compute032:~# bridge fdb show | wc -l
1483081
root@compute032:~# bridge fdb show | wc -l
508811
root@compute032:~# bridge fdb show | wc -l
2349221

On this node, you can see over 28,000 duplicates for each of the
entries:

root@compute032:~# bridge fdb show | sort | uniq -c | sort -nr
  28871 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.39 self permanent
  28871 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.38 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.243.252 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.243.157 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.243.133 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.242.66 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.242.193 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.60 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.59 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.58 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.57 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.55 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.54 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.53 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.51 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.50 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.49 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.48 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.47 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.46 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.45 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.44 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.43 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.42 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.40 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.37 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.36 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.35 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.34 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.33 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.32 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.31 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.30 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.29 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.28 self permanent
  28870 00:00:00:00:00:00 dev vxlan-15 dst 172.29.240.27 self permanent
  28870 

[Yahoo-eng-team] [Bug 1531011] [NEW] When firewall rule is inserted/deleted from a policy, notifications are not generated

2016-01-04 Thread padkrish
Public bug reported:

For Firewall, Rabbitmq Notifications are generated for the following:
When a Firewall is created/deleted
when a rule is created/deleted/modified
When a policy is created/deleted.

But, after a policy is created, when rules are inserted or removed from
a policy, no notifications are generated. The following is the screen
shot when a firewall is deleted, captured using rabbitmqadmin (an
example to indicate what notifications is referred here). This issue is
found in both Kilo and Juno.

|  routing_key  | exchange | message_count |





  payload   





  
 | payload_bytes | payload_encoding | 
redelivered |
+---+--+---+--
 
--+---+--+-+
| Test_neutron_notify.info | neutron  | 1 | {"_context_roles": 
["_member_", "admin"], "_context_request_id": 
"req-4170bbcc-b467-4686-a97f-38324fc54bc5", "event_type": 
"firewall.delete.start", "timestamp": "2016-01-04 22:28:27.885535", 
"_context_tenant_id": "2028fe85b5ef4cffa1a9a88a39a37787", "_context_user": 
"22fab1c0e5534e1099a42fb85286c922", "_unique_id": 
"93de171182df4b00a77be4e1b9ea02da", "_context_tenant_name": "KLPROJ", 
"_context_user_id": "22fab1c0e5534e1099a42fb85286c922", "payload": 
{"firewall_id": "ddce3c3c-5a5c-48e1-8d44-612b21c96033"}, 
"_context_project_name": "KLPROJ", "_context_read_deleted": "no", 
"_context_auth_token": "b1166ae3cbb4419ca9983c3cf8895ed0", "_context_tenant": 
"2028fe85b5ef4cffa1a9a88a39a37787", "priority": "INFO", "_context_is_admin": 
true, "_context_project_id": "2028fe85b5ef4cffa1a9a88a39a37787", 
"_context_timestamp": "2016-01-04 22:28:27.882236", "_context_user_name": 
"kilo", "publisher_id": "network.paddu-krish-133", "message_id": "4a3918
 57-a18e-4188-83a4-17407b4ca8bb"} | 974   | string   | False
   |

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas logging neutron

** Description changed:

  For Firewall, Rabbitmq Notifications are generated for the following:
  When a Firewall is created/deleted
  when a rule is created/deleted/modified
  When a policy is created/deleted.
  
  But, after a policy is created, when rules are inserted or removed from
  a policy, no notifications are generated. The following is the screen
- shot when a firewall is deleted, captured using rabbitmqadmin. This
- issue is found in both Kilo and Juno.
+ shot when a firewall is deleted, captured using rabbitmqadmin (an
+ example to indicate what notifications is referred here). This issue is
+ found in both Kilo and Juno.
  
  |  routing_key  | exchange | message_count |  




   

[Yahoo-eng-team] [Bug 1531022] [NEW] libvirt driver doesn't cleanup the tap interface on vm re-schedule

2016-01-04 Thread pritesh
Public bug reported:

Here when you use libvirt driver with tap interfaces, it creates a tap
interface on the host but doesn't clean up the interface and leaves in-
tact and creates another same named interface on the new host.

In _do_build_and_run_instance when RescheduledException is called,
manager checks if the network port needs to be de-allocated for a
different host or not using  deallocate_networks_on_reschedule() which
is hard coded to return False. If this is changed to return true or set
via conf file configuration to allow being changed for specific mech
drivers in neutron then it would be helpful to not only clean up the tap
interface properly but also also mech drivers in neutron to re-create
new ports on new host instead of shifting and re-using same ports which
fails.

tested on master and stable/liberty and fails in both cases, so may need
back porting.

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

Title:
  libvirt driver doesn't cleanup the tap interface on vm re-schedule

Status in OpenStack Compute (nova):
  New

Bug description:
  Here when you use libvirt driver with tap interfaces, it creates a tap
  interface on the host but doesn't clean up the interface and leaves
  in-tact and creates another same named interface on the new host.

  In _do_build_and_run_instance when RescheduledException is called,
  manager checks if the network port needs to be de-allocated for a
  different host or not using  deallocate_networks_on_reschedule() which
  is hard coded to return False. If this is changed to return true or
  set via conf file configuration to allow being changed for specific
  mech drivers in neutron then it would be helpful to not only clean up
  the tap interface properly but also also mech drivers in neutron to
  re-create new ports on new host instead of shifting and re-using same
  ports which fails.

  tested on master and stable/liberty and fails in both cases, so may
  need back porting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1531022/+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 1495876] Re: nova.conf - configuration options in OpenStack Configuration Reference  - kilo

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/224500
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=b3c69ef6d7028962bbde83b7597886d011dbd5af
Submitter: Jenkins
Branch:master

commit b3c69ef6d7028962bbde83b7597886d011dbd5af
Author: Shuquan Huang 
Date:   Thu Sep 17 17:03:19 2015 +0800

Fix nova configuration options description

iscsi_use_multipath = False(BoolOpt) Use multipath connection of the
iSCSI volume
Above description is incorrect and misleading. Actually, this option
is applicable for both FC/iSCSI volumes

Change-Id: Ifdc6a2935702311eb8af363c742b5ab44c7a0d0f
DocImpact: Change the config description of iscsi_use_multipath
Closes-bug: #1495876


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  nova.conf - configuration options in OpenStack Configuration Reference
  - kilo

Status in OpenStack Compute (nova):
  Fix Released
Status in openstack-manuals:
  Invalid

Bug description:
  
  ---
  Built: 2015-08-27T08:45:20 00:00
  git SHA: f062eb42bbc512386ac572b5b830fb4e21c72a41
  URL: 
http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html
  source File: 
file:/home/jenkins/workspace/openstack-manuals-tox-doc-publishdocs/doc/config-reference/compute/section_compute-options-reference.xml
  xml:id: list-of-compute-config-options

  
  iscsi_use_multipath = False   (BoolOpt) Use multipath connection of the iSCSI 
volume

  
  above description is incorrect and very misleading

  actually, this option is applicable for both FC/iSCSI volumes

  
  Thanks
  Peter

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1495876/+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 1507424] Re: Hypervisor type of xen should be XenServer

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/237374
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=6a95ed1057e7bff9d347a95f32e1d3040a2dfe1f
Submitter: Jenkins
Branch:master

commit 6a95ed1057e7bff9d347a95f32e1d3040a2dfe1f
Author: John Hua 
Date:   Tue Oct 20 10:42:04 2015 +0800

XenAPI: Correct hypervisor type in Horizon's admin view

Currently hypervisor_type of xen shown in nova api is 'xen', while
'XenServer' could be more accurate.

Change-Id: Ia406e6762312367c0a12db491623766951d49dc6
Closes-Bug: #1507424
UpgradeImpact: hypervisor_type renamed in Nova API


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  Hypervisor type of xen should be XenServer

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Type is listed as "xen" in Horizon's Admin->Hypervisors view.
  It should be XenServer.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1507424/+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 1525002] Re: The ironic driver needs to scale back how many errors it traces out

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/256615
Committed: 
https://git.openstack.org/cgit/openstack/ironic/commit/?id=bd60603e443ec79b0783bebe2cda48a6b9c89ced
Submitter: Jenkins
Branch:master

commit bd60603e443ec79b0783bebe2cda48a6b9c89ced
Author: Jim Rollenhagen 
Date:   Fri Dec 11 10:03:09 2015 -0800

Don't return tracebacks in API response in debug mode

The API should not return tracebacks in a production environment. As
deployers often run services in debug mode, because OpenStack is hard to
debug, we should not return tracebacks in debug mode. To allow
developers etc to continue to use this feature, add a new config option
'debug_tracebacks_in_api' that maintains this behavior.

Also add to troubleshooting docs.

Change-Id: Idbbf7efc45140e9e3d8b9491edd58905cbba0363
Closes-Bug: #1525002


** Changed in: ironic
   Status: In Progress => Fix Released

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

Title:
  The ironic driver needs to scale back how many errors it traces out

Status in Ironic:
  Fix Released
Status in OpenStack Compute (nova):
  Confirmed
Status in python-ironicclient:
  Fix Released

Bug description:
  The amount of tracing in this n-cpu log is a bit much:

  http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-
  agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE

  Like these warnings:

  http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-
  
agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-12-10_16_11_48_799

  2015-12-10 16:11:48.798 WARNING ironicclient.common.http 
[req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 
tempest-BaremetalBasicOps-1966762451] Request returned failure status.
  2015-12-10 16:11:48.799 WARNING ironicclient.common.http 
[req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 
tempest-BaremetalBasicOps-1966762451] Error contacting Ironic server: Node 1 is 
locked by host localhost, please retry after the current operation is completed.
  Traceback (most recent call last):

    File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", 
line 150, in inner
  return func(*args, **kwargs)

    File "/opt/stack/new/ironic/ironic/conductor/manager.py", line 1519, in 
update_port
  purpose='port update') as task:

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 152, in 
acquire
  driver_name=driver_name, purpose=purpose)

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 222, in 
__init__
  self.release_resources()

    File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
204, in __exit__
  six.reraise(self.type_, self.value, self.tb)

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 203, in 
__init__
  self._lock()

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 243, in 
_lock
  reserve_node()

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 49, in 
wrapped_f
  return Retrying(*dargs, **dkw).call(f, *args, **kw)

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 212, in call
  raise attempt.get()

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 247, in get
  six.reraise(self.value[0], self.value[1], self.value[2])

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 200, in call
  attempt = Attempt(fn(*args, **kwargs), attempt_number, False)

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 236, in 
reserve_node
  self.node_id)

    File "/opt/stack/new/ironic/ironic/objects/node.py", line 260, in reserve
  db_node = cls.dbapi.reserve_node(tag, node_id)

    File "/opt/stack/new/ironic/ironic/db/sqlalchemy/api.py", line 226, in 
reserve_node
  host=node['reservation'])

  NodeLocked: Node 1 is locked by host localhost, please retry after the 
current operation is completed.
   (HTTP 409). Attempt 1 of 61

  UPD from dtantsur:
  The traceback has nothing to do with ironic client or driver. It gets added 
somewhere between ironic conductor and API levels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1525002/+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 1531036] [NEW] Ip table rules for IP/MAC spoofing added when DHCP is disabled

2016-01-04 Thread Liam Haworth
Public bug reported:

When a network is created that has DHCP disabled Neutron still creates
IP/MAC spoof rules to stop the wrong IP being used from a MAC address,
the problem with this is that if DHCP is provided by an external source
on the network that's not Neutron the wrong IP is added to the firewall
and prevents the instance for being able to communicate.


Example:

Instance "net-test" is attached to two networks, Public & QA, Public
provides DHCP to the instance via Neutron whilst QA network provides
DHCP from Windows Server 2012 attached to the same VLAN.

Neutron expects the instance to get 198.18.0.2 for its Public network
interface and 198.18.64.1 for its QA network interface so it adds the
following rules to IPTables:

Chain neutron-linuxbri--x (1 references)
 pkts   bytes target   prot opt in out 
source destination
0   0 RETURN all   -- * 
 * 192.168.64.1 0.0.0.0/0 MAC FA:16:3E:DF:19:1A
0   0DROP  all   --  *  
* 0.0.0.0/00.0.0.0/0

Chain neutron-linuxbri--x (1 references)
 pkts   bytes target   prot opt in out 
source destination
0   0 RETURN all   -- * 
 * 198.18.0.2  0.0.0.0/0 MAC FA:16:3E:45:B9:04
0   0 DROP  all   --  * 
 * 0.0.0.0/00.0.0.0/0

If the Windows 2k12 server returns anything other than 192.168.64.1 to
the instance for DHCP on the QA network the instance can no longer
communicate on the QA network.


How to reproduce:

1. Create VLAN network and subnet with gateway and DHCP disabled.
2. Setup external DHCP service separate from OpenStack on the same VLAN
3. Launch instance on OpenStack attached to the VLAN network


Versions:
  Neutron: 2:7.0.0-0ubuntu1~cloud0
  Distro: Ubuntu 14.04.3 LTS


Perceived severity: Show stopper - We are unable to use the infrastructure as 
required due to this bug and the only option right now is to disable neutron 
firewall drivers till the issue is resolved.

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

Title:
  Ip table rules for IP/MAC spoofing added when DHCP is disabled

Status in neutron:
  New

Bug description:
  When a network is created that has DHCP disabled Neutron still creates
  IP/MAC spoof rules to stop the wrong IP being used from a MAC address,
  the problem with this is that if DHCP is provided by an external
  source on the network that's not Neutron the wrong IP is added to the
  firewall and prevents the instance for being able to communicate.


  Example:

  Instance "net-test" is attached to two networks, Public & QA, Public
  provides DHCP to the instance via Neutron whilst QA network provides
  DHCP from Windows Server 2012 attached to the same VLAN.

  Neutron expects the instance to get 198.18.0.2 for its Public network
  interface and 198.18.64.1 for its QA network interface so it adds the
  following rules to IPTables:

  Chain neutron-linuxbri--x (1 references)
   pkts   bytes target   prot opt in out
 source destination
  0   0 RETURN all   -- *   
   * 192.168.64.1 0.0.0.0/0 MAC FA:16:3E:DF:19:1A
  0   0DROP  all   --  
*  * 0.0.0.0/00.0.0.0/0

  Chain neutron-linuxbri--x (1 references)
   pkts   bytes target   prot opt in out
 source destination
  0   0 RETURN all   -- *   
   * 198.18.0.2  0.0.0.0/0 MAC FA:16:3E:45:B9:04
  0   0 DROP  all   --  
*  * 0.0.0.0/00.0.0.0/0

  If the Windows 2k12 server returns anything other than 192.168.64.1 to
  the instance for DHCP on the QA network the instance can no longer
  communicate on the QA network.


  How to reproduce:

  1. Create VLAN network and subnet with gateway and DHCP disabled.
  2. Setup external DHCP service separate from OpenStack on the same VLAN
  3. Launch instance on OpenStack attached to the VLAN network


  Versions:
Neutron: 2:7.0.0-0ubuntu1~cloud0
Distro: Ubuntu 14.04.3 LTS

  
  Perceived severity: Show stopper - We are unable to use the infrastructure as 
required due to this bug and the only option right now is to disable 

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

2016-01-04 Thread Kan
** Also affects: python-ironicclient
   Importance: Undecided
   Status: New

** Changed in: python-ironicclient
 Assignee: (unassigned) => Kan (kansks)

** Changed in: python-ironicclient
   Status: New => In Progress

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

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in CloudRoast:
  New
Status in congress:
  Fix Released
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-ironicclient:
  In Progress
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in OpenStack SDK:
  In Progress
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Goutham Pacha Ravi
** Also affects: manila
   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/1508442

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  New
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1513000] Re: neutron q-lbaas cannot start - ValueError: Empty module name

2016-01-04 Thread Launchpad Bug Tracker
[Expired for neutron because there has been no activity for 60 days.]

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

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

Title:
  neutron q-lbaas cannot start - ValueError: Empty module name

Status in neutron:
  Expired

Bug description:
  When trying to start neutron q-lbaas on ubuntu devstack we receive
  this error and was unable to track it to source:

  ubuntu@nov-dvs-241480-1:~/devstack$ /usr/local/bin/neutron-lbaas-agent 
--config- 
  file /etc/neutron/neutron.conf 
--config-file=/etc/neutron/services/loadbalancer/ 
  haproxy/lbaas_agent.ini & echo $! >/opt/stack/status/stack/q-lbaas.pid; fg || 
ec 
  ho "q-lbaas failed to start" | tee "/opt/stack/status/stack/q-lbaas.failure"
  [1] 6390
  /usr/local/bin/neutron-lbaas-agent --config-file /etc/neutron/neutron.conf 
--config-file=/etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini
  No handlers could be found for logger "oslo_config.cfg"
  2015-11-04 07:53:37.026 6390 INFO neutron.common.config [-] Logging enabled!
  2015-11-04 07:53:37.027 6390 INFO neutron.common.config [-] 
/usr/local/bin/neutron-lbaas-agent version 8.0.0.dev226
  2015-11-04 07:53:37.027 6390 DEBUG neutron.common.config [-] command line: 
/usr/local/bin/neutron-lbaas-agent --config-file /etc/neutron/neutron.conf 
--config-file=/etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini 
setup_logging /opt/stack/neutron/neutron/common/config.py:191
  2015-11-04 07:53:37.031 CRITICAL neutron 
[req-0c93d2b0-c58e-47cf-ad94-836d71a21e81 None None] ValueError: Empty module 
name
  2015-11-04 07:53:37.031 6390 ERROR neutron Traceback (most recent call last):
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/usr/local/bin/neutron-lbaas-agent", line 10, in 
  2015-11-04 07:53:37.031 6390 ERROR neutron sys.exit(main())
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/services/loadbalancer/agent/agent.py", 
line 61, in main
  2015-11-04 07:53:37.031 6390 ERROR neutron mgr = 
manager.LbaasAgentManager(cfg.CONF)
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/services/loadbalancer/agent/agent_manager.py",
 line 70, in __init__
  2015-11-04 07:53:37.031 6390 ERROR neutron self._load_drivers()
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/services/loadbalancer/agent/agent_manager.py",
 line 95, in _load_drivers
  2015-11-04 07:53:37.031 6390 ERROR neutron self.plugin_rpc
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 38, in 
import_object
  2015-11-04 07:53:37.031 6390 ERROR neutron return 
import_class(import_str)(*args, **kwargs)
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/services/loadbalancer/drivers/haproxy/namespace_driver.py",
 line 71, in __init__
  2015-11-04 07:53:37.031 6390 ERROR neutron vif_driver = 
importutils.import_object(conf.interface_driver, conf)
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 38, in 
import_object
  2015-11-04 07:53:37.031 6390 ERROR neutron return 
import_class(import_str)(*args, **kwargs)
  2015-11-04 07:53:37.031 6390 ERROR neutron   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 27, in 
import_class
  2015-11-04 07:53:37.031 6390 ERROR neutron __import__(mod_str)
  2015-11-04 07:53:37.031 6390 ERROR neutron ValueError: Empty module name
  2015-11-04 07:53:37.031 6390 ERROR neutron 
  q-lbaas failed to start
  ubuntu@nov-dvs-241480-1:~/devstack$

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1513000/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread lei zhang
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

** No longer affects: glance

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Gnocchi:
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  Fix Released
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  Fix Released
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tacker:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread Kan
** Also affects: bifrost
   Importance: Undecided
   Status: New

** Changed in: bifrost
   Status: New => In Progress

** Changed in: bifrost
 Assignee: (unassigned) => Kan (kansks)

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

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  In Progress
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in ooi:
  In Progress
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in OpenStack SDK:
  In Progress
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in refstack:
  New
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in Stackalytics:
  In Progress
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: packstack
   Importance: Undecided
   Status: New

** Changed in: packstack
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1496244] Re: rule change via GUI/CLI puts FW in ERROR mode

2016-01-04 Thread Launchpad Bug Tracker
[Expired for neutron because there has been no activity for 60 days.]

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

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

Title:
  rule change via GUI/CLI puts FW in ERROR mode

Status in neutron:
  Expired

Bug description:
  We have FW rules attached to policy which is assigned to a FW.
  After editing the rule the FW goes into error state

  http://pastebin.com/eF5fCnEe

  Repoducible 100%

  LOGS:
  http://pastebin.com/cHjMX2Q3

  Kilo- openstack-neutron-fwaas-2015.1.1-1.el7ost

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1496244/+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 1526587] Re: Neutron doesn't have a command to show the available ports for one subnet

2016-01-04 Thread Akihiro Motoki
However, it is not easy to know without reading the code.
It looks nice if neutronclient supports appropriate command line options for 
subnet-list.

** Also affects: python-neutronclient
   Importance: Undecided
   Status: New

** Changed in: python-neutronclient
   Importance: Undecided => Wishlist

** Changed in: python-neutronclient
   Status: New => Triaged

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

Title:
  Neutron doesn't have a command to show the available IP addresses for
  one subnet

Status in neutron:
  New

Bug description:
  Neutron doesn't have a command to show the allocated ip addresses for
  one subnet.

  We can get the allocated ip list with command:
  [root@cts-orch ~]# neutron port-list | grep `neutron subnet-show 110-OAM2 | 
awk '/ id / {print $4}'` | cut -d"|" -f5 | cut -d":" -f3 | sort
   "135.111.122.97"}
   "135.111.122.98"}

  But we don't have a command to show the available ips for one subnet.
  I write a shell script to show the available ports as below, but it
  will be helpful if we can provide such a neutron command.

  [root@cts-orch ~]# ./show_available_ip.sh 110-OAM2
  135.111.122.99
  135.111.122.100
  135.111.122.101
  135.111.122.102
  135.111.122.103
  135.111.122.104
  135.111.122.105
  135.111.122.106
  135.111.122.107
  135.111.122.108
  135.111.122.109
  135.111.122.110
  135.111.122.111
  135.111.122.112
  135.111.122.113
  135.111.122.114
  135.111.122.115
  135.111.122.116
  135.111.122.117
  135.111.122.118
  135.111.122.119
  135.111.122.120
  135.111.122.121
  135.111.122.122
  135.111.122.123
  135.111.122.124
  Total Count: 26

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526587/+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 1530650] Re: Neutron: Unable to create ICMP customer rules when type/code is 0

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/263040
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=0410c04fa292a2d2e142228e4c259c22fae95ee3
Submitter: Jenkins
Branch:master

commit 0410c04fa292a2d2e142228e4c259c22fae95ee3
Author: Gary Kotton 
Date:   Sun Jan 3 05:57:12 2016 -0800

Neutron: fix ICMP code and type validators

Ensure that the ICMP codes and types are valid. This can be between
0 and 255 (inclusive).

Please see - 
http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml

Change-Id: I6f7a6f97939364398eb6d73365db4548bdb00e75
Closes-bug: 1530650


** Changed in: horizon
   Status: In Progress => Fix Released

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

Title:
  Neutron: Unable to create ICMP customer rules when type/code is 0

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  The horizon checks for ICMP codes and types are invalid. This should
  be between 0 and 255

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1530650/+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 1526587] Re: Neutron doesn't have a command to show the available ports for one subnet

2016-01-04 Thread Akihiro Motoki
Sorry, I misunderstood the bug description. :-(
I thought the bug said there is no way to know allocation IPs per subnet, but 
it was not

** No longer affects: python-neutronclient

** Summary changed:

- Neutron doesn't have a command to show the available ports for one subnet
+ Neutron doesn't have a command to show the available IP addresses for one 
subnet

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

Title:
  Neutron doesn't have a command to show the available IP addresses for
  one subnet

Status in neutron:
  New

Bug description:
  Neutron doesn't have a command to show the allocated ip addresses for
  one subnet.

  We can get the allocated ip list with command:
  [root@cts-orch ~]# neutron port-list | grep `neutron subnet-show 110-OAM2 | 
awk '/ id / {print $4}'` | cut -d"|" -f5 | cut -d":" -f3 | sort
   "135.111.122.97"}
   "135.111.122.98"}

  But we don't have a command to show the available ips for one subnet.
  I write a shell script to show the available ports as below, but it
  will be helpful if we can provide such a neutron command.

  [root@cts-orch ~]# ./show_available_ip.sh 110-OAM2
  135.111.122.99
  135.111.122.100
  135.111.122.101
  135.111.122.102
  135.111.122.103
  135.111.122.104
  135.111.122.105
  135.111.122.106
  135.111.122.107
  135.111.122.108
  135.111.122.109
  135.111.122.110
  135.111.122.111
  135.111.122.112
  135.111.122.113
  135.111.122.114
  135.111.122.115
  135.111.122.116
  135.111.122.117
  135.111.122.118
  135.111.122.119
  135.111.122.120
  135.111.122.121
  135.111.122.122
  135.111.122.123
  135.111.122.124
  Total Count: 26

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526587/+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 1499204] Re: wrong check for physical function in pci utils

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/227160
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=2ba4644f91aa523c2a14e32a168b853cf0b8c4e1
Submitter: Jenkins
Branch:master

commit 2ba4644f91aa523c2a14e32a168b853cf0b8c4e1
Author: Moshe Levi 
Date:   Wed Sep 23 02:49:28 2015 +0300

libvirt: report pci Type-PF type even when VFs are disabled

libvirt < 1.3 reports virt_functions capability only when pf has
VFs enabled. This workaround patch updates the is_physical_function
function to read the sriov_totalvfs if exists and check it is
greater than 0. The sriov_totalvfs is the number for the
maximum possible VF for this PF. _get_pcidev_info in libvirt driver
is updated to get the correct pci device type using this function.

Closes-Bug: #1499204
Change-Id: I8990c36fb1d6c66093a465930ff3f0948dd64986


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  wrong check for physical function in pci utils

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  in pci utils the is_physical_function function check it based on existing 
virtfn* symbolic link. The check is incorrect because
  if the PF doen't enable SR-IOV meaning sriov_numvfs is set to zero there are 
no  virtfn* ljnks and the nova-compute recognize it as VF.

  see: 
  root@r-ufm160:/opt/stack/logs# ls /sys/bus/pci/devices/\:03\:00.0/
  broken_parity_status  d3cold_allowed   enableiommu_group
modalias   pools  reset sriov_numvfs  uevent
  class device   infinibandirq
msi_buspower  resource  sriov_totalvfsvendor
  commands_cachedma_mask_bitsinfiniband_cm local_cpulist  
msi_irqs   real_miss  resource0 subsystem vpd
  configdriver   infiniband_madlocal_cpus 
netremove resource0_wc  subsystem_device
  consistent_dma_mask_bits  driver_override  infiniband_verbs  mlx5_num_vfs   
numa_node  rescan sriov subsystem_vendor
  root@r-ufm160:/opt/stack/logs# cat 
/sys/bus/pci/devices/\:03\:00.0/sriov_numvfs 
  0

  
  root@r-ufm160:/opt/stack/logs# echo 4 > 
/sys/bus/pci/devices/\:03\:00.0/sriov_numvfs
  root@r-ufm160:/opt/stack/logs# ls /sys/bus/pci/devices/\:03\:00.0/
  broken_parity_status  d3cold_allowed   enableiommu_group
modalias   pools  reset sriov_numvfs  uevent   virtfn3
  class device   infinibandirq
msi_buspower  resource  sriov_totalvfsvendor   vpd
  commands_cachedma_mask_bitsinfiniband_cm local_cpulist  
msi_irqs   real_miss  resource0 subsystem virtfn0
  configdriver   infiniband_madlocal_cpus 
netremove resource0_wc  subsystem_device  virtfn1
  consistent_dma_mask_bits  driver_override  infiniband_verbs  mlx5_num_vfs   
numa_node  rescan sriov subsystem_vendor  virtfn2

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1499204/+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 1530850] [NEW] Neutron QOS bandwidth limit anomaly

2016-01-04 Thread Arslan Qadeer
Public bug reported:

if we set bandwidth of a port to X kbps, the data rate on that port
exceeds from the X kbps.

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

Title:
  Neutron QOS bandwidth limit anomaly

Status in neutron:
  New

Bug description:
  if we set bandwidth of a port to X kbps, the data rate on that port
  exceeds from the X kbps.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1530850/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/258778
Committed: 
https://git.openstack.org/cgit/openstack/ironic-python-agent/commit/?id=cfcef973e832b70c148a2de43fef3d3b6cbb31ce
Submitter: Jenkins
Branch:master

commit cfcef973e832b70c148a2de43fef3d3b6cbb31ce
Author: Shuquan Huang 
Date:   Thu Dec 17 11:31:29 2015 +0800

Replace assertEqual(None, *) with assertIsNone in tests

Replace assertEqual(None, *) with assertIsNone in tests to have
more clear messages in case of failure.

Change-Id: Iad3f8fbb23a8b0f9e5ae4f304799465724c1a433
Closes-bug: #1280522


** Changed in: ironic-python-agent
   Status: In Progress => Fix Released

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

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

** Also affects: ceilometer-powervm
   Importance: Undecided
   Status: New

** Changed in: ceilometer-powervm
 Assignee: (unassigned) => zhangguoqing (474751729-o)

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1525196] Re: change default policy for password and resetstate

2016-01-04 Thread John Garbutt
The owner of the instance should not be able to reset state, that is
totally as intended.

A policy issue will never make an instance go to error, I think you are
hitting a different issue here. Please double check the logs, I suspect
if you are using KVM, you are missing the qemu agent from your image, or
similar.

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

Title:
  change default policy for password and resetstate

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  all cases from devstack, git head commit
  4474dce9e6b847a7691fc3f01d0c594061570d73

  I created an instance with admin tenant then use set-password with demo user, 
it make the instance ERROR
  this kind of operations should not disabled by default

  jichen@devstack1:~$ export OS_USERNAME=demo
  jichen@devstack1:~$ nova set-password t5
  New password:
  Again:
  ERROR (Conflict): Failed to set admin password on 
d3485187-779c-441f-8394-4e3d31234a9f because error setting admin password (HTTP 
409) (Request-ID: req-96b69164-e353-44f8-82a1-ecd20200173b)
  jichen@devstack1:~$ nova list
  
+--+--+++-+---+
  | ID   | Name | Status | Task State | Power 
State | Networks  |
  
+--+--+++-+---+
  | d3485187-779c-441f-8394-4e3d31234a9f | t5   | ERROR  | -  | Running 
| private=10.0.0.10 |
  
+--+--+++-+---+

  
  Also, after the instance become ERROR state, I can't change it to ACTIVE 
state even if I am the owner of the instance

  jichen@devstack1:~$ nova list
  
+--++-++-+--+
  | ID   | Name   | Status  | Task State | 
Power State | Networks |
  
+--++-++-+--+
  | 380e55e3-9726-4928-a44c-a206bc656f48 | t2 | ERROR   | -  | 
Running | private=10.0.0.8 |
  | c426c3d0-a981-4839-969a-50d828e05459 | t4  é | SHUTOFF | -  | 
Shutdown| private=10.0.0.2 ||
  
+--++-++-+--+
  jichen@devstack1:~$ nova reset-state --active t2
  Reset state for server t2 failed: Policy doesn't allow 
os_compute_api:os-admin-actions:reset_state to be performed. (HTTP 403) 
(Request-ID: req-e7669a3c-3075-4a63-a7a6-f646013a5428)
  ERROR (CommandError): Unable to reset the state for the specified server(s)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1525196/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread Swapnil Kulkarni
** Also affects: ooi
   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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in ooi:
  In Progress
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

** Also affects: oslo.vmware
   Importance: Undecided
   Status: New

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  New
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1443421] Re: After VM migration, tunnels not getting removed with L2Pop ON, when using multiple api_workers in controller

2016-01-04 Thread venkata anil
Looks like some corner case needs to be handled, investigating further.

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

Title:
  After VM migration, tunnels not getting removed with L2Pop ON, when
  using multiple api_workers in controller

Status in neutron:
  In Progress
Status in openstack-ansible:
  Confirmed
Status in openstack-ansible liberty series:
  Confirmed
Status in openstack-ansible trunk series:
  Confirmed

Bug description:

  Setup : Neutron server  HA (3 nodes).
  Hypervisor – ESX with OVsvapp
  l2 POP is on Network node and off on Ovsvapp.

  Condition:
  Make L2 pop on OVs agent, api workers =10 in the controller. 

  On network node,the VXLAN tunnel is created with ESX2 and the Tunnel
  with ESX1 is not removed after migrating VM from ESX1 to ESX2.

  Attaching the logs of servers and agent logs.

  stack@OSC-NS1:/opt/stack/logs/screen$ sudo ovs-vsctl show
  662d03fb-c784-498e-927c-410aa6788455
  Bridge br-ex
  Port phy-br-ex
  Interface phy-br-ex
  type: patch
  options: {peer=int-br-ex}
  Port "eth2"
  Interface "eth2"
  Port br-ex
  Interface br-ex
  type: internal
  Bridge br-tun
  Port patch-int
  Interface patch-int
  type: patch
  options: {peer=patch-tun}
  Port "vxlan-6447007a"
  Interface "vxlan-6447007a"
  type: vxlan
  options: {df_default="true", in_key=flow, 
local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.122"} 
This should have been deleted after MIGRATION.
  Port "vxlan-64470082"
  Interface "vxlan-64470082"
  type: vxlan
  options: {df_default="true", in_key=flow, 
local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.130"}
  Port br-tun
  Interface br-tun
  type: internal
  Port "vxlan-6447002a"
  Interface "vxlan-6447002a"
  type: vxlan
  options: {df_default="true", in_key=flow, 
local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.42"}
  Bridge "br-eth1"
  Port "br-eth1"
  Interface "br-eth1"
  type: internal
  Port "phy-br-eth1"
  Interface "phy-br-eth1"
  type: patch
  options: {peer="int-br-eth1"}
  Bridge br-int
  fail_mode: secure
  Port patch-tun
  Interface patch-tun
  type: patch
  options: {peer=patch-int}
  Port "int-br-eth1"
  Interface "int-br-eth1"
  type: patch
  options: {peer="phy-br-eth1"}
  Port br-int
  Interface br-int
  type: internal
  Port int-br-ex
  Interface int-br-ex
  type: patch
  options: {peer=phy-br-ex}
  Port "tap9515e5b3-ec"
  tag: 11
  Interface "tap9515e5b3-ec"
  type: internal
  ovs_version: "2.0.2"

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1443421/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

** Also affects: python-cloudpulseclient
   Importance: Undecided
   Status: New

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  New
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1521928] Re: Nova API v2.1 error to specify multiple different_hosts.

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/259247
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=2841dd3de96792bd9172115945b5ffa5a1fe7c31
Submitter: Jenkins
Branch:master

commit 2841dd3de96792bd9172115945b5ffa5a1fe7c31
Author: Ken'ichi Ohmichi 
Date:   Fri Dec 18 01:23:47 2015 +

Make scheduler_hints schema allow list of id

Nova v2.0 API allows a list of server_id, and the corresponding
filter handles it. However, Nova v2.1 API doesn't do that now.
That is backward incompatibile issue.
This patch fixes this issue.

NOTE: Tempest patch Ib3365ac2783a0578c7a1a1e72d9b6c9cfea340f5
  is for reproducing this problem on the gate.
  After this fixing, the Tempest patch can be merged and
  we will be able to block this problem.

Change-Id: I1de7d184c590e84ab1b38880c8d784d38c37b820
Closes-Bug: #1521928


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  Nova API v2.1 error to specify multiple different_hosts.

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  1.rpm -qa | grep nova
  openstack-novncproxy-12.0.0-1.el7.noarch
  openstack-console-12.0.0-1.el7.noarch
  openstack-common-12.0.0-1.el7.noarch
  openstack-conductor-12.0.0-1.el7.noarch
  openstack-cert-12.0.0-1.el7.noarch
  openstack-nova-api-12.0.0-1.el7.noarch
  openstack-nova-scheduler-12.0.0-1.el7.noarch
  python-novaclient-2.30.1-1.el7.noarch
  python-nova-12.0.0-1.el7.noarch

  2.log
  [server create request]
  POST /v2/28983b2ce4354747a9958de57ea9c328/servers HTTP/1.1
  Host: 220.xxx.xxx.xxx:8774
  X-Auth-Token: 54fdf9becfcc4540b009a29618f13545
  Content-Type: application/json
  Cache-Control: no-cache
  Postman-Token: 7c2f7922-7ac6-0667-0c09-a3a1587d60ba

  {
  "os:scheduler_hints": {
  "different_host": [
  "099b8bee-9264-48fe-a745-45b22f7ff79f",
  "99644acc-8893-4656-9481-0114efdbc9b6"
  ]
  },
  "server": {
  "name": "ccc",
  "imageRef": "df4191a9-caa6-496b-bed0-eb57ec683fcf",
  "flavorRef": "1",
  "networks": [
  {
  "uuid": "fb0232ba-e9f0-423f-b928-aea3fd3741c7"
  }
  ],
  "availability_zone": "nova"
  }
  }

  [api response]
  Status 400 OK
  Time 768 ms

  Connection →
  Connection
  Options that are desired for the connection
  close
  Content-Length → 283
  Content-Type → application/json; charset=UTF-8
  Date → Wed, 02 Dec 2015 09:21:43 GMT
  Server → Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips
  X-Compute-Request-Id → req-f3702257-76b1-4f32-b07c-a0d3608c014f

  {
  "badRequest": {
  "message": "Invalid input for field/attribute different_host. Value: 
[u'099b8bee-9264-48fe-a745-45b22f7ff79f', 
u'99644acc-8893-4656-9481-0114efdbc9b6']. 
[u'099b8bee-9264-48fe-a745-45b22f7ff79f', 
u'99644acc-8893-4656-9481-0114efdbc9b6'] is not a 'uuid'",
  "code": 400
  }
  }

  [nova-api.log]
  2015-12-02 09:21:43.975 22018 DEBUG nova.osapi_compute.wsgi.server [-] 
(22018) accepted ('192.168.0.22', 43272) server 
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:826
  2015-12-02 09:21:43.982 22018 DEBUG nova.api.openstack.wsgi 
[req-f3702257-76b1-4f32-b07c-a0d3608c014f 5c5696fa83854f7690e7fc36320bacd0 
28983b2ce4354747a9958de57ea9c328 - - -] Action: 'create', calling method: 
>, 
body: {
  "os:scheduler_hints": {
  "different_host": [
  "099b8bee-9264-48fe-a745-45b22f7ff79f",
  "99644acc-8893-4656-9481-0114efdbc9b6"
  ]
  },
  "server": {
  "name": "ccc",
  "imageRef": "df4191a9-caa6-496b-bed0-eb57ec683fcf",
  "flavorRef": "1",
  "networks": [
  {
  "uuid": "fb0232ba-e9f0-423f-b928-aea3fd3741c7"
  }
  ],
  "availability_zone": "nova"
  }
  } _process_stack 
/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:789
  2015-12-02 09:21:43.986 22018 DEBUG nova.api.openstack.wsgi 
[req-f3702257-76b1-4f32-b07c-a0d3608c014f 5c5696fa83854f7690e7fc36320bacd0 
28983b2ce4354747a9958de57ea9c328 - - -] Returning 400 to user: Invalid input 
for field/attribute different_host. Value: 
[u'099b8bee-9264-48fe-a745-45b22f7ff79f', 
u'99644acc-8893-4656-9481-0114efdbc9b6']. 
[u'099b8bee-9264-48fe-a745-45b22f7ff79f', 
u'99644acc-8893-4656-9481-0114efdbc9b6'] is not a 'uuid' __call__ 
/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:1175
  2015-12-02 09:21:43.987 22018 INFO nova.osapi_compute.wsgi.server 
[req-f3702257-76b1-4f32-b07c-a0d3608c014f 5c5696fa83854f7690e7fc36320bacd0 
28983b2ce4354747a9958de57ea9c328 - - -] xxx.xxx.xxx.xxx,192.168.0.22 "POST 
/v2/28983b2ce4354747a9958de57ea9c328/servers HTTP/1.1" status: 

[Yahoo-eng-team] [Bug 1530860] [NEW] Nova service restart disconnects Quobyte volumes on systemd systems

2016-01-04 Thread Silvan Kaiser
Public bug reported:

When running an instance from an image in a Cinder Quobyte volume issues
arise when the corresponding Nova service (openstack-nova-compute) is
restarted or stopped while the instance is active. systemd sigterms the
whole cgroup, this includes the Quobyte client(s) handling the instances
mount point(s), which effectively removes the image from under the
VM(s).

Possible immediate Mitigation steps:
- Do _NOT_ restart/stop a Nova service that has running instances using images 
in Cinder Quobyte volumes
- Reconfigure sytemd.kill to use killmode=process or killmode=none instead of 
killmode=control-group (which is the default).
- Migrate instances off the host prior to restarting/stopping the Nova service.

The future solution will be to remove the client instance from the
cgroup of the Nova Quobyte driver.

** Affects: nova
 Importance: Undecided
 Assignee: Silvan Kaiser (2-silvan)
 Status: New


** Tags: quobyte

** Changed in: nova
 Assignee: (unassigned) => Silvan Kaiser (2-silvan)

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

Title:
  Nova service restart disconnects Quobyte volumes on systemd systems

Status in OpenStack Compute (nova):
  New

Bug description:
  When running an instance from an image in a Cinder Quobyte volume
  issues arise when the corresponding Nova service (openstack-nova-
  compute) is restarted or stopped while the instance is active. systemd
  sigterms the whole cgroup, this includes the Quobyte client(s)
  handling the instances mount point(s), which effectively removes the
  image from under the VM(s).

  Possible immediate Mitigation steps:
  - Do _NOT_ restart/stop a Nova service that has running instances using 
images in Cinder Quobyte volumes
  - Reconfigure sytemd.kill to use killmode=process or killmode=none instead of 
killmode=control-group (which is the default).
  - Migrate instances off the host prior to restarting/stopping the Nova 
service.

  The future solution will be to remove the client instance from the
  cgroup of the Nova Quobyte driver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1530860/+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 1489059] Re: "db type could not be determined" running py34

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/254121
Committed: 
https://git.openstack.org/cgit/openstack/zaqar/commit/?id=3c464188fd1c34edc2d778faaaeee7f8ebeb365c
Submitter: Jenkins
Branch:master

commit 3c464188fd1c34edc2d778faaaeee7f8ebeb365c
Author: zhang.lei 
Date:   Mon Dec 7 18:38:39 2015 +0800

Put py34 first in the env order of tox

To solve the problem of "db type could not be determined" on py34
we have to run first the py34 env to, then, run py27. This patch
puts py34 first on the tox.ini list of envs to avoid this problem
to happen.

Change-Id: Iabc31bfa508fbf4fad19bd0f09f389a8d3f52865
Closes-bug: #1489059


** Changed in: zaqar
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  Fix Released
Status in Barbican:
  Fix Released
Status in cloudkitty:
  Fix Committed
Status in Glance:
  Fix Committed
Status in glance_store:
  Fix Committed
Status in hacking:
  Fix Released
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Committed
Status in Manila:
  Fix Released
Status in Murano:
  Fix Committed
Status in networking-midonet:
  Fix Released
Status in networking-ofagent:
  New
Status in neutron:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Committed
Status in python-muranoclient:
  Fix Released
Status in python-solumclient:
  In Progress
Status in Rally:
  Fix Released
Status in Sahara:
  Fix Released
Status in senlin:
  Fix Released
Status in tap-as-a-service:
  New
Status in tempest:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

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

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  New
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1530864] [NEW] VolumeTypeList rest call is not implemented

2016-01-04 Thread Marcos Lobo
Public bug reported:

VolumeTypeList cinder API REST call is not implemented yet in Horizon

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  VolumeTypeList rest call is not implemented

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  VolumeTypeList cinder API REST call is not implemented yet in Horizon

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1530864/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/258885
Committed: 
https://git.openstack.org/cgit/openstack/networking-cisco/commit/?id=7cc1f5e5b60df55c20f220c4066ba1e5c951732d
Submitter: Jenkins
Branch:master

commit 7cc1f5e5b60df55c20f220c4066ba1e5c951732d
Author: Shuquan Huang 
Date:   Thu Dec 17 17:05:31 2015 +0800

Replace assertEqual(None, *) with assertIsNone in tests

Replace assertEqual(None, *) with assertIsNone in tests to have
more clear messages in case of failure.

Change-Id: Id7b3df39092d6a5ae3f0c35a5b8d33986e46f73b
Closes-bug: #1280522


** Changed in: networking-cisco
   Status: In Progress => Fix Released

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

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in ooi:
  In Progress
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in OpenStack SDK:
  New
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in refstack:
  New
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in Stackalytics:
  New
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread Swapnil Kulkarni
** Also affects: refstack
   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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in ooi:
  In Progress
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in OpenStack SDK:
  New
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in refstack:
  New
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1530847] [NEW] TypeError attaching volume to instance

2016-01-04 Thread Valeriy Ponomaryov
Public bug reported:

Manila project has been facing following error since "2016, january 3,
~16:00+" of ZUUL's timezone:

2016-01-04 11:47:11.087 ERROR nova.api.openstack.extensions 
[req-d3ea820b-5b7e-4174-aa92-60b5d6283ee9 nova service] Unexpected exception in 
API method
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/extensions.py", line 478, in wrapped
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/compute/volumes.py", line 283, in create
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
volume_id, device)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 235, in wrapped
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions return 
func(self, context, target, *args, **kwargs)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 224, in inner
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions return 
function(self, context, instance, *args, **kwargs)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 205, in inner
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions return 
f(self, context, instance, *args, **kw)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 3082, in attach_volume
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions disk_bus, 
device_type)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 3055, in _attach_volume
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
device_type=device_type)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/rpcapi.py", line 813, in 
reserve_block_device_name
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
volume_bdm = cctxt.call(ctxt, 'reserve_block_device_name', **kw)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 
158, in call
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
retry=self.retry)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 90, 
in _send
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
timeout=timeout, retry=retry)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 464, in send
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
retry=retry)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 455, in _send
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions raise 
result
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions TypeError: 
__init__() takes at most 2 arguments (3 given)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
143, in _dispatch_and_reply
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
executor_callback))
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
189, in _dispatch
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
executor_callback)
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions 
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
130, in _do_dispatch
2016-01-04 11:47:11.087 26423 ERROR nova.api.openstack.extensions result = 
func(ctxt, **new_args)
2016-01-04 11:47:11.087 26423 ERROR 

[Yahoo-eng-team] [Bug 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

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

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  New
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread Swapnil Kulkarni
** Also affects: python-openstacksdk
   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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in ooi:
  In Progress
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in OpenStack SDK:
  New
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: heat
   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/1508442

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in cloudkitty:
  In Progress
Status in Designate:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in octavia:
  New
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in tuskar:
  In Progress
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: tuskar
   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/1508442

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in cloudkitty:
  In Progress
Status in Designate:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in octavia:
  New
Status in openstack-ansible:
  New
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in tuskar:
  In Progress
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: oslo.cache
   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/1508442

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in cloudkitty:
  In Progress
Status in Designate:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in octavia:
  New
Status in openstack-ansible:
  New
Status in oslo.cache:
  New
Status in oslo.privsep:
  New
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in tuskar:
  In Progress
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread OpenStack Infra
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

Reviewed:  https://review.openstack.org/263269
Committed: 
https://git.openstack.org/cgit/openstack/python-cloudpulseclient/commit/?id=e72c9d5ef8883f93ca02f662f11525e5320e6aab
Submitter: Jenkins
Branch:master

commit e72c9d5ef8883f93ca02f662f11525e5320e6aab
Author: zhangguoqing 
Date:   Mon Jan 4 14:05:29 2016 +

Change LOG.warn to LOG.warning

Python 3 deprecated the logger.warn method, see:
https://docs.python.org/3/library/logging.html#logging.warning
so we prefer to use warning to avoid DeprecationWarning.

Change-Id: I6916a95800f003e96736c7e8fe45f3cfe242d983
Closes-Bug: #1530742


** Changed in: python-cloudpulseclient
   Status: New => Fix Released

** Changed in: cloudpulse
   Status: New => Fix Released

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  Fix Released
Status in Evoque:
  Fix Released
Status in Gnocchi:
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  Fix Released
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  Fix Released
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  Fix Released
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tacker:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1188643] Re: notification queues are created in rabbit but never consumed

2016-01-04 Thread Deliang Fan
** Changed in: keystone
   Status: Confirmed => 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/1188643

Title:
  notification queues are created in rabbit but never consumed

Status in devstack:
  Invalid
Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Compute (nova):
  Won't Fix
Status in oslo.messaging:
  Won't Fix

Bug description:
  The following queues are created in rabbit but there are no consumers
  for them. notifications.info, notifications.warn and
  notifications.error. This means that all events are queued up in them
  until rabbit is restarted or else someone consumes the queue.

  notifications.info in particular collects a large number of events
  very quickly

  All events should be published to an exchange and it should be up the
  consumers on how to configure any queues in rabbit and how they should
  be consumed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1188643/+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 1531065] [NEW] duplicately fetch subnet_id in get_subnet_for_dvr

2016-01-04 Thread ZongKai LI
Public bug reported:

In 
https://github.com/openstack/neutron/blob/77a6d114eae9de8078b358a9bd8502fb7c393641/neutron/db/dvr_mac_db.py#L159-L163,
 get_subnet_for_dvr will try to get subnet_id when fixed_ips is not None:
...
def get_subnet_for_dvr(self, context, subnet, fixed_ips=None):
if fixed_ips:
subnet_data = fixed_ips[0]['subnet_id']
else:
subnet_data = subnet
...

But checking its callers :
https://github.com/openstack/neutron/blob/77a6d114eae9de8078b358a9bd8502fb7c393641/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L509-L531
 , 
and
https://github.com/openstack/neutron/blob/77a6d114eae9de8078b358a9bd8502fb7c393641/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L366-L380
 , they all have similar logic:
...
fixed_ip = fixed_ips[0]
...
subnet_uuid = fixed_ip['subnet_id']
...
subnet_info = self.plugin_rpc.get_subnet_for_dvr(
self.context, subnet_uuid, fixed_ips=fixed_ips)

subnet_id has already be fetched and passed into get_subnet_for_dvr. So
in get_subnet_for_dvr, there is no need to fetch again.

** Affects: neutron
 Importance: Undecided
 Assignee: ZongKai LI (lzklibj)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => ZongKai LI (lzklibj)

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

Title:
  duplicately  fetch subnet_id in get_subnet_for_dvr

Status in neutron:
  New

Bug description:
  In 
https://github.com/openstack/neutron/blob/77a6d114eae9de8078b358a9bd8502fb7c393641/neutron/db/dvr_mac_db.py#L159-L163,
 get_subnet_for_dvr will try to get subnet_id when fixed_ips is not None:
  ...
  def get_subnet_for_dvr(self, context, subnet, fixed_ips=None):
  if fixed_ips:
  subnet_data = fixed_ips[0]['subnet_id']
  else:
  subnet_data = subnet
  ...

  But checking its callers :
  
https://github.com/openstack/neutron/blob/77a6d114eae9de8078b358a9bd8502fb7c393641/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L509-L531
 , 
  and
  
https://github.com/openstack/neutron/blob/77a6d114eae9de8078b358a9bd8502fb7c393641/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L366-L380
 , they all have similar logic:
  ...
  fixed_ip = fixed_ips[0]
  ...
  subnet_uuid = fixed_ip['subnet_id']
  ...
  subnet_info = self.plugin_rpc.get_subnet_for_dvr(
  self.context, subnet_uuid, fixed_ips=fixed_ips)

  subnet_id has already be fetched and passed into get_subnet_for_dvr.
  So in get_subnet_for_dvr, there is no need to fetch again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1531065/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread lei zhang
** Also affects: octavia
   Importance: Undecided
   Status: New

** Changed in: octavia
 Assignee: (unassigned) => lei zhang (zhang-lei)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in cloudkitty:
  In Progress
Status in Designate:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in octavia:
  New
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in tuskar:
  In Progress
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: openstack-ansible
   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/1508442

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in cloudkitty:
  In Progress
Status in Designate:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in octavia:
  New
Status in openstack-ansible:
  New
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in tuskar:
  In Progress
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1494574] Re: Logging missing value types

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/223000
Committed: 
https://git.openstack.org/cgit/openstack/trove/commit/?id=667dc5f50c05b171e3acddf8100a5003a2a59044
Submitter: Jenkins
Branch:master

commit 667dc5f50c05b171e3acddf8100a5003a2a59044
Author: Sergey Vilgelm 
Date:   Mon Sep 14 10:55:27 2015 +0300

Fix missing value types for log message

This patch add missing value types for some log message of exception.

Change-Id: Ib4a1dea4cbfead8367884d9e6c34cb9b3f0a8d6a
Closes-Bug: #1494574
Co-Authored-By: Morgan Jones 


** Changed in: trove
   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/1494574

Title:
  Logging missing value types

Status in Cinder:
  Fix Released
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-midonet:
  Fix Released
Status in neutron:
  Fix Released
Status in os-brick:
  Fix Released
Status in oslo.versionedobjects:
  Fix Released
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released

Bug description:
  There are a few locations in the code where the log string is missing
  the formatting type, causing log messages to fail.

  
  FILE: ../OpenStack/cinder/cinder/volume/drivers/emc/emc_vnx_cli.py
  
  LOG.debug('EMC: Command Exception: %(rc) %(result)s. 
'  
  FILE: ../OpenStack/cinder/cinder/consistencygroup/api.py  
  
  LOG.error(_LE("CG snapshot %(cgsnap) not found 
when "
  LOG.error(_LE("Source CG %(source_cg) not found 
when "
  FILE: ../OpenStack/cinder/cinder/volume/drivers/emc/emc_vmax_masking.py   
  
  "Storage group %(sgGroupName) "   
  
  FILE: ../OpenStack/cinder/cinder/volume/manager.py
  
  '%(image_id) will not create cache 
entry.'),

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1494574/+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 1517839] Re: Make CONF.set_override with paramter enforce_type=True by default

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/263031
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=9ec0f3317bfb92f4f2244752f66dc1a5bb91e40b
Submitter: Jenkins
Branch:master

commit 9ec0f3317bfb92f4f2244752f66dc1a5bb91e40b
Author: LiuNanke 
Date:   Sun Jan 3 20:35:00 2016 +0800

Test: make enforce_type=True in CONF.set_override

each config option has limitation for type and value.
In production code, oslo.conf can ensure user's input
is valid, but in unit test, test methods can pass if
we use method CONF.set_override without parameter
enforce_type=True even we pass wrong type or wrong
value to config option. This commit makes sure calling
method CONF.set_override with enforce_type=True.

Change-Id: I52fdc7ed9f74f80814fbafd00625dcdd5597ba0e
Closes-bug: #1517839


** Changed in: keystone
   Status: New => Fix Released

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

Title:
  Make CONF.set_override with paramter enforce_type=True by default

Status in OpenStack Identity (keystone):
  Fix Released
Status in oslo.config:
  New
Status in Rally:
  Triaged

Bug description:
  1. Problems :
 oslo_config provides method CONF.set_override[1] , developers usually use 
it to change config option's value in tests. That's convenient .
 By default  parameter enforce_type=False,  it doesn't check any type or 
value of override. If set enforce_type=True , will check parameter
 override's type and value.  In production code(running time code),  
oslo_config  always checks  config option's value.
 In short, we test and run code in different ways. so there's  gap:  config 
option with wrong type or invalid value can pass tests when
 parameter enforce_type = False in consuming projects.  that means some 
invalid or wrong tests are in our code base.
 There is nova POC result when I enable "enforce_type=true" [2],  and I 
must fix them in [3]

 [1] 
https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173
 [2] 
http://logs.openstack.org/16/242416/1/check/gate-nova-python27/97b5eff/testr_results.html.gz
 [3]  https://review.openstack.org/#/c/242416/  
https://review.openstack.org/#/c/242717/  
https://review.openstack.org/#/c/243061/

  2. Proposal 
 1) Make  method CONF.set_override with  enforce_type=True  in consuming 
projects. and  fix violations when  enforce_type=True in each project.

2) Make  method CONF.set_override with  enforce_type=True by default
  in oslo_config

 Hope some one from consuming projects can help make
  enforce_type=True in consuming projects and fix violations,

 You can find more details and comments  in
  https://etherpad.openstack.org/p/enforce_type_true_by_default

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1517839/+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 1476329] Re: v2 tokens validated on the v3 API are missing timezones

2016-01-04 Thread Deliang Fan
** Changed in: keystone
   Status: Triaged => Fix Committed

** Changed in: keystone
   Status: Fix Committed => Fix Released

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

Title:
  v2 tokens validated on the v3 API are missing timezones

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  v3 tokens contain the issued_at and expires_at timestamps for each
  token. If a token is created on the v2 API and then validated on the
  v3 API, this timezone information is missing (the 'Z' at the end of
  the timestamp), and thus cannot be validated as ISO 8601 extended
  format timestamps.

  This patch contains two FIXMEs which, if uncommented, will reproduce
  this bug:

    https://review.openstack.org/#/c/203250/

  This appears to affect all token formats.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1476329/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: designate
   Importance: Undecided
   Status: New

** Also affects: cloudkitty
   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/1508442

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in cloudkitty:
  In Progress
Status in Designate:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in octavia:
  New
Status in Packstack:
  In Progress
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

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

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread zhangguoqing
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

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

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tacker:
  New
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1523646] Re: Nova/Cinder Key Manager for Barbican Uses Stale Cache

2016-01-04 Thread Dave McCowan
** Changed in: nova
 Assignee: yuntongjin (yuntongjin) => Dave McCowan (dave-mccowan)

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

** Changed in: ossn
 Assignee: (unassigned) => Dave McCowan (dave-mccowan)

** Changed in: castellan
 Assignee: (unassigned) => Dave McCowan (dave-mccowan)

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

Title:
  Nova/Cinder Key Manager for Barbican Uses Stale Cache

Status in castellan:
  New
Status in Cinder:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Notes:
  New

Bug description:
  The Key Manger for Barbican, implemented in Nova and Cinder, caches a value 
of barbican_client to save extra
  calls to Keystone for authentication.  However, the cached value of 
barbican_client is only valid for the current
  context.  A check needs to be made to ensure the context has not changed 
before using the saved value.

  The symptoms for using a stale cache value include getting the following 
error message when creating
  an encrypted volume.

  From CLI:
  ---
  openstack volume create --size 1 --type LUKS encrypted_volume
  The server has either erred or is incapable of performing the requested 
operation. (HTTP 500) (Request-ID: req-aea6be92-020e-41ed-ba88-44a1f5235ab0)

  
  In cinder.log
  ---
  2015-12-03 09:09:03.648 TRACE cinder.volume.api Traceback (most recent call 
last):
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py", 
line 82, in _exe
  cute_task
  2015-12-03 09:09:03.648 TRACE cinder.volume.api result = 
task.execute(**arguments)
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/opt/stack/cinder/cinder/volume/flows/api/create_volume.py", line 409, in 
execute
  2015-12-03 09:09:03.648 TRACE cinder.volume.api source_volume)
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/opt/stack/cinder/cinder/volume/flows/api/create_volume.py", line 338, in 
_get_encryption_key_
  id
  2015-12-03 09:09:03.648 TRACE cinder.volume.api encryption_key_id = 
key_manager.create_key(context)
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/opt/stack/cinder/cinder/keymgr/barbican.py", line 147, in create_key
  2015-12-03 09:09:03.648 TRACE cinder.volume.api LOG.exception(_LE("Error 
creating key."))
  ….
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 502, in post
  2015-12-03 09:09:03.648 TRACE cinder.volume.api return self.request(url, 
'POST', **kwargs)
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/usr/lib/python2.7/site-packages/keystoneclient/utils.py", line 337, in inner
  2015-12-03 09:09:03.648 TRACE cinder.volume.api return func(*args, 
**kwargs)
  2015-12-03 09:09:03.648 TRACE cinder.volume.api   File 
"/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 402, in 
request
  2015-12-03 09:09:03.648 TRACE cinder.volume.api raise 
exceptions.from_response(resp, method, url)
  2015-12-03 09:09:03.648 TRACE cinder.volume.api Unauthorized: The request you 
have made requires authentication. (Disable debug mode to suppress these 
details.) (HTTP 401) (Request-ID: req-d2c52e0b-c16d-43ec-a7a0-763f1270)

To manage notifications about this bug go to:
https://bugs.launchpad.net/castellan/+bug/1523646/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-01-04 Thread Swapnil Kulkarni
** Also affects: stackalytics
   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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in ooi:
  In Progress
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in OpenStack SDK:
  New
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in refstack:
  New
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in Stackalytics:
  New
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: glance
   Importance: Undecided
   Status: New

** Changed in: glance
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Glance:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in nova-powervm:
  New
Status in python-magnumclient:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: aodh
   Importance: Undecided
   Status: New

** Changed in: aodh
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in nova-powervm:
  New
Status in python-magnumclient:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: zaqar
   Importance: Undecided
   Status: New

** Changed in: zaqar
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in nova-powervm:
  New
Status in python-magnumclient:
  In Progress
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1467589] Re: Remove Cinder V1 support

2016-01-04 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/261787
Committed: 
https://git.openstack.org/cgit/openstack/os-client-config/commit/?id=1cd3e5bb7fd7cd72a481f5ae8bbcd0b2ab114680
Submitter: Jenkins
Branch:master

commit 1cd3e5bb7fd7cd72a481f5ae8bbcd0b2ab114680
Author: Yaguang Tang 
Date:   Sun Dec 27 10:59:08 2015 +0800

Update volume API default version from v1 to v2

Cinder has deprecated API version v1 since Juno release, and
there is a blueprint to remove v1 API support which is in progress.
We should default to v2 API when it's there.

Closes-Bug: 1467589
Change-Id: I83aef4c681cbe342c445f02436fcd40cf1222f23


** Changed in: os-client-config
   Status: In Progress => Fix Released

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

Title:
  Remove Cinder V1 support

Status in Cinder:
  Won't Fix
Status in devstack:
  In Progress
Status in grenade:
  In Progress
Status in heat:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in os-client-config:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in Rally:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Cinder created v2 support in the Grizzly release. This is to track
  progress in removing v1 support in other projects.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1467589/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Drew Thorstensen
** Changed in: nova-powervm
   Status: New => Fix Released

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in nova-powervm:
  Fix Released
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: tempest
   Importance: Undecided
   Status: New

** Changed in: tempest
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

** Changed in: tripleo
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in nova-powervm:
  New
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1530742] Re: Change LOG.warn to LOG.warning

2016-01-04 Thread OpenStack Infra
*** This bug is a duplicate of bug 1508442 ***
https://bugs.launchpad.net/bugs/1508442

Reviewed:  https://review.openstack.org/263291
Committed: 
https://git.openstack.org/cgit/openstack/tacker/commit/?id=ff28020ab78f610baa0cc113fe36d7f71afa86eb
Submitter: Jenkins
Branch:master

commit ff28020ab78f610baa0cc113fe36d7f71afa86eb
Author: zhangguoqing 
Date:   Mon Jan 4 14:45:04 2016 +

Change LOG.warn to LOG.warning

Python 3 deprecated the logger.warn method, see:
https://docs.python.org/3/library/logging.html#logging.warning
so we prefer to use warning to avoid DeprecationWarning.

Change-Id: Iafbe78cdcfac329d3795853fe8cc38e549279375
Closes-Bug: #1530742


** Changed in: tacker
   Status: New => Fix Released

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

Title:
  Change LOG.warn to LOG.warning

Status in ceilometer-powervm:
  Fix Released
Status in CloudPulse:
  New
Status in Evoque:
  Fix Released
Status in Glance:
  New
Status in Gnocchi:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in keystoneauth:
  In Progress
Status in Kingbird:
  New
Status in Mistral:
  New
Status in Murano:
  In Progress
Status in openstack-ansible:
  New
Status in oslo.messaging:
  In Progress
Status in oslo.middleware:
  New
Status in oslo.vmware:
  New
Status in python-cloudpulseclient:
  New
Status in python-evoqueclient:
  In Progress
Status in python-heatclient:
  In Progress
Status in python-muranoclient:
  In Progress
Status in senlin:
  Fix Released
Status in Stackalytics:
  New
Status in tacker:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:
  https://docs.python.org/3/library/logging.html#logging.warning
  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
https://review.openstack.org/263339

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

** Changed in: keystone
   Status: New => In Progress

** Changed in: keystone
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

** Changed in: neutron
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated

2016-01-04 Thread Swapnil Kulkarni
** Also affects: gnocchi
   Importance: Undecided
   Status: New

** Changed in: gnocchi
 Assignee: (unassigned) => Swapnil Kulkarni (coolsvap)

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

Title:
  LOG.warn is deprecated

Status in Aodh:
  In Progress
Status in Glance:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in ironic-python-agent:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in neutron:
  In Progress
Status in nova-powervm:
  Fix Released
Status in python-magnumclient:
  In Progress
Status in tempest:
  In Progress
Status in tripleo:
  New
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated. But it still used in a few places, non-
  deprecated LOG.warning should be used instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1508442/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

2016-01-04 Thread LiuNanke
** Also affects: python-openstacksdk
   Importance: Undecided
   Status: New

** Changed in: python-openstacksdk
   Status: New => In Progress

** Changed in: python-openstacksdk
 Assignee: (unassigned) => LiuNanke (nanke-liu)

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

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in CloudRoast:
  New
Status in congress:
  In Progress
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  In Progress
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in OpenStack SDK:
  In Progress
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+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 1489059] Re: "db type could not be determined" running py34

2016-01-04 Thread Steve McLellan
** Also affects: searchlight
   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/1489059

Title:
  "db type could not be determined" running py34

Status in Aodh:
  Fix Released
Status in Barbican:
  Fix Released
Status in cloudkitty:
  Fix Committed
Status in Glance:
  Fix Committed
Status in glance_store:
  Fix Committed
Status in hacking:
  Fix Released
Status in heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-lib:
  Fix Committed
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Committed
Status in Manila:
  Fix Released
Status in Murano:
  Fix Committed
Status in networking-midonet:
  Fix Released
Status in networking-ofagent:
  New
Status in neutron:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Committed
Status in python-muranoclient:
  Fix Released
Status in python-solumclient:
  In Progress
Status in Rally:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in senlin:
  Fix Released
Status in tap-as-a-service:
  New
Status in tempest:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  When running tox for the first time, the py34 execution fails with an
  error saying "db type could not be determined".

  This issue is know to be caused when the run of py27 preceeds py34 and
  can be solved erasing the .testrepository and running "tox -e py34"
  first of all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1489059/+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 1528676] Re: OpenLDAP password policy not enforced for password changes

2016-01-04 Thread Tristan Cacqueray
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.

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

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

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

Title:
  OpenLDAP password policy not enforced for password changes

Status in OpenStack Identity (keystone):
  New
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Hello there,
  I'm on Ubuntu 14.04.3, Openstack Juno and OpenLDAP v2.4.31 releases.
  I configured OpenLDAP as an identity backend for Keystone and configured it 
according to official documentation from:
  http://docs.openstack.org/developer/keystone/configuration.html
  I'd like my users to be able to change their own passwords, but at the same 
time OpenLDAP password policy to be enforced upon password changes. I've set to 
true all allow_creates, allow_updates and allow_deletes not to be restricted in 
any way by keystone.
  The problem is the following: RootDN account is used for binding when the 
user is changing his/her password. OpenLDAP password policy is not enforced 
when RootDN performs the password change. As a result, no password policy is 
enforced during password change.
  If I don't set LDAP user/password in keystone.conf, then users cannot change 
their own passwords at all.
  Please recommend how I can allow the users to change their own passwords and 
at the same time enforce OpenLDAP password policy.
  Thank you,
  Nodir

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1528676/+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 1425543] Re: (self-documentation) doc/api_samples/all_extensions/extensions-get-resp.json contain broken links

2016-01-04 Thread Darla Ahlert
** Changed in: nova
   Status: In Progress => Invalid

** Changed in: nova
 Assignee: Darla Ahlert (da741q) => (unassigned)

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

Title:
  (self-documentation) doc/api_samples/all_extensions/extensions-get-
  resp.json contain broken links

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  doc/api_samples/all_extensions/extensions-get-resp.json in repository
  contains broken links:

  namespace": 
"http://docs.openstack.org/compute/ext/extended_rescue_with_image/api/v2;
  namespace": "http://docs.openstack.org/compute/ext/rescue/api/v1.1;

  etc.

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