[Yahoo-eng-team] [Bug 1329653] [NEW] Copying objects in swift with a leading / in the path
Public bug reported: (RDO Havana) This seems to ignore the path altogether or give an error depending on the path and destination container. That said, I'm not sure what the correct way to handle a leading slash is, but currently it's inconsistent. The resulting copies are visible in horizon, but can't be downloaded. ** Affects: horizon Importance: Undecided Status: New ** Tags: swift ** Description changed: (RDO Havana) - This seems to ignore the path altogether or give an error depending on the path and destination container. + This seems to ignore the path altogether or give an error depending on the path and destination container. That said, I'm not sure what the correct way to handle a leading slash is, but currently it's inconsistent. + + The resulting copies are visible in horizon, but can't be downloaded. -- 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/1329653 Title: Copying objects in swift with a leading / in the path Status in OpenStack Dashboard (Horizon): New Bug description: (RDO Havana) This seems to ignore the path altogether or give an error depending on the path and destination container. That said, I'm not sure what the correct way to handle a leading slash is, but currently it's inconsistent. The resulting copies are visible in horizon, but can't be downloaded. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1329653/+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 1319354] Re: intermittent failure in unit test job startup
*** This bug is a duplicate of bug 1316486 *** https://bugs.launchpad.net/bugs/1316486 ** This bug has been marked a duplicate of bug 1316486 Package is imported instead of module in neutron/tests/unit/services/loadbalancer/drivers/netscaler/test_netscaler_driver.py -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1319354 Title: intermittent failure in unit test job startup Status in OpenStack Neutron (virtual network service): New Bug description: In some cases the python 27 jobs fails at startup with the following message: import err...@pneutron.tests.unit.services.loadbalancer.drivers.netscaler.test_netscaler_driver This caused a few failures in upstream checks, although it's not immediate to say which ones hit the gate as both check and gate queues seem to be running 'gate-neutron-python27' logstash: http://logstash.openstack.org/#eyJzZWFyY2giOiJidWlsZF9uYW1lOmdhdGUtbmV1dHJvbi1weXRob24yNyBBTkQgdGFnczpjb25zb2xlICBBTkQgbWVzc2FnZTplcnJvcnNAUG5ldXRyb24udGVzdHMudW5pdC5zZXJ2aWNlcy5sb2FkYmFsYW5jZXIuZHJpdmVycy5uZXRzY2FsZXIudGVzdF9uZXRzY2FsZXJfZHJpdmVyIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiJjdXN0b20iLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsiZnJvbSI6IjIwMTQtMDUtMDVUMDc6MDM6MjQrMDA6MDAiLCJ0byI6IjIwMTQtMDUtMDVUMTQ6MDM6MjQrMDA6MDAiLCJ1c2VyX2ludGVydmFsIjoiMCJ9LCJzdGFtcCI6MTQwMDA2NjMyNTcxOH0= To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1319354/+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 1329764] [NEW] Hyper-V volume attach issue: wrong SCSI slot is selected
Public bug reported: When attaching volumes, the Hyper-V driver selects the slot on the SCSI controller by using the number of drives attached to that controller. This leads to exceptions when detaching volumes having lower numbered slots and then attaching a new volume. Take for example 2 volumes attached which will have 0 and 1 as controller addresses. If the first one gets detached, the next time we'll try to attach a volume the controller address 1 will be used (as it's the number of drives attached to the controller at that time) but that slot is actually uesd, so it will raise an exception. ** Affects: nova Importance: Undecided Status: New ** Tags: driver hyper-v -- 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/1329764 Title: Hyper-V volume attach issue: wrong SCSI slot is selected Status in OpenStack Compute (Nova): New Bug description: When attaching volumes, the Hyper-V driver selects the slot on the SCSI controller by using the number of drives attached to that controller. This leads to exceptions when detaching volumes having lower numbered slots and then attaching a new volume. Take for example 2 volumes attached which will have 0 and 1 as controller addresses. If the first one gets detached, the next time we'll try to attach a volume the controller address 1 will be used (as it's the number of drives attached to the controller at that time) but that slot is actually uesd, so it will raise an exception. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1329764/+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 1329042] Re: gate-tempest-dsvm-large-ops fails consistently in stable/havana
** No longer affects: nova
** Changed in: openstack-ci
Importance: Undecided = Critical
** Changed in: openstack-ci
Assignee: Matt Riedemann (mriedem) = Joe Gordon (jogo)
--
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/1329042
Title:
gate-tempest-dsvm-large-ops fails consistently in stable/havana
Status in OpenStack Core Infrastructure:
In Progress
Bug description:
Noticed here:
http://logs.openstack.org/74/98874/2/check/gate-tempest-dsvm-large-
ops/7a996eb/console.html
2014-06-10 20:23:27.323 | FAIL:
tempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]
2014-06-10 20:23:27.323 | tags: worker-0
2014-06-10 20:23:27.323 |
--
2014-06-10 20:23:27.323 | Empty attachments:
2014-06-10 20:23:27.323 | pythonlogging:''
2014-06-10 20:23:27.323 | stderr
2014-06-10 20:23:27.323 | stdout
2014-06-10 20:23:27.323 |
2014-06-10 20:23:27.323 | Traceback (most recent call last):
2014-06-10 20:23:27.323 | File tempest/scenario/test_large_ops.py, line
105, in test_large_ops_scenario
2014-06-10 20:23:27.323 | self.nova_boot()
2014-06-10 20:23:27.324 | File tempest/scenario/test_large_ops.py, line
98, in nova_boot
2014-06-10 20:23:27.324 | self._wait_for_server_status('ACTIVE')
2014-06-10 20:23:27.324 | File tempest/scenario/test_large_ops.py, line
42, in _wait_for_server_status
2014-06-10 20:23:27.324 | self.compute_client.servers, server.id, status)
2014-06-10 20:23:27.324 | File tempest/scenario/manager.py, line 327, in
status_timeout
2014-06-10 20:23:27.324 | not_found_exception=not_found_exception)
2014-06-10 20:23:27.324 | File tempest/scenario/manager.py, line 381, in
_status_timeout
2014-06-10 20:23:27.324 | self.config.compute.build_interval):
2014-06-10 20:23:27.324 | File tempest/test.py, line 256, in
call_until_true
2014-06-10 20:23:27.324 | if func():
2014-06-10 20:23:27.324 | File tempest/scenario/manager.py, line 372, in
check_status
2014-06-10 20:23:27.325 | raise exceptions.BuildErrorException(message)
2014-06-10 20:23:27.325 | BuildErrorException: Server %(server_id)s failed to
build and is in ERROR status
2014-06-10 20:23:27.325 | Details: Server:
scenario-server-1764126375-0cf3a925-46a2-4305-9b9c-df08b6e9302e failed to get
to expected status. In ERROR state.
Looks like it's hitting all stable/havana though:
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiU2VydmVyOiBzY2VuYXJpby1zZXJ2ZXJcIiBBTkQgbWVzc2FnZTpcImZhaWxlZCB0byBnZXQgdG8gZXhwZWN0ZWQgc3RhdHVzXCIgQU5EIG1lc3NhZ2U6XCJJbiBFUlJPUiBzdGF0ZVwiIEFORCBidWlsZF9uYW1lOlwiZ2F0ZS10ZW1wZXN0LWRzdm0tbGFyZ2Utb3BzXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDI1MTQ1Nzc2Nzl9
6 hits in 2 days, all fails, check and gate.
Sounds like this should be 50 for stable/havana:
DEVSTACK_GATE_TEMPEST_LARGE_OPS=100
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ci/+bug/1329042/+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
** Changed in: diskimage-builder 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 Committed Status in Openstack disk image builder: Fix Released Status in tripleo - openstack on openstack: Triaged Status in “cloud-init” package in Ubuntu: Fix Released Status in “cloud-init” source package in Trusty: Triaged 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 disables Cloud Sigma by default. Verification: 1. Purge Cloud-init 2. Install from -proposed 3. Look in /etc/cloud/cloud.d/90_dpkg.cfg, and confirm CloudSigma is not in the list of datasources. Regression: The risk is low, except on CloudSigma targets which try to use new images generated with the new Cloud-init version. [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 1329791] [NEW] Tempest: Deleting the tenant not deleting the security groups/rules associated
Public bug reported: Steps to Reproduce: 1. Create multiple tenant and perform some operations. 2. Check the security groups list multiple default security groups gets created associated to each tenants. 3. Delete all the resources corresponding to each tenant and then delete all the tenant except admin and service. 4. Again list the security group. Note :Running tempest automation create each time tenant and delete them leaving the security group and rule undeleted. Actual Results: All the security group/rile remain as its in spite of deleting the tenant associated to it. Expected Results: All the security group/rule associated to deleted tenant should also gets deleted ** Affects: neutron Importance: Undecided Status: New ** Attachment added: sec_rule_group_del.txt https://bugs.launchpad.net/bugs/1329791/+attachment/4131049/+files/sec_rule_group_del.txt -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1329791 Title: Tempest: Deleting the tenant not deleting the security groups/rules associated Status in OpenStack Neutron (virtual network service): New Bug description: Steps to Reproduce: 1. Create multiple tenant and perform some operations. 2. Check the security groups list multiple default security groups gets created associated to each tenants. 3. Delete all the resources corresponding to each tenant and then delete all the tenant except admin and service. 4. Again list the security group. Note :Running tempest automation create each time tenant and delete them leaving the security group and rule undeleted. Actual Results: All the security group/rile remain as its in spite of deleting the tenant associated to it. Expected Results: All the security group/rule associated to deleted tenant should also gets deleted To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1329791/+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 1329864] [NEW] Owner role is broken in default v2 policy file
Public bug reported: In v2 policy.json owner is defined as owner : user_id:%(user_id)s, It should be owner : user_id:%(user_id)s or user_id:%(target.token.user_id)s, Affected APIs, Using default v2 policy file a user can't delete his own token due to this defect ** 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/1329864 Title: Owner role is broken in default v2 policy file Status in OpenStack Identity (Keystone): New Bug description: In v2 policy.json owner is defined as owner : user_id:%(user_id)s, It should be owner : user_id:%(user_id)s or user_id:%(target.token.user_id)s, Affected APIs, Using default v2 policy file a user can't delete his own token due to this defect To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329864/+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 1329864] Re: Owner role is broken in default v2 policy file
That's originally by design, but I agree with the notion that users should be able to delete their own tokens, even though it's traditionally an administrative function (I see it as logging out). ** Changed in: keystone Importance: Undecided = Wishlist ** Changed in: keystone Status: New = Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1329864 Title: Owner role is broken in default v2 policy file Status in OpenStack Identity (Keystone): Opinion Bug description: In v2 policy.json owner is defined as owner : user_id:%(user_id)s, It should be owner : user_id:%(user_id)s or user_id:%(target.token.user_id)s, Affected APIs, Using default v2 policy file a user can't delete his own token due to this defect To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329864/+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 1329891] [NEW] Keystone Not Able to Add Users to AD/Ldap and OpenLdap
Public bug reported:
I tried to add uses to AD/Ldap through keystone with the following curl command
-
curl -s -k -H 'X-Auth-Token: ADMIN' -H 'Content-Type: application/json' -d
'{user: {name: test7, password: Devtest123}}'
http://localhost:35357/v3/users
Keystone showed the following stack trace -
__init__ /home/leonchio/dev/keystone/keystone/common/ldap/core.py:713
2014-06-13 10:40:50.064 1420 DEBUG keystone.common.ldap.core [-] LDAP bind:
dn=CN=Administrator,CN=Users,DC=vlan44,DC=domain simple_bind_s
/home/leonchio/dev/keystone/keystone/common/ldap/core.py:773
('## values ## %s', {'password':
'{SSHA}BFn5qzp/hJjhJMea9JWrmHymXrNQyjkn', 'enabled': True, 'id':
'1c81387f5aea40329bc9f77c90109c66', 'name': u'test7'})
2014-06-13 10:40:50.066 1420 DEBUG keystone.common.ldap.core [-] LDAP add:
dn=cn=1c81387f5aea40329bc9f77c90109c66,cn=Users,dc=vlan44,dc=domain,
attrs=[('objectClass', [u'person', u'user']), ('userPassword', ['']),
('enabled', [u'TRUE']), ('cn', [u'test7'])] add_s
/home/leonchio/dev/keystone/keystone/common/ldap/core.py:793
2014-06-13 10:40:50.068 1420 DEBUG keystone.common.ldap.core [-] LDAP unbind
unbind_s /home/leonchio/dev/keystone/keystone/common/ldap/core.py:779
2014-06-13 10:40:50.068 1420 ERROR keystone.common.wsgi [-] {'info': 2081:
NameErr: DSID-03050CDA, problem 2003 (BAD_ATT_SYNTAX), data 0, best match
of:\n\t'cn=1c81387f5aea40329bc9f77c90109c66,cn=Users,dc=vlan44,dc=domain'\n,
'desc': 'Invalid DN syntax'}
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi Traceback (most recent
call last):
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/common/wsgi.py, line 207, in __call__
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi result =
method(context, **params)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/common/controller.py, line 152, in inner
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi return f(self,
context, *args, **kwargs)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/identity/controllers.py, line 276, in
create_user
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi ref =
self.identity_api.create_user(ref['id'], ref)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/notifications.py, line 74, in wrapper
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi result = f(*args,
**kwargs)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/identity/core.py, line 189, in wrapper
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi return f(self,
*args, **kwargs)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/identity/core.py, line 299, in
create_user
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi ref =
driver.create_user(user_id, user)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/identity/backends/ldap.py, line 91, in
create_user
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi user_ref =
self.user.create(user)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/identity/backends/ldap.py, line 231, in
create
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi values =
super(UserApi, self).create(values)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/common/ldap/core.py, line 996, in create
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi return
super(EnabledEmuMixIn, self).create(values)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/common/ldap/core.py, line 566, in create
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi
conn.add_s(self._id_to_dn(values['id']), attrs)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/home/leonchio/dev/keystone/keystone/common/ldap/core.py, line 797, in add_s
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi return
self.conn.add_s(dn_utf8, ldap_attrs_utf8)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py, line 194, in add_s
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi return
self.result(msgid,all=1,timeout=self.timeout)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py, line 422, in result
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi
res_type,res_data,res_msgid = self.result2(msgid,all,timeout)
2014-06-13 10:40:50.068 1420 TRACE keystone.common.wsgi File
/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py, line 426, in
result2
2014-06-13 10:40:50.068 1420 TRACE
[Yahoo-eng-team] [Bug 1328359] Re: keystone uses incorrect OS_AUTH_URL
** Project changed: keystone = python-keystoneclient ** Tags added: user-experience -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1328359 Title: keystone uses incorrect OS_AUTH_URL Status in Python client library for Keystone: In Progress Bug description: The keystone command does not honor the env[OS_AUTH_URL] or --os-auth- url CLI parameter. The authorization URL defaults to http://controller:35357/v2.0 regardless if a different auth URL is specified. This error was found on CentOS 6.5 (2.6.32-431.17.1.el6.x86_64) in reference to keystone verification: http://docs.openstack.org/icehouse/install-guide/install/yum/content /keystone-verify.html. Steps to reproduce: # export OS_USERNAME=admin # export OS_PASSWORD=ADMIN_PASS # export OS_TENANT_NAME=admin # export OS_AUTH_URL=http://HOST_NAME:35357/v2.0 # keystone user-list or # keystone --os-auth-url=http://HOST_NAME:35357/v2.0 user-list This produces the following error: Unable to establish connection to http://controller:35357/v2.0/users This command continued to fail until an entry for controller was added to the /etc/hosts file. While the documentation does specify to include entries in the hosts file for the controller, it is not reliable to assume static hosts are available in a production ENV. To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1328359/+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 1328288] Re: openvswitch agent fails with bridges longer than 11 chars
** Also affects: fuel Importance: Undecided Status: New ** Changed in: fuel Status: New = Confirmed ** Changed in: fuel Importance: Undecided = Medium ** Changed in: fuel Assignee: (unassigned) = Fuel OSCI Team (fuel-osci) ** Changed in: fuel Milestone: None = 5.1 ** Also affects: fuel/5.0.x Importance: Undecided Status: New ** Changed in: fuel/5.0.x Milestone: None = 5.0.1 ** Changed in: fuel/5.0.x Status: New = Confirmed ** Changed in: fuel/5.0.x Importance: Undecided = Medium ** Changed in: fuel/5.0.x Assignee: (unassigned) = Fuel OSCI Team (fuel-osci) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1328288 Title: openvswitch agent fails with bridges longer than 11 chars Status in Fuel: OpenStack installer that works: Confirmed Status in Fuel for OpenStack 5.0.x series: Confirmed Status in OpenStack Neutron (virtual network service): Fix Released Bug description: The openvswitch agent will try to construct veth pairs with names longer than the maximum allowed (15) and fail. VMs will then have no external connectivity. This happens in cases where the bridge name is very long (e.g. int-br- bonded). To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1328288/+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 1329941] [NEW] XEN: Volume VDIs not cleaned up if boot fails before VBD creation
Public bug reported: During the spawn process the rollback portion of the create_vm_record step is supposed to detach volumes, destroy the VBDs, and then purge the SR. But this process relies on looking up VBDs attached to the instance. If the spawn process fails while creating/resizing a VDI then there's no VBD to lookup and the SR and VDI will be left on the hypervisor as orphans. ** Affects: nova Importance: Medium Status: New ** Tags: xenserver -- 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/1329941 Title: XEN: Volume VDIs not cleaned up if boot fails before VBD creation Status in OpenStack Compute (Nova): New Bug description: During the spawn process the rollback portion of the create_vm_record step is supposed to detach volumes, destroy the VBDs, and then purge the SR. But this process relies on looking up VBDs attached to the instance. If the spawn process fails while creating/resizing a VDI then there's no VBD to lookup and the SR and VDI will be left on the hypervisor as orphans. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1329941/+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 1157331] Re: nvp plugin should allow admin to disable security groups completely
using the port-security extension you can do this on networks so i'm closing this out. ** Changed in: neutron Status: Triaged = 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/1157331 Title: nvp plugin should allow admin to disable security groups completely Status in OpenStack Neutron (virtual network service): Fix Released Bug description: There should be a way for the nvp plugin to disable security groups completely if a cloud does not want to use security groups. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1157331/+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 1329949] [NEW] Snapshots are unsorted when launching from snapshot
Public bug reported: When launching from a snapshot, the snapshots are in arbitrary, unsorted order. ** Affects: horizon Importance: Undecided Assignee: Chris St. Pierre (stpierre) Status: In Progress ** Changed in: horizon Status: New = In Progress ** Changed in: horizon Assignee: (unassigned) = Chris St. Pierre (stpierre) -- 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/1329949 Title: Snapshots are unsorted when launching from snapshot Status in OpenStack Dashboard (Horizon): In Progress Bug description: When launching from a snapshot, the snapshots are in arbitrary, unsorted order. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1329949/+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 1329954] [NEW] Natural sort instance names
Public bug reported: Instance names in most tables are sorted numerically, not naturally, so you get things like: inst1 inst10 inst2 inst3 ... ** Affects: horizon Importance: Undecided Assignee: Chris St. Pierre (stpierre) Status: In Progress ** Changed in: horizon Status: New = In Progress ** Changed in: horizon Assignee: (unassigned) = Chris St. Pierre (stpierre) -- 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/1329954 Title: Natural sort instance names Status in OpenStack Dashboard (Horizon): In Progress Bug description: Instance names in most tables are sorted numerically, not naturally, so you get things like: inst1 inst10 inst2 inst3 ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1329954/+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 1251448] [NEW] BadRequest: Multiple possible networks found, use a Network ID to be more specific.
You have been subscribed to a public bug: Gate (only neutron based) is peridocally failing with the following error: BadRequest: Multiple possible networks found, use a Network ID to be more specific. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiIHBvc3NpYmxlIG5ldHdvcmtzIGZvdW5kLCB1c2UgYSBOZXR3b3JrIElEIHRvIGJlIG1vcmUgc3BlY2lmaWMuIChIVFRQIDQwMClcIiBBTkQgZmlsZW5hbWU6XCJjb25zb2xlLmh0bWxcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNDMyMDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxMzg0NDY2ODA0Mjg2LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 query: message: possible networks found, use a Network ID to be more specific. (HTTP 400) AND filename:console.html Example: http://logs.openstack.org/75/54275/3/check/check-tempest- devstack-vm-neutron-pg/61a2974/console.html Failure breakdown by job: check-tempest-devstack-vm-neutron-pg 34% check-tempest-devstack-vm-neutron 24% gate-tempest-devstack-vm-neutron 10% gate-tempest-devstack-vm-neutron-pg5% ** Affects: neutron Importance: Undecided Status: New ** Affects: tempest Importance: Undecided Status: Won't Fix ** Tags: havana-backport-potential tempest -- BadRequest: Multiple possible networks found, use a Network ID to be more specific. https://bugs.launchpad.net/bugs/1251448 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 1251448] Re: BadRequest: Multiple possible networks found, use a Network ID to be more specific.
I don't see this as a heat issue at all. Heat is deleting things and accepting Neutron's answer that they are in fact deleted. Reassigning to Neutron. ** Project changed: heat = 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/1251448 Title: BadRequest: Multiple possible networks found, use a Network ID to be more specific. Status in OpenStack Neutron (virtual network service): New Status in Tempest: Won't Fix Bug description: Gate (only neutron based) is peridocally failing with the following error: BadRequest: Multiple possible networks found, use a Network ID to be more specific. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiIHBvc3NpYmxlIG5ldHdvcmtzIGZvdW5kLCB1c2UgYSBOZXR3b3JrIElEIHRvIGJlIG1vcmUgc3BlY2lmaWMuIChIVFRQIDQwMClcIiBBTkQgZmlsZW5hbWU6XCJjb25zb2xlLmh0bWxcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNDMyMDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxMzg0NDY2ODA0Mjg2LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 query: message: possible networks found, use a Network ID to be more specific. (HTTP 400) AND filename:console.html Example: http://logs.openstack.org/75/54275/3/check/check-tempest- devstack-vm-neutron-pg/61a2974/console.html Failure breakdown by job: check-tempest-devstack-vm-neutron-pg 34% check-tempest-devstack-vm-neutron24% gate-tempest-devstack-vm-neutron 10% gate-tempest-devstack-vm-neutron-pg 5% To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1251448/+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 1326811] Re: Client failing with six =1.6 error
** Changed in: python-openstackclient Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1326811 Title: Client failing with six =1.6 error Status in devstack - openstack dev environments: Fix Released Status in OpenStack Identity (Keystone): Invalid Status in OpenStack Compute (Nova): Invalid Status in OpenStack Command Line Client: Invalid Status in Openstack Database (Trove): Invalid Bug description: 13:20:45 + screen -S stack -p key -X stuff 'cd /opt/stack/keystone /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --debug echo $! /opt/stack/status/stack/key.pid; fg || echo key failed to start | tee /opt/stack/status/stack/key.failure ' 13:20:45 Waiting for keystone to start... 13:20:45 + echo 'Waiting for keystone to start...' 13:20:45 + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -k -s http://10.5.141.237:5000/v2.0/ /dev/null; do sleep 1; done' 13:20:46 + is_service_enabled tls-proxy 13:20:46 ++ set +o 13:20:46 ++ grep xtrace 13:20:46 + local 'xtrace=set -o xtrace' 13:20:46 + set +o xtrace 13:20:46 + return 1 13:20:46 + SERVICE_ENDPOINT=http://10.5.141.237:35357/v2.0 13:20:46 + is_service_enabled tls-proxy 13:20:46 ++ set +o 13:20:46 ++ grep xtrace 13:20:46 + local 'xtrace=set -o xtrace' 13:20:46 + set +o xtrace 13:20:46 + return 1 13:20:46 + export OS_TOKEN=be19c524ddc92109a224 13:20:46 + OS_TOKEN=be19c524ddc92109a224 13:20:46 + export OS_URL=http://10.5.141.237:35357/v2.0 13:20:46 + OS_URL=http://10.5.141.237:35357/v2.0 13:20:46 + create_keystone_accounts 13:20:46 ++ openstack project create admin 13:20:46 ++ grep ' id ' 13:20:46 ++ get_field 2 13:20:46 ++ read data 13:20:46 ERROR: openstackclient.shell Exception raised: six=1.6.0 13:20:46 + ADMIN_TENANT= 13:20:46 ++ openstack user create admin --project '' --email ad...@example.com --password 3de4922d8b6ac5a1aad9 13:20:46 ++ grep ' id ' 13:20:46 ++ get_field 2 13:20:46 ++ read data 13:20:47 ERROR: openstackclient.shell Exception raised: six=1.6.0 13:20:47 + ADMIN_USER= 13:20:47 ++ openstack role create admin 13:20:47 ++ grep ' id ' 13:20:47 ++ get_field 2 13:20:47 ++ read data 13:20:47 ERROR: openstackclient.shell Exception raised: six=1.6.0 13:20:47 + ADMIN_ROLE= 13:20:47 + openstack role add --project --user 13:20:47 ERROR: openstackclient.shell Exception raised: six=1.6.0 13:20:47 + exit_trap 13:20:47 + local r=1 13:20:47 ++ jobs -p 13:20:47 + jobs= 13:20:47 + [[ -n '' ]] 13:20:47 + kill_spinner 13:20:47 + '[' '!' -z '' ']' 13:20:47 + exit 1 https://rdjenkins.dyndns.org/job/Trove-Gate/3974/console To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1326811/+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 1327397] Re: No notice given when db migrations are not run due to missing engine
** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Status: New = Confirmed ** Changed in: nova Importance: Undecided = Low -- 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/1327397 Title: No notice given when db migrations are not run due to missing engine Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Released Status in OpenStack Compute (Nova): Confirmed Status in Oslo - a Library of Common OpenStack Code: New Bug description: When the unit test suite is run and there is no backend configured for testing migrations, the test passes rather than indicating that it was skipped. This has caused developers to assume the test passed when, in fact, it never ran. To run the migration tests, one must configure a storage backend in tests/db/sqlalchemy/test_migrations.conf In the absence of this, TestMigrations.test_walk_versions should be skipped. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1327397/+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 1329984] [NEW] improve help messages on modals
Public bug reported: It will be a great effort to clean up all the messaging in Horizon, but we can take a first step with some of the help messages. :) Here are some examples of things to update: 1. From here you can create a new domain to organize projects, groups and users. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/domains/workflows.py#L45 (a) You don't need the first four words. (b) You shouldn't use new when you use the verb create because new is implicit when you create. (c) Insert a comma before and. Therefore, the suggested replacement text is as follows: Create a domain to organize projects, groups, and users. We should apply this to other modals as well. 2. We should also avoid using words like Info. Those should all be replaced with Information. Domain Info == Domain Information https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/domains/workflows.py#L43 Other Guidelines: https://wiki.openstack.org/wiki/UX/Improve_User_Experience_of_Messaging_in_Horizon ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1329984 Title: improve help messages on modals Status in OpenStack Dashboard (Horizon): New Bug description: It will be a great effort to clean up all the messaging in Horizon, but we can take a first step with some of the help messages. :) Here are some examples of things to update: 1. From here you can create a new domain to organize projects, groups and users. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/domains/workflows.py#L45 (a) You don't need the first four words. (b) You shouldn't use new when you use the verb create because new is implicit when you create. (c) Insert a comma before and. Therefore, the suggested replacement text is as follows: Create a domain to organize projects, groups, and users. We should apply this to other modals as well. 2. We should also avoid using words like Info. Those should all be replaced with Information. Domain Info == Domain Information https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/domains/workflows.py#L43 Other Guidelines: https://wiki.openstack.org/wiki/UX/Improve_User_Experience_of_Messaging_in_Horizon To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1329984/+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 1330026] [NEW] API docs say POST token request returns 200
Public bug reported: http://developer.openstack.org/api-ref-identity-v3.html In the tokens section, for creating a token, its says: the Normal Response Codes is 200, but the normal response code is 201. ** Affects: keystone Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1330026 Title: API docs say POST token request returns 200 Status in OpenStack Identity (Keystone): New Bug description: http://developer.openstack.org/api-ref-identity-v3.html In the tokens section, for creating a token, its says: the Normal Response Codes is 200, but the normal response code is 201. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330026/+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
