[Yahoo-eng-team] [Bug 1379663] [NEW] After upgrading - ovs-vswitchd cannot add existing ports
Public bug reported: Hi there, After upgrading (stop all services, yum upgrade, db sync) from older Icehouse build to latest Icehouse build, my compute node (specifically openstack-nova-compute) cannot be started. I deployed a number of instances before upgrade, and after upgrading openstack-nova-compute refuses to start up. The logs seem to point to some issue with ovs- vswitch unable to bind ports of the existing instances. All other services at controller and network nodes seem to be running fine. And before upgrading, everything was working fine. # rpm -qa | grep openstack-nova openstack-nova-compute-2014.1.2-1.el6.noarch openstack-nova-common-2014.1.2-1.el6.noarch At compute.log: 2014-10-10 14:37:39.372 24897 ERROR nova.openstack.common.threadgroup [-] Unexpected vif_type=binding_failed 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup Traceback (most recent call last): 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py, line 117, in wait 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup x.wait() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py, line 49, in wait 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup return self.thread.wait() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/eventlet/greenthread.py, line 173, in wait 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup return self._exit_event.wait() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/eventlet/event.py, line 121, in wait 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup return hubs.get_hub().switch() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/eventlet/hubs/hub.py, line 293, in switch 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup return self.greenlet.switch() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/eventlet/greenthread.py, line 212, in main 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup result = function(*args, **kwargs) 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/openstack/common/service.py, line 486, in run_service 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup service.start() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/service.py, line 163, in start 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup self.manager.init_host() 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 1044, in init_host 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup self._init_instance(context, instance) 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/compute/manager.py, line 902, in _init_instance 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup self.driver.plug_vifs(instance, net_info) 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py, line 860, in plug_vifs 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup self.vif_driver.plug(instance, vif) 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.6/site-packages/nova/virt/libvirt/vif.py, line 616, in plug 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup _(Unexpected vif_type=%s) % vif_type) 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup NovaException: Unexpected vif_type=binding_failed 2014-10-10 14:37:39.372 24897 TRACE nova.openstack.common.threadgroup At ovs-vswitchd.log: 2014-10-10T06:37:38Z|00377|dpif|WARN|Dropped 9 log messages in last 17953 seconds (most recently, 17952 seconds ago) due to excessive rate 2014-10-10T06:37:38Z|00378|dpif|WARN|system@ovs-system: port_del failed (Invalid argument) 2014-10-10T06:37:38Z|00379|netdev_linux|WARN|Dropped 8 log messages in last 17953 seconds (most recently, 17952 seconds ago) due to excessive rate 2014-10-10T06:37:38Z|00380|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on network device qvo1a5fea4a-6e failed: No such device 2014-10-10T06:37:38Z|00381|dpif|WARN|system@ovs-system: failed to add qvo1a5fea4a-6e as port: No such device 2014-10-10T06:37:38Z|00382|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS on
[Yahoo-eng-team] [Bug 1379666] [NEW] unable to Ping my external IP
Public bug reported: iam unable to ping my External Ip address, and in my router details my external network is down. ** 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/1379666 Title: unable to Ping my external IP Status in OpenStack Neutron (virtual network service): New Bug description: iam unable to ping my External Ip address, and in my router details my external network is down. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1379666/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379682] [NEW] instance_template_name does not work for vmware driver
Public bug reported: Currently vmware driver will adopt uuid for instance names. This will lead two problems: 1) instance name template will not apply for vmware driver. But it will display instance name with nova show command. It will be misleading. [root@cmwo cmwo]# nova show temp-vm-host1-99 +--+---+ | Property | Value | +--+---+ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | cluster01 | | OS-EXT-SRV-ATTR:host | vcenter-cluster01 | | OS-EXT-SRV-ATTR:hypervisor_hostname | domain-c129(cluster01) | | OS-EXT-SRV-ATTR:instance_name| instance-00ec | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state| - | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2014-10-09T10:02:15.00 | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2014-10-09T09:59:15Z | | demovlan network | 25.0.0.21 | | flavor | m1.tiny (1) | | hostId | 0cfba386e1e5cad832d2fbc316c33ca6a124c3d0b386127a55707070 | | id | 6d3e0f11-0a4c-46eb-a3a6-4e397d917228 | 2) This uuid is not user friendly for VM names. ** Affects: nova Importance: Undecided Status: New ** Tags: vmware ** Tags added: vmware -- 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/1379682 Title: instance_template_name does not work for vmware driver Status in OpenStack Compute (Nova): New Bug description: Currently vmware driver will adopt uuid for instance names. This will lead two problems: 1) instance name template will not apply for vmware driver. But it will display instance name with nova show command. It will be misleading. [root@cmwo cmwo]# nova show temp-vm-host1-99 +--+---+ | Property | Value | +--+---+ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | cluster01 | | OS-EXT-SRV-ATTR:host | vcenter-cluster01 | | OS-EXT-SRV-ATTR:hypervisor_hostname | domain-c129(cluster01) | | OS-EXT-SRV-ATTR:instance_name| instance-00ec | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state| - | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2014-10-09T10:02:15.00 | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2014-10-09T09:59:15Z | | demovlan network
[Yahoo-eng-team] [Bug 1379684] [NEW] Remove 'require_admin_context' from sqlalchemy api
Public bug reported: There are still many 'require_admin_context' defined for db operation, which prevent rbac definition in policy.json. For example, a user defined non-admin role to manage quota will not be able to modify quota size. Plan to remove 'require_admin_context' from sqlalchemy module, so that we only use policy to do those permission checking. ** 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/1379684 Title: Remove 'require_admin_context' from sqlalchemy api Status in OpenStack Compute (Nova): New Bug description: There are still many 'require_admin_context' defined for db operation, which prevent rbac definition in policy.json. For example, a user defined non-admin role to manage quota will not be able to modify quota size. Plan to remove 'require_admin_context' from sqlalchemy module, so that we only use policy to do those permission checking. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1379684/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1378968] Re: Metadef schema column name is a reserved word in MySQL
Reviewed: https://review.openstack.org/127317 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=f259cac74d3e988b4012dcc2abd30091df27f5ce Submitter: Jenkins Branch:proposed/juno commit f259cac74d3e988b4012dcc2abd30091df27f5ce Author: Wayne Okuma wayne.ok...@hp.com Date: Wed Oct 8 08:17:20 2014 -0700 Metadef schema column name is a reserved word in MySQL The metadef_properties and metadef_objects tables both have a column named schema. Unfortunately, schema is a reserved word in some relational database products, including MySQL and PostgreSQL. The metadef_properties.schema and metadef_objects.schema columns should be renamed to a non reserved word. Conflicts: glance/db/sqlalchemy/metadata.py glance/tests/unit/test_migrations.py Change-Id: I9c1b497d2b09b9282a83bd8c19c32edfa4dd159f Closes-Bug: 1378968 ** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1378968 Title: Metadef schema column name is a reserved word in MySQL Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: The metadef_properties and metadef_objects tables both have a column named schema. Unfortunately, schema is a reserved word in some relational database products, including MySQL and PostgreSQL. The metadef_properties.schema and metadef_objects.schema columns should be renamed to a non reserved word. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1378968/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1378866] Re: leftover router ports
Reviewed: https://review.openstack.org/127357 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8e76cccb1ed9a248439b1188d1d805649169e46b Submitter: Jenkins Branch:proposed/juno commit 8e76cccb1ed9a248439b1188d1d805649169e46b Author: Mark McClain mmccl...@yahoo-inc.com Date: Wed Oct 8 18:49:20 2014 + Add database relationship between router and ports Add an explicit schema relationship between a router and its ports. This change ensures referential integrity among the entities and prevents orphaned ports. Change-Id: I09e8a694cdff7f64a642a39b45cbd12422132806 Closes-Bug: #1378866 (cherry picked from commit 93012915a3445a8ac8a0b30b702df30fe728) ** Changed in: neutron 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/1378866 Title: leftover router ports Status in OpenStack Neutron (virtual network service): Fix Released Bug description: During testing, we've found some instances of leftover router ports. The ports are not properly cleaned up when a router is removed. The user is able to manually remove the ports to work around the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1378866/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1378855] Re: juno capstone migration is missing
Reviewed: https://review.openstack.org/127359 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9cce0bfdb713c2b975b289d90de6d57b68ca3854 Submitter: Jenkins Branch:proposed/juno commit 9cce0bfdb713c2b975b289d90de6d57b68ca3854 Author: Mark McClain mmccl...@yahoo-inc.com Date: Thu Oct 9 13:29:48 2014 + Add Juno release milestone Change-Id: Iea584b00329d9474c14847db958f8743d4058525 Closes-Bug: #1378855 (cherry picked from commit 4e8a5b7de71ba6f8c050c424613c025310498940) ** Changed in: neutron 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/1378855 Title: juno capstone migration is missing Status in OpenStack Neutron (virtual network service): Fix Released Bug description: The Juno capstone migration is missing. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1378855/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379711] [NEW] Error log emit when running tox like “Extension path 'unit/extensions' doesn't exist!”
Public bug reported: when I use tox to test some case like below, it could pass, but some err log will print. #tox -epy27 -vvv neutron.tests.unit.ml2.drivers.cisco.nexus.test_cisco_mech.TestCiscoPortsV2.test_update_port_add_additional_ip ... 2014-10-10 16:53:48,003 INFO [neutron.plugins.ml2.drivers.type_tunnel] vxlan ID ranges: [] 2014-10-10 16:53:48,004 INFO [neutron.plugins.ml2.managers] Initializing mechanism driver 'cisco_nexus' 2014-10-10 16:53:48,005 INFO [neutron.plugins.ml2.plugin] Modular L2 Plugin initialization complete 2014-10-10 16:53:48,005 WARNING [neutron.agent.securitygroups_rpc] Driver configuration doesn't match with enable_security_group 2014-10-10 16:53:48,005ERROR [neutron.api.extensions] Extension path 'unit/extensions' doesn't exist! ... although the test passed, but the path defined in neutron/tests/etc/neutron.conf.test unit/extensions seems should be ./neutron/tests/unit/extensions ** 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/1379711 Title: Error log emit when running tox like “Extension path 'unit/extensions' doesn't exist!” Status in OpenStack Neutron (virtual network service): New Bug description: when I use tox to test some case like below, it could pass, but some err log will print. #tox -epy27 -vvv neutron.tests.unit.ml2.drivers.cisco.nexus.test_cisco_mech.TestCiscoPortsV2.test_update_port_add_additional_ip ... 2014-10-10 16:53:48,003 INFO [neutron.plugins.ml2.drivers.type_tunnel] vxlan ID ranges: [] 2014-10-10 16:53:48,004 INFO [neutron.plugins.ml2.managers] Initializing mechanism driver 'cisco_nexus' 2014-10-10 16:53:48,005 INFO [neutron.plugins.ml2.plugin] Modular L2 Plugin initialization complete 2014-10-10 16:53:48,005 WARNING [neutron.agent.securitygroups_rpc] Driver configuration doesn't match with enable_security_group 2014-10-10 16:53:48,005ERROR [neutron.api.extensions] Extension path 'unit/extensions' doesn't exist! ... although the test passed, but the path defined in neutron/tests/etc/neutron.conf.test unit/extensions seems should be ./neutron/tests/unit/extensions To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1379711/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379774] [NEW] 017_quote_encrypted_swift_credentials is a NOOP
Public bug reported: After running glance-manage db_sync I saw the following entry in the log messages. I am not sure if this is intended. I have not configured Swift as a storage adapter. But I think that should not change the database schema? 2014-10-10 12:16:10.362 12396 INFO 017_quote_encrypted_swift_credentials [-] 'metadata_encryption_key' was not specified in the config file or a config file was not specified. This means that this migration is a NOOP. ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1379774 Title: 017_quote_encrypted_swift_credentials is a NOOP Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: After running glance-manage db_sync I saw the following entry in the log messages. I am not sure if this is intended. I have not configured Swift as a storage adapter. But I think that should not change the database schema? 2014-10-10 12:16:10.362 12396 INFO 017_quote_encrypted_swift_credentials [-] 'metadata_encryption_key' was not specified in the config file or a config file was not specified. This means that this migration is a NOOP. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1379774/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379775] [NEW] Messaging enabled by default in Juno
Public bug reported: After configuration Glance using the latest Juno RC packages I got the following issue when trying to upload an image: 2014-10-10 12:26:13.015 12703 ERROR oslo.messaging._drivers.impl_rabbit [bed8aa08-d1f3-4089-9286-beadc9faeba4 7bd2899605ab4037892e1d48b144f3a6 c637c767fa044299be5a7d5df65a4db7 - - -] AMQP server localhost:5672 closed the connection. Check login credentials: Socket closed According to the documentation the notification driver should be 'noop' by default (https://github.com/openstack/glance/blob/master/etc/glance- api.conf#L237-L239). But it looks like this parameter has no more function in Juno and that only the rpc_backend parameter is relevant and that messaging is enabled by default and cannot be disabled. ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1379775 Title: Messaging enabled by default in Juno Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: After configuration Glance using the latest Juno RC packages I got the following issue when trying to upload an image: 2014-10-10 12:26:13.015 12703 ERROR oslo.messaging._drivers.impl_rabbit [bed8aa08-d1f3-4089-9286-beadc9faeba4 7bd2899605ab4037892e1d48b144f3a6 c637c767fa044299be5a7d5df65a4db7 - - -] AMQP server localhost:5672 closed the connection. Check login credentials: Socket closed According to the documentation the notification driver should be 'noop' by default (https://github.com/openstack/glance/blob/master/etc /glance-api.conf#L237-L239). But it looks like this parameter has no more function in Juno and that only the rpc_backend parameter is relevant and that messaging is enabled by default and cannot be disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1379775/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379779] [NEW] neutron-openvswitch-agent fails to apply iptables rules
Public bug reported:
2014-10-10 12:49:19.947 4498 ERROR
neutron.plugins.openvswitch.agent.ovs_neutron_agent
[req-4865cb3b-e783-4368-82c4-6d585ba08248 None] Error while processing VIF ports
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent Traceback (most recent call
last):
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py,
line 1406, in rpc_loop
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent ovs_restarted)
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py,
line 1205, in process_network_ports
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
port_info.get('updated', set()))
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/securitygroups_rpc.py, line
316, in setup_port_filters
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
self.prepare_devices_filter(new_devices)
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/securitygroups_rpc.py, line
211, in prepare_devices_filter
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent security_groups,
security_group_member_ips)
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent self.gen.next()
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/firewall.py, line 106, in
defer_apply
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
self.filter_defer_apply_off()
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/linux/iptables_firewall.py,
line 557, in filter_defer_apply_off
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
self.iptables.defer_apply_off()
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/linux/iptables_manager.py,
line 373, in defer_apply_off
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent self._apply()
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/linux/iptables_manager.py,
line 389, in _apply
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent return
self._apply_synchronized()
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/linux/iptables_manager.py,
line 444, in _apply_synchronized
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent '\n'.join(log_lines))
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/openstack/common/excutils.py, line
82, in __exit__
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent six.reraise(self.type_,
self.value, self.tb)
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/linux/iptables_manager.py,
line 423, in _apply_synchronized
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
root_helper=self.root_helper)
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py, line 84, in
execute
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent raise RuntimeError(m)
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent RuntimeError:
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent Command: ['sudo',
'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'iptables-restore', '-c']
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent Exit code: 2
2014-10-10 12:49:19.947 4498 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent Stdout: ''
2014-10-10 12:49:19.947 4498 TRACE
[Yahoo-eng-team] [Bug 1379775] Re: Messaging enabled by default in Juno
I think there should be a a noop oslo.messaging driver. This way it should be possible to disable messaging in Glance using noop as rpc_backend. ** Also affects: oslo.messaging Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1379775 Title: Messaging enabled by default in Juno Status in OpenStack Image Registry and Delivery Service (Glance): New Status in Messaging API for OpenStack: In Progress Bug description: After configuration Glance using the latest Juno RC packages I got the following issue when trying to upload an image: 2014-10-10 12:26:13.015 12703 ERROR oslo.messaging._drivers.impl_rabbit [bed8aa08-d1f3-4089-9286-beadc9faeba4 7bd2899605ab4037892e1d48b144f3a6 c637c767fa044299be5a7d5df65a4db7 - - -] AMQP server localhost:5672 closed the connection. Check login credentials: Socket closed According to the documentation the notification driver should be 'noop' by default (https://github.com/openstack/glance/blob/master/etc /glance-api.conf#L237-L239). But it looks like this parameter has no more function in Juno and that only the rpc_backend parameter is relevant and that messaging is enabled by default and cannot be disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1379775/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379358] Re: Changes in openstack_dashboard/conf/*policy.json won't take effect for Panel visibility until User re-logins
@Thiago, sure, the fix should be pretty simple, will upload it in a while. ** Changed in: horizon Status: Opinion = Confirmed -- 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/1379358 Title: Changes in openstack_dashboard/conf/*policy.json won't take effect for Panel visibility until User re-logins Status in OpenStack Dashboard (Horizon): Confirmed Bug description: The Panel class is a subclass of HorizonComponent class, which should check `self.policy_rules` while determining whether the entity is visible or not. Unfortunately the actual values `self.policy_rules` relies upon are being loaded during first request to Horizon, also the final result of checking whether Panel is visible or not will be cached in user session. Speaking of concrete example, for Identity - Users panel https://github.com/openstack/horizon/blob/2014.2.rc1/openstack_dashboard/dashboards/identity/users/panel.py#L29 you can check it yourself by changing both rules in https://github.com/openstack/horizon/blob/2014.2.rc1/openstack_dashboard/conf/keystone_policy.json#L43 to ! and see that the panel is still visible - until you _both_ reload Horizon and re-login to clear session. After that it will be hidden. While reloading Horizon is fine - because changing kind of server settings is involved, the need to sign-out and the sign-in for the visibility changes to take effect is not. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1379358/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379779] Re: neutron-openvswitch-agent fails to apply iptables rules
1. # Generated by iptables-save v1.4.21 on Fri Oct 10 12:57:46 2014 2. *raw 3. :PREROUTING ACCEPT [14112:2558828] 4. :OUTPUT ACCEPT [15144:2771232] 5. :neutron-openvswi-OUTPUT - [0:0] 6. :neutron-openvswi-PREROUTING - [0:0] 7. [14112:2558828] -A PREROUTING -j neutron-openvswi-PREROUTING 8. [15144:2771232] -A OUTPUT -j neutron-openvswi-OUTPUT 9. COMMIT 10. # Completed on Fri Oct 10 12:57:46 2014 11. # Generated by iptables-save v1.4.21 on Fri Oct 10 12:57:46 2014 12. *mangle 13. :PREROUTING ACCEPT [32301:28693852] 14. :INPUT ACCEPT [32291:28693414] 15. :FORWARD ACCEPT [0:0] 16. :OUTPUT ACCEPT [28668:5226155] 17. :POSTROUTING ACCEPT [28668:5226155] 18. [0:0] -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill 19. COMMIT 20. # Completed on Fri Oct 10 12:57:46 2014 21. # Generated by iptables-save v1.4.21 on Fri Oct 10 12:57:46 2014 22. *nat 23. :PREROUTING ACCEPT [11:498] 24. :INPUT ACCEPT [1:60] 25. :OUTPUT ACCEPT [3960:318233] 26. :POSTROUTING ACCEPT [3960:318233] 27. :neutron-postrouting-bottom - [0:0] 28. :neutron-openvswi-OUTPUT - [0:0] 29. :neutron-openvswi-POSTROUTING - [0:0] 30. :neutron-openvswi-PREROUTING - [0:0] 31. :neutron-openvswi-float-snat - [0:0] 32. :neutron-openvswi-snat - [0:0] 33. [3:140] -A PREROUTING -j neutron-openvswi-PREROUTING 34. [2312:186295] -A OUTPUT -j neutron-openvswi-OUTPUT 35. [2312:186295] -A POSTROUTING -j neutron-openvswi-POSTROUTING 36. [2312:186295] -A POSTROUTING -j neutron-postrouting-bottom 37. [2312:186295] -A neutron-postrouting-bottom -j neutron-openvswi-snat 38. [2312:186295] -A neutron-openvswi-snat -j neutron-openvswi-float-snat 39. [0:0] -A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN 40. [0:0] -A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN 41. [0:0] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 42. [0:0] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 43. [0:0] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE 44. COMMIT 45. # Completed on Fri Oct 10 12:57:46 2014 46. # Generated by iptables-save v1.4.21 on Fri Oct 10 12:57:46 2014 47. *filter 48. :INPUT ACCEPT [32961:28761138] 49. :FORWARD ACCEPT [0:0] 50. :OUTPUT ACCEPT [29341:5283975] 51. :neutron-filter-top - [0:0] 52. :neutron-openvswi-FORWARD - [0:0] 53. :neutron-openvswi-INPUT - [0:0] 54. :neutron-openvswi-OUTPUT - [0:0] 55. :neutron-openvswi-i3d3f7a31-9 - [0:0] 56. :neutron-openvswi-i62de4e08-b - [0:0] 57. :neutron-openvswi-i7010a0ba-c - [0:0] 58. :neutron-openvswi-local - [0:0] 59. :neutron-openvswi-o3d3f7a31-9 - [0:0] 60. :neutron-openvswi-o62de4e08-b - [0:0] 61. :neutron-openvswi-o7010a0ba-c - [0:0] 62. :neutron-openvswi-s3d3f7a31-9 - [0:0] 63. :neutron-openvswi-s62de4e08-b - [0:0] 64. :neutron-openvswi-s7010a0ba-c - [0:0] 65. :neutron-openvswi-sg-chain - [0:0] 66. :neutron-openvswi-sg-fallback - [0:0] 67. [0:0] -A FORWARD -j neutron-filter-top 68. [0:0] -A OUTPUT -j neutron-filter-top 69. [0:0] -A neutron-filter-top -j neutron-openvswi-local 70. [0:0] -A INPUT -j neutron-openvswi-INPUT 71. [0:0] -A OUTPUT -j neutron-openvswi-OUTPUT 72. [0:0] -A FORWARD -j neutron-openvswi-FORWARD 73. [0:0] -A neutron-openvswi-sg-fallback -j DROP 74. [0:0] -A neutron-openvswi-FORWARD -m physdev --physdev-out tap62de4e08-b8 --physdev-is-bridged -j neutron-openvswi-sg-chain 75. [0:0] -A neutron-openvswi-sg-chain -m physdev --physdev-out tap62de4e08-b8 --physdev-is-bridged -j neutron-openvswi-i62de4e08-b 76. [0:0] -A neutron-openvswi-i62de4e08-b -m state --state INVALID -j DROP 77. [0:0] -A neutron-openvswi-i62de4e08-b -m state --state RELATED,ESTABLISHED -j RETURN 78. [0:0] -A neutron-openvswi-i62de4e08-b -m set --match-set IPv4cf55331e-3b18-488d-8 src -j RETURN 79. [0:0] -A neutron-openvswi-i62de4e08-b -j neutron-openvswi-sg-fallback 80. [0:0] -A neutron-openvswi-FORWARD -m physdev --physdev-in tap62de4e08-b8 --physdev-is-bridged -j neutron-openvswi-sg-chain 81. [0:0] -A neutron-openvswi-sg-chain -m physdev --physdev-in tap62de4e08-b8 --physdev-is-bridged -j neutron-openvswi-o62de4e08-b 82. [0:0] -A neutron-openvswi-INPUT -m physdev --physdev-in tap62de4e08-b8 --physdev-is-bridged -j neutron-openvswi-o62de4e08-b 83. [0:0] -A neutron-openvswi-s62de4e08-b -m mac --mac-source fa:16:3e:bf:c7:49 -s 192.168.0.3 -j RETURN 84. [0:0] -A neutron-openvswi-s62de4e08-b -j DROP 85. [0:0] -A neutron-openvswi-o62de4e08-b -p udp -m udp --sport 68 --dport 67 -j RETURN 86. [0:0] -A neutron-openvswi-o62de4e08-b -j
[Yahoo-eng-team] [Bug 1379798] [NEW] Glance returns HTTPInternalServerError 500 in case of image server is down
Public bug reported: HTTPInternalServerError 500 response is returned to the user while image server is down during downloading the image. When user tries to download the image from the remote location (image server) which is down, Connection refused ECONNREFUSED error is raised on the glance server. Ideally it should return 503 HTTPServiceUnavailable response to the user. Steps to reproduce: 1. Create a file 'test_image.py' at any location. example: /home/openstack/ 2. Run Simple HTTP server using python -m SimpleHTTPServer 8050 from location mentioned in step 1. 3. Create an image using location parameter. example: glance image-create --name myimage --disk-format=raw --container-format=bare --location http://10.69.4.178:8050/test_image.py 4. Stop Simple HTTP server. 5. Download image using glance image-download image_id created in step 3. Please refer http://paste.openstack.org/show/120165/ for v1 and v2 api logs. ** Affects: glance Importance: Undecided Assignee: Ankit Agrawal (ankitagrawal) Status: New ** Tags: ntt ** Changed in: glance Assignee: (unassigned) = Ankit Agrawal (ankitagrawal) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1379798 Title: Glance returns HTTPInternalServerError 500 in case of image server is down Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: HTTPInternalServerError 500 response is returned to the user while image server is down during downloading the image. When user tries to download the image from the remote location (image server) which is down, Connection refused ECONNREFUSED error is raised on the glance server. Ideally it should return 503 HTTPServiceUnavailable response to the user. Steps to reproduce: 1. Create a file 'test_image.py' at any location. example: /home/openstack/ 2. Run Simple HTTP server using python -m SimpleHTTPServer 8050 from location mentioned in step 1. 3. Create an image using location parameter. example: glance image-create --name myimage --disk-format=raw --container-format=bare --location http://10.69.4.178:8050/test_image.py 4. Stop Simple HTTP server. 5. Download image using glance image-download image_id created in step 3. Please refer http://paste.openstack.org/show/120165/ for v1 and v2 api logs. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1379798/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379811] [NEW] VPN: Update logging to use i18n hints
Public bug reported: The VPN logging code should use the new marker functions for info, warning, error and critical log levels to separate log messages into different catalogs for translation priority. We also need to ensure that the new i18n guidelines are followed. ** Affects: neutron Importance: Undecided Assignee: Andrew Boik (drewboik) Status: In Progress ** Tags: i18n vpnaas ** Changed in: neutron Assignee: (unassigned) = Andrew Boik (drewboik) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1379811 Title: VPN: Update logging to use i18n hints Status in OpenStack Neutron (virtual network service): In Progress Bug description: The VPN logging code should use the new marker functions for info, warning, error and critical log levels to separate log messages into different catalogs for translation priority. We also need to ensure that the new i18n guidelines are followed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1379811/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379666] Re: unable to Ping my external IP
Sorry, this looks like support request which is better to post to openstack mailing list ** Changed in: neutron Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1379666 Title: unable to Ping my external IP Status in OpenStack Neutron (virtual network service): Invalid Bug description: iam unable to ping my External Ip address, and in my router details my external network is down. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1379666/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1377687] Re: Typo in CLI error message: seting
Correct analysis from Sam Betts. Closing as invalid ** Changed in: neutron Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1377687 Title: Typo in CLI error message: seting Status in OpenStack Neutron (virtual network service): Invalid Bug description: OpenStack version: Juno localadmin@qa4:~/devstack$ nova-manage version 2015.1 Issue: typo in CLI error message; setting should be setting localadmin@qa4:~/devstack$ ip netns exec qrouter-7b422c9d-c5f9-4bb5-b1b3-159954c72323 ip addr list seting TYPO the network namespace qrouter-7b422c9d-c5f9-4bb5-b1b3-159954c72323 failed: Operation not permitted To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1377687/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379201] Re: openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build [error: too many arguments to function ‘ip_select_ident’]
** No longer affects: neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1379201 Title: openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build [error: too many arguments to function ‘ip_select_ident’] Status in “openvswitch” package in Ubuntu: Confirmed Bug description: Update gives this message. ProblemType: Package DistroRelease: Ubuntu 12.04 Package: openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3 ProcVersionSignature: Ubuntu 3.2.0-69.103-generic 3.2.62 Uname: Linux 3.2.0-69-generic x86_64 ApportVersion: 2.0.1-0ubuntu17.7 Architecture: amd64 DKMSKernelVersion: 3.2.0-70-generic Date: Thu Oct 9 09:35:00 2014 InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release amd64 (20120425) MarkForUpload: True PackageArchitecture: all PackageVersion: 1.4.6-0ubuntu1.12.04.3 SourcePackage: openvswitch Title: openvswitch-datapath-dkms 1.4.6-0ubuntu1.12.04.3: openvswitch kernel module failed to build UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1379201/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1182681] Re: v3 doesn't return Location header on 201 Created
++ I should have referenced this bug in the commit message, and tracked
this against openstack-api-site.
** Changed in: keystone
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1182681
Title:
v3 doesn't return Location header on 201 Created
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
According to the identity V3 API doc[1] the create group response should
include the Location header, but when I create a group there's no Location
header returned. Either the identity V3 API doc is incorrect or the Keystone
server is incorrect.
[1] https://github.com/openstack/identity-api/blame/master/openstack-
identity-api/src/markdown/identity-api-v3.md#L1997
To recreate, create a group and look at the headers returned.
$ curl -i -H X-Auth-Token: admin1token -H Content-Type: application/json
-d '{group: {name: Group2}}' http://localhost:35357/v3/groups
HTTP/1.1 201 Created
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 201
Date: Tue, 21 May 2013 22:45:58 GMT
{group: {domain_id: default, description: , id:
290aec9bf893468d81d173425ca3973b, links: {self:
http://localhost:5000/v3/groups/290aec9bf893468d81d173425ca3973b},
name: Group2}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1182681/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1303986] Re: [SRU][FFe] CloudSigma Datasource doesn't handle vendor-data correctly
fix-released in 0.7.6 ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1303986 Title: [SRU][FFe] CloudSigma Datasource doesn't handle vendor-data correctly Status in Init scripts for use on cloud images: Fix Released Status in “cloud-init” package in Ubuntu: Fix Released Status in “cloud-init” source package in Trusty: Fix Released Bug description: SRU Justificaton: This SRU fulfills the FFE exception granted. Cloud Sigma has asked that we update the DataSource in Cloud-init to support the 14.04 VendorData construct. The regression potential for this change is low, as only the cloud-init Cloud-Sigma datasource is changed, a test suite has been provided and it has been tested by Cloud Sigma. The reason for this late-in-the-cylce change is so that Cloud Sigma can have use the official Ubuntu Images with out conflating user and vendor-data. Currently Cloud Sigma uses the user-data channel improperly for transmitting vendor specific information to Cloud-init, when they should be using the vendor-data channel. By switching to the proper channel for vendor specific information, user-data and vendor- data will not be mangled, preventing collisions of user-data and vendor-specific data. [ORIGINAL BUG REPORT] It appears as the CloudSigma datasource only has support for 'user-data', and not 'vendor-data.' To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1303986/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1316475] Re: [SRU] CloudSigma DS for causes hangs when serial console present
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1316475 Title: [SRU] CloudSigma DS for causes hangs when serial console present Status in Init scripts for use on cloud images: Fix Released Status in Openstack disk image builder: Fix Released Status in tripleo - openstack on openstack: Invalid Status in “cloud-init” package in Ubuntu: Fix Released Status in “cloud-init” source package in Trusty: Fix Released Bug description: SRU Justification Impact: The Cloud Sigma Datasource read and writes to /dev/ttyS1 if present; the Datasource does not have a time out. On non-CloudSigma Clouds or systems w/ /dev/ttyS1, Cloud-init will block pending a response, which may never come. Further, it is dangerous for a default datasource to write blindly on a serial console as other control plane software and Clouds use /dev/ttyS1 for communication. Fix: The patch queries the BIOS to see if the instance is running on CloudSigma before querying /dev/ttys1. Verification: On both a CloudSigma instance and non-CloudSigma instance with /dev/ttys1: 1. Install new cloud-init 2. Purge existing cloud-init data (rm -rf /var/lib/cloud) 3. Run cloud-init --debug init 4. Confirm that CloudSigma provisioned while CloudSigma datasource skipped non-CloudSigma instance Regression: The risk is low, as this change further restrict where the CloudSigma Datasource can run. [Original Report] DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 3 (xid=0x7e777c23) DHCPREQUEST of 10.22.157.186 on eth2 to 255.255.255.255 port 67 (xid=0x7e777c23) DHCPOFFER of 10.22.157.186 from 10.22.157.149 DHCPACK of 10.22.157.186 from 10.22.157.149 bound to 10.22.157.186 -- renewal in 39589 seconds. * Starting Mount network filesystems[ OK ] * Starting configure network device [ OK ] * Stopping Mount network filesystems[ OK ] * Stopping DHCP any connected, but unconfigured network interfaces [ OK ] * Starting configure network device [ OK ] * Stopping DHCP any connected, but unconfigured network interfaces [ OK ] * Starting configure network device [ OK ] And it stops there. I see this on about 10% of deploys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1316475/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1333920] Re: sshd can start before cloud-init injects keys
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1333920 Title: sshd can start before cloud-init injects keys Status in Init scripts for use on cloud images: Fix Released Bug description: Description of problem: When using automated scripts for deployment, many wait for sshd to come up, then ssh in. Since cloud-init and sshd are started in parallel, this creates a race condition for cloud-init to add ssh keys before sshd starts or the user can't login and the automated scripts can fail. Specifically, this is happening to me using test-kitchen with the kitchen-openstack plugin, which uses Fog. It calls wait_for and watches for sshd to come up. It catches sshd before cloud-init finishes installing keys, and fails to ssh. Reproducing: Attempt to ssh in before cloud-init finishes but after sshd is up and running. Steps to Reproduce: 1. Pull in Fedora Cloud image for OpenStack 2. Configure test kitchen to use Fedora 3. Run test-kitchen tests Actual results: ssh fails, which causes test-kitchen or other automated scripts to fail. Expected results: ssh should succeed. This is specifically affecting me on Fedora-20, but can potentially affect any distribution using systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1333920/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1327065] Re: typo in cloud-config-user-groups.txt
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1327065 Title: typo in cloud-config-user-groups.txt Status in Init scripts for use on cloud images: Fix Released Bug description: Hi, please fix doc/examples/cloud-config-user-groups.txt change ssh-authorized-key to ssh-authorized-keys. Cheers. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1327065/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1316597] Re: test_smartos fails in a chroot
fixed in 0.7.6
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1316597
Title:
test_smartos fails in a chroot
Status in Init scripts for use on cloud images:
Fix Released
Status in “cloud-init” package in Ubuntu:
Fix Released
Bug description:
All tests from test_smartos.py fail in a chroot as follows (only first
failure shown):
$ nosetests tests/unittests/test_datasource/test_smartos.py
F
==
FAIL: test_b64_keys
(tests.unittests.test_datasource.test_smartos.TestSmartOSDataSource)
--
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/mocker.py, line 146, in
test_method_wrapper
result = test_method()
File /root/cloud-init/tests/unittests/test_datasource/test_smartos.py,
line 270, in test_b64_keys
self.assertTrue(ret)
AssertionError: False is not true
begin captured logging
cloudinit.importer: DEBUG: Looking for modules ['cloudinit.mergers.m_list']
that have attributes ['Merger']
cloudinit.importer: DEBUG: Found m_list with attributes ['Merger'] in
['cloudinit.mergers.m_list']
cloudinit.importer: DEBUG: Looking for modules ['cloudinit.mergers.m_dict']
that have attributes ['Merger']
cloudinit.importer: DEBUG: Found m_dict with attributes ['Merger'] in
['cloudinit.mergers.m_dict']
cloudinit.importer: DEBUG: Looking for modules ['cloudinit.mergers.m_str']
that have attributes ['Merger']
cloudinit.importer: DEBUG: Found m_str with attributes ['Merger'] in
['cloudinit.mergers.m_str']
cloudinit.mergers: DEBUG: Merging 'dict' into 'dict' using method
'_handle_unknown' of 'LookupMerger: (3)'
cloudinit.mergers: DEBUG: Merging using located merger 'DictMerger:
(method=no_replace,recurse_str=False,recurse_dict=True,recurse_array=False,allow_delete=False)'
since it had method '_on_dict'
cloudinit.sources.DataSourceSmartOS: DEBUG: Host does not appear to be on
SmartOS
- end captured logging -
This is because DataSourceSmartOS.get_data() bails out if it can't
find the seed (/dev/ttyS1), which obviously doesn't exist in a
pbuilder chroot. The check for /dev/ttyS1 needs to be subbed out.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1316597/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1328953] Re: template for resolv.conf doesn't work if no options are provided
fixed in 0.7.6
** Changed in: cloud-init
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1328953
Title:
template for resolv.conf doesn't work if no options are provided
Status in Init scripts for use on cloud images:
Fix Released
Bug description:
When using the plugin for configuring resolv.conf it will always fail
if no options are provided in the config.
The reason is the template includes the check [1]:
#if $varExists('options') or $varExists('flags')
The flags variable is set to an empty list in the generate_resolv_conf
function [2] before the template is rendered and $varExists('flags')
will always return true because of this. Because I know the variable
will always exist and an empty list resolves as false in python I was
able to work around this bug by changing the line in the template to
read:
#if $varExists('options') or $flags
The plugin is now handling my configs properly and generating a valid
resolv.conf on the systems.
[1]
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/971/templates/resolv.conf.tmpl#L30
[2]
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/971/cloudinit/config/cc_resolv_conf.py#L67
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1328953/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1313114] Re: Update cloud-config-disk-setup.txt to use table_type instead of type
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1313114 Title: Update cloud-config-disk-setup.txt to use table_type instead of type Status in Init scripts for use on cloud images: Fix Released Bug description: While I was reading cc_disk_setup.py I realized that the docs use type to define disk table types, while the code uses table_type. The patch should fix it. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1313114/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1329583] Re: Typo in default data source list breaks Ec2 and OpenStack sources
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1329583 Title: Typo in default data source list breaks Ec2 and OpenStack sources Status in Init scripts for use on cloud images: Fix Released Bug description: The built-in list of data sources that appears in cloudinit/settings.py is missing a comma between 'OpenStack' and 'Ec2', breaking both of those data sources. From the looks of things debconf manages the data source list on Ubuntu, which would mask this problem there, but we don't have that luxury on Fedora. See the attached patch for a fix. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1329583/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1338614] Re: Backgrounded resizing does not work
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1338614 Title: Backgrounded resizing does not work Status in Init scripts for use on cloud images: Fix Released Bug description: When setting resize_rootfs to 'noblock', cloud-init should fork a new process and continue with it's own initialization process. However, it seems that this is currently broken, as you see from these logs that it still blocks on it: Jul 7 12:34:20 localhost [CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing (via forking) root filesystem (type=ext4, val=noblock) Jul 7 12:34:20 localhost [CLOUDINIT] util.py[WARNING]: Failed forking and calling callback NoneType Jul 7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: Failed forking and calling callback NoneType#012Traceback (most recent call last):#012 File /usr/lib/python2.6/site-packages/cloudinit/util.py, line 220, in fork_cb#012 child_cb(*args)#012TypeError: 'NoneType' object is not callable Also, when looking at timings, you can see that it was blocked on it for the whole time Jul 7 12:33:38 localhost [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.4 running 'init' at Mon, 07 Jul 2014 12:33:38 +. Up 5.67 seconds. Jul 7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: backgrounded Resizing took 41.487 seconds Jul 7 12:34:20 localhost [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'init' took 41.799 seconds (41.80) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1338614/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1219223] Re: Is it possible that we switch from cheetah to a lighter weight template engine?.
fixed in 0.7.6 ** Changed in: cloud-init Status: Triaged = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1219223 Title: Is it possible that we switch from cheetah to a lighter weight template engine?. Status in Init scripts for use on cloud images: Fix Released Bug description: Switch is suggested as cheetah pulls in too many dependencies. I would like to suggest something smaller to ensure our package is lighter. Related bugs: bug 1247132: Python 3 support and dropping cheetah To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1219223/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1341710] Re: Comment placed inside of /etc/timezone
fixed in 0.7.6 ** Changed in: cloud-init Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1341710 Title: Comment placed inside of /etc/timezone Status in Init scripts for use on cloud images: Fix Released Status in “cloud-init” package in Ubuntu: Fix Released Bug description: Greetings! cloud-init v0.7.5 (trusty) is placing a comment in the /etc/timezone file, when that file isn't intended to contain a comment. This is confusing openjdk (and perhaps other programs?), which is unable to determine the correct timezone. Sample /etc/timezone from v0.7.5: # Created by cloud-init v. 0.7.5 on Mon, 14 Jul 2014 18:01:38 + US/Eastern Openjdk has been informed of this back in 2012, and decided that they won't change things on their end because comments in /etc/timezone aren't part of the spec. https://bugs.openjdk.java.net/browse/JDK-7192951. Of course, there is no formal spec for /etc/timezone. The closest that I've seen to a spec is actually contained within the bug report at openjdk: = I am not sure that a formal spec of /etc/timezone exists. The Debian tools for manipulating it (tzconfig and tzsetup) do basically the same thing. --- reading --- if [ -L /etc/localtime ] ; then current_timezone=$(readlink /etc/localtime | sed 's%^/usr/share/zoneinfo/%%') elif [ -f /etc/timezone ] [ -f /etc/localtime ]; then current_timezone=$(cat /etc/timezone) fi --- setting --- echo $timezone /etc/timezone It is the same in Ubuntu. So, in Debian-based distros it is just a LF-terminated line, with no spaces and extra characters. To be a little more general, I suggest ignoring all leading spaces (including new lines) and then reading consecutive non-space characters. = For the record, cloud-init previously did not include a comment in /etc/timezone. Would it be possible to revert to the previous behavior of not including a comment in /etc/timezone? A quick skim of the source code tells me that the set_timezone() method would have to be changed to no longer include the line with util.make_header(). Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1341710/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1336855] Re: [SRU] non-interactive grub updates broken for /dev/xvda devices on Cloud-Images/Cloud-init
fixed in 0.7.6 ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Importance: Undecided = Medium ** Changed in: cloud-init Status: New = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1336855 Title: [SRU] non-interactive grub updates broken for /dev/xvda devices on Cloud-Images/Cloud-init Status in Init scripts for use on cloud images: Fix Released Status in “cloud-init” package in Ubuntu: Fix Released Status in “cloud-init” source package in Precise: Fix Committed Status in “cloud-init” source package in Trusty: Fix Committed Status in “cloud-init” source package in Utopic: Fix Released Bug description: [SRU JUSTIFICATION] [IMPACT] Cloud-init, as part of the first boot configures grub-pc to set the device that grub should install to. However, in the case of HVM instances, /dev/xvda and /dev/xvda1 are not considered (only sda, sda1, vda and vda1). Since AWS HVM instances and Xen use /dev/xvdX devices, this means that any Grub update with an ABI change will break the instances, rendering them unable to boot. [FIX] Cloud-init has been patched to understand /dev/xvda devices and set the correct grub-pc/install_device. Further, cloud-init's postinst has been patched to fix people who might be affected by this bug. [Test Case 1] 1. Boot HVM instance store AMI ami-90b156f8 (us-east-1) 2. Update grub 3. Update cloud-init from -proposed 4. Reboot instance 5. instance should come back up [Test Case 2 -- 12.04 Only] 1. Boot HVM instance store AMI ami-90b156f8 (us-east-1) 2. run cloud-init-cfg grub_dpkg --freqenucy always 3. run debconf-show grub-pc, confirm that grub-pc/install_devices is /dev/xvda 4. update grub 5. Reboot 6. instance should come back up [Test Case 3 -- 14.04 Only] 1. Boot HVM instance store AMI ami-1f958c76 (us-east-1) 2. run cloud-init single grub_dpkg --freqenucy always 3. run debconf-show grub-pc, confirm that grub-pc/install_devices is /dev/xvda 4. update grub 5. Reboot 6. instance should come back up [Test Case 4] 1. Install from -proposed 2. Simulate a first-run: echo grub-pc grub-pc/install_devices select /dev/sda | debconf-set-selections 3. Run: cloud-init single --name=grub-dpkg --frequency=always 4. Run: debconf-show grub-pc 5. confirm that /dev/xvda is shown as the install device ORIGINAL report It looks like a recent update to grub or the kernel on 12.04 is breaking unattended installs on EC2 for HVM instances. You can reproduce the problem by doing the following: region: us-east-1 virtualization type: HVM (e.g. r3.xlarge) AMI ID: ami-7a916212 dpkg --configure –a apt-get update apt-get install -y ruby ruby-dev libicu-dev libssl-dev libxslt-dev libxml2-dev monit apt-get dist-upgrade –y To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1336855/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1174499] Re: Keystone token hashing is MD5
Reviewed: https://review.openstack.org/127452 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=3a64723917366eff4d8896b2b2d3d82fa462d25d Submitter: Jenkins Branch:proposed/juno commit 3a64723917366eff4d8896b2b2d3d82fa462d25d Author: Brant Knudson bknud...@us.ibm.com Date: Sun Aug 24 10:04:10 2014 -0500 Document token hash algorithm option With https://review.openstack.org/#/c/116509/ , django-openstack-auth will support a new option for the token hash algorithm. This adds the documentation to Horizon's local settings example file. This is for security hardening. The token hash algorithm defaults to MD5, which is considered too weak due to the potential for hash collisions. Some security standards require a SHA2 hash algorithm to be used. DocImpact SecurityImpact Change-Id: I6774b9b7215d191259586e4721e357487bb777cd Closes-Bug: #1174499 (cherry picked from commit 372d033d89c0f5d305959a6ad5fd3e1159cc91ed) ** Changed in: horizon Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in Django OpenStack Auth: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack API documentation site: Confirmed Status in Python client library for Keystone: Fix Released Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1334196] Re: User may be able to set 'system' style swift location
Reviewed: https://review.openstack.org/127540 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=c0d90a580f87dbbf71e3a5d5c1b5cf8d7c7245b2 Submitter: Jenkins Branch:proposed/juno commit c0d90a580f87dbbf71e3a5d5c1b5cf8d7c7245b2 Author: Stuart McLaren stuart.mcla...@hp.com Date: Wed Jul 16 13:33:32 2014 + Prevent setting swift+config locations Forbid setting 'swift+config' locations in a similar manner to 'file' for security reasons; knowledge of the reference name should not be exploitable. Setting swift+config had been prevented when swift was the default store, this patch changes to forbid setting no matter which store is the default. As with change id I75af34145521f533dcd6f5fd7690f5a68f3b44b3 this is v1 only for now. Change-Id: I62c4980bd5c2f3dd77fc40cd007bc1067eca63a4 Closes-bug: 1334196 ** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1334196 Title: User may be able to set 'system' style swift location Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: This change: https://review.openstack.org/#/c/98722/ Introduces a new system style swift scheme: swift+config A new function validate_location verifies that that scheme is not being set by a user when using the 'set location' functionality. However, that function will only perform that check if the default backend is swift. If the swift store is enabled but the default store is 'ceph' say then the base version of that function (which performs no checking) will be called. I think 'validate_location' should probably be removed and a check against 'swift+config' should be performed in _validate_source, in the same way as 'file' is checked there. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1334196/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379889] [NEW] exit(1) masks errors
Public bug reported: In wsgi.py, line 134, os.exit(1) prevents errors from being raised, which makes debugging difficult. Changing os.exit(1) to raise will allow developers to see the proper debugging information. ** Affects: neutron Importance: Undecided Status: New ** Description changed: - In wsgi.py, line 143, os.exit(1) prevents errors from being raised, + In wsgi.py, line 134, os.exit(1) prevents errors from being raised, which makes debugging difficult. Changing os.exit(1) to raise will allow developers to see the proper debugging information. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1379889 Title: exit(1) masks errors Status in OpenStack Neutron (virtual network service): New Bug description: In wsgi.py, line 134, os.exit(1) prevents errors from being raised, which makes debugging difficult. Changing os.exit(1) to raise will allow developers to see the proper debugging information. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1379889/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379931] [NEW] Create Network Cancel Back Next buttons misaligned
Public bug reported: The Cancel, Back, and Next button alignment is messed up. I included a picture to clarify. To recreate go to Project-Networks-Create Network ** Affects: horizon Importance: Undecided Status: New ** Attachment added: CreateNetworkButtons.png https://bugs.launchpad.net/bugs/1379931/+attachment/4231019/+files/CreateNetworkButtons.png -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1379931 Title: Create Network Cancel Back Next buttons misaligned Status in OpenStack Dashboard (Horizon): New Bug description: The Cancel, Back, and Next button alignment is messed up. I included a picture to clarify. To recreate go to Project-Networks-Create Network To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1379931/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1234857] Re: neutron unittest require minimum 4gb memory
** Changed in: neutron Status: In Progress = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1234857 Title: neutron unittest require minimum 4gb memory Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron havana series: Fix Released Status in neutron icehouse series: Fix Released Bug description: tox -e py26 The unittest hang forever. Each test seem to take around 25mins to complete. Each test report following error, though it is PASS. It sounds like a regression caused by fix for https://bugs.launchpad.net/neutron/+bug/1191768. https://github.com/openstack/neutron/commit/06f679df5d025e657b2204151688ffa60c97a3d3 As per this fix, the default behavior for neutron.agent.rpc.report_state() is modified to use cast(), to report back the state in json format. The original behavior was to use call() method. Using call() method by default might fix this problem. ERROR:neutron.plugins.linuxbridge.agent.linuxbridge_neutron_agent:Failed reporting state! Traceback (most recent call last): File /home/jenkins/workspace/csi-neutron-upstream/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py, line 759, in _report_state self.agent_state) File /home/jenkins/workspace/csi-neutron-upstream/neutron/agent/rpc.py, line 74, in report_state return self.cast(context, msg, topic=self.topic) File /home/jenkins/workspace/csi-neutron-upstream/neutron/openstack/common/rpc/proxy.py, line 171, in cast rpc.cast(context, self._get_topic(topic), msg) File /home/jenkins/workspace/csi-neutron-upstream/neutron/openstack/common/rpc/__init__.py, line 158, in cast return _get_impl().cast(CONF, context, topic, msg) File /home/jenkins/workspace/csi-neutron-upstream/neutron/openstack/common/rpc/impl_fake.py, line 166, in cast check_serialize(msg) File /home/jenkins/workspace/csi-neutron-upstream/neutron/openstack/common/rpc/impl_fake.py, line 131, in check_serialize json.dumps(msg) File /usr/lib64/python2.6/json/__init__.py, line 230, in dumps return _default_encoder.encode(obj) File /usr/lib64/python2.6/json/encoder.py, line 367, in encode chunks = list(self.iterencode(o)) File /usr/lib64/python2.6/json/encoder.py, line 309, in _iterencode for chunk in self._iterencode_dict(o, markers): File /usr/lib64/python2.6/json/encoder.py, line 275, in _iterencode_dict for chunk in self._iterencode(value, markers): File /usr/lib64/python2.6/json/encoder.py, line 309, in _iterencode for chunk in self._iterencode_dict(o, markers): File /usr/lib64/python2.6/json/encoder.py, line 275, in _iterencode_dict for chunk in self._iterencode(value, markers): File /usr/lib64/python2.6/json/encoder.py, line 309, in _iterencode for chunk in self._iterencode_dict(o, markers): File /usr/lib64/python2.6/json/encoder.py, line 275, in _iterencode_dict for chunk in self._iterencode(value, markers): File /usr/lib64/python2.6/json/encoder.py, line 309, in _iterencode for chunk in self._iterencode_dict(o, markers): File /usr/lib64/python2.6/json/encoder.py, line 275, in _iterencode_dict for chunk in self._iterencode(value, markers): File /usr/lib64/python2.6/json/encoder.py, line 309, in _iterencode for chunk in self._iterencode_dict(o, markers): File /usr/lib64/python2.6/json/encoder.py, line 275, in _iterencode_dict for chunk in self._iterencode(value, markers): File /usr/lib64/python2.6/json/encoder.py, line 317, in _iterencode for chunk in self._iterencode_default(o, markers): File /usr/lib64/python2.6/json/encoder.py, line 323, in _iterencode_default newobj = self.default(o) File /usr/lib64/python2.6/json/encoder.py, line 344, in default raise TypeError(repr(o) + is not JSON serializable) TypeError: MagicMock name='LinuxBridgeManager().local_ip' id='666599248' is not JSON serializable To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1234857/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379952] [NEW] API accepts tenant name for TenantId, fails, and provides not helpful message
Public bug reported: When authenticating with Keystone's REST API, if I happen to provide my tenant name in the TenantId field, the resulting error tells me that I am not authorized for that tenant, even though all the information (user, pass, tenant) are correct. It *should* tell me that I just passed invalid data into a field that expects a UUID, which, as a user, would tell me exactly what was wrong. For what it's worth, in debugging my auth problem, I ended up tcpdump'ing keystone which led to this gem of a demonstration of the problem: http://paste.openstack.org/show/4v5JtwbGNu6QhQ3K5oQ1/ ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1379952 Title: API accepts tenant name for TenantId, fails, and provides not helpful message Status in OpenStack Identity (Keystone): New Bug description: When authenticating with Keystone's REST API, if I happen to provide my tenant name in the TenantId field, the resulting error tells me that I am not authorized for that tenant, even though all the information (user, pass, tenant) are correct. It *should* tell me that I just passed invalid data into a field that expects a UUID, which, as a user, would tell me exactly what was wrong. For what it's worth, in debugging my auth problem, I ended up tcpdump'ing keystone which led to this gem of a demonstration of the problem: http://paste.openstack.org/show/4v5JtwbGNu6QhQ3K5oQ1/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1379952/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1379973] [NEW] REST API didn't verify json data format
Public bug reported:
When try to create a server with REST API, I set attribute block_device_mapping
with wrong value, not a listdict but a string (from block_device_mapping:
[{volume_id: 1, delete_on_termination: 0, device_name: /dev/vdb}]
to block_device_mapping: abc,). And then I got a response with code 500.
In nova CLI, when params are wrong you will get a notice, but in REST you get
nothing.
If openstack use json schema to describe every REST API and verify json
requested , users can easily know how to use these API and which attribute was
wrong.
** 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/1379973
Title:
REST API didn't verify json data format
Status in OpenStack Compute (Nova):
New
Bug description:
When try to create a server with REST API, I set attribute
block_device_mapping with wrong value, not a listdict but a string (from
block_device_mapping: [{volume_id: 1, delete_on_termination: 0,
device_name: /dev/vdb}] to block_device_mapping: abc,). And then I got
a response with code 500.
In nova CLI, when params are wrong you will get a notice, but in REST you get
nothing.
If openstack use json schema to describe every REST API and verify json
requested , users can easily know how to use these API and which attribute was
wrong.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1379973/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
