[Yahoo-eng-team] [Bug 1626379] [NEW] Truncated tooltip Japanese text found in Detach Volume dialog
Public bug reported: openstack_dashboard/dashboards/project/instances/forms.py Project > Instances > Detach Volume Japanese tool tip displayed next to the "Volume ID" in Detach Volume dialog is not fully visible. The top of the text is not fitted within the box (or the popup is hidden by the top section of the dialog. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Truncated_ToolTip_DetachVolume.png" https://bugs.launchpad.net/bugs/1626379/+attachment/4745905/+files/Truncated_ToolTip_DetachVolume.png ** Description changed: openstack_dashboard/dashboards/project/instances/forms.py Project > Instances > Detach Volume Japanese tool tip displayed next to the "Volume ID" in Detach Volume dialog is not fully visible. - The top of the text is not fitted within the box (or the popup is hidded by the top section of the dialog. + The top of the text is not fitted within the box (or the popup is hidden by the top section of the dialog. -- 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/1626379 Title: Truncated tooltip Japanese text found in Detach Volume dialog Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/dashboards/project/instances/forms.py Project > Instances > Detach Volume Japanese tool tip displayed next to the "Volume ID" in Detach Volume dialog is not fully visible. The top of the text is not fitted within the box (or the popup is hidden by the top section of the dialog. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626379/+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 1625872] Re: CallbackNotFound errors found in API job logs
Reviewed: https://review.openstack.org/373575 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bad3eaace1a320e33d3bcdff43e4c66ff0c49066 Submitter: Jenkins Branch:master commit bad3eaace1a320e33d3bcdff43e4c66ff0c49066 Author: Armando Migliaccio Date: Tue Sep 20 18:00:07 2016 -0700 Stop oslo_messaging from error logging CallbackNotFound This is expected when the server is pushing for a resource and some listeners (like the OVS agent) are not interested in the event. This happens when Trunk create/delete events are dispatched by the server. Change-Id: I90ddffda546af45ca85b3e4f4f22eed005d971df Closes-bug: #1625872 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625872 Title: CallbackNotFound errors found in API job logs Status in neutron: Fix Released Bug description: Example: http://logs.openstack.org/50/372750/7/check/gate-neutron-dsvm-api- ubuntu-trusty/181c946/logs/screen-q-agt.txt.gz?level=TRACE The API job configures the trunk plugin/OVS to be active. The OVS agent explicitly unsubscribe the callback [1] and thus we should avoid emitting noise. This is a sister change of [2] [1] https://github.com/openstack/neutron/blob/master/neutron/services/trunk/drivers/openvswitch/agent/driver.py#L38 [2] https://review.openstack.org/#/c/370543/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625872/+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 1626348] [NEW] The label for "Floating IP" is shown as "F" in Japanese and Korean
Public bug reported: openstack_dashboard/static/app/resources/resources.module.js Developer > Resources > Registered Resource Types The label for "Floating IP" is shown as "F" in Japanese and Korean, despite the translation is available in Zanata. Note: We do not translate this term and is supposed to be shown as "Floating IP". This might have something to do with this issue? I checked Chinese and it is OK (it is translated into Chinese characters). ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "TruncatedLabel_FloatingIPs_Resources.png" https://bugs.launchpad.net/bugs/1626348/+attachment/4745786/+files/TruncatedLabel_FloatingIPs_Resources.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/1626348 Title: The label for "Floating IP" is shown as "F" in Japanese and Korean Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/static/app/resources/resources.module.js Developer > Resources > Registered Resource Types The label for "Floating IP" is shown as "F" in Japanese and Korean, despite the translation is available in Zanata. Note: We do not translate this term and is supposed to be shown as "Floating IP". This might have something to do with this issue? I checked Chinese and it is OK (it is translated into Chinese characters). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626348/+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 1625106] Re: gate failure: check_public_network_connectivity
** 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/1625106 Title: gate failure: check_public_network_connectivity Status in neutron: Invalid Bug description: http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22in%20check_public_network_connectivity%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625106/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
Reviewed: https://review.openstack.org/355157
Committed:
https://git.openstack.org/cgit/openstack/python-manilaclient/commit/?id=ee60b3aabe1fe7de3527c2a8a18f1769d2338b7e
Submitter: Jenkins
Branch:master
commit ee60b3aabe1fe7de3527c2a8a18f1769d2338b7e
Author: yuyafei
Date: Sat Aug 13 15:42:08 2016 +0800
Add __ne__ built-in function
In Python 3 __ne__ by default delegates to __eq__ and inverts the
result, but in Python 2 they urge you to define __ne__ when you
define __eq__ for it to work properly [1].There are no implied
relationships among the comparison operators. The truth of x==y
does not imply that x!=y is false. Accordingly, when defining
__eq__(), one should also define __ne__() so that the operators
will behave as expected.
[1]https://docs.python.org/2/reference/datamodel.html#object.__ne__
Without the change in base.py, if r1==r2, the follow code should all
pass.
self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
The change here is for a way to self.assertNotEqual(r1, r2) as
expected.
Change-Id: I72485d38eab8b5a2034a621e1eebf33b86832f35
Closes-Bug: #1586268
** Changed in: python-manilaclient
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/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
Fix Released
Status in daisycloud-core:
New
Status in heat:
New
Status in OpenStack Dashboard (Horizon):
New
Status in Kosmos:
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in octavia:
New
Status in Panko:
Fix Released
Status in python-barbicanclient:
New
Status in python-ceilometerclient:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-congressclient:
Fix Released
Status in python-glanceclient:
In Progress
Status in python-heatclient:
Fix Released
Status in python-smaugclient:
Fix Released
Status in python-keystoneclient:
Fix Released
Status in python-manilaclient:
Fix Released
Status in python-muranoclient:
Fix Released
Status in python-novaclient:
Fix Released
Status in taskflow:
Fix Released
Status in tempest:
Fix Released
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1626343] [NEW] Status dropdown list label in "Available" is unlocalized
Public bug reported: Admin > Volume > Change Volume Status Status dropdown list label "Available" is unlocalized. I am not sure whether this is referring to "Available status options" or the status "Available" but either way, it should be localized. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Unlocalized_ChangeVolumeStatus_DropdownLabel.png" https://bugs.launchpad.net/bugs/1626343/+attachment/4745782/+files/Unlocalized_ChangeVolumeStatus_DropdownLabel.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/1626343 Title: Status dropdown list label in "Available" is unlocalized Status in OpenStack Dashboard (Horizon): New Bug description: Admin > Volume > Change Volume Status Status dropdown list label "Available" is unlocalized. I am not sure whether this is referring to "Available status options" or the status "Available" but either way, it should be localized. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626343/+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 1626216] Re: unable to retrieve nova info
** Changed in: nova Status: New => Invalid ** Changed in: horizon Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1626216 Title: unable to retrieve nova info Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Compute (nova): Invalid Bug description: Horizon reports error: unable to retrieve flavors list, among other errors whenever nova related information is accessed. The problem occurs immediately on a fresh devstack install at the latest versions: devstack: commit 81d89cf3584a5edadbaa2514305cf5721b29cdff horizon: commit 877344de0d9e62c8cf24c9e3ab21f994b2b43b05; Merge: 35fdc05 2fec0a1 nova: commit 4cc5ef121f262b8990274b60404457a62fc9778c; Merge: c7bf2ba e843628 Horizon log file attached. Excerpt: 2016-09-21 06:22:04.897365 Call to list supported extensions failed. This is likely due to a problem communicating with the Nova endpoint. Host Aggregates panel will not be displayed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626216/+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 1626341] [NEW] The path "themes/default" next to the section title "Default" on Developer tab should be removed
Public bug reported: "theme/default" is shown next to Default section title on the developer tab. Since other section does not include paths, this one should probably be removed. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "UnneededPath_DeveloperTab.png" https://bugs.launchpad.net/bugs/1626341/+attachment/4745780/+files/UnneededPath_DeveloperTab.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/1626341 Title: The path "themes/default" next to the section title "Default" on Developer tab should be removed Status in OpenStack Dashboard (Horizon): New Bug description: "theme/default" is shown next to Default section title on the developer tab. Since other section does not include paths, this one should probably be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626341/+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 1626336] [NEW] "Subnet" label in Create Subnet dialog is unlocalized
Public bug reported: openstack_dashboard/dashboards/project/networks/subnets/workflows.py "Subnet" label is shown as CreateSubnetInfoAction in Create Subnet dialog. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "UnlocalizedText_CreateSubnetTabLabel.png" https://bugs.launchpad.net/bugs/1626336/+attachment/4745770/+files/UnlocalizedText_CreateSubnetTabLabel.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/1626336 Title: "Subnet" label in Create Subnet dialog is unlocalized Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/dashboards/project/networks/subnets/workflows.py "Subnet" label is shown as CreateSubnetInfoAction in Create Subnet dialog. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626336/+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 1623390] Re: Wrong calculation of quotas
This is actually going to be expected behavior right now with the way the quota engine works. See the commit message in https://review.openstack.org/371739 for an explanation. ** Changed in: neutron Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1623390 Title: Wrong calculation of quotas Status in neutron: Won't Fix Bug description: Neutron has rally non-voting job. It is red now. Rally report: http://logs.openstack.org/44/367744/7/check/gate-rally-dsvm-neutron-neutron/b3af93f/rally-plot/results.html.gz#/NeutronNetworks.create_and_list_networks/failures Scenario: - [pre-step] create new test tenant - [pre-step] set quotas for new tenant to allow create 100 networks (neutron.quotas.update networks=100) - [repeat 100 times] create and list networks Expected result: all 100 iterations are finished successfully == it is possible to create N networks if networks quotas is set to N Actual result: The last iteration is failed == it is possible to create N-1 networks if networks quotas is set to N To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1623390/+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 1625973] Re: RuntimeError on test_standard_attr_resource_model_map
Reviewed: https://review.openstack.org/373868 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=414f607374e7d5ee7048539aa2aa96fae040d6cb Submitter: Jenkins Branch:master commit 414f607374e7d5ee7048539aa2aa96fae040d6cb Author: Ihar Hrachyshka Date: Sat Sep 17 02:29:52 2016 + Garbage collect HasStandardAttributes subclasses in StandardAttrTestCase Otherwise they may affect consequent calls to get_standard_attr_resource_model_map on next plugin instantiation. Change-Id: If8030776b3880e8c61980aeb28a65b397cca5ec4 Closes-Bug: #1625973 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625973 Title: RuntimeError on test_standard_attr_resource_model_map Status in neutron: Fix Released Bug description: http://logs.openstack.org/52/372552/7/check/gate-neutron- python34/e7b00a0/testr_results.html.gz Traceback (most recent call last): File "/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/extensions/test_address_scope.py", line 132, in setUp super(TestAddressScope, self).setUp(plugin=plugin, ext_mgr=ext_mgr) File "/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/db/test_db_base_plugin_v2.py", line 133, in setUp self.api = router.APIRouter() File "/home/jenkins/workspace/gate-neutron-python34/neutron/api/v2/router.py", line 76, in __init__ plugin = manager.NeutronManager.get_plugin() File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 244, in get_plugin return weakref.proxy(cls.get_instance().plugin) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 238, in get_instance cls._create_instance() File "/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/oslo_concurrency/lockutils.py", line 271, in inner return f(*args, **kwargs) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 224, in _create_instance cls._instance = cls() File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 126, in __init__ plugin_provider) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 160, in _get_plugin_instance return plugin_class() File "/home/jenkins/workspace/gate-neutron-python34/neutron/db/standardattrdescription_db.py", line 28, in __new__ for resource in standard_attr.get_standard_attr_resource_model_map(): File "/home/jenkins/workspace/gate-neutron-python34/neutron/db/standard_attr.py", line 167, in get_standard_attr_resource_model_map res=resource)) RuntimeError: Model .MyModel'> tried to register for API resource my_resource which conflicts with model .Dup'>. It happens when garbage collector has not cleaned up the offending subclasses before we call to get_standard_attr_resource_model_map. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625973/+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 1624109] Re: keystone-manage fernet_setup fails silently
Sounds this should be invalid. It picks up if the option is required or not, and prints valid output when the user id is garbage ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1624109 Title: keystone-manage fernet_setup fails silently Status in OpenStack Identity (keystone): Invalid Bug description: This from the Newton build openstack- keystone-10.0.0-0.20160905112836.816d260.el7.centos.noarch I created a /etc/keystone/fernet-keys directory with 775 permissions and tried to run keystone-manage fernet_setup: [root@newton1 fernet-keys]# keystone-manage fernet_setup usage: keystone-manage [bootstrap|credential_setup|db_sync|db_version|doctor|domain_config_upload|fernet_rotate|fernet_setup|mapping_populate|mapping_purge|mapping_engine|pki_setup|saml_idp_metadata|token_flush] fernet_setup [-h] --keystone-user KEYSTONE_USER --keystone-group KEYSTONE_GROUP keystone-manage [bootstrap|credential_setup|db_sync|db_version|doctor|domain_config_upload|fernet_rotate|fernet_setup|mapping_populate|mapping_purge|mapping_engine|pki_setup|saml_idp_metadata|token_flush] fernet_setup: error: argument --keystone-user is required Two issues, the first is that it's asking for a --keystone-user, and --keystone-group switch, which is probably not meant to be required switches for this command. If I supply some value for these switches, the command executes but does nothing (does not generate startup keys in the directory). I am unable to testout fernet tokens. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1624109/+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 1626312] [NEW] "Detach Volume" is unlocalized Project > Instances action menu, window title and button
Public bug reported: openstack_dashboard/dashboards/project/instances/tables.py:937 openstack_dashboard/dashboards/project/instances/views.py:489 openstack_dashboard/dashboards/project/instances/views.py:491 The string "Detach Volume" is unlocalized in 3 places: 1. Action menu 2. Window title 3. Action button in the window The same text appears in Manager Attachments on the Volumes tab is localized (openstack_dashboard/dashboards/project/volumes/volumes/tables.py:521) ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Unlocalized_DetachVolumeMenu.png" https://bugs.launchpad.net/bugs/1626312/+attachment/4745723/+files/Unlocalized_DetachVolumeMenu.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/1626312 Title: "Detach Volume" is unlocalized Project > Instances action menu, window title and button Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/dashboards/project/instances/tables.py:937 openstack_dashboard/dashboards/project/instances/views.py:489 openstack_dashboard/dashboards/project/instances/views.py:491 The string "Detach Volume" is unlocalized in 3 places: 1. Action menu 2. Window title 3. Action button in the window The same text appears in Manager Attachments on the Volumes tab is localized (openstack_dashboard/dashboards/project/volumes/volumes/tables.py:521) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626312/+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 1626310] [NEW] Truncated tooltip Japanese text found in Create Volume Type dialog
Public bug reported: openstack_dashboard/dashboards/admin/volumes/volume_types/forms The following tooltip text in Japanese, which is located at "Public" checkbox is truncated, unable to read the entire message: デフォルトでは、ボリューム種別はパブリックで作成されます。プライベートなボリューム種別を作成するには、このフィールドのチェックを外してください。 (English source) By default, volume type is created as public. To create a private volume type, uncheck this field. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "TruncatedText_CreateVolumeType.png" https://bugs.launchpad.net/bugs/1626310/+attachment/4745722/+files/TruncatedText_CreateVolumeType.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/1626310 Title: Truncated tooltip Japanese text found in Create Volume Type dialog Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/dashboards/admin/volumes/volume_types/forms The following tooltip text in Japanese, which is located at "Public" checkbox is truncated, unable to read the entire message: デフォルトでは、ボリューム種別はパブリックで作成されます。プライベートなボリューム種別を作成するには、このフィールドのチェックを外してください。 (English source) By default, volume type is created as public. To create a private volume type, uncheck this field. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626310/+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 1626306] [NEW] Unlocalized button label and text found in Configuration tab in Launch Instance dialog
Public bug reported: Project > Instances > Launch Instance > Configuration Found unlocalized the following GUI button label and text on Configuration tab in Launch Instance dialog: Choose File No file chosen ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "UnlocalizedString_LaunchInstance_Configuration.png" https://bugs.launchpad.net/bugs/1626306/+attachment/4745719/+files/UnlocalizedString_LaunchInstance_Configuration.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/1626306 Title: Unlocalized button label and text found in Configuration tab in Launch Instance dialog Status in OpenStack Dashboard (Horizon): New Bug description: Project > Instances > Launch Instance > Configuration Found unlocalized the following GUI button label and text on Configuration tab in Launch Instance dialog: Choose File No file chosen To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626306/+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 1626307] [NEW] Unlocalized text found on Metadata tab on Metadata tab in Create Image dialog
Public bug reported: Project > Images > Create Image > Metadata Metadata item names and description including nested items are shown unlocalized and cannot be located in Zanata. Might be related to https://bugs.launchpad.net/horizon/+bug/1626303 ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Unlocalized_CreateImage_ImageMetaData.png" https://bugs.launchpad.net/bugs/1626307/+attachment/4745721/+files/Unlocalized_CreateImage_ImageMetaData.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/1626307 Title: Unlocalized text found on Metadata tab on Metadata tab in Create Image dialog Status in OpenStack Dashboard (Horizon): New Bug description: Project > Images > Create Image > Metadata Metadata item names and description including nested items are shown unlocalized and cannot be located in Zanata. Might be related to https://bugs.launchpad.net/horizon/+bug/1626303 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626307/+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 1611171] Re: re-runs self via sudo
Consensus seems to confirm Tristan's observation this meets the VMT's
class D report (security hardening) definition, so I'm marking our
advisory task Won't Fix and annotating the bug status and tags
accordingly. If the situation is discovered to be explicitly vulnerable
after all, we can revisit it at that time.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Information type changed from Public Security to Public
** Tags added: security
--
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/1611171
Title:
re-runs self via sudo
Status in Cinder:
In Progress
Status in Designate:
In Progress
Status in ec2-api:
In Progress
Status in gce-api:
In Progress
Status in Manila:
In Progress
Status in masakari:
Fix Released
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Status in Rally:
In Progress
Bug description:
Hello, I'm looking through Designate source code to determine if is
appropriate to include in Ubuntu Main. This isn't a full security
audit.
This looks like trouble:
./designate/cmd/manage.py
def main():
CONF.register_cli_opt(category_opt)
try:
utils.read_config('designate', sys.argv)
logging.setup(CONF, 'designate')
except cfg.ConfigFilesNotFoundError:
cfgfile = CONF.config_file[-1] if CONF.config_file else None
if cfgfile and not os.access(cfgfile, os.R_OK):
st = os.stat(cfgfile)
print(_("Could not read %s. Re-running with sudo") % cfgfile)
try:
os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] +
sys.argv)
except Exception:
print(_('sudo failed, continuing as if nothing happened'))
print(_('Please re-run designate-manage as root.'))
sys.exit(2)
This is an interesting decision -- if the configuration file is _not_
readable by the user in question, give the executing user complete privileges
of the user that owns the unreadable file.
I'm not a fan of hiding privilege escalation / modifications in
programs -- if a user had recently used sudo and thus had the
authentication token already stored for their terminal, this 'hidden'
use of sudo may be unexpected and unwelcome, especially since it
appears that argv from the first call leaks through to the sudo call.
Is this intentional OpenStack style? Or unexpected for you guys too?
(Feel free to make this public at your convenience.)
Thanks
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+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 1626298] Re: Out of tree drivers fail to run hacking checks now
** Changed in: neutron Status: In Progress => Invalid ** Changed in: neutron Assignee: Eric Fried (efried) => (unassigned) ** Changed in: networking-powervm Status: New => Confirmed ** No longer affects: neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1626298 Title: Out of tree drivers fail to run hacking checks now Status in networking-powervm: Confirmed Bug description: This change recently went in to the neutron hacking checks: https://github.com/openstack/neutron/commit/31e1aeb66b2d8abb0d8424e9550693fad6f37c1c While this serves the purpose of not allowing functional tests from within neturon to extend unit test functions, it blocks out of tree neutron drivers/ml2 agents from importing the neutron unit tests within their own unit tests. Out of tree drivers/ml2 agents are no longer able to run the hacking checks that they extend from neutron against their own source tree - or they have to explicitly exclude the check_no_imports_from_tests rule. Neutron Code: https://github.com/openstack/neutron/blame/master/neutron/hacking/checks.py#L390-L403 Example of broken check (PowerVM): https://github.com/openstack /networking- powervm/blob/master/networking_powervm/hacking/checks.py#L45 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-powervm/+bug/1626298/+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 1626302] [NEW] Boot source description in the Launch Instance dialog is missing the Volume Snapshot option
Public bug reported: openstack_dashboard/dashboards/project/static/dashboard/project/workflow /launch-instance/source/source.html The following description text which appears on the Source tab in the Launch Instance dialog is missing the Volume Snapshot option, that is actually available under the dropdown list. Instance source is the template used to create an instance. You can use a snapshot of an existing instance, an image, or a volume (if enabled). You can also choose to use persistent storage by creating a new volume. ** 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/1626302 Title: Boot source description in the Launch Instance dialog is missing the Volume Snapshot option Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/dashboards/project/static/dashboard/project/workflow /launch-instance/source/source.html The following description text which appears on the Source tab in the Launch Instance dialog is missing the Volume Snapshot option, that is actually available under the dropdown list. Instance source is the template used to create an instance. You can use a snapshot of an existing instance, an image, or a volume (if enabled). You can also choose to use persistent storage by creating a new volume. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626302/+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 1626303] [NEW] Unlocalized text found on Metadata tab in the Launch Instance dialog
Public bug reported: Project > Instances > Launch Instance > Metadata Metadata item names and description including nested items are shown unlocalized and cannot be located in Zanata. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "UnlocalizedDescriptions_LaunchInstance_MetadataTab.png" https://bugs.launchpad.net/bugs/1626303/+attachment/4745714/+files/UnlocalizedDescriptions_LaunchInstance_MetadataTab.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/1626303 Title: Unlocalized text found on Metadata tab in the Launch Instance dialog Status in OpenStack Dashboard (Horizon): New Bug description: Project > Instances > Launch Instance > Metadata Metadata item names and description including nested items are shown unlocalized and cannot be located in Zanata. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626303/+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 1626298] [NEW] Out of tree drivers fail to run hacking checks now
Public bug reported: This change recently went in to the neutron hacking checks: https://github.com/openstack/neutron/commit/31e1aeb66b2d8abb0d8424e9550693fad6f37c1c While this serves the purpose of not allowing functional tests from within neturon to extend unit test functions, it blocks out of tree neutron drivers/ml2 agents from importing the neutron unit tests within their own unit tests. Out of tree drivers/ml2 agents are no longer able to run the hacking checks that they extend from neutron against their own source tree - or they have to explicitly exclude the check_no_imports_from_tests rule. Neutron Code: https://github.com/openstack/neutron/blame/master/neutron/hacking/checks.py#L390-L403 Example of broken check (PowerVM): https://github.com/openstack /networking-powervm/blob/master/networking_powervm/hacking/checks.py#L45 ** Affects: networking-powervm Importance: Undecided Status: New ** Affects: neutron Importance: Undecided Status: New ** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1626298 Title: Out of tree drivers fail to run hacking checks now Status in networking-powervm: New Status in neutron: New Bug description: This change recently went in to the neutron hacking checks: https://github.com/openstack/neutron/commit/31e1aeb66b2d8abb0d8424e9550693fad6f37c1c While this serves the purpose of not allowing functional tests from within neturon to extend unit test functions, it blocks out of tree neutron drivers/ml2 agents from importing the neutron unit tests within their own unit tests. Out of tree drivers/ml2 agents are no longer able to run the hacking checks that they extend from neutron against their own source tree - or they have to explicitly exclude the check_no_imports_from_tests rule. Neutron Code: https://github.com/openstack/neutron/blame/master/neutron/hacking/checks.py#L390-L403 Example of broken check (PowerVM): https://github.com/openstack /networking- powervm/blob/master/networking_powervm/hacking/checks.py#L45 To manage notifications about this bug go to: https://bugs.launchpad.net/networking-powervm/+bug/1626298/+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 1626292] [NEW] Horizon gate failed with connection refused
Public bug reported: Horizon gate gate-horizon-dsvm-integration-deprecated-ubuntu-xenial failed with connection refused. Console log: http://logs.openstack.org/17/374317/2/check/gate-horizon- dsvm-integration-deprecated-ubuntu-xenial/ecbbe3d/console.html 2016-09-21 21:16:04.335905 | 2016-09-21 21:16:04.335 | ERROR: openstack_dashboard.test.integration_tests.tests.test_volumes.TestVolumesActions.test_volume_launch_as_instance 2016-09-21 21:16:04.337476 | 2016-09-21 21:16:04.337 | -- 2016-09-21 21:16:04.339203 | 2016-09-21 21:16:04.338 | _StringException: Traceback (most recent call last): 2016-09-21 21:16:04.341388 | 2016-09-21 21:16:04.340 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_volumes.py", line 230, in setUp 2016-09-21 21:16:04.343492 | 2016-09-21 21:16:04.342 | super(TestVolumesActions, self).setUp() 2016-09-21 21:16:04.345331 | 2016-09-21 21:16:04.344 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py", line 299, in setUp 2016-09-21 21:16:04.347271 | 2016-09-21 21:16:04.346 | super(TestCase, self).setUp() 2016-09-21 21:16:04.348897 | 2016-09-21 21:16:04.348 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/helpers.py", line 162, in setUp 2016-09-21 21:16:04.350506 | 2016-09-21 21:16:04.349 | desired_capabilities=desired_capabilities 2016-09-21 21:16:04.352357 | 2016-09-21 21:16:04.351 | File "/opt/stack/new/horizon/horizon/test/firefox_binary.py", line 74, in __init__ 2016-09-21 21:16:04.355746 | 2016-09-21 21:16:04.355 | desired_capabilities, proxy) 2016-09-21 21:16:04.358357 | 2016-09-21 21:16:04.357 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/firefox/webdriver.py", line 85, in __init__ 2016-09-21 21:16:04.361330 | 2016-09-21 21:16:04.361 | keep_alive=True) 2016-09-21 21:16:04.366289 | 2016-09-21 21:16:04.365 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 90, in __init__ 2016-09-21 21:16:04.368827 | 2016-09-21 21:16:04.368 | self.start_session(desired_capabilities, browser_profile) 2016-09-21 21:16:04.370617 | 2016-09-21 21:16:04.370 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 177, in start_session 2016-09-21 21:16:04.372788 | 2016-09-21 21:16:04.372 | response = self.execute(Command.NEW_SESSION, capabilities) 2016-09-21 21:16:04.374632 | 2016-09-21 21:16:04.374 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 234, in execute 2016-09-21 21:16:04.376447 | 2016-09-21 21:16:04.376 | response = self.command_executor.execute(driver_command, params) 2016-09-21 21:16:04.382014 | 2016-09-21 21:16:04.379 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py", line 401, in execute 2016-09-21 21:16:04.384349 | 2016-09-21 21:16:04.384 | return self._request(command_info[0], url, body=data) 2016-09-21 21:16:04.386332 | 2016-09-21 21:16:04.386 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py", line 432, in _request 2016-09-21 21:16:04.388404 | 2016-09-21 21:16:04.388 | self._conn.request(method, parsed_url.path, body, headers) 2016-09-21 21:16:04.390058 | 2016-09-21 21:16:04.389 | File "/usr/lib/python2.7/httplib.py", line 1057, in request 2016-09-21 21:16:04.392109 | 2016-09-21 21:16:04.391 | self._send_request(method, url, body, headers) 2016-09-21 21:16:04.393841 | 2016-09-21 21:16:04.393 | File "/usr/lib/python2.7/httplib.py", line 1097, in _send_request 2016-09-21 21:16:04.396391 | 2016-09-21 21:16:04.396 | self.endheaders(body) 2016-09-21 21:16:04.398035 | 2016-09-21 21:16:04.397 | File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders 2016-09-21 21:16:04.399777 | 2016-09-21 21:16:04.399 | self._send_output(message_body) 2016-09-21 21:16:04.401536 | 2016-09-21 21:16:04.401 | File "/usr/lib/python2.7/httplib.py", line 897, in _send_output 2016-09-21 21:16:04.404163 | 2016-09-21 21:16:04.402 | self.send(msg) 2016-09-21 21:16:04.406033 | 2016-09-21 21:16:04.405 | File "/usr/lib/python2.7/httplib.py", line 859, in send 2016-09-21 21:16:04.408328 | 2016-09-21 21:16:04.407 | self.connect() 2016-09-21 21:16:04.412046 | 2016-09-21 21:16:04.410 | File "/usr/lib/python2.7/httplib.py", line 836, in connect 2016-09-21 21:16:04.414167 | 2016-09-21 21:16:04.413 | self.timeout, self.source_address) 2016-09-21 21:16:04.416083 | 2016-09-21 21:16:04.415 | File "/usr/lib/python2.7/socket.py", line 575, in create_connection 2016-09-21 21:16:
[Yahoo-eng-team] [Bug 1626277] [NEW] DB migration tests are timing out
Public bug reported: Tests involving database migrations are timing out. This may be related to http://lists.openstack.org/pipermail/openstack-dev/2016-September/103664.html ** Affects: neutron Importance: Critical Assignee: Henry Gessau (gessau) Status: In Progress ** Tags: db functional-tests gate-failure newton-rc-potential ** Tags added: db functional-tests gate-failure ** Changed in: neutron Importance: Undecided => Critical ** Changed in: neutron Assignee: (unassigned) => Henry Gessau (gessau) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1626277 Title: DB migration tests are timing out Status in neutron: In Progress Bug description: Tests involving database migrations are timing out. This may be related to http://lists.openstack.org/pipermail/openstack-dev/2016-September/103664.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1626277/+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 1625322] Re: nova newton specs docs link to sections of live-migrate-rescued-instances spec
Reviewed: https://review.openstack.org/372710 Committed: https://git.openstack.org/cgit/openstack/nova-specs/commit/?id=bb91981b9c6fe0e8bcbd28aac138e357f4851f52 Submitter: Jenkins Branch:master commit bb91981b9c6fe0e8bcbd28aac138e357f4851f52 Author: Matt Riedemann Date: Mon Sep 19 15:09:01 2016 -0400 Fix live-migrate-rescued-instances title formatting Because this spec didn't have a title it messed up the links in the specs/newton/approved list in the docs. Change-Id: I8a630592eecce88709d3adf35573911e0bdb3c1f Closes-Bug: #1625322 ** 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/1625322 Title: nova newton specs docs link to sections of live-migrate-rescued- instances spec Status in OpenStack Compute (nova): Fix Released Bug description: If you look at the approved newton specs: https://specs.openstack.org/openstack/nova- specs/specs/newton/index.html You'll see some called "Problem description" and "Proposed change". These are linked from: https://specs.openstack.org/openstack/nova-specs/specs/newton/approved /live-migrate-rescued-instances.html Looks like something got messed up with the formatting in that spec which bleeds into the listing of the approved specs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1625322/+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 parameter enforce_type=True by default
** No longer affects: gnocchi -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1517839 Title: Make CONF.set_override with parameter enforce_type=True by default Status in Aodh: In Progress Status in Ceilometer: In Progress Status in Cinder: In Progress Status in cloudkitty: Fix Released Status in Designate: Fix Released Status in Freezer: In Progress Status in Glance: Invalid Status in glance_store: In Progress Status in heat: Fix Released Status in Ironic: Triaged Status in Karbor: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in kolla: New Status in Magnum: In Progress Status in Manila: Fix Released Status in Murano: Fix Released Status in neutron: Won't Fix Status in OpenStack Compute (nova): Fix Released Status in octavia: New Status in oslo.config: In Progress Status in oslo.messaging: Fix Released Status in Quark: Money Reinvented: New Status in Rally: Fix Released Status in senlin: New Status in tacker: In Progress Status in watcher: Fix Released 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. [1] https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173 2. Proposal 1) Fix violations when enforce_type=True in each project. 2) Make method CONF.set_override with enforce_type=True by default in oslo_config You can find more details and comments in https://etherpad.openstack.org/p/enforce_type_true_by_default 3. How to find violations in your projects. 1. Run tox -e py27 2. then modify oslo.config with enforce_type=True cd .tox/py27/lib64/python2.7/site-packages/oslo_config edit cfg.py with enforce_type=True -def set_override(self, name, override, group=None, enforce_type=False): +def set_override(self, name, override, group=None, enforce_type=True): 3. Run tox -e py27 again, you will find violations. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+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 1626216] Re: unable to retrieve nova info
** Also 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/1626216 Title: unable to retrieve nova info Status in OpenStack Dashboard (Horizon): New Status in OpenStack Compute (nova): New Bug description: Horizon reports error: unable to retrieve flavors list, among other errors whenever nova related information is accessed. The problem occurs immediately on a fresh devstack install at the latest versions: devstack: commit 81d89cf3584a5edadbaa2514305cf5721b29cdff horizon: commit 877344de0d9e62c8cf24c9e3ab21f994b2b43b05; Merge: 35fdc05 2fec0a1 nova: commit 4cc5ef121f262b8990274b60404457a62fc9778c; Merge: c7bf2ba e843628 Horizon log file attached. Excerpt: 2016-09-21 06:22:04.897365 Call to list supported extensions failed. This is likely due to a problem communicating with the Nova endpoint. Host Aggregates panel will not be displayed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626216/+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 1626243] [NEW] Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive
Public bug reported:
The symptom is similar to 1611074 but the cause is different. In this
case it seems there is an error accessing /dev/sdb1 when lsblk is run,
possibly because sgdisk isn't done creating the partition. The specific
error message is "/dev/sdb1: not a block device." A simple wait and
retry here may resolve the issue.
util.py[DEBUG]: Running command ['/sbin/sgdisk', '-p', '/dev/sdb'] with allowed
return codes [0] (shell=False, capture=True)
cc_disk_setup.py[DEBUG]: Device partitioning layout matches
util.py[DEBUG]: Creating partition on /dev/disk/cloud/azure_resource took 0.056
seconds
cc_disk_setup.py[DEBUG]: setting up filesystems: [{'filesystem': 'ext4',
'device': 'ephemeral0.1', 'replace_fs': 'ntfs'}]
cc_disk_setup.py[DEBUG]: ephemeral0.1 is mapped to
disk=/dev/disk/cloud/azure_resource part=1
cc_disk_setup.py[DEBUG]: Creating new filesystem.
cc_disk_setup.py[DEBUG]: Checking /dev/sdb against default devices
cc_disk_setup.py[DEBUG]: Manual request of partition 1 for /dev/sdb1
cc_disk_setup.py[DEBUG]: Checking device /dev/sdb1
util.py[DEBUG]: Running command ['/sbin/blkid', '-c', '/dev/null', '/dev/sdb1']
with allowed return codes [0, 2] (shell=False, capture=True)
cc_disk_setup.py[DEBUG]: Device /dev/sdb1 has None None
cc_disk_setup.py[DEBUG]: Device /dev/sdb1 is cleared for formating
cc_disk_setup.py[DEBUG]: File system None will be created on /dev/sdb1
util.py[DEBUG]: Running command ['/bin/lsblk', '--pairs', '--output',
'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', '--nodeps'] with allowed return codes
[0] (shell=False, capture=True)
util.py[DEBUG]: Creating fs for /dev/disk/cloud/azure_resource took 0.008
seconds
util.py[WARNING]: Failed during filesystem operation#012Failed during disk
check for /dev/sdb1#012Unexpected error while running command.#012Command:
['/bin/lsblk', '--pairs', '--output', 'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1',
'--nodeps']#012Exit code: 32#012Reason: -#012Stdout: ''#012Stderr: 'lsblk:
/dev/sdb1: not a block device\n'
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1626243
Title:
Cloud-init fails to write ext4 filesystem to Azure Ephemeral Drive
Status in cloud-init:
New
Bug description:
The symptom is similar to 1611074 but the cause is different. In this
case it seems there is an error accessing /dev/sdb1 when lsblk is run,
possibly because sgdisk isn't done creating the partition. The
specific error message is "/dev/sdb1: not a block device." A simple
wait and retry here may resolve the issue.
util.py[DEBUG]: Running command ['/sbin/sgdisk', '-p', '/dev/sdb'] with
allowed return codes [0] (shell=False, capture=True)
cc_disk_setup.py[DEBUG]: Device partitioning layout matches
util.py[DEBUG]: Creating partition on /dev/disk/cloud/azure_resource took
0.056 seconds
cc_disk_setup.py[DEBUG]: setting up filesystems: [{'filesystem': 'ext4',
'device': 'ephemeral0.1', 'replace_fs': 'ntfs'}]
cc_disk_setup.py[DEBUG]: ephemeral0.1 is mapped to
disk=/dev/disk/cloud/azure_resource part=1
cc_disk_setup.py[DEBUG]: Creating new filesystem.
cc_disk_setup.py[DEBUG]: Checking /dev/sdb against default devices
cc_disk_setup.py[DEBUG]: Manual request of partition 1 for /dev/sdb1
cc_disk_setup.py[DEBUG]: Checking device /dev/sdb1
util.py[DEBUG]: Running command ['/sbin/blkid', '-c', '/dev/null',
'/dev/sdb1'] with allowed return codes [0, 2] (shell=False, capture=True)
cc_disk_setup.py[DEBUG]: Device /dev/sdb1 has None None
cc_disk_setup.py[DEBUG]: Device /dev/sdb1 is cleared for formating
cc_disk_setup.py[DEBUG]: File system None will be created on /dev/sdb1
util.py[DEBUG]: Running command ['/bin/lsblk', '--pairs', '--output',
'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1', '--nodeps'] with allowed return codes
[0] (shell=False, capture=True)
util.py[DEBUG]: Creating fs for /dev/disk/cloud/azure_resource took 0.008
seconds
util.py[WARNING]: Failed during filesystem operation#012Failed during disk
check for /dev/sdb1#012Unexpected error while running command.#012Command:
['/bin/lsblk', '--pairs', '--output', 'NAME,TYPE,FSTYPE,LABEL', '/dev/sdb1',
'--nodeps']#012Exit code: 32#012Reason: -#012Stdout: ''#012Stderr: 'lsblk:
/dev/sdb1: not a block device\n'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1626243/+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 1613542] Re: tempest.conf doesn't contain $project in [service_available] section
** Changed in: gnocchi
Status: Fix Committed => Fix Released
** Changed in: gnocchi
Milestone: None => 3.0.0
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1613542
Title:
tempest.conf doesn't contain $project in [service_available] section
Status in Aodh:
Fix Released
Status in Ceilometer:
Fix Released
Status in ec2-api:
Fix Released
Status in Gnocchi:
Fix Released
Status in Ironic:
In Progress
Status in Ironic Inspector:
Fix Released
Status in OpenStack Identity (keystone):
Invalid
Status in Magnum:
Fix Released
Status in neutron:
New
Status in OpenStack Data Processing ("Sahara") sahara-tests:
Fix Released
Status in senlin:
In Progress
Status in Vitrage:
In Progress
Status in vmware-nsx:
Fix Released
Bug description:
When generating the tempest conf, the tempest plugins need to register the
config options.
But for the [service_available] section, ceilometer (and the other mentioned
projects) doesn't register any value so it's missng in the tempest sample
config.
Steps to reproduce:
$ tox -egenconfig
$ source .tox/genconfig/bin/activate
$ oslo-config-generator --config-file
.tox/genconfig/lib/python2.7/site-packages/tempest/cmd/config-generator.tempest.conf
--output-file tempest.conf.sample
Now check the [service_available] section from tempest.conf.sample
To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1613542/+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 1626230] [NEW] evacuate leaves instance on target compute node if it fails to spawn
Public bug reported: When an instance is evacuated an attempt to rebuild it on a different host is made. If the instance spawn method in the libvirt driver (probably true for other drivers too) fails and raises and exception then the instance is placed in an error state. However the instance is still recorded a being on the source node but depending on how far through the spawn instance related files will be present and the instance may be running on the target. In the case where compute nodes do not use shared storage a subsequent attempt to evacuate the instance to the same target will fail because the instance directory is already present. The use of reset-state and then evacuate to another node will enable the successful evacuation of the instance. However the 'orphaned' files and running instance on the original target will need to be cleaned up manually. I'd recommend we update the instance's host once the claim is complete on the target. In this case in the event of a failure to spawn it will effectively have evacuated so the files on the original host will be cleaned up when that node is restored. ** 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/1626230 Title: evacuate leaves instance on target compute node if it fails to spawn Status in OpenStack Compute (nova): New Bug description: When an instance is evacuated an attempt to rebuild it on a different host is made. If the instance spawn method in the libvirt driver (probably true for other drivers too) fails and raises and exception then the instance is placed in an error state. However the instance is still recorded a being on the source node but depending on how far through the spawn instance related files will be present and the instance may be running on the target. In the case where compute nodes do not use shared storage a subsequent attempt to evacuate the instance to the same target will fail because the instance directory is already present. The use of reset-state and then evacuate to another node will enable the successful evacuation of the instance. However the 'orphaned' files and running instance on the original target will need to be cleaned up manually. I'd recommend we update the instance's host once the claim is complete on the target. In this case in the event of a failure to spawn it will effectively have evacuated so the files on the original host will be cleaned up when that node is restored. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1626230/+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 1616424] Re: Keystone OAuth1 doesn't handle invalid request properly
Reviewed: https://review.openstack.org/359795
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=be5385c5389aa9c4879647c9b9e4327cc73189a2
Submitter: Jenkins
Branch:master
commit be5385c5389aa9c4879647c9b9e4327cc73189a2
Author: Dave Chen
Date: Wed Aug 24 18:54:14 2016 +0800
Handle the exception from creating access token properly
If there is any request from client with any invalid request
parameters, invalid signature for example, keystone should
capture that and raise the exception.
It was `NotImplementedError`, `TypeError` thrown out and
presented directly to end user, and nothing helpful message
is given.
This patch fix that and show as many exception message that
is helpful for diagnosis as possible.
Change-Id: I112d0cd0c8a460c7b4d8d0e1c0b9c742aab9fde7
Closes-Bug: #1616424
** Changed in: keystone
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/1616424
Title:
Keystone OAuth1 doesn't handle invalid request properly
Status in OpenStack Identity (keystone):
Fix Released
Bug description:
For the access token request,
- If the signature is not valid, it will raise TypeError exception.
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi File
"./keystone/common/wsgi.py", line 227, in __call__
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result =
method(req, **params)
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi File
"./keystone/oauth1/controllers.py", line 309, in create_access_token
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params =
oauth1.extract_non_oauth_params(b)
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi File
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for
k, v in params if not k.startswith('oauth_')}
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType'
object is not iterable
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi
- If the provided consumer does not exist, it will throw
NotImplementedError exception to show that dummy_client is not
implemented.
All these exception is not properly handled, end user doens't know
anything from these exception message. It should be Unauthorized
exception raised.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1616424/+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 1625557] Re: Concurrent security groups creation fails with DBDuplicateEntry
Reviewed: https://review.openstack.org/373841 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=09d1185d24c30690358a9314c14fabaead2f4c78 Submitter: Jenkins Branch:master commit 09d1185d24c30690358a9314c14fabaead2f4c78 Author: Oleg Bondarev Date: Wed Sep 21 10:36:05 2016 +0300 Do not retry default security group creation No need to retry creation of a default security group - it will always fail with DBDuplicate. The patch opens a transaction before calling to create_security_group() when creating default security group, thus avoiding db retries. Closes-Bug: #1625557 Change-Id: Id15b55b097641325ac68275fe4bb3ebe93718cdd ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625557 Title: Concurrent security groups creation fails with DBDuplicateEntry Status in neutron: Fix Released Bug description: - create_security_group() is wrapped with a db retry decorator - it calls _ensure_default_security_group() to create a default security group for a tenant if one does not exist - _ensure_default_security_group() in turn calls back to create_security_group() to create a default security group - due to concurrency the creation of default security group my fail with DBDuplicateEntry - this is retried for max attempts and the request eventually fails Traceback: http://paste.openstack.org/show/581903/ Example of failed job in rally: http://logs.openstack.org/04/371604/1/check/gate-rally-dsvm-neutron-rally/b1c384d/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625557/+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 1625660] Re: Volume detach is broken when using volume-update first
** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Status: New => In Progress ** Changed in: nova/newton Importance: Undecided => High ** Changed in: nova/newton Assignee: (unassigned) => Matt Riedemann (mriedem) -- 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/1625660 Title: Volume detach is broken when using volume-update first Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Bug description: https://bugs.launchpad.net/nova/+bug/1490236 was focusing on correcting the volume-update API so that it was idempotent. Unfortunately, the merged solution is introducing a huge regression by incorrectly providing the old volume ID as the new attachment information. https://github.com/openstack/nova/commit/be553fb15591c6fc212ef3a07c1dd1cbc43d6866 Consequently, it's now impossible for an end-user to detach a volume if some operator updated the BDM to point to a different volume. Evidence here: http://paste.openstack.org/show/582248/ What's unfortunate is that the original bug is about to be worked around by just detaching/attaching the volume to the instance before swapping back... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1625660/+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 1626132] Re: IPv6 Prefix delegation: dibbler.filters rootwrap file is not installed
Reviewed: https://review.openstack.org/374197 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d1389dcc4b622ab670c37c290a594665fab222cb Submitter: Jenkins Branch:master commit d1389dcc4b622ab670c37c290a594665fab222cb Author: Bernard Cafarelli Date: Wed Sep 21 16:24:39 2016 +0200 Install dibbler.filters rootwrap file This file was added in https://review.openstack.org/#/c/185977, but was not listed in setup.cfg As a consequence, it is not installed in current RDO packages Closes-Bug: #1626132 Change-Id: I1b87d89367ab534164394f9f18e81223ff4111ce ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1626132 Title: IPv6 Prefix delegation: dibbler.filters rootwrap file is not installed Status in neutron: Fix Released Bug description: This file was added in https://review.openstack.org/#/c/185977, but was not listed in setup.cfg As a consequence, it is not installed in current RDO packages: https://bugzilla.redhat.com/show_bug.cgi?id=1377622 Without the file, dibbler-client will not start properly on these installations, so IPv6 Prefix delegation does not work To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1626132/+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 1602081] Re: Use oslo.context's policy dict
Reviewed: https://review.openstack.org/341905 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=304bc201c004d549de408c75cfe731eb65fde78d Submitter: Jenkins Branch:master commit 304bc201c004d549de408c75cfe731eb65fde78d Author: Adam Young Date: Mon Sep 12 21:39:45 2016 -0400 Use to_policy_values for policy credentials The base oslo.context defines to_policy_values with all the information that it expects a service to require to enforce policy. Use that instead of throwing everything in to_dict at policy enforcement. Change-Id: I0a42b4425e9dd1bd062c48792c4d116dd370afe3 Closes-Bug: #1602081 ** 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 neutron. https://bugs.launchpad.net/bugs/1602081 Title: Use oslo.context's policy dict Status in Cinder: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Identity (keystone): New Status in neutron: In Progress Status in OpenStack Compute (nova): Fix Released Bug description: This is a cross project goal to standardize the values available to policy writers and to improve the basic oslo.context object. It is part of the follow up work to bug #1577996 and bug #968696. There has been an ongoing problem for how we define the 'admin' role. Because tokens are project scoped having the 'admin' role on any project granted you the 'admin' role on all of OpenStack. As a solution to this keystone defined an is_admin_project field so that keystone defines a single project that your token must be scoped to to perform admin operations. This has been implemented. The next phase of this is to make all the projects understand the X -Is-Admin-Project header from keystonemiddleware and pass it to oslo_policy. However this pattern of keystone changes something and then goes to every project to fix it has been repeated a number of times now and we would like to make it much more automatic. Ongoing work has enhanced the base oslo.context object to include both the load_from_environ and to_policy_values methods. The load_from_environ classmethod takes an environment dict with all the standard auth_token and oslo middleware headers and loads them into their standard place on the context object. The to_policy_values() then creates a standard credentials dictionary with all the information that should be required to enforce policy from the context. The combination of these two methods means in future when authentication information needs to be passed to policy it can be handled entirely by oslo.context and does not require changes in each individual service. Note that in future a similar pattern will hopefully be employed to simplify passing authentication information over RPC to solve the timeout issues. This is a prerequisite for that work. There are a few common problems in services that are required to make this work: 1. Most service context.__init__ functions take and discard **kwargs. This is so if the context.from_dict receives arguments it doesn't know how to handle (possibly because new things have been added to the base to_dict) it ignores them. Unfortunately to make the load_from_environ method work we need to pass parameters to __init__ that are handled by the base class. To make this work we simply have to do a better job of using from_dict. Instead of passing everything to __init__ and ignoring what we don't know we have from_dict extract only the parameters that context knows how to use and call __init__ with those. 2. The parameters passed to the base context.__init__ are old. Typically they are user and tenant where most services expect user_id and project_id. There is ongoing work to improve this in oslo.context but for now we have to ensure that the subclass correctly sets and uses the right variable names. 3. Some services provide additional information to the policy enforcement method. To continue to make this function we will simply override the to_policy_values method in the subclasses. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1602081/+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 1626216] [NEW] unable to retrieve nova info
Public bug reported: Horizon reports error: unable to retrieve flavors list, among other errors whenever nova related information is accessed. The problem occurs immediately on a fresh devstack install at the latest versions: devstack: commit 81d89cf3584a5edadbaa2514305cf5721b29cdff horizon: commit 877344de0d9e62c8cf24c9e3ab21f994b2b43b05; Merge: 35fdc05 2fec0a1 nova: commit 4cc5ef121f262b8990274b60404457a62fc9778c; Merge: c7bf2ba e843628 Horizon log file attached. Excerpt: 2016-09-21 06:22:04.897365 Call to list supported extensions failed. This is likely due to a problem communicating with the Nova endpoint. Host Aggregates panel will not be displayed. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "horizon_nova_log.TXT" https://bugs.launchpad.net/bugs/1626216/+attachment/4745558/+files/horizon_nova_log.TXT -- 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/1626216 Title: unable to retrieve nova info Status in OpenStack Dashboard (Horizon): New Bug description: Horizon reports error: unable to retrieve flavors list, among other errors whenever nova related information is accessed. The problem occurs immediately on a fresh devstack install at the latest versions: devstack: commit 81d89cf3584a5edadbaa2514305cf5721b29cdff horizon: commit 877344de0d9e62c8cf24c9e3ab21f994b2b43b05; Merge: 35fdc05 2fec0a1 nova: commit 4cc5ef121f262b8990274b60404457a62fc9778c; Merge: c7bf2ba e843628 Horizon log file attached. Excerpt: 2016-09-21 06:22:04.897365 Call to list supported extensions failed. This is likely due to a problem communicating with the Nova endpoint. Host Aggregates panel will not be displayed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626216/+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 1626210] [NEW] Inconsistent name set for BatchAction
Public bug reported: The name attribute for BatchAction should be a slug for the action. This attribute is used as part of the id of the action button so it's useful to have a consistent naming convention for custom styling. Most of the subclasses of BatchAction already have one word as the name the rest should be consistent. ** Affects: horizon Importance: Undecided Assignee: Ying Zuo (yingzuo) Status: New ** Changed in: horizon Assignee: (unassigned) => Ying Zuo (yingzuo) -- 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/1626210 Title: Inconsistent name set for BatchAction Status in OpenStack Dashboard (Horizon): New Bug description: The name attribute for BatchAction should be a slug for the action. This attribute is used as part of the id of the action button so it's useful to have a consistent naming convention for custom styling. Most of the subclasses of BatchAction already have one word as the name the rest should be consistent. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626210/+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 1626205] [NEW] increase token validation performance relating to revoked tokens
Public bug reported: Currently, there is are two methods called is_revoke and matches that iterate over all revoked events one by one and then further iterate over every field, one by one until it can either short circuit by not matching one value in the event to the passed in token, or until it has matched all fields of non-empty values in the revocation event to the corresponding fields in the given token. In most cases, the token is not revoked and it will iterate over the entire list of revocations. As the list gets longer, validation becomes slower. You start to see big performance issues around 1500+ revocation entries. It would be nice to directly query the database using sql instead of pulling all the revocation events down, deserializing them, and then iterating over each one in python. ** Affects: keystone Importance: Undecided Assignee: Richard (csravelar) Status: In Progress ** Tags: revoke ** Changed in: keystone Assignee: (unassigned) => Richard (csravelar) -- 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/1626205 Title: increase token validation performance relating to revoked tokens Status in OpenStack Identity (keystone): In Progress Bug description: Currently, there is are two methods called is_revoke and matches that iterate over all revoked events one by one and then further iterate over every field, one by one until it can either short circuit by not matching one value in the event to the passed in token, or until it has matched all fields of non-empty values in the revocation event to the corresponding fields in the given token. In most cases, the token is not revoked and it will iterate over the entire list of revocations. As the list gets longer, validation becomes slower. You start to see big performance issues around 1500+ revocation entries. It would be nice to directly query the database using sql instead of pulling all the revocation events down, deserializing them, and then iterating over each one in python. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1626205/+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 1618666] Re: deprecated warning for SafeConfigParser
Reviewed: https://review.openstack.org/369838 Committed: https://git.openstack.org/cgit/openstack/python-ironicclient/commit/?id=e7d88230b08689dcf904d94fc398b1e54254cb8f Submitter: Jenkins Branch:master commit e7d88230b08689dcf904d94fc398b1e54254cb8f Author: qinchunhua Date: Wed Sep 14 02:11:48 2016 -0400 Use ConfigParser instead of SafeConfigParser in Python 3 The SafeConfigParser class has been renamed to ConfigParser in Python 3.2 [1]. The alias SafeConfigParser maybe removed in future versions of Python 3. Use ConfigParser instead of SafeConfigParser in Python 3 [1] http://bugs.python.org/issue10627 Change-Id: I7b550cbd7b5d4c4fe3511c456b5f738030e07d5e Closes-Bug: #1618666 ** Changed in: python-ironicclient 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/1618666 Title: deprecated warning for SafeConfigParser Status in Glance: In Progress Status in glance_store: In Progress Status in Ironic: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in PBR: Fix Released Status in python-ironicclient: Fix Released Status in python-swiftclient: In Progress Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Status in OpenStack DBaaS (Trove): In Progress Bug description: tox -e py34 is reporting a deprecation warning for SafeConfigParser /octavia/.tox/py34/lib/python3.4/site-packages/pbr/util.py:207: DeprecationWarning: The SafeConfigParser class has been renamed to ConfigParser in Python 3.2. This alias will be removed in future versions. Use ConfigParser directly instead. parser = configparser.SafeConfigParser() To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1618666/+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 1626202] [NEW] Instance snapshots are listed under Images instead of Instance Snapshot
Public bug reported: When I create an instance snapshot, and try to launch a new instance using this snapshot as boot source, it's listed under Image instead of Instance Snapshot. Steps to reproduce: - Create an instance - Create an Instance Snapshot - Go to Launch Instance -> Source Actual Behaviour: The instance snapshot above is listed under Select Boot Source -> Image Expected Behaviour: The instance snapshot should be listed under Select Boot Source -> Instance Snapshot ** Affects: horizon Importance: Undecided Status: New ** Tags: instance snapshot -- 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/1626202 Title: Instance snapshots are listed under Images instead of Instance Snapshot Status in OpenStack Dashboard (Horizon): New Bug description: When I create an instance snapshot, and try to launch a new instance using this snapshot as boot source, it's listed under Image instead of Instance Snapshot. Steps to reproduce: - Create an instance - Create an Instance Snapshot - Go to Launch Instance -> Source Actual Behaviour: The instance snapshot above is listed under Select Boot Source -> Image Expected Behaviour: The instance snapshot should be listed under Select Boot Source -> Instance Snapshot To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1626202/+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 1493448] Re: All operations are perfomed with admin priveleges when 'use_user_token' is False
"use_user_token" and related glance config options were deprecated in Mitaka: https://review.openstack.org/#/c/237742/ Bug may be closed. ** Changed in: glance Status: Triaged => 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/1493448 Title: All operations are perfomed with admin priveleges when 'use_user_token' is False Status in Glance: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +--+--+ | Property | Value| +--+--+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.00 | | deleted | False| | deleted_at | None | | disk_format | qcow2| | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public| False| | min_disk | 0| | min_ram | 0| | name | private | | owner| e1cec705e33b4dfaaece11b623f3c680 | | protected| False| | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.00 | | virtual_size | None | +--+--+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--+-+-+--+--++ | ID | Name| Disk Format | Container Format | Size | Status | +--+-+-+--+--++ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--+-+-+--+--++ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--+-+-+--+--++ | ID | Name| Disk Format | Container Format | Size | Status | +--+-+-+--+--++ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-
[Yahoo-eng-team] [Bug 1618559] Re: LBaaS v2 healthmonitor wrong status detection
Ok, moving back to the neutron-lbaas bug queue. Sergey is using the
HaproxyOnHostPluginDriver and not the octavia driver.
** Changed in: octavia
Status: Incomplete => New
** Tags added: lbaas
** Project changed: octavia => neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1618559
Title:
LBaaS v2 healthmonitor wrong status detection
Status in neutron:
New
Bug description:
Summary:
After enabling health monitor loadbalancer on any request returns
HTTP/1.0 503 Service Unavailable
I have loadbalancer with vip ip 10.123.21.15. HTTP listener, pool and
member with IP 10.123.21.12.
I check status of web-server by:
curl -I -X GET http://10.123.21.15/owncloud/status.php
...
HTTP/1.1 200 OK
But when I add healthmonitor:
neutron lbaas-healthmonitor-create \
--delay 5 \
--max-retries 2 \
--timeout 10 \
--type HTTP \
--url-path /owncloud/status.php \
--pool owncloud-app-lb-http-pool
neutron lbaas-healthmonitor-show
+++
| Field | Value |
+++
| admin_state_up | True |
| delay | 5 |
| expected_codes | 200|
| http_method| GET|
| id | cf3cc795-ab1f-44c7-a521-799281e1ff64 |
| max_retries| 2 |
| name ||
| pools | {"id": "edcd43a2-41ad-4dd7-809d-10d3e45a08a7"} |
| tenant_id | b5d8bbe7742540c2b9b2e1b324ea854e |
| timeout| 10 |
| type | HTTP |
| url_path | /owncloud/status.php |
+++
I expect:
curl -I -X GET http://10.123.21.15/owncloud/status.php
...
HTTP/1.1 200 OK
But result:
curl -I -X GET http://10.123.21.15/owncloud/status.php
...
HTTP/1.0 503 Service Unavailable
Direct request to member:
curl -I -X GET http://10.123.21.12/owncloud/status.php
...
HTTP/1.1 200 OK
In neutron logs have no ERROR.
Some detail about configuration:
I have 3 controllers. Installed by Fuel with l3 population and DVR enabled.
lbaas_agent.ini
interface_driver=openvswitch
neutron lbaas-loadbalancer-status owncloud-app-lb
{
"loadbalancer": {
"name": "owncloud-app-lb",
"provisioning_status": "ACTIVE",
"listeners": [
{
"name": "owncloud-app-lb-http",
"provisioning_status": "ACTIVE",
"pools": [
{
"name": "owncloud-app-lb-http-pool",
"provisioning_status": "ACTIVE",
"healthmonitor": {
"provisioning_status": "ACTIVE",
"type": "HTTP",
"id": "cf3cc795-ab1f-44c7-a521-799281e1ff64",
"name": ""
},
"members": [
{
"name": "",
"provisioning_status": "ACTIVE",
"address": "10.123.21.12",
"protocol_port": 80,
"id": "8a588ed1-8818-44b2-80df-90debee59720",
"operating_status": "ONLINE"
}
],
"id": "edcd43a2-41ad-4dd7-809d-10d3e45a08a7",
"operating_status": "ONLINE"
}
],
"l7policies": [],
"id": "7521308a-15d1-4898-87c8-8f1ed4330b6c",
"operating_status": "ONLINE"
}
],
"pools": [
{
"name": "owncloud-app-lb-http-pool",
"provisioning_status": "ACTIVE",
"healthmonitor": {
"provisioning_status": "ACTIVE",
"type": "HTTP",
"id": "cf3cc795-ab1f-44c7-a521-799281e1ff64",
"name": ""
},
"members": [
{
"name": "",
"provisioning_status": "ACTIVE",
"address": "10.123.21.12"
[Yahoo-eng-team] [Bug 1618559] [NEW] LBaaS v2 healthmonitor wrong status detection
You have been subscribed to a public bug:
Summary:
After enabling health monitor loadbalancer on any request returns
HTTP/1.0 503 Service Unavailable
I have loadbalancer with vip ip 10.123.21.15. HTTP listener, pool and
member with IP 10.123.21.12.
I check status of web-server by:
curl -I -X GET http://10.123.21.15/owncloud/status.php
...
HTTP/1.1 200 OK
But when I add healthmonitor:
neutron lbaas-healthmonitor-create \
--delay 5 \
--max-retries 2 \
--timeout 10 \
--type HTTP \
--url-path /owncloud/status.php \
--pool owncloud-app-lb-http-pool
neutron lbaas-healthmonitor-show
+++
| Field | Value |
+++
| admin_state_up | True |
| delay | 5 |
| expected_codes | 200|
| http_method| GET|
| id | cf3cc795-ab1f-44c7-a521-799281e1ff64 |
| max_retries| 2 |
| name ||
| pools | {"id": "edcd43a2-41ad-4dd7-809d-10d3e45a08a7"} |
| tenant_id | b5d8bbe7742540c2b9b2e1b324ea854e |
| timeout| 10 |
| type | HTTP |
| url_path | /owncloud/status.php |
+++
I expect:
curl -I -X GET http://10.123.21.15/owncloud/status.php
...
HTTP/1.1 200 OK
But result:
curl -I -X GET http://10.123.21.15/owncloud/status.php
...
HTTP/1.0 503 Service Unavailable
Direct request to member:
curl -I -X GET http://10.123.21.12/owncloud/status.php
...
HTTP/1.1 200 OK
In neutron logs have no ERROR.
Some detail about configuration:
I have 3 controllers. Installed by Fuel with l3 population and DVR enabled.
lbaas_agent.ini
interface_driver=openvswitch
neutron lbaas-loadbalancer-status owncloud-app-lb
{
"loadbalancer": {
"name": "owncloud-app-lb",
"provisioning_status": "ACTIVE",
"listeners": [
{
"name": "owncloud-app-lb-http",
"provisioning_status": "ACTIVE",
"pools": [
{
"name": "owncloud-app-lb-http-pool",
"provisioning_status": "ACTIVE",
"healthmonitor": {
"provisioning_status": "ACTIVE",
"type": "HTTP",
"id": "cf3cc795-ab1f-44c7-a521-799281e1ff64",
"name": ""
},
"members": [
{
"name": "",
"provisioning_status": "ACTIVE",
"address": "10.123.21.12",
"protocol_port": 80,
"id": "8a588ed1-8818-44b2-80df-90debee59720",
"operating_status": "ONLINE"
}
],
"id": "edcd43a2-41ad-4dd7-809d-10d3e45a08a7",
"operating_status": "ONLINE"
}
],
"l7policies": [],
"id": "7521308a-15d1-4898-87c8-8f1ed4330b6c",
"operating_status": "ONLINE"
}
],
"pools": [
{
"name": "owncloud-app-lb-http-pool",
"provisioning_status": "ACTIVE",
"healthmonitor": {
"provisioning_status": "ACTIVE",
"type": "HTTP",
"id": "cf3cc795-ab1f-44c7-a521-799281e1ff64",
"name": ""
},
"members": [
{
"name": "",
"provisioning_status": "ACTIVE",
"address": "10.123.21.12",
"protocol_port": 80,
"id": "8a588ed1-8818-44b2-80df-90debee59720",
"operating_status": "ONLINE"
}
],
"id": "edcd43a2-41ad-4dd7-809d-10d3e45a08a7",
"operating_status": "ONLINE"
}
],
"id": "67a9602e-4bcd-4d1c-a41c-7af20ded0300",
"operating_status": "ONLINE"
}
** Affects: neutron
Importance: Undecided
Status: New
** Tags: lbaas
--
LBaaS v2 healthmonitor wrong status detection
https://bugs.launchpad.net/bugs/1618559
You received this bug notification because you a
[Yahoo-eng-team] [Bug 1593813] Re: domain admin unable to setup a domain-specific role to imply another domain-specific role in the same domain
Reviewed: https://review.openstack.org/339558 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=47d4d08ecb6804841d6de640afed8ca743f254b3 Submitter: Jenkins Branch:master commit 47d4d08ecb6804841d6de640afed8ca743f254b3 Author: Sean Perry Date: Thu Sep 15 11:04:14 2016 -0700 Give domain admin rights to domain specific implied roles Currently this is not working because of our default policy.v3cloudsample.json file. Add a new rule to check that the prior role's domain ID matches the domain ID of the user. Co-Authored-By: David Stanek Change-Id: Id1f5ccac3c639a44b33780b001e401bab195d8b3 Closes-Bug: #1593813 ** Changed in: keystone 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/1593813 Title: domain admin unable to setup a domain-specific role to imply another domain-specific role in the same domain Status in OpenStack Identity (keystone): Fix Released Bug description: With policy.v3cloudsample.json, domain admin of a domain is unable to setup a prior domain-specific role to imply another domain-specific role in the same domain. Per design, this is allowed. To reproduce. 1. Create "DomainA" 2. Create domain user "foo" in "DomainA" 3. Make "foo" the domain admin of "DomainA" 4. Get a DA token for "foo" 5. As DA, create a domain-specific role "AppDev" in "DomainA" 6. As DA, create a domain-specific role "AppAdmin" in "DomainA" 7. As DA, try to make "AppAdmin" imples "AppDev" and prepare to receive a HTTP 403 response To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1593813/+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 1619156] [Review update] R3.1
Review in progress for https://review.opencontrail.org/24347 Submitter: Anish Mehta (ameht...@gmail.com) ** Also affects: juniperopenstack/r3.1 Importance: Undecided Status: New ** Also affects: juniperopenstack/r3.1 Importance: Undecided Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1619156 Title: DerivedStats - add support for Time Range based SUM/AVG Status in OpenStack Dashboard (Horizon): Incomplete Status in Juniper Openstack: In Progress Status in Juniper Openstack r3.1 series: In Progress Status in Juniper Openstack trunk series: In Progress Bug description: DerivedStats SUM and AVG should have a time range specified in seconds. Right now, we allow range in terms of number of samples instead. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1619156/+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 1625140] Re: Deprecation warning for unused code
Reviewed: https://review.openstack.org/372324 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=49609f36f5b4b48f7d6cf2c5bbae65eab1a59876 Submitter: Jenkins Branch:master commit 49609f36f5b4b48f7d6cf2c5bbae65eab1a59876 Author: Gary Kotton Date: Mon Jun 13 06:43:26 2016 -0700 Remove deprecated class NeutronController Commit 9b8bf7d25c4dda41b78946ce7a3c0ab63602e834 marked NeutronController as deprecated. This code is no longer used in Neutron and there is no need for the class nor the unit tests for it. TrivialFix Closes-bug: #1625140 Change-Id: Ie02b6f1a45c3ea32a1116a48946c59673e2d2472 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625140 Title: Deprecation warning for unused code Status in neutron: Fix Released Bug description: 2016-09-18 03:20:37.403628 | Captured stderr: 2016-09-18 03:20:37.403670 | 2016-09-18 03:20:37.403795 | neutron/tests/unit/api/test_api_common.py:33: DeprecationWarning: Using class 'NeutronController' (either directly or via inheritance) is deprecated in version 'newton' and will be removed in version 'ocata' 2016-09-18 03:20:37.404051 | self.controller = FakeController(None) 2016-09-18 03:20:37.404091 | To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625140/+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 1621615] Re: network not configured when ipv6 netbooted into cloud-init
** Merge proposal linked: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/306345 ** Also affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1621615 Title: network not configured when ipv6 netbooted into cloud-init Status in cloud-init: New Status in MAAS: New Status in cloud-init package in Ubuntu: Confirmed Bug description: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of how ipv6 netboot with iscsi root disk doesn't work, blocking ipv6-only MAAS. After I hand-walked busybox through getting an IPv6 address, everything worked just fine until cloud-init couldn't fetch the instance data, because it insisted on bringing up the interface in IPv4, and there is no IPv4 DHCP on that vlan. Please work with initramfs and friends on getting ipv6 netboot to actually configure the interface. This may be as simple as teaching it about "inet6 dhcp" interfaces, and bolting the pieces together. Note that "use radvd" is not really an option for our use case. Related bugs: * bug 1621507: initramfs-tools configure_networking() fails to dhcp ipv6 addresses To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1621615/+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 1626132] [NEW] IPv6 Prefix delegation: dibbler.filters rootwrap file is not installed
Public bug reported: This file was added in https://review.openstack.org/#/c/185977, but was not listed in setup.cfg As a consequence, it is not installed in current RDO packages: https://bugzilla.redhat.com/show_bug.cgi?id=1377622 Without the file, dibbler-client will not start properly on these installations, so IPv6 Prefix delegation does not work ** Affects: neutron Importance: Undecided Assignee: Bernard Cafarelli (bcafarel) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1626132 Title: IPv6 Prefix delegation: dibbler.filters rootwrap file is not installed Status in neutron: In Progress Bug description: This file was added in https://review.openstack.org/#/c/185977, but was not listed in setup.cfg As a consequence, it is not installed in current RDO packages: https://bugzilla.redhat.com/show_bug.cgi?id=1377622 Without the file, dibbler-client will not start properly on these installations, so IPv6 Prefix delegation does not work To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1626132/+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 1626123] [NEW] Functional tests result depends on way test running
Public bug reported: Description === testtools.run and testtools.run --load-list work differently with nova tests. Steps to reproduce == amadev@pilgrim:~/m/nova$ source .tox/functional/bin/activate (functional) amadev@pilgrim:~/m/nova$ python -m testtools.run nova.tests.functional.notification_sample_tests.test_instance.TestInstanceNotificationSample.test_create_delete_server_with_instance_update ... Ran 1 test in 5.806s OK (functional) amadev@pilgrim:~/m/nova$ testr list-tests test_create_delete_server_with_instance_update > /tmp/nova-tests (functional) amadev@pilgrim:~/m/nova$ python -m testtools.run discover --load-list /tmp/nova-tests ... Ran 1 test in 4.689s FAILED (failures=1) Expected result === Tests shouldn't depent on the method of running. Environment === upstream master Logs & Configs == http://xsnippet.org/361996/ ** 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/1626123 Title: Functional tests result depends on way test running Status in OpenStack Compute (nova): New Bug description: Description === testtools.run and testtools.run --load-list work differently with nova tests. Steps to reproduce == amadev@pilgrim:~/m/nova$ source .tox/functional/bin/activate (functional) amadev@pilgrim:~/m/nova$ python -m testtools.run nova.tests.functional.notification_sample_tests.test_instance.TestInstanceNotificationSample.test_create_delete_server_with_instance_update ... Ran 1 test in 5.806s OK (functional) amadev@pilgrim:~/m/nova$ testr list-tests test_create_delete_server_with_instance_update > /tmp/nova-tests (functional) amadev@pilgrim:~/m/nova$ python -m testtools.run discover --load-list /tmp/nova-tests ... Ran 1 test in 4.689s FAILED (failures=1) Expected result === Tests shouldn't depent on the method of running. Environment === upstream master Logs & Configs == http://xsnippet.org/361996/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1626123/+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 1625660] Re: Volume detach is broken when using volume-update first
Reviewed: https://review.openstack.org/373390 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ee2c0a00db9d6006fb7c3a07ee252d4ca4d73eff Submitter: Jenkins Branch:master commit ee2c0a00db9d6006fb7c3a07ee252d4ca4d73eff Author: Sylvain Bauza Date: Tue Sep 20 16:50:16 2016 +0200 Revert "Set 'serial' to new volume ID in swap volumes" The below commit introduced a regression by updating the wrong value to the attachment field when calling the volume-update swap operation where the value is now the previous volume ID instead of the current volume ID. It litterally makes it now imposible to detech the volume from the instance once it has been swapped (even after the first swap). Given the original issue can be worked around by detaching and then attaching the volume before swapping back to the original volume, and because the original bug only impacts an admin API while here it impacts a user API, it's preferrable to directly revert the regression and then work on the next cycle about the root problem rather than leaving the change and try to fix something which is hard to troubleshoot, also given the lack of functional tests around the volume operations. This reverts commit be553fb15591c6fc212ef3a07c1dd1cbc43d6866. Change-Id: Ibad1afa5860d611e0e0ea0ba5e7dc98ae8f07190 Closes-Bug: #1625660 ** 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/1625660 Title: Volume detach is broken when using volume-update first Status in OpenStack Compute (nova): Fix Released Bug description: https://bugs.launchpad.net/nova/+bug/1490236 was focusing on correcting the volume-update API so that it was idempotent. Unfortunately, the merged solution is introducing a huge regression by incorrectly providing the old volume ID as the new attachment information. https://github.com/openstack/nova/commit/be553fb15591c6fc212ef3a07c1dd1cbc43d6866 Consequently, it's now impossible for an end-user to detach a volume if some operator updated the BDM to point to a different volume. Evidence here: http://paste.openstack.org/show/582248/ What's unfortunate is that the original bug is about to be worked around by just detaching/attaching the volume to the instance before swapping back... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1625660/+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 1626093] [NEW] LBaaSV2: listener deletion causes LB port to be Detached "forever"
Public bug reported: Case 1: Create a LBaaSV2 LB with a listener. Remove listener. Port Detached. Add listener. Nothing happens. Case 2: Create a LBaaSV2 LB with a listener. Add another listener. Remove one of the two. Port Detached. This is merely an annoyance. neutron port-show shows nothing for device_id and device_owner. In Horizon shows as Detached. ** 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/1626093 Title: LBaaSV2: listener deletion causes LB port to be Detached "forever" Status in neutron: New Bug description: Case 1: Create a LBaaSV2 LB with a listener. Remove listener. Port Detached. Add listener. Nothing happens. Case 2: Create a LBaaSV2 LB with a listener. Add another listener. Remove one of the two. Port Detached. This is merely an annoyance. neutron port-show shows nothing for device_id and device_owner. In Horizon shows as Detached. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1626093/+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 1475722] Re: Never use MagicMock
To all contributors to this bug. While this looks like helping, it is not. This kind of bug is largely a waste of time. Before adding more than 4 projects to a bug, please email the openstack- dev mailing list and ensure this is actually a cross cutting issue that people actually believe should be fixed. This just causes busy work for projects, is not helpful. ** No longer affects: nova ** No longer affects: keystone ** No longer affects: trove ** No longer affects: horizon ** No longer affects: tempest ** No longer affects: barbican ** No longer affects: ceilometer ** No longer affects: designate ** No longer affects: neutron ** No longer affects: oslo.log ** No longer affects: oslo.service ** No longer affects: ironic ** No longer affects: python-barbicanclient ** No longer affects: python-designateclient ** No longer affects: python-aodhclient ** No longer affects: python-ceilometerclient ** No longer affects: aodh ** No longer affects: python-glanceclient ** No longer affects: python-heatclient ** No longer affects: python-novaclient ** No longer affects: python-neutronclient ** No longer affects: tacker ** No longer affects: python-openstackclient ** No longer affects: python-troveclient ** No longer affects: cinder ** No longer affects: glance ** No longer affects: keystonemiddleware ** No longer affects: oslo.messaging -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in kolla: New Status in Mistral: In Progress Status in Murano: In Progress Status in Panko: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/kolla/+bug/1475722/+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 1626045] [NEW] log info fix
Public bug reported: log info is not reasonable enough ** Affects: neutron Importance: Undecided Assignee: Tony Xu (hhktony) Status: New ** Changed in: neutron Assignee: (unassigned) => Tony Xu (hhktony) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1626045 Title: log info fix Status in neutron: New Bug description: log info is not reasonable enough To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1626045/+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 1475722] Re: Never use MagicMock
** Also affects: kolla Importance: Undecided Status: New ** Changed in: kolla Assignee: (unassigned) => guo yunxian (guoyunxian) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: In Progress Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: In Progress Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic: In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in kolla: New Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in oslo.log: New Status in oslo.messaging: New Status in oslo.service: New Status in Panko: In Progress Status in python-aodhclient: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-glanceclient: In Progress Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1625871] Re: Filter with an instance name is not a perfect matching
Yes, I'm sorry for an extra work. ** Changed in: horizon Status: New => 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/1625871 Title: Filter with an instance name is not a perfect matching Status in OpenStack Dashboard (Horizon): Invalid Bug description: According to compute API, the key of Instance Name can be used regular expressions. Actually, when I use this filter from horizon, it can work well. So, following the discussion below, we need to remove '='. https://bugs.launchpad.net/horizon/+bug/1358909 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1625871/+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 1475722] Re: Never use MagicMock
** Also affects: python-aodhclient Importance: Undecided Status: New ** Changed in: python-aodhclient Assignee: (unassigned) => Wenyan Zhang (zhang-wenyan3) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: In Progress Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: In Progress Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic: In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in oslo.log: New Status in oslo.messaging: New Status in oslo.service: New Status in Panko: In Progress Status in python-aodhclient: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-glanceclient: In Progress Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: ironic Importance: Undecided Status: New ** Changed in: ironic Assignee: (unassigned) => Sharat Sharma (sharat-sharma) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: In Progress Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: In Progress Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic: New Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in oslo.log: New Status in oslo.messaging: New Status in oslo.service: New Status in Panko: In Progress Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-glanceclient: In Progress Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1626010] [NEW] Connectivity problem on trunk parent with MAC reuse and openvswitch firewall driver
Public bug reported:
It seems we have a case where the openvswitch firewall driver and a use
of trunks interferes with each other. I tried using the parent's MAC
address for a subport. Like this:
openstack network create net0
openstack network create net1
openstack subnet create --network net0 --subnet-range 10.0.4.0/24 subnet0
openstack subnet create --network net1 --subnet-range 10.0.5.0/24 subnet1
openstack port create --network net0 port0
parent_mac="$( openstack port show port0 | awk '/ mac_address / { print $4 }'
)"
openstack port create --network net1 --mac-address "$parent_mac" port1
openstack network trunk create --parent-port port0 --subport
port=port1,segmentation-type=vlan,segmentation-id=101 trunk0
openstack server create --flavor cirros256 --image cirros-0.3.4-x86_64-uec
--nic port-id=port0 --key-name key0 --wait vm0
Then all packets are lost on the trunk's parent port:
$ openstack server show vm0 | egrep addresses.*net0
| addresses| net0=10.0.4.6
|
$ sudo ip netns exec "qdhcp-$( openstack network show net0 | awk '/ id / {
print $4 }' )" ping -c3 10.0.4.6
WARNING: openstackclient.common.utils is deprecated and will be removed after
Jun 2017. Please use osc_lib.utils
PING 10.0.4.6 (10.0.4.6) 56(84) bytes of data.
--- 10.0.4.6 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
If I change the firewall_driver to noop and redo the same I have
connectivity.
If I still have the openvswitch firewall_driver but I don't explicitly
set the subport MAC, but let neutron automatically assign one, then
again I have connectivity.
devstack version: 81d89cf
neutron version: 60010a8
relevant parts of local.conf:
[[local|localrc]]
enable_service neutron-api
enable_service neutron-l3
enable_service neutron-agent
enable_service neutron-dhcp
enable_service neutron-metadata-agent
[[post-config|$NEUTRON_CONF]]
[DEFAULT]
service_plugins = router,trunk
[[post-config|$NEUTRON_PLUGIN_CONF]]
[securitygroup]
firewall_driver = openvswitch
** 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/1626010
Title:
Connectivity problem on trunk parent with MAC reuse and openvswitch
firewall driver
Status in neutron:
New
Bug description:
It seems we have a case where the openvswitch firewall driver and a
use of trunks interferes with each other. I tried using the parent's
MAC address for a subport. Like this:
openstack network create net0
openstack network create net1
openstack subnet create --network net0 --subnet-range 10.0.4.0/24 subnet0
openstack subnet create --network net1 --subnet-range 10.0.5.0/24 subnet1
openstack port create --network net0 port0
parent_mac="$( openstack port show port0 | awk '/ mac_address / { print $4
}' )"
openstack port create --network net1 --mac-address "$parent_mac" port1
openstack network trunk create --parent-port port0 --subport
port=port1,segmentation-type=vlan,segmentation-id=101 trunk0
openstack server create --flavor cirros256 --image cirros-0.3.4-x86_64-uec
--nic port-id=port0 --key-name key0 --wait vm0
Then all packets are lost on the trunk's parent port:
$ openstack server show vm0 | egrep addresses.*net0
| addresses| net0=10.0.4.6
|
$ sudo ip netns exec "qdhcp-$( openstack network show net0 | awk '/ id / {
print $4 }' )" ping -c3 10.0.4.6
WARNING: openstackclient.common.utils is deprecated and will be removed
after Jun 2017. Please use osc_lib.utils
PING 10.0.4.6 (10.0.4.6) 56(84) bytes of data.
--- 10.0.4.6 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
If I change the firewall_driver to noop and redo the same I have
connectivity.
If I still have the openvswitch firewall_driver but I don't explicitly
set the subport MAC, but let neutron automatically assign one, then
again I have connectivity.
devstack version: 81d89cf
neutron version: 60010a8
relevant parts of local.conf:
[[local|localrc]]
enable_service neutron-api
enable_service neutron-l3
enable_service neutron-agent
enable_service neutron-dhcp
enable_service neutron-metadata-agent
[[post-config|$NEUTRON_CONF]]
[DEFAULT]
service_plugins = router,trunk
[[post-config|$NEUTRON_PLUGIN_CONF]]
[securitygroup]
firewall_driver = openvswitch
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1626010/+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 1625253] Re: Collection of test artifacts in integration tests is broken after transition to xenial
Reviewed: https://review.openstack.org/372616 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=2fec0a1ae8515d49a771c1920bb2f98e6a734daf Submitter: Jenkins Branch:master commit 2fec0a1ae8515d49a771c1920bb2f98e6a734daf Author: Timur Sufiev Date: Mon Sep 19 19:19:05 2016 +0300 Fix the collection of integration tests artifacts Don't rely on a particular workspace name, as it changes when job's name changes. Depends-On: I28d84235fb51a49492ed9c96794ba74f317f66b6 Change-Id: I63e45ee89711b429d0d878303aefeec4b159125a Closes-Bug: #1625253 ** 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/1625253 Title: Collection of test artifacts in integration tests is broken after transition to xenial Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The destination path for gathering artifacts in tools/gate/integration/post_test_hook.sh was harcoded to a specific workspace dir name (which was derived in turn from job name). When the job name changed due to transition trusty->xenial, artifacts were no longer collected. We should not rely on any particular workspace name as it's very fragile. Will use relative paths instead. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1625253/+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 1475722] Re: Never use MagicMock
** Also affects: python-glanceclient Importance: Undecided Status: New ** Changed in: python-glanceclient Assignee: (unassigned) => Wenyan Zhang (zhang-wenyan3) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: In Progress Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: In Progress Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): New Status in oslo.log: New Status in oslo.messaging: New Status in oslo.service: New Status in Panko: In Progress Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-glanceclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: oslo.messaging Importance: Undecided Status: New ** Changed in: oslo.messaging Assignee: (unassigned) => ZTE-Zhengwei Su (su-zhengwei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: In Progress Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: In Progress Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): New Status in oslo.log: New Status in oslo.messaging: New Status in oslo.service: New Status in Panko: In Progress Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-glanceclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: oslo.service Importance: Undecided Status: New ** Also affects: oslo.log Importance: Undecided Status: New ** Changed in: oslo.log Assignee: (unassigned) => ZTE-Zhengwei Su (su-zhengwei) ** Changed in: oslo.service Assignee: (unassigned) => ZTE-Zhengwei Su (su-zhengwei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): New Status in oslo.log: New Status in oslo.service: New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1625981] [NEW] update response of ML2 doesn't include bumped revision number
Public bug reported: Any operations the bump the revision number of the port that don't happen in the base_db_plugin update_port method don't reflect the increased revision number in the API response, mech driver pre/postcommit operations, or the registry events. This is because ML2 calls make_port_dict before performing any of the additional port- related operations that might increase the revision number (changing security groups, etc). ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) ** Changed in: neutron Milestone: None => newton-rc2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625981 Title: update response of ML2 doesn't include bumped revision number Status in neutron: New Bug description: Any operations the bump the revision number of the port that don't happen in the base_db_plugin update_port method don't reflect the increased revision number in the API response, mech driver pre/postcommit operations, or the registry events. This is because ML2 calls make_port_dict before performing any of the additional port- related operations that might increase the revision number (changing security groups, etc). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625981/+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 1625867] Re: dhcp agent not discarding stale updates
Reviewed: https://review.openstack.org/373566 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9019ff2f744ae91839d05a188358ef92343add43 Submitter: Jenkins Branch:master commit 9019ff2f744ae91839d05a188358ef92343add43 Author: Kevin Benton Date: Mon Sep 19 18:44:02 2016 -0700 Make DHCP agent use 'revision_number' Change I445974b0e0dabb762807c6f318b1b44f51b3fe15 updated the 'revision' field to 'revision_number' but it missed the DHCP agent and subsequently broke it's ability to detect stale updates. This fixes the name in the agent. This is marked as a partial for 1622616 because one of the reasons the agent was frequently updating the DHCP port was in reaction to stale port update messages for its own port. Partial-Bug: #1622616 Closes-Bug: #1625867 Change-Id: Id41000127e1084f7ff243f8dc9c39fbdaab4 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625867 Title: dhcp agent not discarding stale updates Status in neutron: Fix Released Bug description: The DHCP agent ends up asking for IPs on subnets it already has IPs on because of the following order of events: neutron_port_create (for DHCP port) neutron_port_status_update (from l2 agent for dhcp port) neutron_subnet_create However, because the dhcp agent uses a semaphore, events may be processed in this order subnet_create_end (which DHCP agent uses to update dhcp port) port_update_end (which has the DHCP agent's port from port_status_update and causes the agent to think IPs have changed and retriggers a request to the server) The issue here is that the agent is recognizing the port update message as stale. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625867/+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 1475722] Re: Never use MagicMock
** Also affects: python-designateclient Importance: Undecided Status: New ** Changed in: python-designateclient Assignee: (unassigned) => sonu (sonu-bhumca11) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1625973] [NEW] RuntimeError: Model .MyModel'> tried to registe
Public bug reported: http://logs.openstack.org/52/372552/7/check/gate-neutron- python34/e7b00a0/testr_results.html.gz Traceback (most recent call last): File "/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/extensions/test_address_scope.py", line 132, in setUp super(TestAddressScope, self).setUp(plugin=plugin, ext_mgr=ext_mgr) File "/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/db/test_db_base_plugin_v2.py", line 133, in setUp self.api = router.APIRouter() File "/home/jenkins/workspace/gate-neutron-python34/neutron/api/v2/router.py", line 76, in __init__ plugin = manager.NeutronManager.get_plugin() File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 244, in get_plugin return weakref.proxy(cls.get_instance().plugin) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 238, in get_instance cls._create_instance() File "/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/oslo_concurrency/lockutils.py", line 271, in inner return f(*args, **kwargs) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 224, in _create_instance cls._instance = cls() File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 126, in __init__ plugin_provider) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 160, in _get_plugin_instance return plugin_class() File "/home/jenkins/workspace/gate-neutron-python34/neutron/db/standardattrdescription_db.py", line 28, in __new__ for resource in standard_attr.get_standard_attr_resource_model_map(): File "/home/jenkins/workspace/gate-neutron-python34/neutron/db/standard_attr.py", line 167, in get_standard_attr_resource_model_map res=resource)) RuntimeError: Model .MyModel'> tried to register for API resource my_resource which conflicts with model .Dup'>. It happens when garbage collector has not cleaned up the offending subclasses before we call to get_standard_attr_resource_model_map. ** Affects: neutron Importance: High Assignee: Ihar Hrachyshka (ihar-hrachyshka) Status: In Progress ** Tags: gate-failure unittest ** Changed in: neutron Importance: Undecided => High ** Tags added: gate-failure unittest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1625973 Title: RuntimeError: Model .MyModel'> tried to register for API resource my_resource which conflicts with model .Dup'>. Status in neutron: In Progress Bug description: http://logs.openstack.org/52/372552/7/check/gate-neutron- python34/e7b00a0/testr_results.html.gz Traceback (most recent call last): File "/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/extensions/test_address_scope.py", line 132, in setUp super(TestAddressScope, self).setUp(plugin=plugin, ext_mgr=ext_mgr) File "/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/db/test_db_base_plugin_v2.py", line 133, in setUp self.api = router.APIRouter() File "/home/jenkins/workspace/gate-neutron-python34/neutron/api/v2/router.py", line 76, in __init__ plugin = manager.NeutronManager.get_plugin() File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 244, in get_plugin return weakref.proxy(cls.get_instance().plugin) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 238, in get_instance cls._create_instance() File "/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/oslo_concurrency/lockutils.py", line 271, in inner return f(*args, **kwargs) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 224, in _create_instance cls._instance = cls() File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 126, in __init__ plugin_provider) File "/home/jenkins/workspace/gate-neutron-python34/neutron/manager.py", line 160, in _get_plugin_instance return plugin_class() File "/home/jenkins/workspace/gate-neutron-python34/neutron/db/standardattrdescription_db.py", line 28, in __new__ for resource in standard_attr.get_standard_attr_resource_model_map(): File "/home/jenkins/workspace/gate-neutron-python34/neutron/db/standard_attr.py", line 167, in get_standard_attr_resource_model_map res=resource)) RuntimeError: Model .MyModel'> tried to register for API resource my_resource which conflicts with model .Dup'>. It happens when garbage collector has not cleaned up the offending subclasses before we call to get_standard_attr_resource_model_map. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1625973/+subscriptions -- Mailing list: https://launchpad.net/~ya
[Yahoo-eng-team] [Bug 1475722] Re: Never use MagicMock
** Also affects: senlin Importance: Undecided Status: New ** Changed in: senlin Assignee: (unassigned) => Lu lei (lei-lu) ** Also affects: python-senlinclient Importance: Undecided Status: New ** Changed in: python-senlinclient Assignee: (unassigned) => Lu lei (lei-lu) ** Also affects: tacker Importance: Undecided Status: New ** Changed in: tacker Assignee: (unassigned) => Lu lei (lei-lu) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-designateclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** No longer affects: glance-store -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-senlinclient: New Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in senlin: New Status in OpenStack Object Storage (swift): New Status in tacker: New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: glance-store 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in glance_store: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => QiangTang (qtang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** No longer affects: heat -- 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in Mistral: In Progress Status in Murano: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: python-novaclient 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: New Status in Mistral: In Progress Status in Murano: In Progress Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: keystonemiddleware 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: New Status in Mistral: In Progress Status in Murano: In Progress Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) => Sharat Sharma (sharat-sharma) -- 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: New Status in Mistral: In Progress Status in Murano: In Progress Status in OpenStack Compute (nova): New Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-novaclient: New Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Assignee: (unassigned) => Sharat Sharma (sharat-sharma) -- 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in heat: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Mistral: In Progress Status in Murano: In Progress Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: python-barbicanclient Importance: Undecided Status: New ** Changed in: python-barbicanclient Assignee: (unassigned) => Sharat Sharma (sharat-sharma) -- 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in heat: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Mistral: In Progress Status in Murano: In Progress Status in Panko: New Status in python-barbicanclient: In Progress Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: panko Importance: Undecided Status: New ** Changed in: panko Assignee: (unassigned) => Wenyan Zhang (zhang-wenyan3) ** Also affects: aodh Importance: Undecided Status: New ** Changed in: aodh Assignee: (unassigned) => Wenyan Zhang (zhang-wenyan3) -- 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/1475722 Title: Never use MagicMock Status in Aodh: New Status in Barbican: In Progress Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in heat: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Mistral: In Progress Status in Murano: In Progress Status in Panko: New Status in python-barbicanclient: New Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: barbican Importance: Undecided Status: New ** Changed in: barbican Assignee: (unassigned) => Sharat Sharma (sharat-sharma) -- 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/1475722 Title: Never use MagicMock Status in Barbican: New Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in heat: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Mistral: In Progress Status in Murano: In Progress Status in Panko: New Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1475722/+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 1475722] Re: Never use MagicMock
** Also affects: designate Importance: Undecided Status: New ** Changed in: designate Assignee: (unassigned) => sonu (sonu-bhumca11) -- 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/1475722 Title: Never use MagicMock Status in Barbican: New Status in Ceilometer: New Status in Cinder: New Status in Designate: New Status in Glance: New Status in heat: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Mistral: In Progress Status in Murano: In Progress Status in Panko: New Status in python-ceilometerclient: New Status in python-heatclient: In Progress Status in python-mistralclient: In Progress Status in python-muranoclient: In Progress Status in python-neutronclient: In Progress Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Committed Status in python-swiftclient: In Progress Status in python-troveclient: In Progress Status in Rally: New Status in OpenStack Object Storage (swift): New Status in OpenStack DBaaS (Trove): New Bug description: They magically allow things to pass. This is bad. Any usage should be replaced with the Mock class and explicit attributes should be set on it. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1475722/+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
