[Yahoo-eng-team] [Bug 1482772] Re: Region filtering for endpoints does not work
According to the V3 API docs, only interface and service_id are the
supported query parameter: http://specs.openstack.org/openstack
/keystone-specs/api/v3/identity-api-v3.html#list-endpoints
Opened a bug to remove the region query parameter from OSC.
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** Changed in: keystone
Status: New = Invalid
** Changed in: python-openstackclient
Assignee: (unassigned) = Lin Hua Cheng (lin-hua-cheng)
** Also affects: python-keystoneclient
Importance: Undecided
Status: New
** Changed in: python-keystoneclient
Assignee: (unassigned) = Lin Hua Cheng (lin-hua-cheng)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1482772
Title:
Region filtering for endpoints does not work
Status in Keystone:
Invalid
Status in python-keystoneclient:
New
Status in python-openstackclient:
New
Bug description:
When i run “openstack endpoint list --os-url http://192.168.33.10:5000/v3
--os-identity-api-version=3 --service identity --interface public --region
RegionTwo” i would expect that it only lists endpoints from RegionTwo. But i
get the identity endpoint from RegionOne. Here is the output:
+--+---+--+--+-+---++
| ID | Region| Service Name | Service Type
| Enabled | Interface | URL|
+--+---+--+--+-+---++
| 4b3efc615c044fb4a2c70ca2e5e7bba9 | RegionOne | keystone | identity
| True| public| http://192.168.33.10:5000/v2.0 |
+--+---+--+--+-+---++
As this snippet from the debug output from openstackclient shows, the
client sends the correct query to keystone. So i assume this is a
filtering problem in keystone.
DEBUG: requests.packages.urllib3.connectionpool GET
/v3/endpoints?interface=publicservice_id=050872861656437184778a822032d8d6region=RegionTwo
HTTP/1.1 200 506
DEBUG: keystoneclient.session RESP: [200] content-length: 506 vary:
X-Auth-Token keep-alive: timeout=5, max=96 server: Apache/2.4.7 (Ubuntu)
connection: Keep-Alive date: Fri, 07 Aug 2015 19:37:08 GMT content-type:
application/json x-openstack-request-id:
req-72481573-7fff-4ae0-9a2f-33584b476bd3
RESP BODY: {endpoints: [{region_id: RegionOne, links: {self:
http://192.168.33.10:35357/v3/endpoints/4b3efc615c044fb4a2c70ca2e5e7bba9},
url: http://192.168.33.10:5000/v2.0;, region: RegionOne, enabled:
true, interface: public, service_id: 050872861656437184778a822032d8d6,
id: 4b3efc615c044fb4a2c70ca2e5e7bba9}], links: {self:
http://192.168.33.10:35357/v3/endpoints?interface=publicservice_id=050872861656437184778a822032d8d6region=RegionTwo;,
previous: null, next: null}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1482772/+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 1483497] [NEW] Validate local_ip for linuxbridge-agent
Public bug reported: Currently, linuxbridge-agent does some validation on local_ip, but it is not sufficient. When local_ip doesn't exist, linuxbridge-agent just logs a warning and continue processing. When a vxlan interface creates, it runs 'ip link vxlan-xxx ... dev None' and the shell command returns 255, which seems weird. The local ip should be validated and the agent doesn't need to continue working when local_ip is not there. ** Affects: neutron Importance: Undecided Assignee: Li Ma (nick-ma-z) Status: New ** Tags: linuxbridge-agent ** Changed in: neutron Assignee: (unassigned) = Li Ma (nick-ma-z) ** Tags added: linuxbridge-agent -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1483497 Title: Validate local_ip for linuxbridge-agent Status in neutron: New Bug description: Currently, linuxbridge-agent does some validation on local_ip, but it is not sufficient. When local_ip doesn't exist, linuxbridge-agent just logs a warning and continue processing. When a vxlan interface creates, it runs 'ip link vxlan-xxx ... dev None' and the shell command returns 255, which seems weird. The local ip should be validated and the agent doesn't need to continue working when local_ip is not there. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1483497/+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 836973] Re: nova should keep instance data after termination
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api Importance: Undecided = Wishlist -- 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/836973 Title: nova should keep instance data after termination Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: On EC2, instances are available in DescribeInstances output afer they're terminated. In nova, at the moment, they disappear immediately. This makes getting shutdown console output just about impossible. Relevant link to amazon ec2 documentation: http://docs.amazonwebservices.com/AWSEC2/latest/DeveloperGuide/index.html?instance-console.html Only the most recent 64 KB of posted output is stored, which is available for at least 1 hour after the last posting. $ euca-run-instances --key mykey ami-0056 RESERVATION r-227nsegw smoser_project default INSTANCE i-0200 ami-0056scheduling mykey 0 m1.small2011-08-29T20:11:09Zunknown zone aki-0052ari-0053 $ euca-get-console-output i-0201 | tail -n 5 ec2: 1024 83:c3:7a:9b:42:fc:0d:c5:48:96:bd:46:62:25:bf:34 /etc/ssh/ssh_host_dsa_key.pub (DSA) ec2: -END SSH HOST KEY FINGERPRINTS- ec2: # landscape-client is not configured, please run landscape-config. $ euca-terminate-instances i-0201 #no output # wait 10 seconds or so $ euca-describe-instances i-0201 #no output $ echo $? 0 $ euca-get-console-output i-0201 InstanceNotFound: Instance %(instance_id)s could not be found. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/836973/+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 1278526] Re: EC2 signature verification does not take port into account
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api 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/1278526 Title: EC2 signature verification does not take port into account Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: Nova Version: master (and probably previous) Tested with euca2ools 3.0.2-1 on Debian Line numbers based on commit 48e8f992f46862cb4f50fe0cc9b77a3017e7bb23 in master for nova, commit 8557e4756e8a326579df826076478d98ca634345 in master for keystone. EC2 protocol requires Signature calculated for every request. The signature is calculated from: access_key, signature, host, verb, path and params. These values together with the signature are passed to Keystone for verification as seen in: https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py#L201-L232 Verification is done by Kestone's check_signature functon define: https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L53-L67 The root of the problem: - euca2ools use port in host field (hostname.of.endpoint:8773 for signing signature - keystone takes into account that client signing the request may append the port into the host field and does the signature verification twice: with the port and without - nova never passes the port along with the host to keystone (line 205 of nova/api/ec2/__init__.py) This results in always incorrect signature rendering EC2 protocol useless for clients that append port to the host. It is not an issue if the port is not used to calculate signature if such clients exist. Simple fix: append the port in /nova/api/ec2/__init__.py line 204. Actual problem: for deployments that use SSL termination proxy and/or rewrite URLs, the port visible to the client is not necessarily the standard port used by Nova for EC2 (8773) nor the one specified in the configuration for nova to listen on. Therefore, I suggest to create a new configuration option for this purpose, which dynamically defaults to ec2_listen_port (usually 8773). It also seems that ec2_port configuration option can be used for that purpose as it already has this meaning to hold port visible by the user, not the one that EC2 API is listening on. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1278526/+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 829880] Re: object store doesn't like key with '/'
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Fix Committed ** Changed in: ec2-api Importance: Undecided = Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/829880 Title: object store doesn't like key with '/' Status in ec2-api: Fix Committed Status in pyjuju: Fix Released Status in OpenStack Compute (nova): Won't Fix Status in juju package in Ubuntu: Fix Released Bug description: It looks like it should be correct given that its taking a hash of the key for the filename in the bucket dir, but it looks like its running afoul before it gets there.. sample script to reproduce (python+boto) against nova-objectstore (s3server.py) import boto import os from boto.s3.connection import S3Connection, OrdinaryCallingFormat s3 = S3Connection( aws_access_key_id=os.environ[EC2_ACCESS_KEY], aws_secret_access_key=os.environ[EC2_SECRET_KEY], host = os.environ[S3_URL][len(http://;):], is_secure = False, calling_format=OrdinaryCallingFormat()) bucket = s3.create_bucket(es-testing-123) print new key key = bucket.new_key(abc.txt) key.set_contents_from_string(abcdef) print new nested key key = bucket.new_key(zoo/abc.txt) key.set_contents_from_string(abcdef) Fails with S3ResponseError: 404 Not Found 404 Not Found The resource could not be found. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/829880/+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 827569] Re: ec2metadata service does not include 2011-01-01
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Confirmed ** Changed in: ec2-api Importance: Undecided = Wishlist -- 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/827569 Title: ec2metadata service does not include 2011-01-01 Status in ec2-api: Confirmed Status in OpenStack Compute (nova): Opinion Bug description: On EC2: $ wget -q -O - http://169.254.169.254/; echo 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 latest on Openstack: wget -q -O - http://169.254.169.254/; echo 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 I noticed this when using 'ec2metadata'. I shoudl probably back of the api version for that, or use 'latest'. but it would be nice if 2011-01-01 was present. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/827569/+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 1160850] Re: ec2 (DescribeKeyPairs) does not supports filtering by fingerprint
** Also affects: ec2-api Importance: Undecided Status: New ** Changed in: ec2-api Status: New = Fix Committed ** Changed in: ec2-api Importance: Undecided = Low ** Changed in: ec2-api Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1160850 Title: ec2 (DescribeKeyPairs) does not supports filtering by fingerprint Status in ec2-api: Fix Released Status in OpenStack Compute (nova): Opinion Bug description: euca-describe-keypairs --filter fingerprint=c0:40:d9:8b:e2:09:11:2b:59:a8:86:3b:03:87:5d:e5 KEYPAIR testc0:40:d9:8b:e2:09:11:2b:59:a8:86:3b:03:87:5d:e5 KEYPAIR test2 1d:25:e8:42:1a:59:ce:59:6c:b1:2c:76:d6:4b:cd:de The listing shows me all keypairs even if I define a filter. nova version: 9a90f6ccdb88a22ff17b3f48d26378b4fa613ede To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1160850/+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 1483287] [NEW] test_models_sync() will be broken on upcoming Alembic versions
Public bug reported: test_models_sync() is currently making assumptions, that won't be true in the upcoming Alembic releases (0.7.7 and 0.8.0 respectively). Unless we fix it now, it's going to break the gate when the releases of Alembic are cut. Mike Bayer's comment in the original patch: https://review.openstack.org/#/c/192760/14/nova/tests/unit/db/test_migrations.py,cm ML thread: http://lists.openstack.org/pipermail/openstack- dev/2015-August/071638.html ** Affects: nova Importance: Undecided Assignee: Roman Podoliaka (rpodolyaka) Status: New ** Changed in: nova Assignee: (unassigned) = Roman Podoliaka (rpodolyaka) -- 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/1483287 Title: test_models_sync() will be broken on upcoming Alembic versions Status in OpenStack Compute (nova): New Bug description: test_models_sync() is currently making assumptions, that won't be true in the upcoming Alembic releases (0.7.7 and 0.8.0 respectively). Unless we fix it now, it's going to break the gate when the releases of Alembic are cut. Mike Bayer's comment in the original patch: https://review.openstack.org/#/c/192760/14/nova/tests/unit/db/test_migrations.py,cm ML thread: http://lists.openstack.org/pipermail/openstack- dev/2015-August/071638.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483287/+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 1472712] Re: [SRU] Using SSL with rabbitmq prevents communication between nova-compute and conductor after latest nova updates
** Changed in: python-amqp (Ubuntu)
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1472712
Title:
[SRU] Using SSL with rabbitmq prevents communication between nova-
compute and conductor after latest nova updates
Status in OpenStack Compute (nova):
Invalid
Status in oslo.messaging:
Invalid
Status in python-amqp package in Ubuntu:
Fix Released
Status in python-amqp source package in Trusty:
In Progress
Bug description:
[Impact]
Current oslo.messaging and python-amqp results in repeated connection
timeouts in the amqp transport layer (SSLError) and thus excessive
reconnect attempts. This is a known issues that was fixed in python-
amqp 1.4.4.
[Test Case]
Deploy openstack using current Trusty versions + this version of
python-amqp + rabbitmq configured to allow ssl connections only. Once
up and running, check the following:
- number of rabbitmq connections - with single nova-compute,
conductor etc I see approx 20 connections whereas previously i saw
well over 100 and rising.
sudo rabbitmqctl list_connections
- check that messages are being consumed from openstack queues
sudo rabbitmqctl list_queues -p openstack consumers messages name
- also check e.g. nova-compute and nova-conductor logs and verify that
the erros menioned below no longer appear
[Regression Potential]
None.
[Other Info]
None.
-
On the latest update of the Ubuntu OpenStack packages, it was
discovered that the nova-compute/nova-conductor
(1:2014.1.4-0ubuntu2.1) packages encountered a bug with using SSL to
connect to rabbitmq.
When this problem occurs, the compute node cannot connect to the
controller, and this message is constantly displayed:
WARNING nova.conductor.api [req-4022395c-9501-47cf-bf8e-476e1cc58772
None None] Timed out waiting for nova-conductor. Is it running? Or did
this service start before nova-conductor?
Investigation revealed that having rabbitmq configured with SSL was
the root cause of this problem. This seems to have been introduced
with the current version of the nova packages. Rabbitmq was not
updated as part of this distribution update, but the messaging library
(python-oslo.messaging 1.3.0-0ubuntu1.1) was updated. So the problem
could exist in any of these components.
Versions installed:
Openstack version: Icehouse
Ubuntu 14.04.2 LTS
nova-conductor1:2014.1.4-0ubuntu2.1
nova-compute1:2014.1.4-0ubuntu2.1
rabbitmq-server 3.2.4-1
openssl:amd64/trusty-security 1.0.1f-1ubuntu2.15
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1472712/+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 1483335] [NEW] ExtendedVolumes extension has poor performance
Public bug reported: ExtendedVolumes has poor performance because it query block device mapping formance for every instances. that's because block_device_mapping_get_all_by_instance() only takes on instance_uuid. if this function taks instance_uuid list. then we can have better performance with IN operator with just on query. ** 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/1483335 Title: ExtendedVolumes extension has poor performance Status in OpenStack Compute (nova): New Bug description: ExtendedVolumes has poor performance because it query block device mapping formance for every instances. that's because block_device_mapping_get_all_by_instance() only takes on instance_uuid. if this function taks instance_uuid list. then we can have better performance with IN operator with just on query. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483335/+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 1446449] Re: ironic hypervisor resource should be released for booting failed case
Hi! I think fix for this problem is within the nova driver, so I'm closing the ironic part of this bug. Please let me know if something should be fixed in ironic source code as well. ** Changed in: ironic Status: In Progress = 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/1446449 Title: ironic hypervisor resource should be released for booting failed case Status in Ironic: Invalid Status in OpenStack Compute (nova): In Progress Bug description: nova boot failed in spawn step, the ironic hypervisor show the mem/cpu/disk resource still be occpied by the nova instance which is in error status, I understand for such boot failed case, the ironic hypervisor resource should be released once the boot is completed with error. [root@hbcontrol ~]# nova hypervisor-stats +--+---+ | Property | Value | +--+---+ | count| 1 | | current_workload | 0 | | disk_available_least | 30| | free_disk_gb | 0 | | free_ram_mb | 0 | | local_gb | 30| | local_gb_used| 30| | memory_mb| 2048 | | memory_mb_used | 2048 | | running_vms | 1 | | vcpus| 2 | | vcpus_used | 2 | +--+---+ [root@hbcontrol ~]# [root@hbcontrol ~]# ironic node-list +--+--+---+-++-+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +--+--+---+-++-+ | ccdce9d8-2f6a-4d7f-8c53-f89f289fd0a1 | None | None | power on| available | False | +--+--+---+-++-+ [root@hbcontrol ~]# nova compute log 2015-04-21 07:31:51.979 1337 INFO nova.compute.manager [req-9abbf97b-8bf0-495a-850e-7874dbb87a22 2b0fbc7394cf4459867f2957e268e2d2 db9f9ab6aef84239a0206c2bb810b55a - - -] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] Starting instance... 2015-04-21 07:31:52.923 1337 INFO nova.compute.claims [-] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] Attempting claim: memory 2048 MB, disk 30 GB 2015-04-21 07:31:52.928 1337 INFO nova.compute.claims [-] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] Total memory: 2048 MB, used: 0.00 MB 2015-04-21 07:31:52.928 1337 INFO nova.compute.claims [-] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] memory limit: 2048.00 MB, free: 2048.00 MB 2015-04-21 07:31:52.928 1337 INFO nova.compute.claims [-] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] Total disk: 30 GB, used: 0.00 GB 2015-04-21 07:31:52.928 1337 INFO nova.compute.claims [-] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] disk limit not specified, defaulting to unlimited 2015-04-21 07:31:53.002 1337 INFO nova.compute.claims [-] [instance: 5597c25c-287e-420f-89d3-4f5a211471b8] Claim successful 2015-04-21 07:32:06.331 1337 ERROR nova.servicegroup.drivers.db [req-a53a836a-18b5-4da4-9e1a-3ad4a95de788 - - - - -] model server went away 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db Traceback (most recent call last): 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db File /usr/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py, line 112, in _report_state 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db service.service_ref, state_catalog) 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db File /usr/lib/python2.7/site-packages/nova/conductor/api.py, line 164, in service_update 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db return self._manager.service_update(context, service, values) 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db File /usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py, line 284, in service_update 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db service=service_p, values=values) 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db File /usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py, line 156, in call 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db retry=self.retry) 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db File /usr/lib/python2.7/site-packages/oslo_messaging/transport.py, line 90, in _send 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db timeout=timeout, retry=retry) 2015-04-21 07:32:06.331 1337 TRACE nova.servicegroup.drivers.db File
[Yahoo-eng-team] [Bug 1483315] [NEW] ebtables ARP rules don't account for floating IPs on LinuxBridge
Public bug reported: The new ebtables ARP filtering rules don't account for floating IPs, which blocks ARP replies from the qrouter netns the float lives in, effectively blocking traffic to the float and thus the instance. Looking at the ebtables code, rules are currently only added for ports with port security enabled (port_filter:True), IPs in the fixed_ips list and IPs in the allowed-address pairs list for a given port. Floating IPs do not have port security enabled, aren't fixed_ips and aren't automatically inserted into router gateway port AAPs. This is an example ebtables -L --Lc list of the filter table on the root namespace where the router is: http://paste.openstack.org/show/412384/ 192.168.74.0/24 is the private instance network 172.29.248.0/22 is the public network 192.168.74.1 is the router inside IP 192.168.74.2 is the DHCP server IP 192.168.74.3 is the instance IP 172.29.248.2 is the router gateway/outside IP 172.29.248.3 is the DHCP server IP (forgot to disable for the public) 172.29.248.8 is the floating IP As you can see, the floating IP is not in the rules, which results in ARP replies from the qrouter namespace being dropped. Adding the exception to ebtables results in working traffic, like this (line 18): http://paste.openstack.org/show/412386/ For reference, here's ebtables from the compute node along with the instance information: http://paste.openstack.org/show/412387/ ** 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/1483315 Title: ebtables ARP rules don't account for floating IPs on LinuxBridge Status in neutron: New Bug description: The new ebtables ARP filtering rules don't account for floating IPs, which blocks ARP replies from the qrouter netns the float lives in, effectively blocking traffic to the float and thus the instance. Looking at the ebtables code, rules are currently only added for ports with port security enabled (port_filter:True), IPs in the fixed_ips list and IPs in the allowed-address pairs list for a given port. Floating IPs do not have port security enabled, aren't fixed_ips and aren't automatically inserted into router gateway port AAPs. This is an example ebtables -L --Lc list of the filter table on the root namespace where the router is: http://paste.openstack.org/show/412384/ 192.168.74.0/24 is the private instance network 172.29.248.0/22 is the public network 192.168.74.1 is the router inside IP 192.168.74.2 is the DHCP server IP 192.168.74.3 is the instance IP 172.29.248.2 is the router gateway/outside IP 172.29.248.3 is the DHCP server IP (forgot to disable for the public) 172.29.248.8 is the floating IP As you can see, the floating IP is not in the rules, which results in ARP replies from the qrouter namespace being dropped. Adding the exception to ebtables results in working traffic, like this (line 18): http://paste.openstack.org/show/412386/ For reference, here's ebtables from the compute node along with the instance information: http://paste.openstack.org/show/412387/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1483315/+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 1456684] Re: [SRU] cloud-init does not know central (eu-central-1) is a direction for ec2 zones
This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.7 --- cloud-init (0.7.5-0ubuntu1.7) trusty; urgency=medium * d/patches/lp-1456684-eu-central-1.patch: - Add central as a direction for EC2 availability zones (LP: #1456684). * d/patches/lp-1464253-handle-new-cloudstack-passwords.patch: - Handle both old and new CloudStack password servers (LP: #1464253). * Add python-serial to Build-Depends (LP: #1381776). -- Daniel Watkins daniel.watk...@canonical.com Thu, 16 Jul 2015 17:34:01 +0100 ** Changed in: cloud-init (Ubuntu Trusty) Status: Fix Committed = Fix Released ** Changed in: cloud-init (Ubuntu Precise) 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/1456684 Title: [SRU] cloud-init does not know central (eu-central-1) is a direction for ec2 zones Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Vivid: Fix Released Bug description: cloud-init's code that tries to determine if it is in a ec2 region is simply unaware of the 'central' direction. [Impact] Ubuntu instances launched in the eu-central-1 EC2 region will not discover region-local mirrors. The user will see a degraded experience as they have to interact with mirrors that are further away and under heavier load. They will also potentially have to pay for the bandwidth used this way (as will the default mirror admins). [Test Case] Launch an instance in eu-central-1 and examine the apt sources used. They should be of the form eu-central-1.ec2.archive.ubuntu.com instead of eu-central-1a.clouds.archive.ubuntu.com. [Regression Potential] Limited; the changes are limited to the mirror discovery, and if mirror discovery fails, we have default mirrors that we will use. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1456684/+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 1456684] Re: [SRU] cloud-init does not know central (eu-central-1) is a direction for ec2 zones
This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu4 --- cloud-init (0.7.7~bzr1091-0ubuntu4) vivid; urgency=medium * d/patches/lp-1456684-eu-central-1.patch: Add central as a direction for EC2 availability zones (LP: #1456684). * d/patches/lp-1464253-handle-new-cloudstack-passwords.patch: Handle both old and new CloudStack password servers (LP: #1464253). * d/patches/lp-1475215-fix-cloudsigma-cepko.patch: Fix CloudSigma datasource under Python 3 (LP: #1475215). * d/patches/lp-1463373-fix-apt-gpg-key-fetching.patch: Fix a Python 3 problem with the writing out of the script that fetches GPG keys for apt repos (LP: #1463373). -- Daniel Watkins daniel.watk...@canonical.com Mon, 29 Jun 2015 12:48:33 +0100 ** Changed in: cloud-init (Ubuntu Vivid) 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/1456684 Title: [SRU] cloud-init does not know central (eu-central-1) is a direction for ec2 zones Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Vivid: Fix Released Bug description: cloud-init's code that tries to determine if it is in a ec2 region is simply unaware of the 'central' direction. [Impact] Ubuntu instances launched in the eu-central-1 EC2 region will not discover region-local mirrors. The user will see a degraded experience as they have to interact with mirrors that are further away and under heavier load. They will also potentially have to pay for the bandwidth used this way (as will the default mirror admins). [Test Case] Launch an instance in eu-central-1 and examine the apt sources used. They should be of the form eu-central-1.ec2.archive.ubuntu.com instead of eu-central-1a.clouds.archive.ubuntu.com. [Regression Potential] Limited; the changes are limited to the mirror discovery, and if mirror discovery fails, we have default mirrors that we will use. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1456684/+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 1463373] Re: [SRU] cc_apt_configure does not work with python3
This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu4 --- cloud-init (0.7.7~bzr1091-0ubuntu4) vivid; urgency=medium * d/patches/lp-1456684-eu-central-1.patch: Add central as a direction for EC2 availability zones (LP: #1456684). * d/patches/lp-1464253-handle-new-cloudstack-passwords.patch: Handle both old and new CloudStack password servers (LP: #1464253). * d/patches/lp-1475215-fix-cloudsigma-cepko.patch: Fix CloudSigma datasource under Python 3 (LP: #1475215). * d/patches/lp-1463373-fix-apt-gpg-key-fetching.patch: Fix a Python 3 problem with the writing out of the script that fetches GPG keys for apt repos (LP: #1463373). -- Daniel Watkins daniel.watk...@canonical.com Mon, 29 Jun 2015 12:48:33 +0100 ** Changed in: cloud-init (Ubuntu Vivid) 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/1463373 Title: [SRU] cc_apt_configure does not work with python3 Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Bug description: The way cc_apt_configure.py writes out the script to fetch GPG keys breaks when using Python 3. [Impact] GPG keys specified in cloud configuration cannot be checked. [Test Case] Specify a key in a source in the apt_sources cloud config key, and ensure that there aren't warnings about it in /var/log/cloud-init.log after boot. [Regression Potential] This part of the feature is completely broken at the moment, so very little chance to regress. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1463373/+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 1406161] Re: boot from fcsan volume live migration caused bdm table lost connection_info value
** Changed in: nova
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1406161
Title:
boot from fcsan volume live migration caused bdm table lost
connection_info value
Status in OpenStack Compute (nova):
Fix Released
Status in os-brick:
Fix Released
Bug description:
this issue reproduce steps:
1. nova boot vm1 base fcsan volume, this instance bdm table connection_info
as following:
{driver_volume_type: fibre_channel, serial:
63013f85-34fd-4040-a234-6ee57e1a8eeb, data: {device_path: /dev/dm-11,
target_discovered: false, devices: [{device: /dev/sdv, host: 7,
id: 0, channel: 0, lun: 8}, {device: /dev/sdx, host: 8,
id: 0, channel: 0, lun: 8}], qos_specs: null, volume_id:
63013f85-34fd-4040-a234-6ee57e1a8eeb, target_lun: 8, access_mode: rw,
target_wwn: [20014c09b4b04d0e, 20024c09b4b04d0e, 20034c09b4b04d0e,
20044c09b4b04d0e, 20014c09b4b04d18, 20024c09b4b04d18, 20034c09b4b04d18,
20044c09b4b04d18], multipath_id: 3500422790776c4d6}}
2. run nova live-migration vm1 fininshed, vm1 was migrated another host, but
this instance bdm table connection_info as following:
{driver_volume_type: fibre_channel, serial:
63013f85-34fd-4040-a234-6ee57e1a8eeb, data: { target_discovered: false,
qos_specs: null, volume_id: 63013f85-34fd-4040-a234-6ee57e1a8eeb,
target_lun: 9, access_mode: rw, target_wwn: [20014c09b4b04d0e,
20024c09b4b04d0e, 20034c09b4b04d0e, 20044c09b4b04d0e, 20014c09b4b04d18,
20024c09b4b04d18, 20034c09b4b04d18, 20044c09b4b04d18], multipath_id:
3500422790776c4d6}}
we can find the key device_path and devices was lost
3.if we live-migration this vm1 again,will fail . Call chain are as follows:
2014-12-16 05:19:12.039 9678 INFO nova.compute.manager [-] [instance:
5901a64a-32a6-448d-a535-5b03bb4df533] _post_live_migration() is started..
2014-12-16 05:19:12.068 9678 INFO urllib3.connectionpool [-] Starting new
HTTP connection (1): 10.43.177.244
2014-12-16 05:19:12.139 9678 INFO nova.compute.manager [-] [instance:
5901a64a-32a6-448d-a535-5b03bb4df533] During sync_power_state the instance has
a pending task. Skip.
2014-12-16 05:19:12.512 9678 ERROR nova.openstack.common.loopingcall [-] in
fixed duration looping call
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
Traceback (most recent call last):
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/openstack/common/loopingcall.py, line
78, in _inner
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
self.f(*self.args, **self.kw)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py, line 4987, in
wait_for_live_migration
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
migrate_data)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/exception.py, line 88, in wrapped
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
payload)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/openstack/common/excutils.py, line 68,
in __exit__
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
six.reraise(self.type_, self.value, self.tb)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/exception.py, line 71, in wrapped
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
return f(self, context, *args, **kw)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/compute/manager.py, line 369, in
decorated_function
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall e,
sys.exc_info())
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/openstack/common/excutils.py, line 68,
in __exit__
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
six.reraise(self.type_, self.value, self.tb)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/compute/manager.py, line 356, in
decorated_function
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
return function(self, context, *args, **kwargs)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
/usr/lib/python2.7/site-packages/nova/compute/manager.py, line 4824, in
_post_live_migration
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall
migrate_data)
2014-12-16 05:19:12.512 9678 TRACE nova.openstack.common.loopingcall File
[Yahoo-eng-team] [Bug 1483370] [NEW] Wishlist: Attach specific metadata within add tenant screen
You have been subscribed to a public bug: Ability to attach specific metadata to add tenant screen. Example need: cloud administrators may require attaching specific metadata to a tenant for proper post-processing and inventory of VM ** Affects: horizon Importance: Undecided Status: New ** Tags: wishlist -- Wishlist: Attach specific metadata within add tenant screen https://bugs.launchpad.net/bugs/1483370 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). -- 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 1475215] Re: [SRU] cloudinit.cs_utils.Cepko doesn't work under Python 3
This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu4 --- cloud-init (0.7.7~bzr1091-0ubuntu4) vivid; urgency=medium * d/patches/lp-1456684-eu-central-1.patch: Add central as a direction for EC2 availability zones (LP: #1456684). * d/patches/lp-1464253-handle-new-cloudstack-passwords.patch: Handle both old and new CloudStack password servers (LP: #1464253). * d/patches/lp-1475215-fix-cloudsigma-cepko.patch: Fix CloudSigma datasource under Python 3 (LP: #1475215). * d/patches/lp-1463373-fix-apt-gpg-key-fetching.patch: Fix a Python 3 problem with the writing out of the script that fetches GPG keys for apt repos (LP: #1463373). -- Daniel Watkins daniel.watk...@canonical.com Mon, 29 Jun 2015 12:48:33 +0100 ** Changed in: cloud-init (Ubuntu Vivid) 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/1475215 Title: [SRU] cloudinit.cs_utils.Cepko doesn't work under Python 3 Status in cloud-init: In Progress Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Vivid: Fix Released Bug description: In Python 3, Serial objects expect to be communicated with in bytes, we still try to pass strings in. [Impact] Versions of Ubuntu which have Python 3 as the default Python (15.04 onwards) won't successfully boot on CloudSigma. [Test Case] Try to boot a vivid (or wily) instance in CloudSigma, and observe your inability to SSH in to it. [Regression Potential] None; cloud-init is completely broken on CloudSigma at the moment. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1475215/+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 1464253] Re: [SRU] CloudStack data source will always set password to HTTP/1.0 200 OK on CloudStack 4.5.1 and later
This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.7 --- cloud-init (0.7.5-0ubuntu1.7) trusty; urgency=medium * d/patches/lp-1456684-eu-central-1.patch: - Add central as a direction for EC2 availability zones (LP: #1456684). * d/patches/lp-1464253-handle-new-cloudstack-passwords.patch: - Handle both old and new CloudStack password servers (LP: #1464253). * Add python-serial to Build-Depends (LP: #1381776). -- Daniel Watkins daniel.watk...@canonical.com Thu, 16 Jul 2015 17:34:01 +0100 ** Changed in: cloud-init (Ubuntu Trusty) Status: Fix Committed = Fix Released ** Changed in: cloud-init (Ubuntu Precise) 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/1464253 Title: [SRU] CloudStack data source will always set password to HTTP/1.0 200 OK on CloudStack 4.5.1 and later Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Utopic: Won't Fix Status in cloud-init source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Bug description: First reported in https://bugs.launchpad.net/ubuntu/+source/cloud- init/+bug/1440263/comments/6 Older versions of CloudStack return the password as the first thing on the socket after an HTTP request (eschewing the tradition of HTTP response headers), which is what we take and use. This lack of proper HTTP headers has been fixed in ACS 4.5.1, which means we will always use the status line of the HTTP response as the password. [Impact] Ubuntu instances deployed on more recent versions of CloudStack will always set the root password to HTTP/1.0 200 OK. [Test Case] Launch an instance in a recent CloudStack environment and try to log in using HTTP/1.0 200 OK and the password provided by the environment. The former should fail and the latter should work. [Regression Potential] This change moves to using wget rather than our own custom client, which is more inline with CloudStack's own scripting around this. We shouldn't regress on new or old CloudStack environments. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1464253/+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 1464253] Re: [SRU] CloudStack data source will always set password to HTTP/1.0 200 OK on CloudStack 4.5.1 and later
This bug was fixed in the package cloud-init - 0.7.7~bzr1091-0ubuntu4 --- cloud-init (0.7.7~bzr1091-0ubuntu4) vivid; urgency=medium * d/patches/lp-1456684-eu-central-1.patch: Add central as a direction for EC2 availability zones (LP: #1456684). * d/patches/lp-1464253-handle-new-cloudstack-passwords.patch: Handle both old and new CloudStack password servers (LP: #1464253). * d/patches/lp-1475215-fix-cloudsigma-cepko.patch: Fix CloudSigma datasource under Python 3 (LP: #1475215). * d/patches/lp-1463373-fix-apt-gpg-key-fetching.patch: Fix a Python 3 problem with the writing out of the script that fetches GPG keys for apt repos (LP: #1463373). -- Daniel Watkins daniel.watk...@canonical.com Mon, 29 Jun 2015 12:48:33 +0100 ** Changed in: cloud-init (Ubuntu Vivid) 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/1464253 Title: [SRU] CloudStack data source will always set password to HTTP/1.0 200 OK on CloudStack 4.5.1 and later Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Utopic: Won't Fix Status in cloud-init source package in Vivid: Fix Released Status in cloud-init source package in Wily: Fix Released Bug description: First reported in https://bugs.launchpad.net/ubuntu/+source/cloud- init/+bug/1440263/comments/6 Older versions of CloudStack return the password as the first thing on the socket after an HTTP request (eschewing the tradition of HTTP response headers), which is what we take and use. This lack of proper HTTP headers has been fixed in ACS 4.5.1, which means we will always use the status line of the HTTP response as the password. [Impact] Ubuntu instances deployed on more recent versions of CloudStack will always set the root password to HTTP/1.0 200 OK. [Test Case] Launch an instance in a recent CloudStack environment and try to log in using HTTP/1.0 200 OK and the password provided by the environment. The former should fail and the latter should work. [Regression Potential] This change moves to using wget rather than our own custom client, which is more inline with CloudStack's own scripting around this. We shouldn't regress on new or old CloudStack environments. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1464253/+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 1483370] [NEW] Wishlist: Attach specific metadata within add tenant screen
Public bug reported: Ability to attach specific metadata to add tenant screen. Example need: cloud administrators may require attaching specific metadata to a tenant for proper post-processing and inventory of VM ** Affects: horizon Importance: Undecided Status: New ** Tags: wishlist ** Project changed: horizon-cisco-ui = horizon -- 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/1483370 Title: Wishlist: Attach specific metadata within add tenant screen Status in OpenStack Dashboard (Horizon): New Bug description: Ability to attach specific metadata to add tenant screen. Example need: cloud administrators may require attaching specific metadata to a tenant for proper post-processing and inventory of VM To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1483370/+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 1483375] [NEW] Bad query.one() usage in endpoint-policy extension
Public bug reported:
In the file keystone/endpoint_policy/backends/sql.py, the return of
get_policy_association(..) is a dict in the form {'policy_id':
policy_id}.
However, policy_id was the return of the call:
session.query(PolicyAssociation.policy_id).one(),
having the following format:
(PolicyAssociation.policy_id, )
when it is expected to be only that column's value, i.e
PolicyAssociation.policy_id.
This patch fixes the usage of the return of the one() call, returning
only the value of the right column instead of a tuple.
This worked before because the return of get_policy_association(..) is
always used to be passed as a PK filter of the Policy table through the
get_policy(policy_id) call (in the policy backend), which uses the
get(ident) method from SQLAlchemy.
From the SQLAlchemy docs [1]:
ident - calar or tuple value representing the primary key.
[1]
http://docs.sqlalchemy.org/en/rel_1_0/orm/query.html#sqlalchemy.orm.query.Query.get
** 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/1483375
Title:
Bad query.one() usage in endpoint-policy extension
Status in Keystone:
New
Bug description:
In the file keystone/endpoint_policy/backends/sql.py, the return of
get_policy_association(..) is a dict in the form {'policy_id':
policy_id}.
However, policy_id was the return of the call:
session.query(PolicyAssociation.policy_id).one(),
having the following format:
(PolicyAssociation.policy_id, )
when it is expected to be only that column's value, i.e
PolicyAssociation.policy_id.
This patch fixes the usage of the return of the one() call, returning
only the value of the right column instead of a tuple.
This worked before because the return of get_policy_association(..) is
always used to be passed as a PK filter of the Policy table through
the get_policy(policy_id) call (in the policy backend), which uses the
get(ident) method from SQLAlchemy.
From the SQLAlchemy docs [1]:
ident - calar or tuple value representing the primary key.
[1]
http://docs.sqlalchemy.org/en/rel_1_0/orm/query.html#sqlalchemy.orm.query.Query.get
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1483375/+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 1483353] [NEW] v1: x-image-meta-id header provokes E500
Public bug reported: $ curl -v -X PUT http://127.0.0.1:9292/v1/images/8aa1f62d-73f2-4ed7-8d4c-b66407abd439 -H 'X-Auth-Token: 7535a1be77e3459e8e4928aae02a8042' -H 'x-image-meta-id: fd6db2fa-9c9d-4105-aa3b-657914593de8' * Hostname was NOT found in DNS cache * Trying 127.0.0.1... * Connected to 127.0.0.1 (127.0.0.1) port 9292 (#0) PUT /v1/images/8aa1f62d-73f2-4ed7-8d4c-b66407abd439 HTTP/1.1 User-Agent: curl/7.35.0 Host: 127.0.0.1:9292 Accept: */* X-Auth-Token: 7535a1be77e3459e8e4928aae02a8042 x-image-meta-id: fd6db2fa-9c9d-4105-aa3b-657914593de8 HTTP/1.1 500 Internal Server Error Content-Type: text/plain Content-Length: 0 Date: Mon, 10 Aug 2015 17:00:00 GMT Connection: close * Closing connection 0 ** 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/1483353 Title: v1: x-image-meta-id header provokes E500 Status in Glance: New Bug description: $ curl -v -X PUT http://127.0.0.1:9292/v1/images/8aa1f62d-73f2-4ed7-8d4c-b66407abd439 -H 'X-Auth-Token: 7535a1be77e3459e8e4928aae02a8042' -H 'x-image-meta-id: fd6db2fa-9c9d-4105-aa3b-657914593de8' * Hostname was NOT found in DNS cache * Trying 127.0.0.1... * Connected to 127.0.0.1 (127.0.0.1) port 9292 (#0) PUT /v1/images/8aa1f62d-73f2-4ed7-8d4c-b66407abd439 HTTP/1.1 User-Agent: curl/7.35.0 Host: 127.0.0.1:9292 Accept: */* X-Auth-Token: 7535a1be77e3459e8e4928aae02a8042 x-image-meta-id: fd6db2fa-9c9d-4105-aa3b-657914593de8 HTTP/1.1 500 Internal Server Error Content-Type: text/plain Content-Length: 0 Date: Mon, 10 Aug 2015 17:00:00 GMT Connection: close * Closing connection 0 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1483353/+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 1456684] Re: [SRU] cloud-init does not know central (eu-central-1) is a direction for ec2 zones
** 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/1456684 Title: [SRU] cloud-init does not know central (eu-central-1) is a direction for ec2 zones Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Released Status in cloud-init source package in Trusty: Fix Released Status in cloud-init source package in Vivid: Fix Released Bug description: cloud-init's code that tries to determine if it is in a ec2 region is simply unaware of the 'central' direction. [Impact] Ubuntu instances launched in the eu-central-1 EC2 region will not discover region-local mirrors. The user will see a degraded experience as they have to interact with mirrors that are further away and under heavier load. They will also potentially have to pay for the bandwidth used this way (as will the default mirror admins). [Test Case] Launch an instance in eu-central-1 and examine the apt sources used. They should be of the form eu-central-1.ec2.archive.ubuntu.com instead of eu-central-1a.clouds.archive.ubuntu.com. [Regression Potential] Limited; the changes are limited to the mirror discovery, and if mirror discovery fails, we have default mirrors that we will use. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1456684/+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 1483316] [NEW] FEATURE_BLACKLIST parameter is unused
Public bug reported: glance/common/utils.py has a FEATURE_BLACKLIST parameter, but this is no longer referenced in the code. ** Affects: glance Importance: Undecided Assignee: Stuart McLaren (stuart-mclaren) Status: New ** Changed in: glance Assignee: (unassigned) = Stuart McLaren (stuart-mclaren) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1483316 Title: FEATURE_BLACKLIST parameter is unused Status in Glance: New Bug description: glance/common/utils.py has a FEATURE_BLACKLIST parameter, but this is no longer referenced in the code. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1483316/+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 1483322] [NEW] python-memcached get_multi has much faster than get when get multiple value
Public bug reported: nova use memcache with python.memcached's get function. when multiple litem reterived it uses as for .. in .. loop.. in this case get_multi has better performance. In my case, here is test result get 2.3020670414 get_multi 0.0353858470917 ** 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/1483322 Title: python-memcached get_multi has much faster than get when get multiple value Status in OpenStack Compute (nova): New Bug description: nova use memcache with python.memcached's get function. when multiple litem reterived it uses as for .. in .. loop.. in this case get_multi has better performance. In my case, here is test result get 2.3020670414 get_multi 0.0353858470917 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483322/+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 1483321] [NEW] Kilo nova-compute unable to register with Juno nova-conductor
Public bug reported:
When deploying a compute node running Kilo against a control node
running Juno, nova-compute fails to start with the following exceptions
thrown by nova-conductor:
2015-08-10 16:56:02.236 977 ERROR oslo.messaging.rpc.dispatcher
[req-1d9be6ed-7b53-4dc8-bb3a-995a7ca7e359 ] Exception during message handling:
Version 1.12 of Service is not supported
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher Traceback (most
recent call last):
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 134,
in _dispatch_and_reply
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher
incoming.message))
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 177,
in _dispatch
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher return
self._do_dispatch(endpoint, method, ctxt, args)
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 123,
in _do_dispatch
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher result =
getattr(endpoint, method)(ctxt, **new_args)
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/nova/conductor/manager.py, line 408, in
object_class_action
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher objver)
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/nova/objects/base.py, line 288, in
obj_class_from_name
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher
supported=latest_ver)
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher
IncompatibleObjectVersion: Version 1.12 of Service is not supported
2015-08-10 16:56:02.236 977 TRACE oslo.messaging.rpc.dispatcher
2015-08-10 16:56:02.237 977 ERROR oslo.messaging._drivers.common
[req-1d9be6ed-7b53-4dc8-bb3a-995a7ca7e359 ] Returning exception Version 1.12 of
Service is not supported to caller
2015-08-10 16:56:02.237 977 ERROR oslo.messaging._drivers.common
[req-1d9be6ed-7b53-4dc8-bb3a-995a7ca7e359 ] ['Traceback (most recent call
last):\n', ' File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 134,
in _dispatch_and_reply\nincoming.message))\n', ' File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 177,
in _dispatch\nreturn self._do_dispatch(endpoint, method, ctxt, args)\n', '
File /usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line
123, in _do_dispatch\nresult = getattr(endpoint, method)(ctxt,
**new_args)\n', ' File
/usr/lib/python2.7/dist-packages/nova/conductor/manager.py, line 408, in
object_class_action\nobjver)\n', ' File
/usr/lib/python2.7/dist-packages/nova/objects/base.py, line 288, in
obj_class_from_name\nsupported=latest_ver)\n', 'IncompatibleObjectVersion:
Version 1.12 of Service is not supported\n']
2015-08-10 16:56:04.212 976 WARNING nova.context [-] Arguments dropped when
creating context: {u'read_only': False, u'domain': None, u'show_deleted':
False, u'user_identity': u'- - - - -', u'project_domain': None,
u'resource_uuid': None, u'user_domain': None}
2015-08-10 16:56:04.244 972 ERROR oslo.messaging.rpc.dispatcher
[req-eb961fea-3b0a-4c34-b774-7c8f4312467f ] Exception during message handling:
Version 1.16 of InstanceList is not supported
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher Traceback (most
recent call last):
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 134,
in _dispatch_and_reply
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher
incoming.message))
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 177,
in _dispatch
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher return
self._do_dispatch(endpoint, method, ctxt, args)
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 123,
in _do_dispatch
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher result =
getattr(endpoint, method)(ctxt, **new_args)
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/nova/conductor/manager.py, line 408, in
object_class_action
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher objver)
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher File
/usr/lib/python2.7/dist-packages/nova/objects/base.py, line 288, in
obj_class_from_name
2015-08-10 16:56:04.244 972 TRACE oslo.messaging.rpc.dispatcher
[Yahoo-eng-team] [Bug 1483379] [NEW] OPENSTACK_NEUTRON_NETWORK['enable_quotas'] = False breaks network topology page
Public bug reported: if OPENSTACK_NEUTRON_NETWORK[enable_quotas] = False the Network Topology page will not render. This is because a dict is searched for a key (available) which wont be there if its disabled. This generates a KeyError at runtime. This is very similar to https://bugs.launchpad.net/horizon/+bug/1482354 It has the same exact root cause ** 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/1483379 Title: OPENSTACK_NEUTRON_NETWORK['enable_quotas'] = False breaks network topology page Status in OpenStack Dashboard (Horizon): New Bug description: if OPENSTACK_NEUTRON_NETWORK[enable_quotas] = False the Network Topology page will not render. This is because a dict is searched for a key (available) which wont be there if its disabled. This generates a KeyError at runtime. This is very similar to https://bugs.launchpad.net/horizon/+bug/1482354 It has the same exact root cause To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1483379/+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 1483387] [NEW] neutron-fwaas needs oslotest
Public bug reported:
scollins@Sean-Collins-MBPr15 ~/src/openstack/neutron-fwaas ±ipv6_validate⚡ »
tox -e functional
functional develop-inst-nodeps: /Users/scollins/src/openstack/neutron-fwaas
functional runtests: PYTHONHASHSEED='2715531808'
functional runtests: commands[0] | python setup.py testr --slowest --testr-args=
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron_fwaas/tests/unit} --list
No handlers could be found for logger neutron.quota
--- import errors ---
Failed to import test module: neutron_fwaas.tests.functional.test_fwaas_driver
Traceback (most recent call last):
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/lib/python2.7/site-packages/unittest2/loader.py,
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/lib/python2.7/site-packages/unittest2/loader.py,
line 395, in _get_module_from_name
__import__(name)
File neutron_fwaas/tests/functional/test_fwaas_driver.py, line 19, in
module
from neutron.tests.functional import base
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/src/neutron/neutron/tests/functional/base.py,
line 23, in module
from neutron.tests.common import base as common_base
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/src/neutron/neutron/tests/common/base.py,
line 17, in module
from oslo_db.sqlalchemy import test_base
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_base.py,
line 23, in module
raise NameError('Oslotest is not installed. Please add oslotest in your'
NameError: Oslotest is not installed. Please add oslotest in your
test-requirements
Non-zero exit code (2) from test listing.
error: testr failed (3)
** Affects: neutron
Importance: Undecided
Assignee: Sean M. Collins (scollins)
Status: In Progress
** Tags: fwaas
** Tags added: fwaas
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1483387
Title:
neutron-fwaas needs oslotest
Status in neutron:
In Progress
Bug description:
scollins@Sean-Collins-MBPr15 ~/src/openstack/neutron-fwaas ±ipv6_validate⚡ »
tox -e functional
functional develop-inst-nodeps: /Users/scollins/src/openstack/neutron-fwaas
functional runtests: PYTHONHASHSEED='2715531808'
functional runtests: commands[0] | python setup.py testr --slowest
--testr-args=
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron_fwaas/tests/unit} --list
No handlers could be found for logger neutron.quota
--- import errors ---
Failed to import test module: neutron_fwaas.tests.functional.test_fwaas_driver
Traceback (most recent call last):
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/lib/python2.7/site-packages/unittest2/loader.py,
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/lib/python2.7/site-packages/unittest2/loader.py,
line 395, in _get_module_from_name
__import__(name)
File neutron_fwaas/tests/functional/test_fwaas_driver.py, line 19, in
module
from neutron.tests.functional import base
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/src/neutron/neutron/tests/functional/base.py,
line 23, in module
from neutron.tests.common import base as common_base
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/src/neutron/neutron/tests/common/base.py,
line 17, in module
from oslo_db.sqlalchemy import test_base
File
/Users/scollins/src/openstack/neutron-fwaas/.tox/functional/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_base.py,
line 23, in module
raise NameError('Oslotest is not installed. Please add oslotest in your'
NameError: Oslotest is not installed. Please add oslotest in your
test-requirements
Non-zero exit code (2) from test listing.
error: testr failed (3)
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1483387/+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 1483408] [NEW] Decryption failure after replacing openssl with cryptography lib
Public bug reported: After updating some packages Python on Tintri CI, the server has started failing an ec2 test. The logs contain error messages indicating trouble with decryption. Most likely breaking change: https://github.com/openstack/nova/commit/452fe92787ff871417846748fc13e2a6a2899325 Failing tempest test: tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest Operating system: RHEL 7.1 Failing run logs: http://openstack-ci.tintri.com/tintri/refs- changes-37-203237-10/ Passing logs from before CI started failing: http://openstack- ci.tintri.com/tintri/refs-changes-76-182276-28/ ** Affects: nova Importance: High Assignee: Eric Brown (ericwb) Status: Confirmed ** Tags: cert -- 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/1483408 Title: Decryption failure after replacing openssl with cryptography lib Status in OpenStack Compute (nova): Confirmed Bug description: After updating some packages Python on Tintri CI, the server has started failing an ec2 test. The logs contain error messages indicating trouble with decryption. Most likely breaking change: https://github.com/openstack/nova/commit/452fe92787ff871417846748fc13e2a6a2899325 Failing tempest test: tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest Operating system: RHEL 7.1 Failing run logs: http://openstack-ci.tintri.com/tintri/refs- changes-37-203237-10/ Passing logs from before CI started failing: http://openstack- ci.tintri.com/tintri/refs-changes-76-182276-28/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483408/+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 1483419] [NEW] Single Domain to Multi Domain assignments are lost
Public bug reported: When upgrading from a single domain LDAP environment to a multi domain LDAP environment all user role assignments are lost. The assignments' field actor_id is mapped to a user name in a single domain setup. When setting 'domain_specific_drivers_enabled=true' the actor_id field now maps to a new UUID which results in all existing users, including service users, losing their role assignments. I was able to overcome this rather forcefully with this SQL query: INSERT IGNORE INTO assignment(actor_id, target_id, role_id) SELECT id_mapping.public_id, assignment.target_id, assignment.role_id FROM id_mapping INNER JOIN assignment on id_mapping.local_id = assignment.actor_id; Version Tested: 2014.2.4 ** 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/1483419 Title: Single Domain to Multi Domain assignments are lost Status in Keystone: New Bug description: When upgrading from a single domain LDAP environment to a multi domain LDAP environment all user role assignments are lost. The assignments' field actor_id is mapped to a user name in a single domain setup. When setting 'domain_specific_drivers_enabled=true' the actor_id field now maps to a new UUID which results in all existing users, including service users, losing their role assignments. I was able to overcome this rather forcefully with this SQL query: INSERT IGNORE INTO assignment(actor_id, target_id, role_id) SELECT id_mapping.public_id, assignment.target_id, assignment.role_id FROM id_mapping INNER JOIN assignment on id_mapping.local_id = assignment.actor_id; Version Tested: 2014.2.4 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1483419/+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 1483480] [NEW] RFE - Allow annotations on Neutron resources
Public bug reported: Management of security groups and rules is very difficult without the ability to annotate. Some sort of optional annotation field on Neutron resources would make the cloud much more usable. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1483480 Title: RFE - Allow annotations on Neutron resources Status in neutron: New Bug description: Management of security groups and rules is very difficult without the ability to annotate. Some sort of optional annotation field on Neutron resources would make the cloud much more usable. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1483480/+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 1473953] Re: rbd cannot delete residual image from ceph in some situations
** Changed in: glance Status: Invalid = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1473953 Title: rbd cannot delete residual image from ceph in some situations Status in Glance: Invalid Status in glance_store: In Progress Bug description: When user through glance RESTful api upload image, the image generally has a large size. In fact, uploading a large enough image may be failed due to http connection broken or other situations like that. RBD supports a mechanism that when add operation failed, rollback operation must be triggered (delete residual image if it was created). Base on a condition, we have already encountered, that the incomplete image has not been taken snapshot yet, then rollback operation do unprotect snap will throw exception rbd.ImageNotFound. This exception will be disposed finally, while the code relating to remove residual image from ceph has been skipped. Therefore, re-uploading image will failed using the same image id due to above reason (residual image already exists) residual image need to be deleted manually from ceph. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1473953/+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 1473953] Re: rbd cannot delete residual image from ceph in some situations
** Changed in: glance Status: In Progress = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1473953 Title: rbd cannot delete residual image from ceph in some situations Status in Glance: Invalid Status in glance_store: In Progress Bug description: When user through glance RESTful api upload image, the image generally has a large size. In fact, uploading a large enough image may be failed due to http connection broken or other situations like that. RBD supports a mechanism that when add operation failed, rollback operation must be triggered (delete residual image if it was created). Base on a condition, we have already encountered, that the incomplete image has not been taken snapshot yet, then rollback operation do unprotect snap will throw exception rbd.ImageNotFound. This exception will be disposed finally, while the code relating to remove residual image from ceph has been skipped. Therefore, re-uploading image will failed using the same image id due to above reason (residual image already exists) residual image need to be deleted manually from ceph. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1473953/+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 1483486] [NEW] Ironic: get_available_resource doesn't report numa_topology
Public bug reported: in update_available_resource of RT we have # TODO(berrange): remove this once all virt drivers are updated # to report topology if numa_topology not in resources: resources[numa_topology] = None by searching codes, all other hypervisor report numa_topology in get_available_resource except ironic driver. this can be improved. ** Affects: nova Importance: Undecided Assignee: Eli Qiao (taget-9) Status: New ** Tags: ironic ** Changed in: nova Assignee: (unassigned) = Eli Qiao (taget-9) -- 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/1483486 Title: Ironic: get_available_resource doesn't report numa_topology Status in OpenStack Compute (nova): New Bug description: in update_available_resource of RT we have # TODO(berrange): remove this once all virt drivers are updated # to report topology if numa_topology not in resources: resources[numa_topology] = None by searching codes, all other hypervisor report numa_topology in get_available_resource except ironic driver. this can be improved. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483486/+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 1483468] [NEW] new files added in horizon does not get installed
Public bug reported: When there is a patch file adding python or html template, it does not get installed on the generated rpm In the log I found an interesting entry [pbr] Reusing existing SOURCES.txt I suspect an old SOURCES.txt is re-used, leaving out the new file added by the patches. ** Affects: anvil Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to anvil. https://bugs.launchpad.net/bugs/1483468 Title: new files added in horizon does not get installed Status in anvil: New Bug description: When there is a patch file adding python or html template, it does not get installed on the generated rpm In the log I found an interesting entry [pbr] Reusing existing SOURCES.txt I suspect an old SOURCES.txt is re-used, leaving out the new file added by the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1483468/+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 1483236] [NEW] It´s not possible to disable the nova compute service on one compute node
Public bug reported: I have multiple nova compute nodes and for maintenance reasons I want to disable one of them. Migration of a virtual machine is not possible, due to bug https://bugs.launchpad.net/cinder/+bug/1348811, so it would be ok, if it is not possible, to start a machine on that compute node. I stopped virtual machine foo on compute node bar $ nova stop 86db11f7-a1e4-4be0-880c-0720cd24c3aa disabled nova-compute service $ sudo nova-manage service disable bar nova-compute and checked it with $ sudo nova-manage service list --host bar -- Binary Host Zone Status State Updated_At nova-compute barCluster Xdisabled :-) 2015-08-10 12:29:10 -- Expected result: VM foo is not able to run on that host Actual result: VM foo is able to run on that host $ nova start 86db11f7-a1e4-4be0-880c-0720cd24c3aa The machine is running I tested, if its possible to create new virtual machines on that compute node bar with the disabled nova-compute service $ nova boot --image c196615d-d3ed-49d7-8bc6-c65f8360aa02 --flavor m1.smaller --nic net-id=6a38402f-4a5b-4239-a683-ceb4ae220c30 --availability-zone Cluster X:bar foo2 This machine is also running. Versions: $ dpkg -l | grep nova ii nova-common 1:2014.1.4-0ubuntu2.1 all OpenStack Compute - common files ii nova-compute1:2014.1.4-0ubuntu2.1 all OpenStack Compute - compute node base ii nova-compute-kvm1:2014.1.4-0ubuntu2.1 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt1:2014.1.4-0ubuntu2.1 all OpenStack Compute - compute node libvirt support ii python-nova 1:2014.1.4-0ubuntu2.1 all OpenStack Compute Python libraries ii python-novaclient 1:2.17.0-0ubuntu1.2 all client library for OpenStack Compute API $ dpkg -l | grep ceph ii ceph-common 0.94.1-1trusty amd64common utilities to mount and interact with a ceph storage cluster ii ceph-fs-common 0.94.1-1trusty amd64common utilities to mount and interact with a ceph file system ii ceph-fuse 0.94.1-1trusty amd64FUSE-based client for the Ceph distributed file system ii libcephfs1 0.94.1-1trusty amd64Ceph distributed file system client library ii python-cephfs 0.94.1-1trusty amd64Python libraries for the Ceph libcephfs library ** 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/1483236 Title: It´s not possible to disable the nova compute service on one compute node Status in OpenStack Compute (nova): New Bug description: I have multiple nova compute nodes and for maintenance reasons I want to disable one of them. Migration of a virtual machine is not possible, due to bug https://bugs.launchpad.net/cinder/+bug/1348811, so it would be ok, if it is not possible, to start a machine on that compute node. I stopped virtual machine foo on compute node bar $ nova stop 86db11f7-a1e4-4be0-880c-0720cd24c3aa disabled nova-compute service $ sudo nova-manage service disable bar nova-compute and checked it with $ sudo nova-manage service list --host bar -- Binary Host Zone Status State Updated_At nova-compute barCluster Xdisabled :-) 2015-08-10 12:29:10 -- Expected result: VM foo is not able to run on that host Actual result: VM foo is able to run on that host $ nova start 86db11f7-a1e4-4be0-880c-0720cd24c3aa The machine is running I tested, if its possible to create new virtual machines on that compute node bar with the disabled nova-compute service $ nova boot --image c196615d-d3ed-49d7-8bc6-c65f8360aa02 --flavor m1.smaller --nic net-id=6a38402f-4a5b-4239-a683-ceb4ae220c30 --availability-zone Cluster X:bar foo2 This machine is also running. Versions: $ dpkg -l | grep nova ii nova-common 1:2014.1.4-0ubuntu2.1 all OpenStack Compute - common files ii nova-compute1:2014.1.4-0ubuntu2.1 all OpenStack Compute - compute node base
[Yahoo-eng-team] [Bug 1483212] Re: can't authenticate with os_token, in multidomain environment and keystone V3 API
** Also affects: fuel Importance: Undecided Status: New ** Changed in: fuel Milestone: None = 7.0 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1483212 Title: can't authenticate with os_token, in multidomain environment and keystone V3 API Status in Fuel for OpenStack: New Status in Keystone: New Bug description: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) I'm using keystone from kilo To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1483212/+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 1483212] Re: can't authenticate with os_token, in multidomain environment and keystone V3 API
** Changed in: fuel Assignee: (unassigned) = MOS Keystone (mos-keystone) ** Project changed: fuel = mos ** Changed in: mos Milestone: 7.0 = None -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1483212 Title: can't authenticate with os_token, in multidomain environment and keystone V3 API Status in Keystone: New Status in Mirantis OpenStack: New Bug description: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) I'm using keystone from kilo To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1483212/+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 1483245] [NEW] LBaaS v2 plugin does not catch driver's LBConfigurationUnsupported exception
Public bug reported: As for now, LBaaS v2 plugin does not explicitly catch LBConfigurationUnsupported exception that can be potentially thrown by specific driver's method. _call_driver_operation method of the plugin is explicitly catching agent exceptions only, any specific exception from the driver (like LBConfigurationUnsupported ) is caught generally with LOG message saying There was an error in the driver ** Affects: neutron Importance: Undecided Status: New ** Tags: lbaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1483245 Title: LBaaS v2 plugin does not catch driver's LBConfigurationUnsupported exception Status in neutron: New Bug description: As for now, LBaaS v2 plugin does not explicitly catch LBConfigurationUnsupported exception that can be potentially thrown by specific driver's method. _call_driver_operation method of the plugin is explicitly catching agent exceptions only, any specific exception from the driver (like LBConfigurationUnsupported ) is caught generally with LOG message saying There was an error in the driver To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1483245/+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 1483159] Re: Canonical naming for non-x86 architectures
** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1483159 Title: Canonical naming for non-x86 architectures Status in OpenStack Compute (nova): In Progress Status in nova package in Ubuntu: Confirmed Bug description: Various non-x86 architectures (POWER and ARM) don't correctly canonicalize into things that libvirt natively understands. The attached patches normalizes some alternative architecture strings into standardized ones for Nova/libvirt. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483159/+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 1483132] [NEW] ssh-keygen-to-Paramiko change breaks third-party tools
Public bug reported: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 ** Affects: nova Importance: Undecided Status: New ** Summary changed: - ssh-keygen-to-paramiko change breaks third-party tools + ssh-keygen-to-Paramiko change breaks third-party tools -- 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/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): New Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+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 1483191] [NEW] A little improvement of show error messages on create keypair
Public bug reported: When input a key pair name that already exist, we will see the error message on the top of the modal form. If the error message beside the key pair name, it will be more better. This bug is inspired from https://bugs.launchpad.net/horizon/+bug/1480001 ** Affects: horizon Importance: Undecided Status: New ** Attachment added: keypair_error.jpg https://bugs.launchpad.net/bugs/1483191/+attachment/4442171/+files/keypair_error.jpg -- 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/1483191 Title: A little improvement of show error messages on create keypair Status in OpenStack Dashboard (Horizon): New Bug description: When input a key pair name that already exist, we will see the error message on the top of the modal form. If the error message beside the key pair name, it will be more better. This bug is inspired from https://bugs.launchpad.net/horizon/+bug/1480001 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1483191/+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 1483248] [NEW] unable to start compute service Kilo
Public bug reported: unable to start nova-compute service due to netaddr library is not able to resolve the hostname of the VM on which I am installing Openstack(1:2015.1.0-0ubuntu1.1~cloud0). I have added hostname entry in /etc/hosts file. Glance and Keystone services were able to resolve the hostname and services are running successfully. Below is the error which I am getting in nova-compute.log file(server is my hostname) ValueError: failed to detect a valid IP address from u'server' After changing /usr/lib/python2.7/dist- packages/nova/objects/fields.py:340 small code in this file which is like bypassing the variable value to replace hostname with my ip then i am able to make sure my compute service is up and running. class IPAddress(FieldType): @staticmethod def coerce(obj, attr, value): try: if value == 'server': return 'xx.xx.xx.xx' else: return netaddr.IPAddress(value) Please suggest if this is problem with netaddr library version(0.7.12-2~cloud0) or a bug. ** 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/1483248 Title: unable to start compute service Kilo Status in OpenStack Compute (nova): New Bug description: unable to start nova-compute service due to netaddr library is not able to resolve the hostname of the VM on which I am installing Openstack(1:2015.1.0-0ubuntu1.1~cloud0). I have added hostname entry in /etc/hosts file. Glance and Keystone services were able to resolve the hostname and services are running successfully. Below is the error which I am getting in nova-compute.log file(server is my hostname) ValueError: failed to detect a valid IP address from u'server' After changing /usr/lib/python2.7/dist- packages/nova/objects/fields.py:340 small code in this file which is like bypassing the variable value to replace hostname with my ip then i am able to make sure my compute service is up and running. class IPAddress(FieldType): @staticmethod def coerce(obj, attr, value): try: if value == 'server': return 'xx.xx.xx.xx' else: return netaddr.IPAddress(value) Please suggest if this is problem with netaddr library version(0.7.12-2~cloud0) or a bug. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483248/+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 1483254] [NEW] Swift fails to authenticate user by token
Public bug reported:
Ther'a 2 issues with authentication.
1. Consider the following code.
client = swift_api_client.Connection(
user=keystone.user.username,
preauthurl=url,
preauthtoken=keystone.user.token.id,
tenant_name=keystone.user.tenant_name,
insecure=insecure,
cacert=cacert)
Since ther's no ``auth_version`` specified, 1 used by default.
In this case swiftclient will try to use ``get_auth_1_0``:
storage_url, token = get_auth_1_0(auth_url,
user,
key,
kwargs.get('snet'),
insecure=insecure)
As you can see, no keystone token passed to that function, therefore
authentication fails.
Furthermore, swiftclient will fail miserably with exception:
Traceback (most recent call last):
File ./test_keystone.py, line 22, in module
t.run('blah', user_id=483)
File /home/testproject/src/testproject_dev/stack/swift_task.py, line 75, in
run
return self.test(swift_client)
File /home/testproject/src/testproject_dev/stack/swift_task.py, line 45, in
test
swift_client.get_capabilities()
File
/home/testproject/.virtualenvs/testproject/local/lib/python2.7/site-packages/swiftclient/client.py,
line 1386, in get_capabilities
url, _ = self.get_auth()
File
/home/testproject/.virtualenvs/testproject/local/lib/python2.7/site-packages/swiftclient/client.py,
line 1210, in get_auth
insecure=self.insecure)
File
/home/testproject/.virtualenvs/testproject/local/lib/python2.7/site-packages/swiftclient/client.py,
line 377, in get_auth
insecure=insecure)
File
/home/testproject/.virtualenvs/testproject/local/lib/python2.7/site-packages/swiftclient/client.py,
line 255, in get_auth_1_0
parsed, conn = http_connection(url, insecure=insecure)
File
/home/testproject/.virtualenvs/testproject/local/lib/python2.7/site-packages/swiftclient/client.py,
line 249, in http_connection
conn = HTTPConnection(*arg, **kwarg)
File
/home/testproject/.virtualenvs/testproject/local/lib/python2.7/site-packages/swiftclient/client.py,
line 156, in __init__
self.parsed_url = urlparse(url)
File /usr/lib/python2.7/urlparse.py, line 143, in urlparse
tuple = urlsplit(url, scheme, allow_fragments)
File /usr/lib/python2.7/urlparse.py, line 182, in urlsplit
i = url.find(':')
AttributeError: 'NoneType' object has no attribute 'find'
2. If you specify auth_version = 2, the following code will be executed.
elif auth_version in AUTH_VERSIONS_V2 + AUTH_VERSIONS_V3:
# We are allowing to specify a token/storage-url to re-use
# without having to re-authenticate.
if (os_options.get('object_storage_url') and
os_options.get('auth_token')):
return (os_options.get('object_storage_url'),
os_options.get('auth_token'))
It checks if there are ``object_storage_url`` and ``auth_token`` argumens were
provided.
Of course they were absent, since initial values were: os_options or {}
So in order to get it working, you have to specify those options manually:
client.os_options = {
'object_storage_url': url,
'auth_token': keystone.user.token.id,
}
Conclusion. The only way to use swift client with existing tokens is the
following:
def get_swift_client(self, keystone):
insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False)
cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None)
url = keystone.url_for('object-store')
client = swift_api_client.Connection(
user=keystone.user.username,
preauthurl=url,
preauthtoken=keystone.user.token.id,
tenant_name=keystone.user.tenant_name,
insecure=insecure,
cacert=cacert,
auth_version=2)
client.os_options = {
'object_storage_url': url,
'auth_token': keystone.user.token.id,
}
return client
I think you should fix version handling or reflect the way it works in
documentation.
** Affects: python-swiftclient
Importance: Undecided
Status: New
** Project changed: nova = python-swiftclient
** Description changed:
Ther'a 2 issues with authentication.
1. Consider the following code.
- client = swift_api_client.Connection(
- user=keystone.user.username,
- preauthurl=url,
- preauthtoken=keystone.user.token.id,
- tenant_name=keystone.user.tenant_name,
- insecure=insecure,
- cacert=cacert)
+ client = swift_api_client.Connection(
+ user=keystone.user.username,
+ preauthurl=url,
+ preauthtoken=keystone.user.token.id,
+ tenant_name=keystone.user.tenant_name,
+
[Yahoo-eng-team] [Bug 1481370] Re: system logging module is still in use in many places
** Also affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1481370 Title: system logging module is still in use in many places Status in murano: Fix Committed Status in neutron: In Progress Status in Stackalytics: Fix Committed Status in tempest: In Progress Status in Trove: Fix Committed Status in tuskar: In Progress Bug description: The system logging module is still in use in many places, i suggest to use the oslo.log library. Form the 1.8 version of oslo.log we can use the constants of the log levels (INFO, DEBUG, etc) directly from log module instead of system logging module. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1481370/+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 1483266] [NEW] q-svc fails to start in kilo due to ImportError: No module named neutron_vpnaas.services.vpn.service_drivers.ipsec
Public bug reported: http://logs.openstack.org/70/210870/1/check/gate-grenade-dsvm- neutron/20f794e/logs/new/screen-q-svc.txt.gz?level=TRACE Looks like this is blocking kilo jobs that use neutron: 2015-08-10 00:37:30.529 8402 ERROR neutron.common.config [-] Unable to load neutron from configuration file /etc/neutron/api-paste.ini. 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config Traceback (most recent call last): 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /opt/stack/new/neutron/neutron/common/config.py, line 227, in load_paste_app 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config app = deploy.loadapp(config:%s % config_path, name=app_name) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return loadobj(APP, uri, name=name, **kw) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return context.create() 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return self.object_type.invoke(self) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config **context.local_conf) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 55, in fix_call 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config val = callable(*args, **kw) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/urlmap.py, line 28, in urlmap_factory 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config app = loader.get_app(app_name, global_conf=global_conf) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config name=name, global_conf=global_conf).create() 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return self.object_type.invoke(self) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config **context.local_conf) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 55, in fix_call 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config val = callable(*args, **kw) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /opt/stack/new/neutron/neutron/auth.py, line 71, in pipeline_factory 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config app = loader.get_app(pipeline[-1]) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config name=name, global_conf=global_conf).create() 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return self.object_type.invoke(self) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in invoke 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return fix_call(context.object, context.global_conf, **context.local_conf) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 55, in fix_call 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config val = callable(*args, **kw) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /opt/stack/new/neutron/neutron/api/v2/router.py, line 71, in factory 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return cls(**local_config) 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /opt/stack/new/neutron/neutron/api/v2/router.py, line 75, in __init__ 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config plugin = manager.NeutronManager.get_plugin() 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config File /opt/stack/new/neutron/neutron/manager.py, line 222, in get_plugin 2015-08-10 00:37:30.529 8402 TRACE neutron.common.config return
[Yahoo-eng-team] [Bug 1483212] [NEW] can't authenticate with os_token, in multidomain environment and keystone V3 API
Public bug reported: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) I'm using keystone from kilo ** Affects: keystone Importance: Undecided Status: New ** Summary changed: - can't authenticate with os_token, in multidomain environment and V3 API + can't authenticate with os_token, in multidomain environment and keystone V3 API ** Description changed: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, - multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) + + I'm using keystone from kilo -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1483212 Title: can't authenticate with os_token, in multidomain environment and keystone V3 API Status in Keystone: New Bug description: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) I'm using keystone from kilo To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1483212/+subscriptions
[Yahoo-eng-team] [Bug 1483212] Re: can't authenticate with os_token, in multidomain environment and keystone V3 API
** Changed in: keystone Assignee: (unassigned) = Boris Bobrov (bbobrov) ** No longer affects: mos -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1483212 Title: can't authenticate with os_token, in multidomain environment and keystone V3 API Status in Keystone: New Bug description: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) I'm using keystone from kilo To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1483212/+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 1483212] Re: can't authenticate with os_token, in multidomain environment and keystone V3 API
This is by design and there is a unit-test that checks that (test_v3_identity.py, test_list_users_with_multiple_backends). The controller requires a domain to be specified either as a filter or by using a domain scoped token. In your case you need to provide a domain via --domain parameter of `openstack` cli. Also don't forget that this parameter is available only if you use OS_IDENTITY_API_VERSION=3. ** Changed in: keystone Status: New = 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/1483212 Title: can't authenticate with os_token, in multidomain environment and keystone V3 API Status in Keystone: Invalid Bug description: multidomains are disabled ( domain_specific_drivers_enabled = False ): root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, WIN-9FRJ87RBRG2,WIN-9FRJ87RBRG2,,, krbtgt,krbtgt,,, admin_ad,admin_ad,,, multidomains are enabled ( domain_specific_drivers_enabled = True ) root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v2.0/ ID,Name,Project,Email,Enabled Administrator,Administrator,,, Guest,Guest,,, root@node-4:/etc/puppet/modules/fuel-plugin-ldap/deployment_scripts# /usr/bin/openstack user list --quiet --format csv --long --os-token p2Z73yRj --os-url http://192.168.0.3:35357/v3/ ERROR: openstack The request you have made requires authentication. (HTTP 401) (Request-ID: req-72256f63-68c6-4842-9a66-cac3c35a9770) I'm using keystone from kilo To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1483212/+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 1415087] Re: [OSSA 2015-011] Format-guessing and file disclosure in image convert (CVE-2015-1850, CVE-2015-1851)
The OSSA tasks is now closed. If Nova turns out to be affected, a new OSSA will be required anyway. ** Changed in: ossa Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1415087 Title: [OSSA 2015-011] Format-guessing and file disclosure in image convert (CVE-2015-1850, CVE-2015-1851) Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Committed Status in Cinder kilo series: Fix Released Status in OpenStack Compute (nova): Triaged Status in OpenStack Security Advisory: Fix Released Bug description: Cinder does not provide input format to several calls of qemu-img convert. This allows the attacker to play the format guessing by providing a volume with a qcow2 signature. If this signature contains a base file, this file will be read by a process running as root and embedded in the output. This bug is similar to CVE-2013-1922. Tested with: lvm backed volume storage, it may apply to others as well Steps to reproduce: - create volume and attach to vm, - create a qcow2 signature with base-file[1] from within the vm and - trigger upload to glance with cinder upload-to-image --disk-type qcow2[2]. The image uploaded to glance will have /etc/passwd from the cinder-volume host embedded. Affected versions: tested on 2014.1.3, found while reading 2014.2.1 Fix: Always specify both input -f and output format -O to qemu- img convert. The code is in module cinder.image.image_utils. Bastian Blank [1]: qemu-img create -f qcow2 -b /etc/passwd /dev/vdb [2]: The disk-type != raw triggers the use of qemu-img convert To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1415087/+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
