[Yahoo-eng-team] [Bug 1940324] Re: [CI][Devstack] Failing to SSH to test VMs with IPv6
** Summary changed:
- IPv6 job tests failing to SSH
+ [CI][Devstack] Failing to SSH to test VMs with IPv6
** 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/1940324
Title:
[CI][Devstack] Failing to SSH to test VMs with IPv6
Status in OpenStack Shared File Systems Service (Manila):
Triaged
Status in neutron:
New
Bug description:
Description
===
The LVM job for manila is failing constantly. Few tests are having the same
issue while trying to SSH into instances.
Steps to reproduce
==
- Configure tempest
- Configure LVM backend
- Run functional tests
Expected result
===
The job should be able to ssh into the instances and the tests should be
passing.
Actual result
=
The following tests are failing:
{0}
manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsNFSIPv6.test_mount_share_one_vm
{5}
manila_tempest_tests.tests.scenario.test_share_extend.TestShareExtendNFSIPv6.test_create_extend_and_write
{0}
manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsNFSIPv6.test_read_mountable_snapshot
{0}
manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsNFSIPv6.test_read_write_two_vms
{0}
manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsNFSIPv6.test_write_data_to_share_created_from_snapshot
{0}
manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsNFSIPv6.test_write_with_ro_access
This exception is being raised:
https://paste.openstack.org/show/808158/
Environment
===
- Ubuntu 20.04
- Manila using the master branch
Logs & Configs
==
local.conf example: https://paste.openstack.org/show/808159/
manila.conf example: https://paste.openstack.org/show/808160/
To manage notifications about this bug go to:
https://bugs.launchpad.net/manila/+bug/1940324/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1926399] Re: UT failing with sqlalchemy 1.4
** Also affects: manila Importance: Undecided Status: New ** Changed in: manila Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1926399 Title: UT failing with sqlalchemy 1.4 Status in Cinder: Fix Released Status in OpenStack Shared File Systems Service (Manila): New Status in masakari: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in oslo.db: Fix Released Bug description: See job cross-neutron-py36 in test patch https://review.opendev.org/c/openstack/requirements/+/788339/ https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ac7/788339/1/check /cross-neutron-py36/ac77335/testr_results.html To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1926399/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : 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
** Changed in: manila 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/1602081 Title: Use oslo.context's policy dict Status in Cinder: Fix Released Status in Glance: Fix Released Status in OpenStack Heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Released 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 1602081] Re: Use oslo.context's policy dict
** Also affects: manila Importance: Undecided Status: New ** Changed in: manila Assignee: (unassigned) => Goutham Pacha Ravi (gouthamr) -- 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/1602081 Title: Use oslo.context's policy dict Status in Cinder: Fix Released Status in Glance: Fix Released Status in OpenStack Heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Shared File Systems Service (Manila): New 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 1886298] Re: Few of the lower constraints are not compatible with python3.8
Fix released in manila-ui: https://review.opendev.org/#/c/743135/ ** Changed in: manila-ui Status: New => 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: In Progress Status in ec2-api: In Progress Status in futurist: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in kolla: Fix Released Status in kolla-ansible: Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Committed Status in manila-ui: Fix Released Status in masakari: In Progress Status in OpenStack Compute (nova): Fix Released Status in os-win: New Status in oslo.messaging: In Progress Status in oslo.policy: In Progress Status in oslo.privsep: Fix Released Status in oslo.reports: Fix Released Status in oslo.vmware: Fix Released Status in Glance Client: New Status in python-keystoneclient: Fix Committed Status in python-manilaclient: Fix Released Status in python-novaclient: Fix Released Status in python-senlinclient: New Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in tacker: In Progress Status in taskflow: New Status in tripleo-validations: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Changed in: python-manilaclient Importance: Undecided => Medium ** Changed in: python-manilaclient Status: New => Fix Released ** Also affects: manila Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Shared File Systems Service (Manila): New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): Fix Released Status in os-win: New Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: Fix Released Status in python-novaclient: In Progress Status in python-senlinclient: New Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in tacker: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Changed in: manila-ui Importance: Undecided => High ** Changed in: manila-ui Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: manila-ui Milestone: None => victoria-client-release ** Also affects: python-manilaclient Importance: Undecided Status: New ** Changed in: python-manilaclient Milestone: None => victoria-client-release -- 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/manila-ui/+bug/1886298/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1700501] Re: Insecure rootwrap usage
In Manila, we've discussed migrating off of rootwrap, to privsep - and are yet to find an owner to complete that work. We'll hopefully do that soon. However, I agree this bug is wide open. We'll use a different tracker to call out the tasks to deprecate the usage of rootwrap. ** Changed in: manila Status: Incomplete => 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/1700501 Title: Insecure rootwrap usage Status in Cinder: New Status in OpenStack Shared File Systems Service (Manila): Invalid Status in OpenStack Compute (nova): Incomplete Status in OpenStack Security Advisory: Won't Fix Bug description: Reported by Benjamin Deuter of SUSE: Some rootwrap filters are too permissive and allow privilege escalation from service user, as explained here: https://security.openstack.org/guidelines/dg_use-oslo-rootwrap- securely.html#incorrect For example this shouldn't be authorized: sudo nova-rootwrap /etc/nova/rootwrap.conf chmod 777 /etc/shadow To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1700501/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1850626] Re: neutron-dynamic-routing: TypeError: bind() takes 4 positional arguments but 5 were given
** Changed in: manila
Status: Fix Committed => Fix Released
** Changed in: manila
Assignee: (unassigned) => Goutham Pacha Ravi (gouthamr)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1850626
Title:
neutron-dynamic-routing: TypeError: bind() takes 4 positional
arguments but 5 were given
Status in Manila:
Fix Released
Status in neutron:
Fix Released
Bug description:
Neutron-dynamic-routing scenario jobs in neutron-tempest-plugin repo
are failing all the time since few days.
Example of failure
https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_cee/691855/1/check
/neutron-tempest-plugin-dynamic-routing/cee3785/testr_results.html.gz
It seems that this happens due to error in service plugin, see neutron
server log:
Notify callbacks
['neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727']
for bgp_speaker, after_create {{(pid=19640) _notify_loop
/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py:193}}
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager [None
req-c747f1f4-6424-4812-b7e4-cfc5c083fd81 tempest-BgpSpeakerTestJSON-1886159994
tempest-BgpSpeakerTestJSON-1886159994] Error during notification for
neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727
bgp_speaker, after_create: TypeError: bind() takes 4 positional arguments but
5 were given
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager Traceback (most
recent call last):
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py", line
197, in _notify_loop
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
callback(resource, event, trigger, **kwargs)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron-dynamic-routing/neutron_dynamic_routing/services/bgp/scheduler/bgp_dragent_scheduler.py",
line 202, in schedule_bgp_speaker_callback
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
plugin.schedule_bgp_speaker(ctx, payload['bgp_speaker'])
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron-dynamic-routing/neutron_dynamic_routing/db/bgp_dragentscheduler_db.py",
line 100, in schedule_bgp_speaker
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
created_bgp_speaker)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/scheduler/base_scheduler.py", line 55, in schedule
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager context,
chosen_agents, resource['id'], force_scheduling)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager TypeError: bind()
takes 4 positional arguments but 5 were given
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
It is caused by https://review.opendev.org/#/c/288271/ which we merged
recently and revert of this patch is already proposed in
https://review.opendev.org/#/c/691710/
To manage notifications about this bug go to:
https://bugs.launchpad.net/manila/+bug/1850626/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1850626] Re: neutron-dynamic-routing: TypeError: bind() takes 4 positional arguments but 5 were given
** Also affects: manila
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1850626
Title:
neutron-dynamic-routing: TypeError: bind() takes 4 positional
arguments but 5 were given
Status in Manila:
New
Status in neutron:
Confirmed
Bug description:
Neutron-dynamic-routing scenario jobs in neutron-tempest-plugin repo
are failing all the time since few days.
Example of failure
https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_cee/691855/1/check
/neutron-tempest-plugin-dynamic-routing/cee3785/testr_results.html.gz
It seems that this happens due to error in service plugin, see neutron
server log:
Notify callbacks
['neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727']
for bgp_speaker, after_create {{(pid=19640) _notify_loop
/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py:193}}
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager [None
req-c747f1f4-6424-4812-b7e4-cfc5c083fd81 tempest-BgpSpeakerTestJSON-1886159994
tempest-BgpSpeakerTestJSON-1886159994] Error during notification for
neutron_dynamic_routing.services.bgp.scheduler.bgp_dragent_scheduler.BgpDrAgentSchedulerBase.schedule_bgp_speaker_callback--9223372036854649727
bgp_speaker, after_create: TypeError: bind() takes 4 positional arguments but
5 were given
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager Traceback (most
recent call last):
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/usr/local/lib/python3.6/dist-packages/neutron_lib/callbacks/manager.py", line
197, in _notify_loop
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
callback(resource, event, trigger, **kwargs)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron-dynamic-routing/neutron_dynamic_routing/services/bgp/scheduler/bgp_dragent_scheduler.py",
line 202, in schedule_bgp_speaker_callback
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
plugin.schedule_bgp_speaker(ctx, payload['bgp_speaker'])
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron-dynamic-routing/neutron_dynamic_routing/db/bgp_dragentscheduler_db.py",
line 100, in schedule_bgp_speaker
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
created_bgp_speaker)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/scheduler/base_scheduler.py", line 55, in schedule
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager context,
chosen_agents, resource['id'], force_scheduling)
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager TypeError: bind()
takes 4 positional arguments but 5 were given
Oct 29 19:11:05.959429 ubuntu-bionic-ovh-bhs1-0012563860
neutron-server[19534]: ERROR neutron_lib.callbacks.manager
It is caused by https://review.opendev.org/#/c/288271/ which we merged
recently and revert of this patch is already proposed in
https://review.opendev.org/#/c/691710/
To manage notifications about this bug go to:
https://bugs.launchpad.net/manila/+bug/1850626/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1229324] Re: extraneous vim editor configuration comments
** Changed in: manila-ui Importance: Undecided => Low ** Changed in: manila-ui Status: Fix Committed => 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/1229324 Title: extraneous vim editor configuration comments Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Glance: Fix Released Status in OpenStack Heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Manila: Fix Released Status in manila-ui: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in Glance Client: Fix Released Status in python-neutronclient: Fix Released Status in python-swiftclient: In Progress Status in python-troveclient: Fix Released Status in storyboard: New Status in OpenStack Object Storage (swift): In Progress Status in taskflow: Fix Released Status in tempest: Fix Released Status in tuskar: Fix Released Bug description: Many of the source code files have a beginning line # vim: tabstop=4 shiftwidth=4 softtabstop=4 This should be deleted. Many of these lines are in the ceilometer/openstack/common directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1229324/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1804084] Re: Nova API responds with HTTP 500 / DBError on instance creation
Tempest log for manila-tempest-dsvm-postgres-zfsonlinux on
https://review.openstack.org/#/c/545695/19
** Attachment added:
"manila_zfsonlinux_postgresql_tempest_545695_PS19.txt.gz.txt"
https://bugs.launchpad.net/nova/+bug/1804084/+attachment/5214342/+files/manila_zfsonlinux_postgresql_tempest_545695_PS19.txt.gz.txt
** Also affects: manila
Importance: Undecided
Status: New
** Changed in: manila
Status: New => Opinion
--
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/1804084
Title:
Nova API responds with HTTP 500 / DBError on instance creation
Status in Manila:
Opinion
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
When creating a new instance with the POST /servers API, a HTTP 500 is
encountered:
Request and Response:
500 POST http://38.108.68.93/compute/v2.1/servers 1.804s
2018-11-19 07:17:28.015 3332 DEBUG tempest.lib.common.rest_client
[req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9 ] Request - Headers: {'Content-Type':
'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''}
Body: {"server": {"name":
"tempest-ShareManageUnmanageNFS-server-1394122281", "imageRef":
"0ab32d82-b8f2-4bf7-969f-8f3339dd4efa", "key_name":
"tempest-ShareManageUnmanageNFS-1797925906", "flavorRef": "100", "networks":
[{"uuid": "4051f365-fc7c-46d3-8295-2f3e4317e5ee"}], "security_groups":
[{"name": "tempest-secgroup-smoke-1206484509"}]}}
Response - Headers: {'status': '500', u'content-length': '199',
'content-location': 'http://38.108.68.93/compute/v2.1/servers',
u'x-compute-request-id': 'req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9', u'vary':
'OpenStack-API-Version,X-OpenStack-Nova-API-Version', u'server': 'Apache/2.4.29
(Ubuntu)', u'openstack-api-version': 'compute 2.1', u'connection': 'close',
u'x-openstack-nova-api-version': '2.1', u'date': 'Mon, 19 Nov 2018 07:17:26
GMT', u'content-type': 'application/json; charset=UTF-8',
u'x-openstack-request-id': 'req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9'}
Body: {"computeFault": {"message": "Unexpected API Error. Please
report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.\n", "code": 500}}
_log_request_full tempest/lib/common/rest_client.py:437
Steps to reproduce
==
This occurred in the openstack/manila project gate when running "scenario"
tests which attempt to create a Nova VM to mount shared file systems and
perform I/O. The tests bail out on the first step, i.e, creating a VM.
Environment
===
1. OpenStack version: master / Stein
2. Env:
Setup: DevStack/DevStack gate - local.conf is here [1] (Also Attached)
Hypervisor: Libvirt/KVM
Storage: LVM
Networking type: Neutron with OpenVSwitch
Database used: PostgreSQL
Logs & Configs
==
nova-api logs are attached. Only the relevant sections of the manila/tempest
logs are attached with this report. See this paste [3] for Relevant log file
links and debug steps followed by the reporter.
[1] Local.conf:
http://logs.openstack.org/67/616467/1/check/manila-tempest-dsvm-scenario/e765422/logs/local.conf.txt.gz
[2] Nova API log:
http://logs.openstack.org/67/616467/1/check/manila-tempest-dsvm-scenario/e765422/logs/screen-n-api.txt.gz
[3] Paste with relevant details: http://paste.openstack.org/show/735697/
To manage notifications about this bug go to:
https://bugs.launchpad.net/manila/+bug/1804084/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1804084] [NEW] Nova API responds with HTTP 500 / DBError on instance creation
Public bug reported:
Description
===
When creating a new instance with the POST /servers API, a HTTP 500 is
encountered:
Request and Response:
500 POST http://38.108.68.93/compute/v2.1/servers 1.804s
2018-11-19 07:17:28.015 3332 DEBUG tempest.lib.common.rest_client
[req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9 ] Request - Headers: {'Content-Type':
'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''}
Body: {"server": {"name":
"tempest-ShareManageUnmanageNFS-server-1394122281", "imageRef":
"0ab32d82-b8f2-4bf7-969f-8f3339dd4efa", "key_name":
"tempest-ShareManageUnmanageNFS-1797925906", "flavorRef": "100", "networks":
[{"uuid": "4051f365-fc7c-46d3-8295-2f3e4317e5ee"}], "security_groups":
[{"name": "tempest-secgroup-smoke-1206484509"}]}}
Response - Headers: {'status': '500', u'content-length': '199',
'content-location': 'http://38.108.68.93/compute/v2.1/servers',
u'x-compute-request-id': 'req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9', u'vary':
'OpenStack-API-Version,X-OpenStack-Nova-API-Version', u'server': 'Apache/2.4.29
(Ubuntu)', u'openstack-api-version': 'compute 2.1', u'connection': 'close',
u'x-openstack-nova-api-version': '2.1', u'date': 'Mon, 19 Nov 2018 07:17:26
GMT', u'content-type': 'application/json; charset=UTF-8',
u'x-openstack-request-id': 'req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9'}
Body: {"computeFault": {"message": "Unexpected API Error. Please report
this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.\n", "code": 500}}
_log_request_full tempest/lib/common/rest_client.py:437
Steps to reproduce
==
This occurred in the openstack/manila project gate when running "scenario"
tests which attempt to create a Nova VM to mount shared file systems and
perform I/O. The tests bail out on the first step, i.e, creating a VM.
Environment
===
1. OpenStack version: master / Stein
2. Env:
Setup: DevStack/DevStack gate - local.conf is here [1] (Also Attached)
Hypervisor: Libvirt/KVM
Storage: LVM
Networking type: Neutron with OpenVSwitch
Database used: PostgreSQL
Logs & Configs
==
nova-api logs are attached. Only the relevant sections of the manila/tempest
logs are attached with this report. See this paste [3] for Relevant log file
links and debug steps followed by the reporter.
[1] Local.conf:
http://logs.openstack.org/67/616467/1/check/manila-tempest-dsvm-scenario/e765422/logs/local.conf.txt.gz
[2] Nova API log:
http://logs.openstack.org/67/616467/1/check/manila-tempest-dsvm-scenario/e765422/logs/screen-n-api.txt.gz
[3] Paste with relevant details: http://paste.openstack.org/show/735697/
** Affects: manila
Importance: Undecided
Status: Opinion
** Affects: nova
Importance: Undecided
Status: New
** Tags: postgresql
** Tags added: postgresql
--
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/1804084
Title:
Nova API responds with HTTP 500 / DBError on instance creation
Status in Manila:
Opinion
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
When creating a new instance with the POST /servers API, a HTTP 500 is
encountered:
Request and Response:
500 POST http://38.108.68.93/compute/v2.1/servers 1.804s
2018-11-19 07:17:28.015 3332 DEBUG tempest.lib.common.rest_client
[req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9 ] Request - Headers: {'Content-Type':
'application/json', 'Accept': 'application/json', 'X-Auth-Token': ''}
Body: {"server": {"name":
"tempest-ShareManageUnmanageNFS-server-1394122281", "imageRef":
"0ab32d82-b8f2-4bf7-969f-8f3339dd4efa", "key_name":
"tempest-ShareManageUnmanageNFS-1797925906", "flavorRef": "100", "networks":
[{"uuid": "4051f365-fc7c-46d3-8295-2f3e4317e5ee"}], "security_groups":
[{"name": "tempest-secgroup-smoke-1206484509"}]}}
Response - Headers: {'status': '500', u'content-length': '199',
'content-location': 'http://38.108.68.93/compute/v2.1/servers',
u'x-compute-request-id': 'req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9', u'vary':
'OpenStack-API-Version,X-OpenStack-Nova-API-Version', u'server': 'Apache/2.4.29
(Ubuntu)', u'openstack-api-version': 'compute 2.1', u'connection': 'close',
u'x-openstack-nova-api-version': '2.1', u'date': 'Mon, 19 Nov 2018 07:17:26
GMT', u'content-type': 'application/json; charset=UTF-8',
u'x-openstack-request-id': 'req-807e4720-03a9-4acc-8c5a-a9fbeb8a5df9'}
Body: {"computeFault": {"message": "Unexpected API Error. Please
report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.\n", "code": 500}}
_log_request_full tempest/lib/common/rest_client.py:437
Steps to reproduce
==
This occurred in the openstack/manila project gate when running "scenario"
tests which attempt to create a Nova VM to
[Yahoo-eng-team] [Bug 1280105] Re: urllib/urllib2 is incompatible for python 3
** Changed in: manila Status: Fix Committed => 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/1280105 Title: urllib/urllib2 is incompatible for python 3 Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Fuel for OpenStack: Fix Released Status in Glance: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in python-troveclient: Fix Released Status in refstack: Fix Released Status in Sahara: Fix Released Status in OpenStack Object Storage (swift): Fix Released Status in tacker: Fix Released Status in tempest: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in Zuul: In Progress Bug description: urllib/urllib2 is incompatible for python 3 To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1280105/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1793364] Re: mysql db opportunistic unit tests timing out intermittently in the gate (bad thread switch?)
Latching on, we had a similar failure on the manila gate today: http://paste.openstack.org/show/730492/ ** Also affects: manila Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1793364 Title: mysql db opportunistic unit tests timing out intermittently in the gate (bad thread switch?) Status in Cinder: Confirmed Status in Manila: New Status in OpenStack Compute (nova): Confirmed Status in oslo.db: New Bug description: Seen in nova and cinder unit test runs in the gate: http://logs.openstack.org/03/602403/1/gate/openstack-tox- py35/b4c9214/testr_results.html.gz http://logs.openstack.org/94/603194/1/gate/openstack-tox- py35/e37d161/testr_results.html.gz Years ago we updated the timeout scaling factor on those tests in nova: https://review.openstack.org/#/c/370805/ For bug 1216851. Looking at a timeout/failed run for nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_models_sync against a passing run: nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_models_sync [664.512994s] ... FAILED nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_models_sync [39.644814s] ... ok Based on that, it's clear that we're not just missing some timeout - it looks like we're totally breaking somewhere and only being caught by the timeout. There are a couple of errors in the logs when we see this: b'sqlalchemy.exc.ResourceClosedError: This result object does not return rows. It has been closed automatically.' 2018-09-19 05:35:08.697560 | ubuntu-xenial | b'' 2018-09-19 05:35:08.697658 | ubuntu-xenial | b'The above exception was the direct cause of the following exception:' 2018-09-19 05:35:08.697700 | ubuntu-xenial | b'' 2018-09-19 05:35:08.697772 | ubuntu-xenial | b'Traceback (most recent call last):' 2018-09-19 05:35:08.697957 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/oslo_db/sqlalchemy/test_migrations.py", line 585, in test_models_sync' 2018-09-19 05:35:08.698031 | ubuntu-xenial | b' self.db_sync(self.get_engine())' 2018-09-19 05:35:08.698174 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/unit/db/test_migrations.py", line 146, in db_sync' 2018-09-19 05:35:08.698285 | ubuntu-xenial | b'sa_migration.db_sync()' 2018-09-19 05:35:08.698451 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/nova/db/sqlalchemy/migration.py", line 61, in db_sync' 2018-09-19 05:35:08.698522 | ubuntu-xenial | b'repository, version)' 2018-09-19 05:35:08.698682 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/migrate/versioning/api.py", line 186, in upgrade' 2018-09-19 05:35:08.698766 | ubuntu-xenial | b'return _migrate(url, repository, version, upgrade=True, err=err, **opts)' 2018-09-19 05:35:08.698823 | ubuntu-xenial | b' File "", line 2, in _migrate' 2018-09-19 05:35:08.698951 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/migrate/versioning/util/__init__.py", line 167, in with_engine' 2018-09-19 05:35:08.698991 | ubuntu-xenial | b'return f(*a, **kw)' 2018-09-19 05:35:08.699108 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/migrate/versioning/api.py", line 366, in _migrate' 2018-09-19 05:35:08.699164 | ubuntu-xenial | b'schema.runchange(ver, change, changeset.step)' 2018-09-19 05:35:08.699315 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/migrate/versioning/schema.py", line 93, in runchange' 2018-09-19 05:35:08.706788 | ubuntu-xenial | b' change.run(self.engine, step)' 2018-09-19 05:35:08.707005 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/migrate/versioning/script/py.py", line 148, in run' 2018-09-19 05:35:08.707058 | ubuntu-xenial | b'script_func(engine)' 2018-09-19 05:35:08.707248 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/315_add_migration_progresss_detail.py", line 30, in upgrade' 2018-09-19 05:35:08.707326 | ubuntu-xenial | b' shadow_migrations.create_column(column.copy())' 2018-09-19 05:35:08.707475 | ubuntu-xenial | b' File "/home/zuul/src/git.openstack.org/openstack/nova/.tox/py35/lib/python3.5/site-packages/migrate/changeset/schema.py", line 475, in create_column' 2018-09-19 05:35:08.707538 | ubuntu-xenial | b'
[Yahoo-eng-team] [Bug 1455102] Re: some test jobs broken by tox 2.0 not passing env variables
** Changed in: python-manilaclient Status: Fix Committed => Fix Released ** Changed in: python-manilaclient Milestone: liberty-1 => None -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1455102 Title: some test jobs broken by tox 2.0 not passing env variables Status in Magnum: Fix Released Status in neutron: Fix Released Status in neutron kilo series: New Status in OpenStack-Gate: Confirmed Status in python-cinderclient: Fix Released Status in Glance Client: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-swiftclient: In Progress Status in OpenStack Object Storage (swift): Fix Released Bug description: Tox 2.0 brings environment isolation, which is good. Except a lot of test jobs assume passing critical variables via environment (like credentials). There are multiple ways to fix this: 1. stop using environment to pass things, instead use a config file of some sort 2. allow explicit pass through via - http://tox.readthedocs.org/en/latest/config.html#confval-passenv =SPACE-SEPARATED-GLOBNAMES This bug mostly exists for tracking patches, and ensuring that people realize there is a larger change here. To manage notifications about this bug go to: https://bugs.launchpad.net/magnum/+bug/1455102/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1629133] Re: New neutron subnet pool support breaks multinode testing.
** Also affects: manila Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629133 Title: New neutron subnet pool support breaks multinode testing. Status in devstack: In Progress Status in Ironic: New Status in Manila: New Status in neutron: New Bug description: The new subnet pool support in devstack breaks multinode testing bceause it results in the route for 10.0.0.0/8 being set to via br-ex when the host has interfaces that are actually on 10 nets and that is where we need the routes to go out. Multinode testing is affected because it uses these 10 net addresses to run the vxlan overlays between hosts. For many years devstack-gate has set FIXED_RANGE to ensure that the networks devstack uses do not interfere with the underlying test host's networking. However this setting was completely ignored when setting up the subnet pools. I think the correct way to fix this is to use a much smaller subnet pool range to avoid conflicting with every possible 10.0.0.0/8 network in the wild, possibly by defaulting to the existing FIXED_RANGE information. Using the existing information will help ensure that anyone with networks in 10.0.0.0/8 will continue to work if they have specified a range that doesn't conflict using this variable. In addition to this we need to clearly document what this new stuff in devstack does and how people can work around it should they conflict with the new defaults we end up choosing. I have proposed https://review.openstack.org/379543 which mostly works except it fails one tempest test that apparently depends on this new subnet pool stuff. Specifically the V6 range isn't large enough aiui. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1629133/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1508442] Re: LOG.warn is deprecated
** Also affects: manila Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1508442 Title: LOG.warn is deprecated Status in Aodh: In Progress Status in Glance: In Progress Status in Gnocchi: In Progress Status in Ironic: Fix Released Status in Ironic Inspector: Fix Released Status in ironic-lib: Fix Committed Status in ironic-python-agent: Fix Committed Status in OpenStack Identity (keystone): In Progress Status in kolla: Fix Released Status in Magnum: Fix Released Status in Manila: New Status in neutron: In Progress Status in nova-powervm: Fix Released Status in python-magnumclient: In Progress Status in tempest: In Progress Status in tripleo: New Status in zaqar: In Progress Bug description: LOG.warn is deprecated. But it still used in a few places, non- deprecated LOG.warning should be used instead. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1508442/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1503055] Re: Use AssertIsNone
** Also affects: manila Importance: Undecided Status: New ** No longer affects: manila -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1503055 Title: Use AssertIsNone Status in neutron: Confirmed Status in senlin: Fix Committed Bug description: Neutron should use the specific assertion: self.assertIs(Not)None(observed) instead of the generic assertion: self.assert(Not)Equal(None, observed) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1503055/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
