[Yahoo-eng-team] [Bug 1184446] Re: cruft builds up in 'nova service-list' as compute nodes are added and removed
The tripleo part of this should have expired ref comment #4 so removing tripleo from the bug ** Tags removed: tripleo ** No longer affects: tripleo -- 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/1184446 Title: cruft builds up in 'nova service-list' as compute nodes are added and removed Status in OpenStack Compute (nova): Fix Released Bug description: This is our current service-list: heat-admin@bootstack-vm-4:~$ nova service-list +--+--+--+-+---++ | Binary | Host | Zone | Status | State | Updated_at | +--+--+--+-+---++ | nova-conductor | bootstack-vm-4.notcompute.novalocal | internal | enabled | up| 2013-05-26T23:42:55.00 | | nova-cert| bootstack-vm-4.notcompute.novalocal | internal | enabled | up| 2013-05-26T23:42:58.00 | | nova-scheduler | bootstack-vm-4.notcompute.novalocal | internal | enabled | up| 2013-05-26T23:42:57.00 | | nova-consoleauth | bootstack-vm-4.notcompute.novalocal | internal | enabled | up| 2013-05-26T23:43:00.00 | | nova-compute | bootstack-vm-4.notcompute.novalocal | nova | enabled | down | 2013-05-23T08:33:59.00 | | nova-compute | compute-test | nova | enabled | down | 2013-05-24T08:54:40.00 | | nova-compute | compute-test2| nova | enabled | up| 2013-05-26T23:42:54.00 | | nova-compute | compute-group| nova | enabled | down | 2013-05-24T08:55:04.00 | | nova-compute | compute-group.novacompute0.novacompute.novalocal | nova | enabled | down | 2013-05-24T09:07:51.00 | | nova-compute | compute-test0| nova | enabled | up| 2013-05-26T23:43:01.00 | | nova-compute | compute-test1| nova | enabled | up| 2013-05-26T23:42:55.00 | | nova-compute | compute-test3| nova | enabled | up| 2013-05-26T23:42:53.00 | | nova-compute | compute-test4| nova | enabled | up| 2013-05-26T23:43:00.00 | | nova-compute | compute-test5| nova | enabled | up| 2013-05-26T23:42:53.00 | note that the hosts in state down will never be coming back - we've rotated them out. There doesn't seem to be a way to gc this except by fiddling by hand. If there is, perhaps this is just a doc bug. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1184446/+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 1665370] [NEW] api db_sync fails on upgrade due to duplicate migration files
Public bug reported: I'm testing upgrades on TripleO, and hit this problem, discussion with owalsh indicates it may be a nova bug related to backport migration numbering: 14:44 < owalsh> shardy: it's a nova bug, 028 needs to be renamed to 021_build_requests_instance_mediumtext.py in ocata & master This is the error: "ScriptError: You can only have one Python script per version, but you have: /usr/lib/python2.7/site- packages/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/021_build_requests_instance_mediumtext.py and /usr/lib/python2.7/site- packages/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/021_placeholder.py"], "warnings": []} I'm testing this version: [root@overcloud-controller-0 ~]# rpm -qf /usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/021_placeholder.py python-nova-15.0.0-0.20170215034806.bdeb05d.el7.centos.noarch So upgrading to: https://github.com/openstack/nova/commit/bdeb05dfb0f727654ac0b0bae14341fd87b5cbb7 >From stable/newton commit: https://github.com/openstack/nova/commit/c6743ca709d45334cf25332aa834f86a9d91f1a5 [root@overcloud-controller-0 ~]# rpm -qa --last | grep python-nova python-nova-15.0.0-0.20170215034806.bdeb05d.el7.centos.noarch Wed 15 Feb 2017 07:02:12 PM UTC python-nova-14.0.4-0.20170117154931.c6743ca.el7.centos.noarch Mon 23 Jan 2017 01:45:50 PM UTC ** Affects: nova Importance: Undecided Status: New ** Affects: tripleo Importance: Critical Assignee: Steven Hardy (shardy) Status: Triaged ** Also affects: tripleo Importance: Undecided Status: New ** Changed in: tripleo Milestone: None => ocata-rc1 ** Changed in: tripleo Status: New => Triaged ** Changed in: tripleo Importance: Undecided => Critical ** Changed in: tripleo Assignee: (unassigned) => Steven Hardy (shardy) -- 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/1665370 Title: api db_sync fails on upgrade due to duplicate migration files Status in OpenStack Compute (nova): New Status in tripleo: Triaged Bug description: I'm testing upgrades on TripleO, and hit this problem, discussion with owalsh indicates it may be a nova bug related to backport migration numbering: 14:44 < owalsh> shardy: it's a nova bug, 028 needs to be renamed to 021_build_requests_instance_mediumtext.py in ocata & master This is the error: "ScriptError: You can only have one Python script per version, but you have: /usr/lib/python2.7/site- packages/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/021_build_requests_instance_mediumtext.py and /usr/lib/python2.7/site- packages/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/021_placeholder.py"], "warnings": []} I'm testing this version: [root@overcloud-controller-0 ~]# rpm -qf /usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/021_placeholder.py python-nova-15.0.0-0.20170215034806.bdeb05d.el7.centos.noarch So upgrading to: https://github.com/openstack/nova/commit/bdeb05dfb0f727654ac0b0bae14341fd87b5cbb7 From stable/newton commit: https://github.com/openstack/nova/commit/c6743ca709d45334cf25332aa834f86a9d91f1a5 [root@overcloud-controller-0 ~]# rpm -qa --last | grep python-nova python-nova-15.0.0-0.20170215034806.bdeb05d.el7.centos.noarch Wed 15 Feb 2017 07:02:12 PM UTC python-nova-14.0.4-0.20170117154931.c6743ca.el7.centos.noarch Mon 23 Jan 2017 01:45:50 PM UTC To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1665370/+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 1649341] Re: Undercloud upgrade fails with "Cell mappings are not created, but required for Ocata"
[stack@instack ~]$ sudo grep transport_url /etc/nova/nova.conf
transport_url=rabbit://55f7b1c2b4ee0e8a4f8311de334c6b71d13c1b45:1cf85a15b3fb0d86ec3bda2dedd3b8952ad6d72a@192.0.2.1//
[stack@instack ~]$ sudo nova-manage cell_v2 simple_cell_setup --transport-url
"rabbit://55f7b1c2b4ee0e8a4f8311de334c6b71d13c1b45:1cf85a15b3fb0d86ec3bda2dedd3b8952ad6d72a@192.0.2.1//"
Traceback (most recent call last):
File "/bin/nova-manage", line 10, in
sys.exit(main())
File "/usr/lib/python2.7/site-packages/nova/cmd/manage.py", line 1561, in main
config.parse_args(sys.argv)
File "/usr/lib/python2.7/site-packages/nova/config.py", line 50, in parse_args
rpc.init(CONF)
File "/usr/lib/python2.7/site-packages/nova/rpc.py", line 74, in init
TRANSPORT = create_transport(get_transport_url())
File "/usr/lib/python2.7/site-packages/nova/rpc.py", line 154, in
get_transport_url
return messaging.TransportURL.parse(CONF, url_str, TRANSPORT_ALIASES)
File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line
398, in parse
url = url or conf.transport_url
File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2320, in
__getattr__
raise NoSuchOptError(name)
oslo_config.cfg.NoSuchOptError: no such option transport_url in group [DEFAULT]
It may be this is partly a nova and partly a puppet-nova bug? As it
seems the nova releasenotes and api_db sync help text is wrong, and it
seems like puppet-nova isn't driving the cells_v2 simple_cell_setup at
the appropriate time with the URL it expects (which isn't all that clear
as evidently it doesn't match the nova.conf setting with the same name).
** Also affects: nova
Importance: Undecided
Status: New
** Also affects: puppet-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/1649341
Title:
Undercloud upgrade fails with "Cell mappings are not created, but
required for Ocata"
Status in OpenStack Compute (nova):
New
Status in puppet-nova:
New
Status in tripleo:
Triaged
Bug description:
Trying to upgrade with recent trunk nova and puppet-nova gives this
error:
Notice: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns:
error: Cell mappings are not created, but required for Ocata. Please run
nova-manage db simple_cell_setup before continuing.
Error: /usr/bin/nova-manage api_db sync returned 1 instead of one of [0]
Error: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns: change
from notrun to 0 failed: /usr/bin/nova-manage api_db sync returned 1 instead
of one of [0]
Debugging manually gives:
$ sudo /usr/bin/nova-manage api_db sync
error: Cell mappings are not created, but required for Ocata. Please run
nova-manage db simple_cell_setup before continuing.
but...
$ sudo nova-manage db simple_cell_setup
usage: nova-manage db [-h]
{archive_deleted_rows,null_instance_uuid_scan,online_data_migrations,sync,version}
...
nova-manage db: error: argument action: invalid choice: 'simple_cell_setup'
(choose from 'archive_deleted_rows', 'null_instance_uuid_scan',
'online_data_migrations', 'sync', 'version')
I tried adding openstack-nova* to the delorean-current whitelist, but with
the latest nova packages there still appears to be this mismatch.
[stack@instack /]$ rpm -qa | grep nova
openstack-nova-conductor-15.0.0-0.20161212155146.909410c.el7.centos.noarch
python-nova-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-scheduler-15.0.0-0.20161212155146.909410c.el7.centos.noarch
puppet-nova-10.0.0-0.20161211003757.09b9f7b.el7.centos.noarch
python2-novaclient-6.0.0-0.20161003181629.25117fa.el7.centos.noarch
openstack-nova-api-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-cert-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-common-15.0.0-0.20161212155146.909410c.el7.centos.noarch
openstack-nova-compute-15.0.0-0.20161212155146.909410c.el7.centos.noarch
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1649341/+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 1291396] Re: No exact match of nodes with flavors
We ended up fixing this with node tagging in ironic and a special version of the ComputeCapabilities filter, so marking this fix released https://github.com/openstack/tripleo- common/blob/master/tripleo_common/filters/capabilities_filter.py ** Changed in: tripleo Assignee: Devananda van der Veen (devananda) => (unassigned) ** Changed in: tripleo Status: Incomplete => 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/1291396 Title: No exact match of nodes with flavors Status in Ironic: Fix Released Status in OpenStack Compute (nova): Fix Released Status in tripleo: Fix Released Bug description: Seems like we are not doing exact match and we never did. http://paste.openstack.org/show/73250/ Confirmed with Lucas Gomes that it's not in Ironic nor Nova BM. Right now we are using default nova filters that takes => resources with RamWeight=1. We probably need to write new filters that will implement exact match and list them in nova.conf of nova image-element. filters docs http://docs.openstack.org/developer/nova/devref/filter_scheduler.html To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1291396/+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 1464239] Re: mount: special device /dev/sdb does not exist
** Changed in: tripleo 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/1464239 Title: mount: special device /dev/sdb does not exist Status in OpenStack Compute (nova): In Progress Status in tripleo: Fix Released Bug description: As of today it looks like all jobs fail due to a missing Ephemeral partition: mount: special device /dev/sdb does not exist This Nova commit looks suspicious: 7f8128f87f5a2fa93c857295fb7e4163986eda25 "Add the swap and ephemeral BDMs if needed" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1464239/+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 1531881] Re: AttributeError: 'module' object has no attribute 'dump_as_bytes'
** Changed in: tripleo 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/1531881 Title: AttributeError: 'module' object has no attribute 'dump_as_bytes' Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) liberty series: In Progress Status in tripleo: Fix Released Bug description: Seeing the following traceback from nova-compute when trying to launch instances in tripleo-ci for stable/liberty (using the ironic driver): 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] Traceback (most recent call last): 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2155, in _build_resources 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] yield resources 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2009, in _build_and_run_instance 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] block_device_info=block_device_info) 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 802, in spawn 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] files=injected_files) 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 716, in _generate_configdrive 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] "error: %s"), e, instance=instance) 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195, in __exit__ 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] six.reraise(self.type_, self.value, self.tb) 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 711, in _generate_configdrive 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] with configdrive.ConfigDriveBuilder(instance_md=i_meta) as cdb: 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/virt/configdrive.py", line 72, in __init__ 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] self.add_instance_metadata(instance_md) 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/virt/configdrive.py", line 93, in add_instance_metadata 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] for (path, data) in instance_md.metadata_for_config_drive(): 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] File "/usr/lib/python2.7/site-packages/nova/api/metadata/base.py", line 465, in metadata_for_config_drive 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] yield (filepath, jsonutils.dump_as_bytes(data['meta-data'])) 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] AttributeError: 'module' object has no attribute 'dump_as_bytes' 2016-01-07 13:32:27.691 19349 ERROR nova.compute.manager [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] 2016-01-07 13:32:27.693 19349 INFO nova.compute.manager [req-6b73f4c5-c031-496e-b2f0-a5380d3ca7ba 285d1c33eca8410e9ed03bbe3de03d15 9448d5b54ff84bd6a8a04b1083eb920f - - -] [instance: 5a7c299b-f6b6-48d8-a20e-36e72c7bed79] Termi I believe it's caused by this commit: https://review.openstack.org/#/c/246792/ which I've submitted a revert for: https://review.openstack.org/#/c/264793/ The failed tripleo-ci job: http://logs.openstack.org/46/254946/4/check-tripleo/gate-tripleo-ci-f22-nonha/1363b32/ from this patch: https://review.openstack.org/#/c/254946/ The version of oslo.serialization in use on the job is
[Yahoo-eng-team] [Bug 1503501] Re: oslo.db no longer requires testresources and testscenarios packages
** Also affects: heat/liberty
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/1503501
Title:
oslo.db no longer requires testresources and testscenarios packages
Status in Cinder:
Fix Released
Status in Glance:
Fix Released
Status in heat:
Fix Committed
Status in heat liberty series:
New
Status in Ironic:
Fix Committed
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
Fix Released
Status in Sahara:
Fix Committed
Status in Sahara liberty series:
Fix Committed
Status in Sahara mitaka series:
Fix Committed
Bug description:
As of https://review.openstack.org/#/c/217347/ oslo.db no longer has
testresources or testscenarios in its requirements, So next release of
oslo.db will break several projects. These project that use fixtures
from oslo.db should add these to their requirements if they need it.
Example from Nova:
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests}
--list
---Non-zero exit code (2) from test listing.
error: testr failed (3)
import errors ---
Failed to import test module: nova.tests.unit.db.test_db_api
Traceback (most recent call last):
File
"/home/travis/build/dims/nova/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
"/home/travis/build/dims/nova/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name
__import__(name)
File "nova/tests/unit/db/test_db_api.py", line 31, in
from oslo_db.sqlalchemy import test_base
File
"/home/travis/build/dims/nova/.tox/py27/src/oslo.db/oslo_db/sqlalchemy/test_base.py",
line 17, in
import testresources
ImportError: No module named testresources
https://travis-ci.org/dims/nova/jobs/83992423
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1503501/+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 1474959] Re: Cloud Image launched by Heat, creates a ec2-user user without Shell.
*** This bug is a duplicate of bug 1474194 ***
https://bugs.launchpad.net/bugs/1474194
If you're getting ec2-user, then you need to set instance_user to an
empty string, as I mentioned in comment #1, and this is a duplicate of
bug #1474194
** Changed in: cloud-init
Status: New = Invalid
** This bug has been marked a duplicate of bug 1474194
When launching a template with the OS::Nova::Server type the
user_data_format attribute determines the user on Ubuntu images
--
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/1474959
Title:
Cloud Image launched by Heat, creates a ec2-user user without Shell.
Status in cloud-init:
Invalid
Status in heat:
New
Bug description:
Guys,
If I launch an Ubuntu Trusty Instance using Heat, there is no ubuntu
user available.
Instead, there is a ec2-user user, without shell!
Look:
No ubuntu user:
---
username@kilo-1:~$ ssh ubuntu@172.31.254.158
Permission denied (publickey).
---
Instead, there is a ec2-user user without shell:
---
username@kilo-1:~$ ssh ec2-user@172.31.254.158
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-57-generic x86_64)
...
$
$ bash -i
ec2-user@ubuntu-1:~$ grep ec2-user /etc/passwd
ec2-user:x:1000:1000::/home/ec2-user:
---
No shell (/bin/bash) for ec2-user user!
Heat template block:
---
ubuntusrv1:
type: OS::Nova::Server
properties:
name:
key_name: { get_param: 'ssh_key' }
image: { get_param: 'ubuntusrv1_image' }
flavor: m1.small
networks:
- network: { get_resource: data_sub_net1 }
---
But, if I launch the very same Ubuntu Trusty image, using Horizon,
then, the ubuntu user becomes available, without any problems.
And, if your specify admin_user: cloud, for example, it also have no
shell.
I'm using OpenStack Kilo, on top of Trusty using Ubuntu Cloud
Archives.
Trusty Image: http://uec-
images.ubuntu.com/releases/14.04.2/release/ubuntu-14.04-server-
cloudimg-amd64-disk1.img
Thanks!
Thiago
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1474959/+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 1396696] [NEW] grenade tests failing with glance 400 error
Public bug reported: I'm seeing the following error in multiple patches failing the check- grenade-dsvm job for stable/juno patches: 2014-11-25 02:41:27.359 | ++ glance --os-auth-token snipped huge token 2014-11-25 02:41:27.360 | == --os-image-url http://127.0.0.1:9292 image-create --name cirros-0.3.1-x86_64-uec-kernel --is-public True --container-format aki --disk-format aki 2014-11-25 02:41:27.360 | ++ get_field 2 2014-11-25 02:41:27.360 | ++ read data 2014-11-25 02:41:59.353 | html 2014-11-25 02:41:59.353 | head 2014-11-25 02:41:59.353 | title400 Bad Request/title 2014-11-25 02:41:59.353 | /head 2014-11-25 02:41:59.353 | body 2014-11-25 02:41:59.353 | h1400 Bad Request/h1 2014-11-25 02:41:59.353 | Client disconnected before sending all data to backendbr /br / 2014-11-25 02:41:59.353 | 2014-11-25 02:41:59.353 | /body 2014-11-25 02:41:59.353 | /html (HTTP 400) http://logs.openstack.org/29/136729/2/check/check-grenade- dsvm/4391ba6/logs/grenade.sh.txt.gz Here's links to reviews showing this failure: https://review.openstack.org/#/c/136729/ https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno+topic:bug/1389499_juno,n,z I'm not clear how to fix this, as it appears to be either a grenade or glance issue, and not related to the heat patches I'm trying to backport, AFAICT. ** 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/1396696 Title: grenade tests failing with glance 400 error Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: I'm seeing the following error in multiple patches failing the check- grenade-dsvm job for stable/juno patches: 2014-11-25 02:41:27.359 | ++ glance --os-auth-token snipped huge token 2014-11-25 02:41:27.360 | == --os-image-url http://127.0.0.1:9292 image-create --name cirros-0.3.1-x86_64-uec-kernel --is-public True --container-format aki --disk-format aki 2014-11-25 02:41:27.360 | ++ get_field 2 2014-11-25 02:41:27.360 | ++ read data 2014-11-25 02:41:59.353 | html 2014-11-25 02:41:59.353 | head 2014-11-25 02:41:59.353 | title400 Bad Request/title 2014-11-25 02:41:59.353 | /head 2014-11-25 02:41:59.353 | body 2014-11-25 02:41:59.353 | h1400 Bad Request/h1 2014-11-25 02:41:59.353 | Client disconnected before sending all data to backendbr /br / 2014-11-25 02:41:59.353 | 2014-11-25 02:41:59.353 | /body 2014-11-25 02:41:59.353 | /html (HTTP 400) http://logs.openstack.org/29/136729/2/check/check-grenade- dsvm/4391ba6/logs/grenade.sh.txt.gz Here's links to reviews showing this failure: https://review.openstack.org/#/c/136729/ https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno+topic:bug/1389499_juno,n,z I'm not clear how to fix this, as it appears to be either a grenade or glance issue, and not related to the heat patches I'm trying to backport, AFAICT. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1396696/+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 1394530] [NEW] firewall.FirewallNotFound error in icehouse check job
Public bug reported: http://logs.openstack.org/27/131827/4/check/gate-tempest-dsvm-neutron- src-python-heatclient-icehouse/36ab6c1/logs/screen-q-svc.txt.gz? Seeing this error in python-heatclient check job 2014-11-20 09:05:57.196 25851 ERROR neutron.openstack.common.rpc.amqp [req-ac972bc5-fdcd-4533-a881-9fc7a0ad50e6 None] Exception during message handling 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp Traceback (most recent call last): 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/openstack/common/rpc/amqp.py, line 462, in _process_data 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp **args) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/common/rpc.py, line 45, in dispatch 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp neutron_ctxt, version, method, namespace, **kwargs) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/openstack/common/rpc/dispatcher.py, line 172, in dispatch 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp result = getattr(proxyobj, method)(ctxt, **kwargs) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/services/firewall/fwaas_plugin.py, line 74, in firewall_deleted 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp fw_db = self.plugin._get_firewall(context, firewall_id) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/db/firewall/firewall_db.py, line 99, in _get_firewall 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp raise firewall.FirewallNotFound(firewall_id=id) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp FirewallNotFound: Firewall 1ce11d10-8bff-4666-a027-d9881c0117f5 could not be found. 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp 2014-11-20 09:05:57.199 25851 ERROR neutron.openstack.common.rpc.common [req-ac972bc5-fdcd-4533-a881-9fc7a0ad50e6 None] Returning exception Firewall 1ce11d10-8bff-4666-a027-d9881c0117f5 could not be found. to caller 2014-11-20 09:05:57.199 25851 ERROR neutron.openstack.common.rpc.common [req-ac972bc5-fdcd-4533-a881-9fc7a0ad50e6 None] ['Traceback (most recent call last):\n', ' File /opt/stack/new/neutron/neutron/openstack/common/rpc/amqp.py, line 462, in _process_data\n**args)\n', ' File /opt/stack/new/neutron/neutron/common/rpc.py, line 45, in dispatch\n neutron_ctxt, version, method, namespace, **kwargs)\n', ' File /opt/stack/new/neutron/neutron/openstack/common/rpc/dispatcher.py, line 172, in dispatch\nresult = getattr(proxyobj, method)(ctxt, **kwargs)\n', ' File /opt/stack/new/neutron/neutron/services/firewall/fwaas_plugin.py, line 74, in firewall_deleted\nfw_db = self.plugin._get_firewall(context, firewall_id)\n', ' File /opt/stack/new/neutron/neutron/db/firewall/firewall_db.py, line 99, in _get_firewall\nraise firewall.FirewallNotFound(firewall_id=id)\n', 'FirewallNotFound: Firewall 1ce11d10-8bff-4666-a027-d9881c0117f5 could not be found.\n'] ** 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/1394530 Title: firewall.FirewallNotFound error in icehouse check job Status in OpenStack Neutron (virtual network service): New Bug description: http://logs.openstack.org/27/131827/4/check/gate-tempest-dsvm-neutron- src-python-heatclient-icehouse/36ab6c1/logs/screen-q-svc.txt.gz? Seeing this error in python-heatclient check job 2014-11-20 09:05:57.196 25851 ERROR neutron.openstack.common.rpc.amqp [req-ac972bc5-fdcd-4533-a881-9fc7a0ad50e6 None] Exception during message handling 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp Traceback (most recent call last): 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/openstack/common/rpc/amqp.py, line 462, in _process_data 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp **args) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/common/rpc.py, line 45, in dispatch 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp neutron_ctxt, version, method, namespace, **kwargs) 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp File /opt/stack/new/neutron/neutron/openstack/common/rpc/dispatcher.py, line 172, in dispatch 2014-11-20 09:05:57.196 25851 TRACE neutron.openstack.common.rpc.amqp result = getattr(proxyobj, method)(ctxt, **kwargs) 2014-11-20
[Yahoo-eng-team] [Bug 1366133] [NEW] User create via v3 API doesn't add _member_ role in default project
Public bug reported:
There is a discrepancy between creating users via the v2 and v3 API's,
which I'm not sure is a bug or by design:
When creating a user via the v2 API, the _member_ role is added in their
default project, but when creating via the v3 API, despite
default_project_id being specified, it is not.
If possible, I'd like the _member_ role to always be present, as we need
a default role to delegate via trust for heat, and I'd like to move away
from using a special heat_stack_owner role as it's confusing for users:
https://review.openstack.org/#/c/119415/
-bash-4.2$ openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 user create --domain Default --project demo
test123456
++-+
| Field | Value
|
++-+
| default_project_id | 19d521c102844134b4c141af967d75fd
|
| domain_id | default
|
| enabled| True
|
| id | 479882b84fed407a9bc5a95778aba85e
|
| links | {u'self':
u'http://192.168.0.4:5000/v3/users/479882b84fed407a9bc5a95778aba85e'} |
| name | test123456
|
++-+
-bash-4.2$ keystone user-create --tenant demo --name v2test123456
+--+--+
| Property | Value |
+--+--+
| email | |
| enabled | True |
|id| c8d14d95bec24a56b0414b41b94a9e4e |
| name | v2test123456 |
| tenantId | 19d521c102844134b4c141af967d75fd |
| username | v2test123456 |
+--+--+
-bash-4.2$ keystone user-role-list --tenant demo --user test123456
-bash-4.2$ keystone user-role-list --tenant demo --user v2test123456
+--+--+--+--+
|id| name | user_id
|tenant_id |
+--+--+--+--+
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
c8d14d95bec24a56b0414b41b94a9e4e | 19d521c102844134b4c141af967d75fd |
+--+--+--+--+
** 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/1366133
Title:
User create via v3 API doesn't add _member_ role in default project
Status in OpenStack Identity (Keystone):
New
Bug description:
There is a discrepancy between creating users via the v2 and v3 API's,
which I'm not sure is a bug or by design:
When creating a user via the v2 API, the _member_ role is added in
their default project, but when creating via the v3 API, despite
default_project_id being specified, it is not.
If possible, I'd like the _member_ role to always be present, as we
need a default role to delegate via trust for heat, and I'd like to
move away from using a special heat_stack_owner role as it's confusing
for users:
https://review.openstack.org/#/c/119415/
-bash-4.2$ openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 user create --domain Default --project demo
test123456
++-+
| Field | Value
|
++-+
| default_project_id | 19d521c102844134b4c141af967d75fd
|
| domain_id | default
|
| enabled| True
|
| id | 479882b84fed407a9bc5a95778aba85e
|
| links | {u'self':
[Yahoo-eng-team] [Bug 1328067] [NEW] Token with placeholder ID issued
Public bug reported: We're seeing test failures, where it seems that an invalid token is issued, with the ID of placeholder http://logs.openstack.org/69/97569/2/check/check-tempest-dsvm- full/565d328/logs/screen-h-eng.txt.gz See context_auth_token_info which is being passed using the auth_token keystone.token_info request environment variable (ref https://review.openstack.org/#/c/97568/ which is the previous patch in the chain from the log referenced above). It seems like auth_token is getting a token, but there's some sort of race in the backend which prevents an actual token being stored? Trying to use placeholder as a token ID doesn't work, so it seems like this default assigned in the controller is passed back to auth_token, which treats it as a valid token, even though it's not. https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L121 I'm not sure how to debug this further, as I can't reproduce this problem locally. ** 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/1328067 Title: Token with placeholder ID issued Status in OpenStack Identity (Keystone): New Bug description: We're seeing test failures, where it seems that an invalid token is issued, with the ID of placeholder http://logs.openstack.org/69/97569/2/check/check-tempest-dsvm- full/565d328/logs/screen-h-eng.txt.gz See context_auth_token_info which is being passed using the auth_token keystone.token_info request environment variable (ref https://review.openstack.org/#/c/97568/ which is the previous patch in the chain from the log referenced above). It seems like auth_token is getting a token, but there's some sort of race in the backend which prevents an actual token being stored? Trying to use placeholder as a token ID doesn't work, so it seems like this default assigned in the controller is passed back to auth_token, which treats it as a valid token, even though it's not. https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L121 I'm not sure how to debug this further, as I can't reproduce this problem locally. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1328067/+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 1322258] [NEW] Heat environments don't work for local files
Public bug reported: There is an issue with environment files (and heat templates which contain a file reference to a nested stack directly), which means that they don't work via Horizon. The issue is you pass a template and optionally an environment file to Horizon via the file dialog, but Horizon doesn't have any way to resolve the file references and populate the files part of the API call to create the stack. Additionally, the environment is not passed at all when trying to create the stack, so template validation actually fails before you hit the problem above.. ;) Here are some simple examples which demonstrate the problem: In all of the following examples, a default nova keypair of stack_key is expected, as is a glance image of cirros-0.3.2-x86_64-disk, these can be overridden or modified obviously. 1. Template referencing a nested stack directly (no environment) https://github.com/hardys/demo_templates/tree/master/juno_summit_intro_to_heat/example2_server_with_volume_nested This can be launched on the CLI via: heat --debug template-validate -f server_with_volume.yaml heat --debug stack-create test1 -f server_with_volume.yaml The --debug will show the content of the API call, which should hopefully help see what is missing from the horizon call (files section missing from the create) 2. Template referencing nested stack via environment https://github.com/hardys/demo_templates/tree/master/juno_summit_intro_to_heat/example4_provider_environment This can be launched on the CLI via: heat --debug template-validate -f server_with_volume_env.yaml -e env_server_with_volume.yaml heat --debug stack-create test2 -f server_with_volume_env.yaml -e env_server_with_volume.yaml Currently it's not possible to launch either stack via horizon, unless the local file references are replaced with URLs. ** Affects: horizon Importance: Undecided Assignee: Jordan OMara (jomara) 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/1322258 Title: Heat environments don't work for local files Status in OpenStack Dashboard (Horizon): New Bug description: There is an issue with environment files (and heat templates which contain a file reference to a nested stack directly), which means that they don't work via Horizon. The issue is you pass a template and optionally an environment file to Horizon via the file dialog, but Horizon doesn't have any way to resolve the file references and populate the files part of the API call to create the stack. Additionally, the environment is not passed at all when trying to create the stack, so template validation actually fails before you hit the problem above.. ;) Here are some simple examples which demonstrate the problem: In all of the following examples, a default nova keypair of stack_key is expected, as is a glance image of cirros-0.3.2-x86_64-disk, these can be overridden or modified obviously. 1. Template referencing a nested stack directly (no environment) https://github.com/hardys/demo_templates/tree/master/juno_summit_intro_to_heat/example2_server_with_volume_nested This can be launched on the CLI via: heat --debug template-validate -f server_with_volume.yaml heat --debug stack-create test1 -f server_with_volume.yaml The --debug will show the content of the API call, which should hopefully help see what is missing from the horizon call (files section missing from the create) 2. Template referencing nested stack via environment https://github.com/hardys/demo_templates/tree/master/juno_summit_intro_to_heat/example4_provider_environment This can be launched on the CLI via: heat --debug template-validate -f server_with_volume_env.yaml -e env_server_with_volume.yaml heat --debug stack-create test2 -f server_with_volume_env.yaml -e env_server_with_volume.yaml Currently it's not possible to launch either stack via horizon, unless the local file references are replaced with URLs. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1322258/+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 1297512] [NEW] libvirt domain launch Cannot find 'pm-is-supported' in path error
Public bug reported: Seen here: http://logs.openstack.org/29/82829/1/check/check-tempest-dsvm- full/67c8984/logs/screen-n-cpu.txt.gz 2014-03-25 14:27:02.318 ERROR nova.virt.libvirt.driver [req-b485d6b2-cf63-468f-ae09-0c6ba31274db SecurityGroupsTestJSON-1020006517 SecurityGroupsTestJSON-1157433096] An error occurred while trying to launch a defined domain with xml: domain type='qemu' nameinstance-0032/name uuidc3baa6cf-9127-4a69-af9a-58dbba0824cc/uuid memory65536/memory currentMemory65536/currentMemory vcpu1/vcpu sysinfo type='smbios' system entry name='manufacturer'OpenStack Foundation/entry entry name='product'OpenStack Nova/entry entry name='version'2014.1/entry entry name='serial'44361562-54ff-5e7f-6c5b-ba157fe8645a/entry entry name='uuid'c3baa6cf-9127-4a69-af9a-58dbba0824cc/entry /system /sysinfo os type arch='x86_64' machine='pc-1.0'hvm/type kernel/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/kernel/kernel initrd/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/ramdisk/initrd cmdlineroot=/dev/vda console=tty0 console=ttyS0/cmdline boot dev='hd'/ smbios mode='sysinfo'/ /os features acpi/ apic/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/on_crash devices emulator/usr/bin/qemu-system-x86_64/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/disk'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /disk disk type='file' device='cdrom' driver name='qemu' type='raw' cache='none'/ source file='/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/disk.config'/ target dev='hdd' bus='ide'/ readonly/ address type='drive' controller='0' bus='1' unit='1'/ /disk controller type='ide' index='0' address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='fa:16:3e:9e:b7:1c'/ source bridge='br100'/ model type='virtio'/ driver name='qemu'/ filterref filter='nova-instance-instance-0032-fa163e9eb71c'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='file' source path='/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/console.log'/ target port='0'/ /serial serial type='pty' target port='1'/ /serial console type='file' source path='/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/console.log'/ target type='serial' port='0'/ /console memballoon model='virtio' address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices /domain Then: 2014-03-25 14:27:05.135 ERROR nova.compute.manager [req-b485d6b2-cf63-468f-ae09-0c6ba31274db SecurityGroupsTestJSON-1020006517 SecurityGroupsTestJSON-1157433096] [instance: c3baa6cf-9127-4a69-af9a-58dbba0824cc] Cannot reboot instance: internal error Process exited while reading console log output: char device redirected to /dev/pts/2 qemu-system-x86_64: -drive file=/opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /opt/stack/data/nova/instances/c3baa6cf-9127-4a69-af9a-58dbba0824cc/disk: Invalid argument Looking in the libvirtd log: http://logs.openstack.org/29/82829/1/check/check-tempest-dsvm-full/67c8984/logs/libvirtd.txt.gz 2014-03-25 14:54:56.792+: 12413: warning : qemuCapsInit:856 : Failed to get host power management capabilities 2014-03-25 14:54:56.936+: 10184: error : virExecWithHook:327 : Cannot find 'pm-is-supported' in path: No such file or directory 2014-03-25 14:54:56.936+: 10184: warning : qemuCapsInit:856 : Failed to get host power management capabilities 2014-03-25 14:54:57.004+: 12413: error : virExecWithHook:327 : Cannot find 'pm-is-supported' in path: No such file or directory 2014-03-25 14:54:57.004+: 12413: warning : qemuCapsInit:856 : Failed to get host power management capabilities ** 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/1297512 Title: libvirt domain launch Cannot find 'pm-is-supported' in path error Status in OpenStack Compute (Nova): New Bug description: Seen here: http://logs.openstack.org/29/82829/1/check/check-tempest-dsvm- full/67c8984/logs/screen-n-cpu.txt.gz 2014-03-25 14:27:02.318 ERROR nova.virt.libvirt.driver
[Yahoo-eng-team] [Bug 1289309] [NEW] collie not found error in failed gate test
Public bug reported: Hit this error which is not whitelisted so causes the gate test to fail: 2014-03-07 10:54:32.474 31118 ERROR glance.store.sheepdog [-] Error in store configuration: Unexpected error while running command. Command: None Exit code: - Stdout: Unexpected error while running command.\nCommand: collie\nExit code: 127\nStdout: ''\nStderr: '/bin/sh: 1: collie: not found\\n' Stderr: None 2014-03-07 10:54:32.475 31118 WARNING glance.store.base [-] Failed to configure store correctly: Store sheepdog could not be configured correctly. Reason: Error in store configuration: Unexpected error while running command. Command: None Exit code: - Stdout: Unexpected error while running command.\nCommand: collie\nExit code: 127\nStdout: ''\nStderr: '/bin/sh: 1: collie: not found\\n' Stderr: None Disabling add method. http://logs.openstack.org/62/72762/14/check/check-grenade- dsvm/fb2420e/logs/new/screen-g-api.txt.gz ** 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/1289309 Title: collie not found error in failed gate test Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Hit this error which is not whitelisted so causes the gate test to fail: 2014-03-07 10:54:32.474 31118 ERROR glance.store.sheepdog [-] Error in store configuration: Unexpected error while running command. Command: None Exit code: - Stdout: Unexpected error while running command.\nCommand: collie\nExit code: 127\nStdout: ''\nStderr: '/bin/sh: 1: collie: not found\\n' Stderr: None 2014-03-07 10:54:32.475 31118 WARNING glance.store.base [-] Failed to configure store correctly: Store sheepdog could not be configured correctly. Reason: Error in store configuration: Unexpected error while running command. Command: None Exit code: - Stdout: Unexpected error while running command.\nCommand: collie\nExit code: 127\nStdout: ''\nStderr: '/bin/sh: 1: collie: not found\\n' Stderr: None Disabling add method. http://logs.openstack.org/62/72762/14/check/check-grenade- dsvm/fb2420e/logs/new/screen-g-api.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1289309/+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 1284341] [NEW] keystone-manage db_version broken
Public bug reported: A recent commit appears to have broken keystone-manage: keystone-manage db_version 2014-02-24 21:29:17.392 CRITICAL keystone [-] TypeError: db_version() takes exactly 2 arguments (1 given) It appears to be a regression caused by this patch which was recently merged: https://review.openstack.org/#/c/61073/36/keystone/cli.py The )'s on the print statements look to be in the wrong place AFAICS. ** Affects: keystone Importance: Undecided Assignee: Steven Hardy (shardy) Status: In Progress ** Changed in: keystone Assignee: (unassigned) = Steven Hardy (shardy) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1284341 Title: keystone-manage db_version broken Status in OpenStack Identity (Keystone): In Progress Bug description: A recent commit appears to have broken keystone-manage: keystone-manage db_version 2014-02-24 21:29:17.392 CRITICAL keystone [-] TypeError: db_version() takes exactly 2 arguments (1 given) It appears to be a regression caused by this patch which was recently merged: https://review.openstack.org/#/c/61073/36/keystone/cli.py The )'s on the print statements look to be in the wrong place AFAICS. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1284341/+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 1279907] Re: Latest keystoneclient breaks tests
** Also affects: heat/havana
Importance: Undecided
Status: New
** Changed in: heat/havana
Assignee: (unassigned) = Steven Hardy (shardy)
** Changed in: heat/havana
Importance: Undecided = Critical
--
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/1279907
Title:
Latest keystoneclient breaks tests
Status in Orchestration API (Heat):
Fix Committed
Status in heat havana series:
In Progress
Status in OpenStack Dashboard (Horizon):
Fix Committed
Bug description:
The new release of keystoneclient (0.6.0) introduces some new
metaclass magic which breaks our mocking in master :(
We probably need to modify the test to use mock instead of mox, as the
issue seems to be that mox misinterprets the class type due to the
metaclass.
Immediate workaround while we workout the solution is probably to
temporarily cap keystoneclient to 0.5.1 which did not have this issue.
Traceback (most recent call last):
File /home/shardy/git/heat/heat/tests/test_heatclient.py, line 449, in
test_trust_init
self._stubs_v3(method='trust')
File /home/shardy/git/heat/heat/tests/test_heatclient.py, line 83, in
_stubs_v3
self.m.StubOutClassWithMocks(kc_v3, Client)
File /usr/lib/python2.7/site-packages/mox.py, line 366, in
StubOutClassWithMocks
raise TypeError('Given attr is not a Class. Use StubOutWithMock.')
TypeError: Given attr is not a Class. Use StubOutWithMock.
To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1279907/+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 1279823] [NEW] Deleting enabled domain results in confusing error
Public bug reported:
# openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 domain create heat
+-+---+
| Field | Value
|
+-+---+
| enabled | True
|
| id | b1816241c3bd4a67b4059dcf62526e31
|
| links | {u'self':
u'http://192.168.122.214:5000/v3/domains/b1816241c3bd4a67b4059dcf62526e31'} |
| name| heat
|
+-+---+
# openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 domain delete heat
ERROR: cliff.app You are not authorized to perform the requested action, delete
a domain that is not disabled. (HTTP 403)
This, to me at least, is confusing - from a user perspective, it sounds
like an instruction to delete a domain that is not disabled (i.e one
which is enabled, which it is!), rather than information that you can
only delete a domain which is not *enabled*
Rewording this slightly would make the user-visible error clearer IMO:
# openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 domain delete heat
ERROR: cliff.app You are not authorized to perform the requested action, can't
delete a domain that is enabled. (HTTP 403)
** Affects: keystone
Importance: Undecided
Assignee: Steven Hardy (shardy)
Status: In Progress
** Changed in: keystone
Assignee: (unassigned) = Steven Hardy (shardy)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1279823
Title:
Deleting enabled domain results in confusing error
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
# openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 domain create heat
+-+---+
| Field | Value
|
+-+---+
| enabled | True
|
| id | b1816241c3bd4a67b4059dcf62526e31
|
| links | {u'self':
u'http://192.168.122.214:5000/v3/domains/b1816241c3bd4a67b4059dcf62526e31'} |
| name| heat
|
+-+---+
# openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 domain delete heat
ERROR: cliff.app You are not authorized to perform the requested action,
delete a domain that is not disabled. (HTTP 403)
This, to me at least, is confusing - from a user perspective, it
sounds like an instruction to delete a domain that is not disabled
(i.e one which is enabled, which it is!), rather than information that
you can only delete a domain which is not *enabled*
Rewording this slightly would make the user-visible error clearer IMO:
# openstack --os-token foobar --os-url=http://127.0.0.1:5000/v3
--os-identity-api-version=3 domain delete heat
ERROR: cliff.app You are not authorized to perform the requested action,
can't delete a domain that is enabled. (HTTP 403)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1279823/+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 1279100] [NEW] keystone failed to start No module named passlib.hash
Public bug reported: Got this error from a gate verify, don't see any existing bugs describing the problem: https://review.openstack.org/#/c/71929/ http://logs.openstack.org/29/71929/4/check/check-tempest-dsvm-postgres- full/859ca89/console.html 2014-02-11 20:41:33.757 | 2014-02-11 20:41:33 [Call Trace] 2014-02-11 20:41:33.759 | 2014-02-11 20:41:33 ./stack.sh:902:start_keystone 2014-02-11 20:41:33.761 | 2014-02-11 20:41:33 /opt/stack/new/devstack/lib/keystone:419:die 2014-02-11 20:41:33.782 | 2014-02-11 20:41:33 [ERROR] /opt/stack/new/devstack/lib/keystone:419 keystone did not start 2014-02-11 20:41:36.751 | Build step 'Execute shell' marked build as failure 2014-02-11 20:41:38.318 | [SCP] Connecting to static.openstack.org http://logs.openstack.org/29/71929/4/check/check-tempest-dsvm-postgres- full/859ca89/logs/screen-key.txt.gz + ln -sf /opt/stack/new/screen-logs/screen-key.2014-02-11-203430.log /opt/stack/new/screen-logs/screen-key.log + export PYTHONUNBUFFERED=1 + PYTHONUNBUFFERED=1 + exec /bin/bash -c 'cd /opt/stack/new/keystone /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --debug' Traceback (most recent call last): File /opt/stack/new/keystone/bin/keystone-all, line 47, in module from keystone.common import sql File /opt/stack/new/keystone/keystone/common/sql/__init__.py, line 18, in module from keystone.common.sql.core import * File /opt/stack/new/keystone/keystone/common/sql/core.py, line 32, in module from keystone.common import utils File /opt/stack/new/keystone/keystone/common/utils.py, line 28, in module import passlib.hash ImportError: No module named passlib.hash ** Affects: keystone Importance: Undecided Status: New ** Affects: tempest Importance: Undecided Status: New ** Also 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/1279100 Title: keystone failed to start No module named passlib.hash Status in OpenStack Identity (Keystone): New Status in Tempest: New Bug description: Got this error from a gate verify, don't see any existing bugs describing the problem: https://review.openstack.org/#/c/71929/ http://logs.openstack.org/29/71929/4/check/check-tempest-dsvm- postgres-full/859ca89/console.html 2014-02-11 20:41:33.757 | 2014-02-11 20:41:33 [Call Trace] 2014-02-11 20:41:33.759 | 2014-02-11 20:41:33 ./stack.sh:902:start_keystone 2014-02-11 20:41:33.761 | 2014-02-11 20:41:33 /opt/stack/new/devstack/lib/keystone:419:die 2014-02-11 20:41:33.782 | 2014-02-11 20:41:33 [ERROR] /opt/stack/new/devstack/lib/keystone:419 keystone did not start 2014-02-11 20:41:36.751 | Build step 'Execute shell' marked build as failure 2014-02-11 20:41:38.318 | [SCP] Connecting to static.openstack.org http://logs.openstack.org/29/71929/4/check/check-tempest-dsvm- postgres-full/859ca89/logs/screen-key.txt.gz + ln -sf /opt/stack/new/screen-logs/screen-key.2014-02-11-203430.log /opt/stack/new/screen-logs/screen-key.log + export PYTHONUNBUFFERED=1 + PYTHONUNBUFFERED=1 + exec /bin/bash -c 'cd /opt/stack/new/keystone /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --debug' Traceback (most recent call last): File /opt/stack/new/keystone/bin/keystone-all, line 47, in module from keystone.common import sql File /opt/stack/new/keystone/keystone/common/sql/__init__.py, line 18, in module from keystone.common.sql.core import * File /opt/stack/new/keystone/keystone/common/sql/core.py, line 32, in module from keystone.common import utils File /opt/stack/new/keystone/keystone/common/utils.py, line 28, in module import passlib.hash ImportError: No module named passlib.hash To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279100/+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 1277027] [NEW] test_admin_delete_servers_of_others failure due to unexpected task state
Public bug reported:
I couldn't find an existing bug for this, apologies if it's a dupe,
looks like a nova bug:
https://review.openstack.org/#/c/70717/
http://logs.openstack.org/17/70717/1/gate/gate-tempest-dsvm-full/9adaf90/console.html
2014-02-06 08:04:16.350 | 2014-02-06 07:48:25,729 Response Body: {server:
{status: ERROR, os-access-ips:access_ip_v6: , updated:
2014-02-06T07:48:25Z, os-access-ips:access_ip_v4: , addresses: {},
links: [{href:
http://127.0.0.1:8774/v3/servers/1cbd2e01-d2f3-45a0-baee-1d16df3dc7fd;, rel:
self}, {href:
http://127.0.0.1:8774/servers/1cbd2e01-d2f3-45a0-baee-1d16df3dc7fd;, rel:
bookmark}], os-extended-status:task_state: null, key_name: null, image:
{id: 7e649e07-3cea-4d95-90b2-2bbea7fce698, links: [{href:
http://23.253.79.233:9292/images/7e649e07-3cea-4d95-90b2-2bbea7fce698;, rel:
bookmark}]}, os-pci:pci_devices: [],
os-extended-availability-zone:availability_zone: nova,
os-extended-status:power_state: 0, os-config-drive:config_drive: ,
host_id: 10f0dc42e72572ed6d30e8dc32b41edc1d41a3dacda6571c5aeabe6e,
flavor: {id: 42, links: [{href: http://127.0.0.1:8774/flavors/42;,
rel: bookmark}]}, id: 1cbd2e01-d2
f3-45a0-baee-1d16df3dc7fd, security_groups: [{name: default}],
user_id: f2262ed0a64c43359867456cfbccc153, name:
ServersAdminV3Test-instance-1705049062, created: 2014-02-06T07:48:21Z,
tenant_id: 8e932e11471a469e85a30195b2198f63, os-extended-status:vm_state:
error, os-server-usage:launched_at: null,
os-extended-volumes:volumes_attached: [], os-server-usage:terminated_at:
null, os-extended-status:locked_by: null, fault: {message: No valid host
was found. , code: 500, created: 2014-02-06T07:48:25Z}, metadata: {}}}
2014-02-06 08:04:16.350 | }}}
2014-02-06 08:04:16.350 |
2014-02-06 08:04:16.350 | Traceback (most recent call last):
2014-02-06 08:04:16.350 | File
tempest/api/compute/v3/admin/test_servers.py, line 85, in
test_admin_delete_servers_of_others
2014-02-06 08:04:16.350 |
self.servers_client.wait_for_server_termination(server['id'])
2014-02-06 08:04:16.351 | File
tempest/services/compute/v3/json/servers_client.py, line 179, in
wait_for_server_termination
2014-02-06 08:04:16.351 | raise
exceptions.BuildErrorException(server_id=server_id)
2014-02-06 08:04:16.351 | BuildErrorException: Server
1cbd2e01-d2f3-45a0-baee-1d16df3dc7fd failed to build and is in ERROR status
2014-02-06 08:04:16.351 |
2014-02-06 08:04:16.351 |
2014-02-06 08:04:16.351 |
==
2014-02-06 08:04:16.351 | FAIL: process-returncode
2014-02-06 08:04:16.351 | process-returncode
2014-02-06 08:04:16.351 |
--
2014-02-06 08:04:16.352 | _StringException: Binary content:
2014-02-06 08:04:16.352 | traceback (test/plain; charset=utf8)
2014-02-06 08:04:16.352 |
2014-02-06 08:04:16.352 |
2014-02-06 08:04:16.352 |
--
2014-02-06 08:04:16.352 | Ran 2101 tests in 2350.793s
2014-02-06 08:04:16.353 |
2014-02-06 08:04:16.353 | FAILED (failures=2, skipped=130)
2014-02-06 08:04:16.353 | ERROR: InvocationError: '/bin/bash
tools/pretty_tox.sh
(?!.*\\[.*\\bslow\\b.*\\])(^tempest\\.(api|scenario|thirdparty|cli))
--concurrency=2'
2014-02-06 08:04:16.354 | ___ summary
2014-02-06 08:04:16.354 | ERROR: full: commands failed
2014-02-06 08:04:16.463 | Checking logs...
2014-02-06 08:04:16.562 | Log File: n-net
2014-02-06 08:04:16.562 | 2014-02-06 07:34:40.598 30086 ERROR
oslo.messaging._executors.base [-] Exception during message handling
2014-02-06 08:04:16.562 |
2014-02-06 08:04:16.563 | 2014-02-06 07:34:40.601 30086 ERROR
oslo.messaging._drivers.common [-] Returning exception Instance
fcfcbace-c4dd-4214-957f-b01e0b47fcf4 could not be found.
2014-02-06 08:04:16.563 |
2014-02-06 08:04:16.563 | 2014-02-06 07:34:40.601 30086 ERROR
oslo.messaging._drivers.common [-] ['Traceback (most recent call last):\n', '
File /opt/stack/new/oslo.messaging/oslo/messaging/_executors/base.py, line
36, in _dispatch\nincoming.reply(self.callback(incoming.ctxt,
incoming.message))\n', ' File
/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py, line 134, in
__call__\nreturn self._dispatch(endpoint, method, ctxt, args)\n', ' File
/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py, line 104, in
_dispatch\nresult = getattr(endpoint, method)(ctxt, **new_args)\n', ' File
/opt/stack/new/nova/nova/network/floating_ips.py, line 117, in
allocate_for_instance\n**kwargs)\n', ' File
/opt/stack/new/nova/nova/network/manager.py, line 521, in
allocate_for_instance\nhost)\n', ' File
/opt/stack/new/oslo.messaging/oslo/messaging/rpc/server.py, line 153, in
inner\nreturn func(*args, **kwargs)\n', ' File /opt/stack/new/nova/
nova/network/manager.py, line 579, in get_instance_nw_info\n
[Yahoo-eng-team] [Bug 1276244] [NEW] v2 default domain not respected via admin endpoint
Public bug reported: So I'm not sure if this is a bug or a feature I just don't want, but it seems that requesting a tenant list via the v2.0 API via the admin endpoint doesn't respect the default domain, so you see projects for all domains: [shardy@localhost ~]$ keystone --os-token f3aaf1597ad546f3a71dd7fd71c2af47 --os-endpoint http://127.0.0.1:5000/v2.0 tenant-list +--+---+-+ |id| name | enabled | +--+---+-+ | 20aedb59aeb247b1a5ec7332843ab092 | admin | True | | b5d498f9631244b59912ce2a0025cf8d | demo | True | +--+---+-+ [shardy@localhost ~]$ keystone --os-token f3aaf1597ad546f3a71dd7fd71c2af47 --os-endpoint http://127.0.0.1:35357/v2.0 tenant-list +--+-+-+ |id| name| enabled | +--+-+-+ | 20aedb59aeb247b1a5ec7332843ab092 |admin| True | | 620f89a53d35496493a7041bbd874568 | alt_demo | True | | b5d498f9631244b59912ce2a0025cf8d | demo| True | | b5caca84c0db4527a4d51200e9abdece | invisible_to_admin | True | | cbbffb57ff0149f1b834898ea359c9e9 | notdefault11601 | True | | be4cd31a14ab4ca9bdd93ed23c383f8c | notindefaultdomain | True | | 2752427c70784ed696482dbf2420f8ac | notindefaultdomain2 | True | | c8d527072b284247bd05441583eb0751 | notindefaultdomain3 | True | | f7d52276b01c4931986000913a23deff | service | True | +--+-+-+ This is particularly confusing when combined with the magic properties of keystoneclient's --os-tenant-name option, which means that if you specify the admin tenant (openrc admin admin), then it selects the admin endpoint: [shardy@localhost ~]$ keystone --os-username admin --os-password foobar --os-auth-url http://127.0.0.1:5000/v2.0 tenant-list +--+---+-+ |id| name | enabled | +--+---+-+ | 20aedb59aeb247b1a5ec7332843ab092 | admin | True | | b5d498f9631244b59912ce2a0025cf8d | demo | True | +--+---+-+ [shardy@localhost ~]$ keystone --os-tenant-name admin --os-username admin --os-password foobar --os-auth-url http://127.0.0.1:5000/v2.0 tenant-list +--+-+-+ |id| name| enabled | +--+-+-+ | 20aedb59aeb247b1a5ec7332843ab092 |admin| True | | 620f89a53d35496493a7041bbd874568 | alt_demo | True | | b5d498f9631244b59912ce2a0025cf8d | demo| True | | b5caca84c0db4527a4d51200e9abdece | invisible_to_admin | True | | cbbffb57ff0149f1b834898ea359c9e9 | notdefault11601 | True | | be4cd31a14ab4ca9bdd93ed23c383f8c | notindefaultdomain | True | | 2752427c70784ed696482dbf2420f8ac | notindefaultdomain2 | True | | c8d527072b284247bd05441583eb0751 | notindefaultdomain3 | True | | f7d52276b01c4931986000913a23deff | service | True | +--+-+-+ Can anyone clarify if this is working as designed or a bug? ** 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/1276244 Title: v2 default domain not respected via admin endpoint Status in OpenStack Identity (Keystone): New Bug description: So I'm not sure if this is a bug or a feature I just don't want, but it seems that requesting a tenant list via the v2.0 API via the admin endpoint doesn't respect the default domain, so you see projects for all domains: [shardy@localhost ~]$ keystone --os-token f3aaf1597ad546f3a71dd7fd71c2af47 --os-endpoint http://127.0.0.1:5000/v2.0 tenant-list +--+---+-+ |id| name | enabled | +--+---+-+ | 20aedb59aeb247b1a5ec7332843ab092 | admin | True | | b5d498f9631244b59912ce2a0025cf8d | demo | True | +--+---+-+ [shardy@localhost ~]$ keystone --os-token f3aaf1597ad546f3a71dd7fd71c2af47 --os-endpoint http://127.0.0.1:35357/v2.0 tenant-list +--+-+-+ |id| name| enabled | +--+-+-+ | 20aedb59aeb247b1a5ec7332843ab092 |admin
[Yahoo-eng-team] [Bug 1268977] [NEW] v3 credentials project is not optional for type=ec2
Public bug reported: The project is documented as being optional when creating credentials via the v3/credentials API, but not providing a project when creating ec2 credentials, then validating a signed request signed with those credentials via ec2tokens fails: 2014-01-14 13:53:19.390 10908 ERROR keystone.common.wsgi [-] object of type 'NoneType' has no len() 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi File /opt/stack/keystone/keystone/common/wsgi.py, line 213, in __call__ 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi result = method(context, **params) 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi File /opt/stack/keystone/keystone/contrib/ec2/controllers.py, line 103, in authenticate 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi tenant_ref = self.assignment_api.get_project(creds_ref['tenant_id']) So we should probably raise an error when creating the credential, since we can never create an appropriately scoped token in ec2tokens without knowing the user and project associated with the credentials. ** Affects: keystone Importance: Undecided Assignee: Steven Hardy (shardy) Status: New ** Changed in: keystone Assignee: (unassigned) = Steven Hardy (shardy) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1268977 Title: v3 credentials project is not optional for type=ec2 Status in OpenStack Identity (Keystone): New Bug description: The project is documented as being optional when creating credentials via the v3/credentials API, but not providing a project when creating ec2 credentials, then validating a signed request signed with those credentials via ec2tokens fails: 2014-01-14 13:53:19.390 10908 ERROR keystone.common.wsgi [-] object of type 'NoneType' has no len() 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi File /opt/stack/keystone/keystone/common/wsgi.py, line 213, in __call__ 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi result = method(context, **params) 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi File /opt/stack/keystone/keystone/contrib/ec2/controllers.py, line 103, in authenticate 2014-01-14 13:53:19.390 10908 TRACE keystone.common.wsgi tenant_ref = self.assignment_api.get_project(creds_ref['tenant_id']) So we should probably raise an error when creating the credential, since we can never create an appropriately scoped token in ec2tokens without knowing the user and project associated with the credentials. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268977/+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 1267530] [NEW] boolean query parameters inconsistently handled
Public bug reported:
The code which handles interpreting boolean query parameters (which are
always converted to strings as part of the request) seems overly
restrictive, it will only except blah?parameter=0 as a definition of
False, and not the (arguably more intuitive) blah?parameter=False
For example, trying to use the domain enabled filter:
# curl -i -X GET -H 'X-Auth-Token: 27c9fcf8c0404de0b15f33e11208bdda' -H
'Content-Type: application/json' -H 'Accept: application/json'
http://127.0.0.1:5000/v3/domains?enabled=0
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 102
Date: Thu, 09 Jan 2014 16:37:29 GMT
{domains: [], links: {self: http://localhost:5000/v3/domains;,
previous: null, next: null}}
# curl -i -X GET -H 'X-Auth-Token: 27c9fcf8c0404de0b15f33e11208bdd -H
'Content-Type: application/json' -H 'Accept: application/json'
http://127.0.0.1:5000/v3/domains?enabled=False
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 536
Date: Thu, 09 Jan 2014 16:37:35 GMT
{domains: [{links: {self:
http://localhost:5000/v3/domains/b10fcb438ed048ada48036c25f8a45de},
enabled: true, description: Owns users and tenants used by the heat
service, name: heat, id: b10fcb438ed048ada48036c25f8a45de},
{links: {self: http://localhost:5000/v3/domains/default},
enabled: true, description: Owns users and tenants (i.e. projects)
available on Identity API v2., name: Default, id: default}],
links: {self: http://localhost:5000/v3/domains;, previous: null,
next: null}}
So passing enabled=False returns all the results for enabled=True, which is,
uh, confusing, particularly since True/False works when specifying enabled in
the body when creating a domain.
The problem is here:
https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L321
** Affects: keystone
Importance: Undecided
Assignee: Steven Hardy (shardy)
Status: In Progress
** Changed in: keystone
Assignee: (unassigned) = Steven Hardy (shardy)
** Changed in: keystone
Status: New = In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1267530
Title:
boolean query parameters inconsistently handled
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
The code which handles interpreting boolean query parameters (which
are always converted to strings as part of the request) seems overly
restrictive, it will only except blah?parameter=0 as a definition of
False, and not the (arguably more intuitive) blah?parameter=False
For example, trying to use the domain enabled filter:
# curl -i -X GET -H 'X-Auth-Token: 27c9fcf8c0404de0b15f33e11208bdda' -H
'Content-Type: application/json' -H 'Accept: application/json'
http://127.0.0.1:5000/v3/domains?enabled=0
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 102
Date: Thu, 09 Jan 2014 16:37:29 GMT
{domains: [], links: {self: http://localhost:5000/v3/domains;,
previous: null, next: null}}
# curl -i -X GET -H 'X-Auth-Token: 27c9fcf8c0404de0b15f33e11208bdd -H
'Content-Type: application/json' -H 'Accept: application/json'
http://127.0.0.1:5000/v3/domains?enabled=False
HTTP/1.1 200 OK
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 536
Date: Thu, 09 Jan 2014 16:37:35 GMT
{domains: [{links: {self:
http://localhost:5000/v3/domains/b10fcb438ed048ada48036c25f8a45de},
enabled: true, description: Owns users and tenants used by the
heat service, name: heat, id:
b10fcb438ed048ada48036c25f8a45de}, {links: {self:
http://localhost:5000/v3/domains/default}, enabled: true,
description: Owns users and tenants (i.e. projects) available on
Identity API v2., name: Default, id: default}], links:
{self: http://localhost:5000/v3/domains;, previous: null, next:
null}}
So passing enabled=False returns all the results for enabled=True, which is,
uh, confusing, particularly since True/False works when specifying enabled in
the body when creating a domain.
The problem is here:
https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L321
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1267530/+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 1259584] [NEW] ec2 signature validation fails with v3 credentials
Public bug reported:
If you create an ec2 keypair via the v3/credentials API:
https://github.com/openstack/identity-api/blob/master/openstack-
identity-api/v3/src/markdown/identity-api-v3.md#credentials-
v3credentials
Then you get a 500 when trying to validate a signed request (signed
using the keypair) via the ec2tokens extension:
2013-12-10 14:52:30.060 722 ERROR keystone.common.wsgi [-] 'unicode' object has
no attribute 'get'
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi Traceback (most recent
call last):
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/common/wsgi.py, line 238, in
__call__
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi result =
method(context, **params)
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/contrib/ec2/controllers.py, line
96, in authenticate
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi creds_ref =
self._get_credentials(credentials['access'])
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/contrib/ec2/controllers.py, line
229, in _get_credentials
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi return
self._convert_v3_to_ec2_credential(creds)
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/contrib/ec2/controllers.py, line
215, in _convert_v3_to_ec2_credential
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi 'access':
blob.get('access'),
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi AttributeError:
'unicode' object has no attribute 'get'
It looks like a mismatch between the way the data blob is stored via
v3/credentials and creating the keypair direct via the ec2tokens
** Affects: keystone
Importance: Undecided
Assignee: Steven Hardy (shardy)
Status: New
** Changed in: keystone
Assignee: (unassigned) = Steven Hardy (shardy)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1259584
Title:
ec2 signature validation fails with v3 credentials
Status in OpenStack Identity (Keystone):
New
Bug description:
If you create an ec2 keypair via the v3/credentials API:
https://github.com/openstack/identity-api/blob/master/openstack-
identity-api/v3/src/markdown/identity-api-v3.md#credentials-
v3credentials
Then you get a 500 when trying to validate a signed request (signed
using the keypair) via the ec2tokens extension:
2013-12-10 14:52:30.060 722 ERROR keystone.common.wsgi [-] 'unicode' object
has no attribute 'get'
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi Traceback (most recent
call last):
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/common/wsgi.py, line 238, in
__call__
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi result =
method(context, **params)
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/contrib/ec2/controllers.py, line
96, in authenticate
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi creds_ref =
self._get_credentials(credentials['access'])
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/contrib/ec2/controllers.py, line
229, in _get_credentials
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi return
self._convert_v3_to_ec2_credential(creds)
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi File
/usr/lib/python2.7/site-packages/keystone/contrib/ec2/controllers.py, line
215, in _convert_v3_to_ec2_credential
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi 'access':
blob.get('access'),
2013-12-10 14:52:30.060 722 TRACE keystone.common.wsgi AttributeError:
'unicode' object has no attribute 'get'
It looks like a mismatch between the way the data blob is stored via
v3/credentials and creating the keypair direct via the ec2tokens
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1259584/+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 1243236] Re: test_keystoneclient inheritance is wrong
Oh wow, I just realized it's a weird and non-obvious way to run the same tests against multiple versions. ** 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/1243236 Title: test_keystoneclient inheritance is wrong Status in OpenStack Identity (Keystone): Invalid Bug description: The test_keystoneclient tests each inherit from each other, but this results in each test-case running all the tests from those in the chain of inheritance. Unless I'm mistaken, this is wrong, they should inherit instead from a common base-class containing only utility functions and no test_* tests. I guess (unless tox/testr does something clever I'm not aware of) this means we're running many of these tests more than once in the gate? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1243236/+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 1213340] Re: v3 token requests always 401 with scope OS-TRUST:trust
Ok, looks like this is invalid, curl examples posted here work OK: http://lists.openstack.org/pipermail/openstack- dev/2013-August/013837.html So my issues have been due to a combination of: - Confusion between project/tenant terminology leading to a project/tenant mismatch in my test code - Trying to create a trust with the admin user which doesn't have a tenantId - Trying to use a trust created with an empty roles list On the last point, it's interesting to note that, as mentioned in the docs: A project_id may not be specified without at least one role, and vice versa. https://github.com/openstack/identity-api/blob/master/openstack- identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md However it appears it is possible to create a trust specifying a project_id with an empty roles list. Trying to consume that trust will always fail with 401, which IMHO is a lot less obvious than just failing at trust-creation time - surely creating the trust is pointless since it can never be consumed? Anyway, maybe a bug to be discussed on the comment above, but this can be closed invalid - thanks! ** 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/1213340 Title: v3 token requests always 401 with scope OS-TRUST:trust Status in OpenStack Identity (Keystone): Invalid Bug description: Whenever a request to get a token contains the OS-TRUST:trust scope, the request always returns a 401 response. The exact same request without the OS-TRUST:trust scope always works. Attempting to consume a trust as per: https://github.com/openstack/identity-api/blob/master/openstack- identity-api/v3/src/markdown/identity-api-v3-os-trust- ext.md#consuming-a-trust-with-post-authtokens I've tried with methods:['token'] and methods:['password'] and the results are the same, whenever the request contains a trust id in the scope section, the request gets 401'd The token case can be reproduced as described in bug #1212778 (which returns 401 with the proposed patch fixing the 500 error) The username/password can be reproduced with the reproducer attached. In both cases you need the keystone client patch from https://review.openstack.org/#/c/39899/ to add the trusts interfaces. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1213340/+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 1134163] Re: Job pep8 fails according can't satisfy test-requires
Marking invalid for heat also - the release of python-quantumclient 2.1.2 in pypi has fixed the issue for us ** Changed in: heat Importance: Critical = Undecided ** Changed in: heat Status: In Progress = Invalid ** Changed in: heat Assignee: Steven Hardy (shardy) = (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to quantum. https://bugs.launchpad.net/bugs/1134163 Title: Job pep8 fails according can't satisfy test-requires Status in Orchestration API (Heat): Invalid Status in OpenStack Compute (Nova): In Progress Status in OpenStack Core Infrastructure: Invalid Status in OpenStack Quantum (virtual network service): In Progress Status in Tempest: New Bug description: In the python-quantumclient project a job fails with next trace: (http://logs.openstack.org/23073/1/check/gate-python-quantumclient-pep8/460/console.html) 2013-02-27 09:33:45.765 | Downloading/unpacking pyparsing=1.5.6 (from cmd2-cliff-cliff-tablib=1.0--r /home/jenkins/workspace/gate-python-quantumclient-pep8/tools/test-requires (line 1)) 2013-02-27 09:33:45.765 | Storing download in cache at /home/jenkins/workspace/gate-python-quantumclient-pep8/.tox/_download/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fp%2Fpyparsing%2Fpyparsing-2.0.0.zip 2013-02-27 09:33:45.766 | Running setup.py egg_info for package pyparsing 2013-02-27 09:33:45.766 | Traceback (most recent call last): 2013-02-27 09:33:45.766 | File string, line 16, in module 2013-02-27 09:33:45.767 | File /home/jenkins/workspace/gate-python-quantumclient-pep8/.tox/pep8/build/pyparsing/setup.py, line 9, in module 2013-02-27 09:33:45.767 | from pyparsing import __version__ as pyparsing_version 2013-02-27 09:33:45.767 | File pyparsing.py, line 629 2013-02-27 09:33:45.768 | nonlocal limit,foundArity 2013-02-27 09:33:45.768 | ^ 2013-02-27 09:33:45.768 | SyntaxError: invalid syntax 2013-02-27 09:33:45.769 | Complete output from command python setup.py egg_info: 2013-02-27 09:33:45.769 | Traceback (most recent call last): 2013-02-27 09:33:45.770 | 2013-02-27 09:33:45.770 | File string, line 16, in module 2013-02-27 09:33:45.771 | 2013-02-27 09:33:45.771 | File /home/jenkins/workspace/gate-python-quantumclient-pep8/.tox/pep8/build/pyparsing/setup.py, line 9, in module 2013-02-27 09:33:45.771 | 2013-02-27 09:33:45.772 | from pyparsing import __version__ as pyparsing_version 2013-02-27 09:33:45.772 | 2013-02-27 09:33:45.773 | File pyparsing.py, line 629 2013-02-27 09:33:45.774 | 2013-02-27 09:33:45.774 | nonlocal limit,foundArity 2013-02-27 09:33:45.774 | 2013-02-27 09:33:45.775 | ^ 2013-02-27 09:33:45.775 | 2013-02-27 09:33:45.776 | SyntaxError: invalid syntax 2013-02-27 09:33:45.776 | 2013-02-27 09:33:45.777 | 2013-02-27 09:33:45.777 | Command python setup.py egg_info failed with error code 1 in /home/jenkins/workspace/gate-python-quantumclient-pep8/.tox/pep8/build/pyparsing 2013-02-27 09:33:45.778 | Storing complete log in /home/jenkins/.pip/pip.log 2013-02-27 09:33:45.778 | 2013-02-27 09:33:45.778 | ERROR: could not install deps [-r/home/jenkins/workspace/gate-python-quantumclient-pep8/tools/test-requires] 2013-02-27 09:33:45.779 | ___ summary 2013-02-27 09:33:45.779 | ERROR: pep8: could not install deps [-r/home/jenkins/workspace/gate-python-quantumclient-pep8/tools/test-requires] 2013-02-27 09:33:45.889 | Build step 'Execute shell' marked build as failure To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1134163/+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
