[Yahoo-eng-team] [Bug 1459943] [NEW] The API unit tests for serial console use http instead of ws
Public bug reported: AFAIK the serial console will only work if a websocket URL is returned, e.g. ws://127.0.0.1:6083/ [1] The API unit tests use http as scheme name [2], which could lead to misinterpretation of the capabilities of this feature. IMO they should use ws in the tests to avoid misleading. [1] table 3.53; http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html [2] https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/contrib/test_consoles.py#L42 ** Affects: nova Importance: Undecided Status: New ** Tags: api console testing ** Tags added: api testing -- 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/1459943 Title: The API unit tests for serial console use http instead of ws Status in OpenStack Compute (Nova): New Bug description: AFAIK the serial console will only work if a websocket URL is returned, e.g. ws://127.0.0.1:6083/ [1] The API unit tests use http as scheme name [2], which could lead to misinterpretation of the capabilities of this feature. IMO they should use ws in the tests to avoid misleading. [1] table 3.53; http://docs.openstack.org/kilo/config-reference/content/list-of-compute-config-options.html [2] https://github.com/openstack/nova/blob/master/nova/tests/unit/api/openstack/compute/contrib/test_consoles.py#L42 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459943/+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 1460044] [NEW] Data loss can occur if cinder attach fails
Public bug reported: Driver detach is not called while handling failure during Cinder's attach API. This can result in volume data loss for VMware driver since during driver attach, the instance VM is reconfigured with volume's vmdk. Subsequent delete of instance will delete the volume's vmdk since the instance is not reconfigured to remove the volume's vmdk even after attach failure. ** Affects: nova Importance: Undecided Assignee: Vipin Balachandran (vbala) Status: New ** Changed in: nova Assignee: (unassigned) = Vipin Balachandran (vbala) -- 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/1460044 Title: Data loss can occur if cinder attach fails Status in OpenStack Compute (Nova): New Bug description: Driver detach is not called while handling failure during Cinder's attach API. This can result in volume data loss for VMware driver since during driver attach, the instance VM is reconfigured with volume's vmdk. Subsequent delete of instance will delete the volume's vmdk since the instance is not reconfigured to remove the volume's vmdk even after attach failure. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460044/+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 1460043] [NEW] libvirt: number of CPUs is not updated after hotplugging host CPUs
Public bug reported: When adding or removing CPUs to a compute node running the libvirt driver, the correct new amount of CPUs is not reported to the controller/scheduler. As a result, the scheduler will not consider added or removed capacity in future scheduling decisions. To fix this, the number of CPUs on a compute node should not be cached in the libvirt driver. Instead it should be recalculated in the periodic task for updating resource availability. I'll provide a patch for fixing the bug along with a unit test. ** 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/1460043 Title: libvirt: number of CPUs is not updated after hotplugging host CPUs Status in OpenStack Compute (Nova): New Bug description: When adding or removing CPUs to a compute node running the libvirt driver, the correct new amount of CPUs is not reported to the controller/scheduler. As a result, the scheduler will not consider added or removed capacity in future scheduling decisions. To fix this, the number of CPUs on a compute node should not be cached in the libvirt driver. Instead it should be recalculated in the periodic task for updating resource availability. I'll provide a patch for fixing the bug along with a unit test. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460043/+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 1460060] [NEW] Glance v1 and v2 api returns 500 while passing --min-ram and --min-disk greater than 2^(31) max value
Public bug reported: glance image-create --name test --container-format bare --disk-format raw --file delete_images.py --min-disk 100 HTTPInternalServerError (HTTP 500) glance image-create --name test --container-format bare --disk-format raw --file delete_images.py --min-ram 100 HTTPInternalServerError (HTTP 500) ** Affects: glance Importance: Undecided Assignee: Pranali Deore (pranali-deore) Status: New ** Changed in: glance Assignee: (unassigned) = Pranali Deore (pranali-deore) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1460060 Title: Glance v1 and v2 api returns 500 while passing --min-ram and --min- disk greater than 2^(31) max value Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: glance image-create --name test --container-format bare --disk-format raw --file delete_images.py --min-disk 100 HTTPInternalServerError (HTTP 500) glance image-create --name test --container-format bare --disk-format raw --file delete_images.py --min-ram 100 HTTPInternalServerError (HTTP 500) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1460060/+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 1459726] Re: api servers hang with 100% CPU if syslog restarted
** Also affects: oslo.log
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/1459726
Title:
api servers hang with 100% CPU if syslog restarted
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Status in OpenStack Neutron (virtual network service):
New
Status in OpenStack Compute (Nova):
New
Status in Logging configuration library for OpenStack:
New
Bug description:
Affected:
glance-api
glance-registry
neutron-server
nova-api
If service was configured to use rsyslog and rsyslog was restarted
after API server started, it hangs on next log line with 100% CPU. If
server have few workers, each worker will eat own 100% CPU share.
Steps to reproduce:
1. Configure syslog:
use_syslog=true
syslog_log_facility=LOG_LOCAL4
2. restart api service
3. restart rsyslog
Execute some command to force logging. F.e.: neutron net-create foo,
nova boot, etc.
Expected result: normal operation
Actual result:
with some chance (about 30-50%) api server will hung with 100% CPU usage and
will not reply to request.
Strace on hung service:
gettimeofday({1432827199, 745141}, NULL) = 0
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}, {fd=5,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 6) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, 151keystonemiddleware.auth_token[12502]: DEBUG Authenticating
user token __call__
/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:650\0, 154,
0, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected)
gettimeofday({1432827199, 745226}, NULL) = 0
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}, {fd=5,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 6) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, 151keystonemiddleware.auth_token[12502]: DEBUG Authenticating
user token __call__
/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:650\0, 154,
0, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected)
gettimeofday({1432827199, 745325}, NULL) = 0
Tested on:
nova, glance, neutron: 1:2014.2.3, Ubuntu version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1459726/+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 1456437] Re: Devstack can not install openstack due to bad md5 hash code
** Project changed: nova = devstack -- 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/1456437 Title: Devstack can not install openstack due to bad md5 hash code Status in devstack - openstack dev environments: New Bug description: when using devstack to install stable branch openstack project, there may fail due to bad md5 hash .. 2015-05-18 19:51:25.980 | Obtaining file:///opt/stack/kilo/nova 2015-05-18 19:51:27.563 | Requirement already satisfied (use --upgrade to upgrade): pbr!=0.7,1.0,=0.6 in /usr/local/lib/python2.7/dist-packages (from nova==2015.1.1.dev13) 2015-05-18 19:51:27.566 | Requirement already satisfied (use --upgrade to upgrade): SQLAlchemy=0.9.99,=0.9.7 in /usr/local/lib/python2.7/dist-packages (from nova==2015.1.1.dev13) 2015-05-18 19:51:27.586 | Collecting boto=2.32.1 (from nova==2015.1.1.dev13) 2015-05-18 19:51:27.692 | Using cached boto-2.38.0-py2.py3-none-any.whl 2015-05-18 19:51:27.694 | Hash of the package https://pypi.python.org/packages/2.7/b/boto/boto-2.38.0-py2.py3-none-any.whl#md5=dd00fcddc668880494987bcb6102ecf2 (from https://pypi.python.org/simple/boto/) (39c6ea46c7f78b4ac829a0cf4ed6bbd3) doesn't match the expected hash dd00fcddc668880494987bcb6102ecf2! 2015-05-18 19:51:27.696 | Bad md5 hash for package https://pypi.python.org/packages/2.7/b/boto/boto-2.38.0-py2.py3-none-any.whl#md5=dd00fcddc668880494987bcb6102ecf2 (from https://pypi.python.org/simple/boto/) To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1456437/+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 1460053] [NEW] nova-compute fails with AttributeError: 'NoneType' object has no attribute 'get' after kilo upgrade
Public bug reported:
On compute node 'compute2', nova-compute fails to start with the
following exception:
2015-05-29 14:12:42.545 16355 ERROR nova.openstack.common.threadgroup
[req-a1d0fd3b-e3ff-48af-a568-4198ca22e3bc - - - - -] 'NoneType' object has no
attribute 'get'
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/nova/conductor/manager.py, line 422,
in _object_dispatch
return getattr(target, method)(*args, **kwargs)
File /usr/lib/python2.7/dist-packages/nova/objects/base.py, line 163, in
wrapper
result = fn(cls, context, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/nova/objects/instance.py, line 1152,
in get_by_host_and_node
expected_attrs)
File /usr/lib/python2.7/dist-packages/nova/objects/instance.py, line 1068,
in _make_instance_list
expected_attrs=expected_attrs)
File /usr/lib/python2.7/dist-packages/nova/objects/instance.py, line 501,
in _from_db_object
db_inst.get('extra').get('numa_topology'))
AttributeError: 'NoneType' object has no attribute 'get'
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup Traceback
(most recent call last):
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line
145, in wait
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
x.wait()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line
47, in wait
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
return self.thread.wait()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 175, in wait
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
return self._exit_event.wait()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/eventlet/event.py, line 121, in wait
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
return hubs.get_hub().switch()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 294, in switch
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
return self.greenlet.switch()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 214, in main
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
result = function(*args, **kwargs)
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/openstack/common/service.py, line 497,
in run_service
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
service.start()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/service.py, line 183, in start
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
self.manager.pre_start_hook()
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1291, in
pre_start_hook
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
self.update_available_resource(nova.context.get_admin_context())
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 6240, in
update_available_resource
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
rt.update_available_resource(context)
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/compute/resource_tracker.py, line 402,
in update_available_resource
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
self._update_available_resource(context, resources)
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py, line 445, in
inner
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
return f(*args, **kwargs)
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/compute/resource_tracker.py, line 436,
in _update_available_resource
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
'numa_topology'])
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/objects/base.py, line 161, in wrapper
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup args,
kwargs)
2015-05-29 14:12:42.545 16355 TRACE nova.openstack.common.threadgroup
[Yahoo-eng-team] [Bug 1460061] [NEW] Security issues reported by bandit
Public bug reported:
Using the tox target added in this review -
https://review.openstack.org/#/c/186752/
Use of exec detected.
- nova/cmd/manage.py::215
214
215 exec(compile(open(path).read(), path, 'exec'), locals(),
globals())
216
Use of insecure MD5 hash function.
- nova/utils.py::1131
1130returns string that represents hash of base_str (in hex
format).
1131return hashlib.md5(base_str).hexdigest()
1132
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/client/session.py::213
212 rv = self.call_plugin(plugin, fn, params)
213 return pickle.loads(rv)
214
Use of possibly insecure function - consider using safer ast.literal_eval.
- nova/virt/xenapi/client/session.py::291
290 # FIXME(comstud): eval is evil.
291 params = eval(exc.details[3])
292 except Exception:
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/fake.py::661
660 def _plugin_migration_transfer_vhd(self, method, args):
661 kwargs = pickle.loads(args['params'])['kwargs']
662 vdi_ref = self.xenapi_request('VDI.get_by_uuid',
Audit url open for permitted schemes. Allowing use of file:/ or custom
schemes is often unexpected.
- nova/virt/xenapi/vm_utils.py::1961
1960try:
1961xml = urllib.urlopen(%s://%s:%s@%s/vm_rrd?uuid=%s % (
1962server[0],
1963CONF.xenserver.connection_username,
1964CONF.xenserver.connection_password,
** 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/1460061
Title:
Security issues reported by bandit
Status in OpenStack Compute (Nova):
New
Bug description:
Using the tox target added in this review -
https://review.openstack.org/#/c/186752/
Use of exec detected.
- nova/cmd/manage.py::215
214
215 exec(compile(open(path).read(), path, 'exec'), locals(),
globals())
216
Use of insecure MD5 hash function.
- nova/utils.py::1131
1130 returns string that represents hash of base_str (in hex
format).
1131 return hashlib.md5(base_str).hexdigest()
1132
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/client/session.py::213
212 rv = self.call_plugin(plugin, fn, params)
213 return pickle.loads(rv)
214
Use of possibly insecure function - consider using safer ast.literal_eval.
- nova/virt/xenapi/client/session.py::291
290 # FIXME(comstud): eval is evil.
291 params = eval(exc.details[3])
292 except Exception:
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/fake.py::661
660 def _plugin_migration_transfer_vhd(self, method, args):
661 kwargs = pickle.loads(args['params'])['kwargs']
662 vdi_ref = self.xenapi_request('VDI.get_by_uuid',
Audit url open for permitted schemes. Allowing use of file:/ or custom
schemes is often unexpected.
- nova/virt/xenapi/vm_utils.py::1961
1960 try:
1961 xml = urllib.urlopen(%s://%s:%s@%s/vm_rrd?uuid=%s % (
1962 server[0],
1963 CONF.xenserver.connection_username,
1964 CONF.xenserver.connection_password,
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1460061/+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 1460054] [NEW] Instance details: switch between tabs is not possible anymore
Public bug reported: Issue = It's not possible anymore to switch between the tabs in the Instance details view. Steps to reproduce == * launch an instance * go to the details view of that instance * click on tab console Expected behavior = The tab console opens Actual behavior === The tab overview is still in focus. The behavior is independent of the chosen tab. IOW, it's the same behavior when clicked on tabs Log or Action Log. Firebug shows: TypeError: horizon.conf.spinner_options is undefined Horizon log: 2015-05-28 15:54:55.100358 Not Found: /horizon/lib/bootstrap_datepicker/datepicker3.css 2015-05-28 15:54:55.100930 Not Found: /horizon/lib/rickshaw.css Same behavior with browsers Firefox and Chrome Logs Env. === * Devstack * Last horizon commit: 65db6d33aa40a202cd16ad60e08273f715a67745 * Last Nova commit: e5c169d15528a8e2eadb8eca668ea0d183cf8648 References == - ** Affects: horizon Importance: Undecided Status: New ** Description changed: Issue = It's not possible anymore to switch between the tabs in the Instance details view. - Steps to reproduce == * launch an instance * go to the details view of that instance * click on tab console - Expected behavior = The tab console opens - Actual behavior === The tab overview is still in focus. The behavior is independent of the chosen tab. IOW, it's the same behavior when clicked on tabs Log or Action Log. - Firebug shows: - TypeError: horizon.conf.spinner_options is undefined + Firebug shows: + TypeError: horizon.conf.spinner_options is undefined - Horizon log: - 2015-05-28 15:54:55.100358 Not Found: /horizon/lib/bootstrap_datepicker/datepicker3.css - 2015-05-28 15:54:55.100930 Not Found: /horizon/lib/rickshaw.css + Horizon log: + 2015-05-28 15:54:55.100358 Not Found: /horizon/lib/bootstrap_datepicker/datepicker3.css + 2015-05-28 15:54:55.100930 Not Found: /horizon/lib/rickshaw.css + + Same behavior with browsers Firefox and Chrome Logs Env. === * Devstack * Last horizon commit: 65db6d33aa40a202cd16ad60e08273f715a67745 * Last Nova commit: e5c169d15528a8e2eadb8eca668ea0d183cf8648 - References == - -- 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/1460054 Title: Instance details: switch between tabs is not possible anymore Status in OpenStack Dashboard (Horizon): New Bug description: Issue = It's not possible anymore to switch between the tabs in the Instance details view. Steps to reproduce == * launch an instance * go to the details view of that instance * click on tab console Expected behavior = The tab console opens Actual behavior === The tab overview is still in focus. The behavior is independent of the chosen tab. IOW, it's the same behavior when clicked on tabs Log or Action Log. Firebug shows: TypeError: horizon.conf.spinner_options is undefined Horizon log: 2015-05-28 15:54:55.100358 Not Found: /horizon/lib/bootstrap_datepicker/datepicker3.css 2015-05-28 15:54:55.100930 Not Found: /horizon/lib/rickshaw.css Same behavior with browsers Firefox and Chrome Logs Env. === * Devstack * Last horizon commit: 65db6d33aa40a202cd16ad60e08273f715a67745 * Last Nova commit: e5c169d15528a8e2eadb8eca668ea0d183cf8648 References == - To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1460054/+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 1460079] [NEW] Instance system metadata is sometimes overwritten by image metadata
Public bug reported: When an instance is first created, a copy of the metadata from the image/volume is saved into the instance system metadata. This provides an accurate point in time record of the metadata used to configure operate instance, even if the metadata on the image is later changed. For a long while though, much of the code would not use this instance system metadata, instead just fetching metadata from the image each time. This had an obvious problem in that if the image was deleted, those operations would not be able to get image metadata, even though it was recorded for posterity in the system metadata. So 2 commits were made to update Nova to fetch system metadata commit 8e575be75c80ea71a6ad8fb73e6ace1ed708938f Author: Xavier Queralt xquer...@redhat.com Date: Mon Aug 26 22:53:03 2013 +0200 Add methods to get image metadata from instance This patch adds a couple of utility functions that enclose all the logic for getting and parsing the image metadata stored in the instance's system metadata. First, this will try to fetch the metadata from the real image and will prevent it from failing if it is not available. It will be then merged with the image metadata stored during the instance creation. Related to bug #1039662 Change-Id: I2130caf19858585571b1199e27f0a98ad5f08701 commit 4389f2292a0177c8eedc0a398ceb3c5535a9ef82 Author: Xavier Queralt xquer...@redhat.com Date: Mon Aug 26 22:55:46 2013 +0200 Avoid errors on some actions when image not usable Using the metadata saved on instance creation, we can now get all the image related metadata we need from the instance itself. This patch replace the logic for getting the image metadata on some actions that shouldn't fail when the image is not accessible (create an snapshot, resize, migrate, rescue an instance or attach an interface). Fixes bug 1039662 Unfortunately the way the compute utils get_image_metadata method was designed, it first fetches the instance system metadata and then fetches the current metadata from the image (if it still exists). The system metadata fields are overwritten by those from the image. So, there remains a problem that many operations are going to be performing actions based on the metadata currently associated with the image, and not that associated with the instance. By good luck, this does not currently have too many serious ill effects, but with ever increasing use of image metadata for tuning instance hardware configuration this is becoming a more pressing problem. For example, if the hw_disk_bus=virtio when the instance was first booted, and then the image was later changed to use hw_disk_bus=scsi, then logic which hotplugs disks may mistakenly end up attempting to hotplug a SCSI disk instead of a virtio disk which the instance was initially booted with. The only code which should look at the image properties should be the initial boot operation. There after all code should be using the recorded instance system metadata, so it is making decisions that are consistent with those made when the instance was first booted. There is an exception for the rescue operation, which by its very nature should be using the metadata from the rescue image, not the original instance system meta, since the hardware configuration needs to match that of the rescue image requirements. ** 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/1460079 Title: Instance system metadata is sometimes overwritten by image metadata Status in OpenStack Compute (Nova): New Bug description: When an instance is first created, a copy of the metadata from the image/volume is saved into the instance system metadata. This provides an accurate point in time record of the metadata used to configure operate instance, even if the metadata on the image is later changed. For a long while though, much of the code would not use this instance system metadata, instead just fetching metadata from the image each time. This had an obvious problem in that if the image was deleted, those operations would not be able to get image metadata, even though it was recorded for posterity in the system metadata. So 2 commits were made to update Nova to fetch system metadata commit 8e575be75c80ea71a6ad8fb73e6ace1ed708938f Author: Xavier Queralt xquer...@redhat.com Date: Mon Aug 26 22:53:03 2013 +0200 Add methods to get image metadata from instance This patch adds a couple of utility functions that enclose all the logic for getting and parsing the image metadata stored in the instance's system metadata. First, this will try to fetch the metadata from the real image and will prevent it from failing if it is not available. It will be
[Yahoo-eng-team] [Bug 1460105] Re: Since end of 2014 IPv6 traffic causes host to reboot
** Project changed: openstack-community = 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/1460105 Title: Since end of 2014 IPv6 traffic causes host to reboot Status in OpenStack Neutron (virtual network service): New Bug description: We launch IPv6 traffic to a VM within an Openstack Host that has icehouse. Soon the host restarts. In /var/log/messages and /var/log/openvswitch/ovs-vswitchd.log we see multiple instances of this error: ovs-vswitchd: ovs|00025|odp_util(revalidator_20)|ERR|mask expected for non-Ethernet II frame We tried the same test on multiple other machines that have slightly different versions of neutron. Our conclusion is that the bug must have been introduced with : openstack-neutron.noarch 2014.1.3-5.el6 openstack-neutron-ml2.noarch 2014.1.3-5.el6 openstack-neutron-openvswitch.noarch 2014.1.3-5.el6 python-neutron.noarch 2014.1.3-5.el6 Machines with the above version (or later) will exhibit the bug. Machines with the following version will work fine: openstack-neutron.noarch 2014.1.3-4.el6 openstack-neutron-ml2.noarch 2014.1.3-4.el6 openstack-neutron-openvswitch.noarch 2014.1.3-4.el6 python-neutron.noarch 2014.1.3-4.el6 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460105/+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 1460105] [NEW] Since end of 2014 IPv6 traffic causes host to reboot
You have been subscribed to a public bug: We launch IPv6 traffic to a VM within an Openstack Host that has icehouse. Soon the host restarts. In /var/log/messages and /var/log/openvswitch/ovs-vswitchd.log we see multiple instances of this error: ovs-vswitchd: ovs|00025|odp_util(revalidator_20)|ERR|mask expected for non-Ethernet II frame We tried the same test on multiple other machines that have slightly different versions of neutron. Our conclusion is that the bug must have been introduced with : openstack-neutron.noarch 2014.1.3-5.el6 openstack-neutron-ml2.noarch 2014.1.3-5.el6 openstack-neutron-openvswitch.noarch 2014.1.3-5.el6 python-neutron.noarch 2014.1.3-5.el6 Machines with the above version (or later) will exhibit the bug. Machines with the following version will work fine: openstack-neutron.noarch 2014.1.3-4.el6 openstack-neutron-ml2.noarch 2014.1.3-4.el6 openstack-neutron-openvswitch.noarch 2014.1.3-4.el6 python-neutron.noarch 2014.1.3-4.el6 ** Affects: neutron Importance: Undecided Status: New -- Since end of 2014 IPv6 traffic causes host to reboot https://bugs.launchpad.net/bugs/1460105 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. -- 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 1459726] Re: api servers hang with 100% CPU if syslog restarted
May be. I'm not sure. Anyway, this is not nova/glance/neutron bug, but
python-eventlet, and it is mostly concerns for distributions, not for
developers.
** Also affects: python-eventlet (Ubuntu)
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/1459726
Title:
api servers hang with 100% CPU if syslog restarted
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Status in OpenStack Neutron (virtual network service):
New
Status in OpenStack Compute (Nova):
New
Status in Logging configuration library for OpenStack:
New
Status in python-eventlet package in Ubuntu:
New
Bug description:
Affected:
glance-api
glance-registry
neutron-server
nova-api
If service was configured to use rsyslog and rsyslog was restarted
after API server started, it hangs on next log line with 100% CPU. If
server have few workers, each worker will eat own 100% CPU share.
Steps to reproduce:
1. Configure syslog:
use_syslog=true
syslog_log_facility=LOG_LOCAL4
2. restart api service
3. restart rsyslog
Execute some command to force logging. F.e.: neutron net-create foo,
nova boot, etc.
Expected result: normal operation
Actual result:
with some chance (about 30-50%) api server will hung with 100% CPU usage and
will not reply to request.
Strace on hung service:
gettimeofday({1432827199, 745141}, NULL) = 0
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}, {fd=5,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 6) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, 151keystonemiddleware.auth_token[12502]: DEBUG Authenticating
user token __call__
/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:650\0, 154,
0, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected)
gettimeofday({1432827199, 745226}, NULL) = 0
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}, {fd=5,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 6) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, 151keystonemiddleware.auth_token[12502]: DEBUG Authenticating
user token __call__
/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:650\0, 154,
0, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected)
gettimeofday({1432827199, 745325}, NULL) = 0
Tested on:
nova, glance, neutron: 1:2014.2.3, Ubuntu version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1459726/+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 1414532] Re: asserts used in cache.py
** Also affects: glance/juno
Importance: Undecided
Status: New
** Changed in: glance/juno
Status: New = Fix Committed
** Changed in: glance/juno
Importance: Undecided = Low
** Changed in: glance/juno
Assignee: (unassigned) = Ian Cordasco (icordasc)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1414532
Title:
asserts used in cache.py
Status in OpenStack Image Registry and Delivery Service (Glance):
Fix Released
Status in Glance juno series:
Fix Committed
Status in OpenStack Security Advisories:
Won't Fix
Status in OpenStack Security Notes:
Fix Released
Bug description:
The asserts in the snippet below check at #2 to see if the HTTP method
match the HTTP methods actually specified in the patterns at #1.
/opt/stack/glance/glance/api/middleware/cache.py
PATTERNS = { --- #1
('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'),
('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'),
('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'),
('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$')
}
...
@staticmethod
def _match_request(request):
Determine the version of the url and extract the image id
:returns tuple of version and image id if the url is a
cacheable,
otherwise None
for ((version, method), pattern) in PATTERNS.items():
match = pattern.match(request.path_info)
try:
assert request.method == method --- #2
image_id = match.group(1)
# Ensure the image id we got looks like an image id to
filter
# out a URI like /images/detail. See LP Bug #879136
assert image_id != 'detail'
except (AttributeError, AssertionError):
continue
else:
return (version, method, image_id)
As stated in the Python documentation assert statements will not be evaluated
when the Python code is compiled with optimization flags. This means that
these
checks will not be properly executed and one can in that case call a specific
method with a completely different HTTP verb. This can result in security
issues.
For example think of having some filtering in place in front of the glance API
to maybe allow only certain API queries to come from certain IP addresses. For
example: 'the HTTP verb DELETE may only be executed from this IP range'. An
attacker can now specify a completely different HTTP verb such as GET and make
sure he still matches regular expressions at #1 and then bypass the firewall.
It's a bit of a hypothetical scenario but in general one should never ever do
error checking with assert statemetns. This should only be done for things
which can never realistically fail and that is simply not an assumption one
can
hold when it comes to untrusted input from the network.
For more information see
https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and
https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE
This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354
but it's not fixed and maybe it should even be a security issue hence why I
reported it again and tagged as a security vulnerability. I am not familiar
enough with the code base to make that call.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1414532/+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 1460116] [NEW] keepalived should have snmp support enabled
Public bug reported: Keepalived should be started with the `-x` switch to enable snmp integration. keepalived will connect to a local snmp daemon, as described in: http://vincent.bernat.im/en/blog/2011-keepalived-snmp-ipv6.html ** Affects: neutron Importance: Undecided Assignee: Abhishek Chanda (abhishek-i) Status: In Progress ** Tags: l3-ha ** Tags added: l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1460116 Title: keepalived should have snmp support enabled Status in OpenStack Neutron (virtual network service): In Progress Bug description: Keepalived should be started with the `-x` switch to enable snmp integration. keepalived will connect to a local snmp daemon, as described in: http://vincent.bernat.im/en/blog/2011-keepalived-snmp-ipv6.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460116/+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 1460150] [NEW] no way to get v3 openrc file
Public bug reported: The is currently no way to get a keystone v3 ready version of the openrc file. ** Affects: horizon Importance: Medium Assignee: David Lyle (david-lyle) 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/1460150 Title: no way to get v3 openrc file Status in OpenStack Dashboard (Horizon): New Bug description: The is currently no way to get a keystone v3 ready version of the openrc file. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1460150/+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 1460137] [NEW] Need openstack_dashboard/test/jasmine_test.py
Public bug reported: I noticed that openstack_dashboard/test/jasmine_test.py was not actually referenced (i.e. adding tests to it didn't cause the tests to be executed). This patch kindly removed the unused file. https://review.openstack.org/#/c/182786/ Now that _scripts.html has been untangled by a source re-organization, we have a way for openstack_dashboard to include .js files that are common to multiple dashboards. See https://review.openstack.org/#/c/185140/. For files that are ONLY used by one dashboard, the source and .spec files can be included from the enabled/_XX_abc.py files. However, for files that are common to multiple dashboards (like the API) I think we want a higher level openstack_dashboard/test/jasmine_tests.py to pull in test code common to multiple dashboards (so that it doesn't need to be duplicated in multiple enabled/* files. See also this patch which attempted to synchronize the jasmine_tests.py files (before one was removed). ** 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/1460137 Title: Need openstack_dashboard/test/jasmine_test.py Status in OpenStack Dashboard (Horizon): New Bug description: I noticed that openstack_dashboard/test/jasmine_test.py was not actually referenced (i.e. adding tests to it didn't cause the tests to be executed). This patch kindly removed the unused file. https://review.openstack.org/#/c/182786/ Now that _scripts.html has been untangled by a source re-organization, we have a way for openstack_dashboard to include .js files that are common to multiple dashboards. See https://review.openstack.org/#/c/185140/. For files that are ONLY used by one dashboard, the source and .spec files can be included from the enabled/_XX_abc.py files. However, for files that are common to multiple dashboards (like the API) I think we want a higher level openstack_dashboard/test/jasmine_tests.py to pull in test code common to multiple dashboards (so that it doesn't need to be duplicated in multiple enabled/* files. See also this patch which attempted to synchronize the jasmine_tests.py files (before one was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1460137/+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 1460176] [NEW] Reschedules sometimes do not allocate networks
Public bug reported: https://gist.github.com/jimrollenhagen/b6b45aa43878cdc89d89 Fixed by https://review.openstack.org/#/c/177470/ ** Affects: nova Importance: Undecided Status: Fix Released ** Changed in: nova Status: New = Fix Committed ** Changed in: nova Status: Fix Committed = 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/1460176 Title: Reschedules sometimes do not allocate networks Status in OpenStack Compute (Nova): Fix Released Bug description: https://gist.github.com/jimrollenhagen/b6b45aa43878cdc89d89 Fixed by https://review.openstack.org/#/c/177470/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460176/+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 1460220] [NEW] ipset functional tests assume system capability
Public bug reported: Production code uses ipset in the root namespace, but functional testing uses them in non-root namespaces. As it turns out, that functionality requires versions of the kernel and ipset not found in all versions of all distributions. ** Affects: neutron Importance: Low Assignee: Assaf Muller (amuller) Status: New ** Changed in: neutron Assignee: (unassigned) = Assaf Muller (amuller) ** Changed in: neutron Importance: Undecided = Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1460220 Title: ipset functional tests assume system capability Status in OpenStack Neutron (virtual network service): New Bug description: Production code uses ipset in the root namespace, but functional testing uses them in non-root namespaces. As it turns out, that functionality requires versions of the kernel and ipset not found in all versions of all distributions. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460220/+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 1460222] [NEW] Add 'labels', a list of opaque strings, to the neutron 'port' object
Public bug reported:
*What is being requested*
This request is to add an attribute 'labels' to the neutron 'port'
object. The type of 'labels' is a list of strings.
*Why is it being requested*
There are many use cases in which you wish to provide hint-by-reference
to downstream providers of neutron services (like controllers) for which
you would like to allow the user to provide hint-by-reference about the
nature of the port and the service it should receive.
In the parlance of the Neutron API Documentation:
Object: ports
Parameter: labels
Style: plain
Type: xsd:list
Description: A list of opaque strings to be interpreted as
hints-by-reference by the neutron provider
*Examples*
1) Indicate the Network Policy that should be applied to the port. Most
network policy systems resolve policy based upon the
'Endpoint Group(s)' (abbreviated EPGs) and Endpoint (think port) (abbreviated
EP) is placed in. 'labels' could be used to indicate EPG membership for a
port. For example:
{
port: {
labels: [ epg:blue, epg:green ],
...
}
}
2) Indicate the type of Virtual Network Function (VNF) of the VM being
deployed on the port. This would be important for a controller
rendering Service Function Chains (SFCs) to know so that it knew it had
additional VNFs of that type to use in the SFCs it was constructing.
For example:
{
port: {
labels: [ vnf-type:firewall-3 ],
...
}
}
*Who needs it*
This is needed to assist the OpenDaylight Controller in being able to
better provide the Policy and SFC services. However, this mechanism is
agnostic as to the underlying controller, and also can be used for a
variety of other useful purposes. Anywhere that it would be useful to
pass on hints-by-reference to downstream providers could take advantage
of it.
** Affects: neutron
Importance: Undecided
Status: Confirmed
** Tags: labels
** Description changed:
*What is being requested*
This request is to add an attribute 'labels' to the neutron 'port'
object. The type of 'labels' is a list of strings.
*Why is it being requested*
There are many use cases in which you wish to provide hint-by-reference
to downstream providers of neutron services (like controllers) for which
you would like to allow the user to provide hint-by-reference about the
nature of the port and the service it should receive.
In the parlance of the Neutron API Documentation:
-
- | Parameter | Style | Type | Description
|
-
---
- | labels | plain | xsd:list | A list of opaque strings to be
interpreted as hints-by-reference by the neutron provider |
-
-
+ **
+ | Parameter | Style | Type | Description |
|
+ --
+ | labels| plain | xsd:list | A list of opaque strings to be|
+ | || | interpreted as hints-by-reference by |
+ | || | the neutron provider |
+ **
- Examples:
+ *Examples*
1) Indicate the Network Policy that should be applied to the port. Most
network policy systems resolve policy based upon the
'Endpoint Group(s)' (abbreviated EPGs) and Endpoint (think port) (abbreviated
EP) is placed in. 'labels' could be used to indicate EPG membership for a
port. For example:
- {
- port: {
- labels: [ epg:blue, epg:green ],
-...
-}
+ {
+ port: {
+ labels: [ epg:blue, epg:green ],
+ ...
+ }
}
-
2) Indicate the type of Virtual Network Function (VNF) of the VM being
deployed on the port. This would be important for a controller
rendering Service Function Chains (SFCs) to know so that it knew it had
additional VNFs of that type to use in the SFCs it was constructing.
For example:
- {
- port: {
- labels: [ vnf-type:firewall-3 ],
-...
-}
+ {
+ port: {
+ labels: [ vnf-type:firewall-3 ],
+ ...
+ }
}
-
*Who needs it*
This is needed to assist the OpenDaylight Controller in being able to
better provide the Policy and SFC services.
[Yahoo-eng-team] [Bug 1460233] [NEW] ovs calls scale linearly with number of ports on agent startup
Public bug reported: There are a couple of places where multiple ovs calls are made for every port that is being plumbed on the agent startup. This leads to hundreds of calls just to startup the agent even when there are 30 ports. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Assignee: (unassigned) = Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1460233 Title: ovs calls scale linearly with number of ports on agent startup Status in OpenStack Neutron (virtual network service): New Bug description: There are a couple of places where multiple ovs calls are made for every port that is being plumbed on the agent startup. This leads to hundreds of calls just to startup the agent even when there are 30 ports. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460233/+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 1338679] Re: Some Neutron plugins might miss network-vif-* events
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete = Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1338679 Title: Some Neutron plugins might miss network-vif-* events Status in OpenStack Neutron (virtual network service): Expired Status in OpenStack Compute (Nova): Invalid Bug description: This has been observed with the VMware NSX plugin, but in theory this issue might occur with every Neutron plugin when the notifications to nova are enabled. In a nutshell the issue is that nova needs to receive a network-vif- plugged even from neutron in order to be able to boot an instance. On the other hand in some cases VIF unplug/plug events might be fairly quick, and thus the neutron side might not be aware at all of the status change and not send any event. As a consequence, the instance will not boot even if its VIF are correctly plugged. This bug is currently being assigned both neutron and nova because: - it might deemed a plugin problem. If the plugin is not smart enough to handle VIF plug/unplug notifications than it's not worth using the notification mechanism exposed by nova - the nova side might add an optional poll mechanism which could run alongside the mechanism waiting for an event and periodically poll neutron to get the VIF status. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1338679/+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 1460177] [NEW] Support metadata service with IPv6 only tenant network
Public bug reported: EC2 metatdata service is supported by nova metadata service that is running in the management network. Cloud-init running in the instance normally accesses the service at 169.254.169.254. Cloud-init can be configured with metadata_urls other than the default http://169.254.169.254 to access the service. But such configuration is not currently supported by openstack. In order for the instance to access the nova metadata service, neutron provides proxy service that terminates http://169.254.169.254 and forwards the request to the nova metadata service. Apparently, this works only when IPv4 is available in the tenant network. For an IPv6 only tenant work, to continue the support of this service, the instance has to access it at an IPv6 address. This requires enhancement in Neutron to support it. A few options have been discussed so far: -- define a well-known ipv6 link-local address to access the metadata service. -- enhance IPv6 RA to advertise the metadata service endpoint to instances. This would require standards work and enhance cloud-init to support it. -- define a well-known name for the metadata service and configure metadata_urls to use the name. The name will be resolved to a datacenter specific IP address. The corresponding DNS record should be pre-provisioned in the datacenter DNS server for the instance to resolve the name. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1460177 Title: Support metadata service with IPv6 only tenant network Status in OpenStack Neutron (virtual network service): New Bug description: EC2 metatdata service is supported by nova metadata service that is running in the management network. Cloud-init running in the instance normally accesses the service at 169.254.169.254. Cloud-init can be configured with metadata_urls other than the default http://169.254.169.254 to access the service. But such configuration is not currently supported by openstack. In order for the instance to access the nova metadata service, neutron provides proxy service that terminates http://169.254.169.254 and forwards the request to the nova metadata service. Apparently, this works only when IPv4 is available in the tenant network. For an IPv6 only tenant work, to continue the support of this service, the instance has to access it at an IPv6 address. This requires enhancement in Neutron to support it. A few options have been discussed so far: -- define a well-known ipv6 link-local address to access the metadata service. -- enhance IPv6 RA to advertise the metadata service endpoint to instances. This would require standards work and enhance cloud-init to support it. -- define a well-known name for the metadata service and configure metadata_urls to use the name. The name will be resolved to a datacenter specific IP address. The corresponding DNS record should be pre-provisioned in the datacenter DNS server for the instance to resolve the name. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1460177/+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 1460206] [NEW] gate-nova-python34 fails to install rfc3986 due to UnicodeDecodeError
Public bug reported: This non-voting job just got turned on yesterday and it's failing consistently: http://logs.openstack.org/15/186315/4/check/gate-nova- python34/c48b0f5/console.html#_2015-05-29_15_57_16_241 2015-05-29 15:57:16.241 | Collecting rfc3986=0.2.0 (from -r /home/jenkins/workspace/gate-nova-python34/requirements.txt (line 46)) 2015-05-29 15:57:16.241 | Downloading http://pypi.region-b.geo-1.openstack.org/packages/source/r/rfc3986/rfc3986-0.2.2.tar.gz 2015-05-29 15:57:16.241 | Complete output from command python setup.py egg_info: 2015-05-29 15:57:16.241 | Traceback (most recent call last): 2015-05-29 15:57:16.242 | File string, line 20, in module 2015-05-29 15:57:16.242 | File /tmp/tmp.ALfXvU5OeC/pip-build-ottfpn10/rfc3986/setup.py, line 22, in module 2015-05-29 15:57:16.242 | readme = f.read() 2015-05-29 15:57:16.242 | File /home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/encodings/ascii.py, line 26, in decode 2015-05-29 15:57:16.242 | return codecs.ascii_decode(input, self.errors)[0] 2015-05-29 15:57:16.242 | UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1030: ordinal not in range(128) 2015-05-29 15:57:16.242 | 2015-05-29 15:57:16.242 | 2015-05-29 15:57:16.242 | Command python setup.py egg_info failed with error code 1 in /tmp/tmp.ALfXvU5OeC/pip-build-ottfpn10/rfc3986 pypi says that library supports python 3.4, so maybe something from the distro is required for this to work? nova doesn't have a requirements- py3.txt file, not sure if we don't need this for py34? ** Affects: nova Importance: Medium Status: Confirmed ** Tags: py3 testing ** Changed in: nova Status: New = Confirmed ** Changed in: nova Importance: Undecided = Medium -- 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/1460206 Title: gate-nova-python34 fails to install rfc3986 due to UnicodeDecodeError Status in OpenStack Compute (Nova): Confirmed Bug description: This non-voting job just got turned on yesterday and it's failing consistently: http://logs.openstack.org/15/186315/4/check/gate-nova- python34/c48b0f5/console.html#_2015-05-29_15_57_16_241 2015-05-29 15:57:16.241 | Collecting rfc3986=0.2.0 (from -r /home/jenkins/workspace/gate-nova-python34/requirements.txt (line 46)) 2015-05-29 15:57:16.241 | Downloading http://pypi.region-b.geo-1.openstack.org/packages/source/r/rfc3986/rfc3986-0.2.2.tar.gz 2015-05-29 15:57:16.241 | Complete output from command python setup.py egg_info: 2015-05-29 15:57:16.241 | Traceback (most recent call last): 2015-05-29 15:57:16.242 | File string, line 20, in module 2015-05-29 15:57:16.242 | File /tmp/tmp.ALfXvU5OeC/pip-build-ottfpn10/rfc3986/setup.py, line 22, in module 2015-05-29 15:57:16.242 | readme = f.read() 2015-05-29 15:57:16.242 | File /home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/encodings/ascii.py, line 26, in decode 2015-05-29 15:57:16.242 | return codecs.ascii_decode(input, self.errors)[0] 2015-05-29 15:57:16.242 | UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1030: ordinal not in range(128) 2015-05-29 15:57:16.242 | 2015-05-29 15:57:16.242 | 2015-05-29 15:57:16.242 | Command python setup.py egg_info failed with error code 1 in /tmp/tmp.ALfXvU5OeC/pip-build-ottfpn10/rfc3986 pypi says that library supports python 3.4, so maybe something from the distro is required for this to work? nova doesn't have a requirements-py3.txt file, not sure if we don't need this for py34? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460206/+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 1460176] Re: Reschedules sometimes do not allocate networks
stable/kilo backport: https://review.openstack.org/#/c/186873/ ** Also affects: nova/kilo Importance: Undecided Status: New ** Changed in: nova Milestone: None = liberty-1 -- 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/1460176 Title: Reschedules sometimes do not allocate networks Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) kilo series: New Bug description: https://gist.github.com/jimrollenhagen/b6b45aa43878cdc89d89 Fixed by https://review.openstack.org/#/c/177470/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1460176/+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
