[Yahoo-eng-team] [Bug 1526559] Re: L3 agent parallel configuration of routers might slow things down
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
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 SongDate: 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
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()
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 HuangDate: 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
*** 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: zhurongDate: 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
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 HuangDate: 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
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 MotokiDate: 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
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 BanerjeeDate: 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
*** 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: zhurongDate: 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
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
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.rongDate: 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
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
*** 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
*** 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: zhangguoqingDate: 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
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
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 EguchiDate: 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
Reviewed: https://review.openstack.org/262876 Committed: https://git.openstack.org/cgit/openstack/rally/commit/?id=e1d332bd5393c9c30aedeafa0073dca99feab322 Submitter: Jenkins Branch:master commit e1d332bd5393c9c30aedeafa0073dca99feab322 Author: LiuNankeDate: 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
** 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
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
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
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
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 HuangDate: 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
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 HuaDate: 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
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 RollenhagenDate: 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
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()
** 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
** 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
[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
*** 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
** 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
** 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
[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
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
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 KottonDate: 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
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
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 LeviDate: 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
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
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 HuangDate: 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
*** 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
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
** 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
*** 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
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
*** 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.
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 OhmichiDate: 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
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
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.leiDate: 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
*** 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
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
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 HuangDate: 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
** 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
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
*** 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
** 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
** 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
** 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
** 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
*** 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: zhangguoqingDate: 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
** 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
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
** 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
** 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
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 VilgelmDate: 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
Reviewed: https://review.openstack.org/263031 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=9ec0f3317bfb92f4f2244752f66dc1a5bb91e40b Submitter: Jenkins Branch:master commit 9ec0f3317bfb92f4f2244752f66dc1a5bb91e40b Author: LiuNankeDate: 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
** 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
** 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
*** 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
*** 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
** 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
** 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
** 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
** 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
** 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
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 TangDate: 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
** 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
** 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
*** 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: zhangguoqingDate: 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
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
** 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()
** 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
** 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
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
** 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