[Yahoo-eng-team] [Bug 1230050] Re: setting of cputune.quota need to recoginse libvirt version
Sorry guys, Daniel is right. I mixed cputune setting of kvm up with that
of lxc.
On 2013-10-08 19:14 , hzguanqi...@corp.netease.com wrote:
Well, Daniel. If the thing is as you said, I'm wrong.
But The fact is with the same cputune xml configure under different version
of libvirt, It will lead to different results in cgroup.
Details are as following:
hzguanqiang@debian1:~$ sudo virsh version
Compiled against library: libvir 0.9.12
Using library: libvir 0.9.12
Using API: QEMU 0.9.12
Running hypervisor: QEMU 1.1.2
hzguanqiang@debian1:/data/nova/instances/instance-0053$ cat libvirt.xml
2bc80c41-ed34-4a7e-8645-e9af789b29cb
instance-0053
8388608
8
hvm
32768
10
10
hzguanqiang@debian1:/data/nova/instances/instance-0053$ cat
/sys/fs/cgroup/cpu/libvirt/qemu/instance-0053/cpu.cfs_quota_us
80
hzguanqiang@debian2:~$ vir version
Compiled against library: libvirt 1.1.2
Using library: libvirt 1.1.2
Using API: LXC 1.1.2
Running hypervisor: LXC 3.9.6
hzguanqiang@debian2:~$ vir dumpxml instance-006c
instance-006c
ab43db36-ee30-4223-92e8-7652255cffb7
1048576
1048576
3
6144
10
57499
/machine
exe
/sbin/init
console=tty0 console=ttyS0
destroy
restart
destroy
/usr/libexec/libvirt_lxc
hzguanqiang@debian2:~$ cat
/sys/fs/cgroup/cpu/machine/instance-006c.libvirt-lxc/cpu.cfs_quota_us
57499
>From the above, you can see with libvirt version of 0.9.12, the
>'cpu.cfs_quota_us' parameter of
instance cgroup is the value of cputune.period multiplied by vcpu numbers.
And with libvirt version of 1.1.2, they are equal.
On 2013-10-08 17:58 , Daniel Berrange wrote:
I don't believe this is correct.
In libvirt < 0.10.0 we created a single cgroup
$ROOT/libvirt/qemu/$GUESTNAME
and set the 'quota * nvcpus' value at that level
In libvirt >= 0.10.0 we create one cgroup per vCPU
$ROOT/libvirt/qemu/$GUESTNAME/{vcpu0,vcpu1,}
and set the 'quota' value at the vcpuN level.
The end result is the same in both cases - you get 'quota * nvcpus'
worth of time allowed.
--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1230050
Title:
setting of cputune.quota need to recoginse libvirt version
Status in OpenStack Compute (Nova):
In Progress
Bug description:
Setting of cputune.quota has changed in libvirt from version 0.10.0. So the
cputune.quota parameter of cpu qos which is writed into the libvirt xml should
be set differently under different version of libvirt.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1230050/+subscriptions
--
Best regards!
GuanQiang
19:04:26
--
Best regards!
GuanQiang
15:12:33
** Changed in: nova
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/1230050
Title:
setting of cputune.quota need to recoginse libvirt version
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Setting of cputune.quota has changed in libvirt from version 0.10.0. So the
cputune.quota parameter of cpu qos which is writed into the libvirt xml should
be set differently under different version of libvirt.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1230050/+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 1235087] Re: Grizzly+Quantum: Could not find Service or Region in Service Catalog
** No longer affects: keystone
** Changed in: neutron
Status: New => Invalid
** Converted to question:
https://answers.launchpad.net/neutron/+question/237065
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1235087
Title:
Grizzly+Quantum: Could not find Service or Region in Service Catalog
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
Hello, I've got a problem with Quantum. It seems something wrong
between keystone and quantum.
user@tyamazaki:~# quantum -v net-list
DEBUG: quantumclient.quantum.v2_0.network.ListNetwork
get_data(Namespace(columns=[], fields=[], filter_specs=[], formatter='table',
page_size=None, quote_mode='nonnumeric', request_format='json',
show_details=False, sort_dir=[], sort_key=[]))
DEBUG: quantumclient.client
REQ: curl -i http://127.0.0.1:5000/v2.0/tokens -X POST -H "Content-Type:
application/json" -H "Accept: application/json" -H "User-Agent:
python-quantumclient" -d '{"auth": {"tenantName": "admin",
"passwordCredentials": {"username": "admin", "password": "admin"}}}'
DEBUG: quantumclient.client RESP:{'date': 'Fri, 04 Oct 2013 05:54:28
GMT', 'vary': 'X-Auth-Token', 'content-length': '2420', 'status':
'200', 'content-type': 'application/json'} {"access": {"token":
{"issued_at": "2013-10-04T05:54:28.073856", "expires":
"2013-10-05T05:54:28Z", "id": "54301638e7a14dbf9ca6a50fd1322932",
"tenant": {"description": null, "enabled": true, "id":
"adc6715159034f43b074ffaad1aa4e13", "name": "admin"}},
"serviceCatalog": [{"endpoints": [{"adminURL":
"http://127.0.0.1:8774/v2/adc6715159034f43b074ffaad1aa4e13";, "region":
"myregion", "internalURL":
"http://127.0.0.1:8774/v2/adc6715159034f43b074ffaad1aa4e13";, "id":
"211f5661b7bb404483e4977dd7b8fc1c", "publicURL":
"http://127.0.0.1:8774/v2/adc6715159034f43b074ffaad1aa4e13"}],
"endpoints_links": [], "type": "compute", "name": "nova"},
{"endpoints": [{"adminURL": "http://127.0.0.1:9292/v1";, "region":
"myregion", "internalURL": "http://127.0.0.1:9292/v1";, "id":
"274a5c465662472c95f8995fbe97e5ae", "publicURL":
"http://127.0.0.1:9292/v1"}], "endpoints_links": [], "type": "image",
"name": "glance"}, {"endpoints": [{"adminURL":
"http://127.0.0.1:8776/v1/adc6715159034f43b074ffaad1aa4e13";, "region":
"myregion", "internalURL":
"http://127.0.0.1:8776/v1/adc6715159034f43b074ffaad1aa4e13";, "id":
"11f4410fff25417d8f3f2f1ca2dc91b4", "publicURL":
"http://127.0.0.1:8776/v1/adc6715159034f43b074ffaad1aa4e13"}],
"endpoints_links": [], "type": "volume", "name": "volume"},
{"endpoints": [{"adminURL": "http://127.0.0.1:9696";, "region":
"myregion", "internalURL": "http://127.0.0.1:9696";, "id":
"272903e74a7b4dff81bec4710bc01b33", "publicURL":
"http://127.0.0.1:9696"}], "endpoints_links": [], "type": "quantum",
"name": "quantum"}, {"endpoints": [{"adminURL":
"http://127.0.0.1:8080/v1";, "region": "myregion", "internalURL":
"http://127.0.0.1:8080/v1/AUTH_adc6715159034f43b074ffaad1aa4e13";,
"id": "7d810507150a418b94cb4e602e1315c6", "publicURL":
"http://127.0.0.1:8080/v1/AUTH_adc6715159034f43b074ffaad1aa4e13"}],
"endpoints_links": [], "type": "object-store", "name": "swift"},
{"endpoints": [{"adminURL": "http://127.0.0.1:35357/v2.0";, "region":
"myregion", "internalURL": "http://127.0.0.1:5000/v2.0";, "id":
"160b8fff02fc4c9fbfbd1b5c8889c824", "publicURL":
"http://127.0.0.1:5000/v2.0"}], "endpoints_links": [], "type":
"identity", "name": "keystone"}], "user": {"username": "admin",
"roles_links": [], "id": "98d120be785d4ab29c46fa79b04a173c", "roles":
[{"name": "Member"}, {"name": "admin"}], "name": "admin"}, "metadata":
{"is_admin": 0, "roles": ["30a2a9b7f951453ab193b72c9e016e34",
"0fec66c915e544e4996c66409bd1f04b"]}}}
ERROR: quantumclient.shell Could not find Service or Region in Service
Catalog.
DEBUG: quantumclient.shell clean_up ListNetwork
DEBUG: quantumclient.shell got an error: Could not find Service or Region in
Service Catalog.
user@tyamazaki:~# netstat -an | grep 9696
tcp0 0 127.0.0.1:9696 0.0.0.0:* LISTEN
user@tyamazaki:~# keystone endpoint-list
+--+--+-+-++--+
|id| region | publicurl
| internalurl |
adminurl|service_id|
+--+--+-+-++--+
| 03180af0d22e4a4aa4702f9d1a2326de | myregion |
http:/
[Yahoo-eng-team] [Bug 1226374] Re: misused assertTrue in unit tests
** Changed in: swift Status: Fix Committed => Fix Released ** Changed in: swift Milestone: None => 1.10.0-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1226374 Title: misused assertTrue in unit tests Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): Fix Released Status in Ironic (Bare Metal Provisioning): Fix Committed Status in OpenStack Identity (Keystone): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in Python client library for Keystone: Fix Committed Status in OpenStack Object Storage (Swift): Fix Released Status in Tempest: Fix Committed Bug description: 1)signature for assertTure: def failUnless(self, expr, msg=None): """Fail the test unless the expression is true.""" if not expr: raise self.failureException, msg assert_ = assertTrue = failUnless 2) signature for assertEqual: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '==' operator. """ if not first == second: raise self.failureException, \ (msg or '%r != %r' % (first, second)) ... assertEqual = assertEquals = failUnlessEqual assertTrue used to evaluate one expression assertEqual used to compare two expressions If passed two expressions to assertTrue , it always evaluate first expression . That 's not expected . To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1226374/+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 1179007] rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 affects swift status fixreleased milestone 1.10.0-rc1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVRlUAAoJEFB6+JAlsQQjdicQAKoqBbM5sRLNnoAuF5FeYoXW SmYPxPWwh2wz/KzMnjq/I2+Z4nvoQJtOKigMlGS5WIfJEZhahQncPlM5eP/4gsdI KIf3HteW0JUndOGOGo9B/SpzP1jzx47nxznaIRNohioYtRNsguqQ28psAHUjdnq6 gmqgwLyV9az0hswp2b9vD6Tv6v5OT+pGyYotA2l6WZBrui0us3fXLnmrV7PNJQWm zrxv2TZdC7KfM1yXxPWzlsMgTndoHELhtmVeNoiTnb4Zyoi9T7SKpl44BXZ25Ble VJGno1/SXr9+nfcHyULoJSdQK+Qd0JdC6TQxbGqD9XLu/DMHPXQjJU9NRpjJeaF0 ugUSsUEiInUfB4olUV8HzlwspyNGzR7kux7heNlMBTWhYLEjKKCADGvj4uLrmLjk KeHNjLSDL5zaHvQe8OcslEQp/hU5JegX5Cs0lSpX3qeBxHPuHjdkKFB+Sl7uS7Q+ oaAP7v4Rl1Q+GefJCySxP92R1iIXqf2yHwkZ29i19cyAZVj9O7ZyUEmBeRemp1AV UWmn8wA2fY54UiqWAWsZ+auUYxXhoEre25S0ZcM86LhA/rZapgUaiNs6x+xUp7FW cb/5KKst/FmByFu4z0sqCB4JGSXLFQfY0HqgB0h3UZI3LZSrgIaTfOtoXOzqxjmH rWp1UaVp0Ev6JqrUzeO5 =6/E/ -END PGP SIGNATURE- ** Changed in: swift Status: Fix Committed => Fix Released ** Changed in: swift Milestone: None => 1.10.0-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1179007 Title: Migrate build system to pbr Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Python Gearman Interface: New Status in Git Review: Fix Committed Status in Orchestration API (Heat): Fix Released Status in Heat API Instance Tools: Fix Committed Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): Fix Released Status in OpenStack Core Infrastructure: Triaged Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in Python client library for Ceilometer: Fix Committed Status in Python client library for Cinder: Fix Committed Status in Python client library for Glance: Fix Committed Status in Python client library for heat: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Marconi: Fix Committed Status in Python client library for Neutron: Fix Committed Status in Python client library for Nova: Fix Released Status in OpenStack Command Line Client: Fix Committed Status in Python client library for Swift: New Status in OpenStack Object Storage (Swift): Fix Released Status in Trove - Database as a Service: Fix Released Status in Zuul: A project gating system: New Bug description: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 openstack.common.setup and openstack.common.version are now in the standalone library pbr. Migrating involves moving build config to setup.cfg, copying in a stub setup.py file, adding pbr and d2to1 to the build depends, removing openstack.common.(setup|version) from the filesystem and from openstack-common.conf and making sure *.egg is in .gitignore. affects ceilometer affects cinder affects git-review affects heat-cfntools affects heat affects keystone affects openstack-ci affects oslo affects python-ceilometerclient affects python-cinderclient affects python-gear affects python-glanceclient affects python-heatclient affects python-keystoneclient affects python-novaclient affects python-openstackclient affects python-quantumclient affects python-swiftclient affects reddwarf affects swift affects zuul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGObdUACgkQ2Jv7/VK1RgFlkACgzycOW0/rPvnLaXXX9/oqYA7q kGEAoMaEzGbFEAnsQA6+cEsKIUSMWAPD =W8F0 -END PGP SIGNATURE- To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1179007/+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 1237334] [NEW] nova-api & nova-metadata-api services are using the same port
You have been subscribed to a public bug:
Description of problem:
The services nova-api and the nova-metadata-api are both using the same port,
8775.
Thus, the services are 'competing' for the port and one of them will not work.
Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.5 Beta (Santiago)
python-novaclient-2.15.0-1.el6ost.noarch
python-nova-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-network-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-common-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-console-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-compute-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-conductor-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-novncproxy-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-scheduler-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-api-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-cert-2013.2-0.24.rc1.el6ost.noarch
How reproducible:
everytime
Steps to Reproduce:
1. Install Havana on RHEL 6.5 AIO installation.
2.
3.
Actual results:
Either the openstack-nova-api or the openstack-nova-metadata-api service is
down.
Expected results:
Both services are up and running.
Additional info:
The error from /var/log/nova/metadata-api.log:
2013-10-09 10:54:21.975 4776 INFO nova.network.driver [-] Loading network
driver 'nova.network.linux_net'
2013-10-09 10:54:22.036 4776 DEBUG nova.wsgi [-] Loading app metadata from
/etc/nova/api-paste.ini load_app
/usr/lib/python2.6/site-packages/nova/wsgi.py:484
2013-10-09 10:54:22.076 4776 INFO nova.openstack.common.periodic_task [-]
Skipping periodic task _periodic_update_dns because its interval is negative
2013-10-09 10:54:22.079 4776 CRITICAL nova [-] [Errno 98] Address already in use
2013-10-09 10:54:22.079 4776 TRACE nova Traceback (most recent call last):
2013-10-09 10:54:22.079 4776 TRACE nova File "/usr/bin/nova-api-metadata",
line 10, in
2013-10-09 10:54:22.079 4776 TRACE nova sys.exit(main())
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/cmd/api_metadata.py", line 33, in main
2013-10-09 10:54:22.079 4776 TRACE nova server =
service.WSGIService('metadata')
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/service.py", line 318, in __init__
2013-10-09 10:54:22.079 4776 TRACE nova max_url_len=max_url_len)
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/wsgi.py", line 123, in __init__
2013-10-09 10:54:22.079 4776 TRACE nova self._socket =
eventlet.listen(bind_addr, family, backlog=backlog)
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/eventlet/convenience.py", line 38, in listen
2013-10-09 10:54:22.079 4776 TRACE nova sock.bind(addr)
2013-10-09 10:54:22.079 4776 TRACE nova File "", line 1, in bind
2013-10-09 10:54:22.079 4776 TRACE nova error: [Errno 98] Address already in use
2013-10-09 10:54:22.079 4776 TRACE nova
The error from the nova-api log:
2013-10-09 11:17:04.520 6048 CRITICAL nova [-] [Errno 98] Address already in use
2013-10-09 11:17:04.520 6048 TRACE nova Traceback (most recent call last):
2013-10-09 11:17:04.520 6048 TRACE nova File "/usr/bin/nova-api", line 10, in
2013-10-09 11:17:04.520 6048 TRACE nova sys.exit(main())
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/cmd/api.py", line 51, in main
2013-10-09 11:17:04.520 6048 TRACE nova server = service.WSGIService(api,
use_ssl=should_use_ssl)
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/service.py", line 318, in __init__
2013-10-09 11:17:04.520 6048 TRACE nova max_url_len=max_url_len)
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/wsgi.py", line 124, in __init__
2013-10-09 11:17:04.520 6048 TRACE nova self._socket =
eventlet.listen(bind_addr, family, backlog=backlog)
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/eventlet/convenience.py", line 38, in listen
2013-10-09 11:17:04.520 6048 TRACE nova sock.bind(addr)
2013-10-09 11:17:04.520 6048 TRACE nova File "", line 1, in bind
2013-10-09 11:17:04.520 6048 TRACE nova error: [Errno 98] Address already in use
2013-10-09 11:17:04.520 6048 TRACE nova
netstat:
tcp0 0 0.0.0.0:87750.0.0.0:*
LISTEN 32327/python
** Affects: nova
Importance: Undecided
Status: New
--
nova-api & nova-metadata-api services are using the same port
https://bugs.launchpad.net/bugs/1237334
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
--
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 1236627] Re: plugin support wrongly set in Embrane based plugins
Reviewed: https://review.openstack.org/50384 Committed: http://github.com/openstack/neutron/commit/9e97305a5b9ca40c9778701180a6b4772d28d0b6 Submitter: Jenkins Branch:milestone-proposed commit 9e97305a5b9ca40c9778701180a6b4772d28d0b6 Author: Ivar Lazzaro Date: Mon Oct 7 17:12:11 2013 -0700 Set correct plugin support in Embrane based plugins Change-Id: I87480415f55894e17458a85ef7918babaceb5e47 Closes-Bug: 1236627 (cherry picked from commit 15103e58443af95451a9ba22bc4a9083950d386e) ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1236627 Title: plugin support wrongly set in Embrane based plugins Status in OpenStack Neutron (virtual network service): Fix Released Bug description: _plugin_support in Embrane based plugins is assigned wrongly. This causes Router interface management to not work To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1236627/+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 1235074] Re: Bigswitch plugin disassociate floatingip call to backend missing
Reviewed: https://review.openstack.org/50381 Committed: http://github.com/openstack/neutron/commit/1bdea915869fc619f829c6c0c1b5f6ffcac05032 Submitter: Jenkins Branch:milestone-proposed commit 1bdea915869fc619f829c6c0c1b5f6ffcac05032 Author: Kevin Benton Date: Fri Oct 4 00:19:12 2013 -0700 BigSwitch: sync state on disassociate floating ip Sends the state of port's parent network to the backend controller when a floating IP is disassociated from a port. Closes-Bug: #1235074 Change-Id: I8375e6564b5d08f1adc7e7aef6affc97c8d03c5e (cherry picked from commit 0bae949eed229613c77c4943edbf68c1c140f977) ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1235074 Title: Bigswitch plugin disassociate floatingip call to backend missing Status in OpenStack Neutron (virtual network service): Fix Released Bug description: The disassociate floatingip call is not being made to the backend and is required to cleanup correctly on the backend. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1235074/+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 1237363] Re: Firewall stuck in PENDING_DELETE forever, no rollback and no option to update/delete associated policy and rules
*** This bug is a duplicate of bug 1223478 *** https://bugs.launchpad.net/bugs/1223478 Update operation is not allowed for PENDING_* firewall. The problem in Delete operation was fixed in RC1. (bug 1223478) ** This bug has been marked a duplicate of bug 1223478 firewall with PENDING_CREATE status cannot be deleted -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1237363 Title: Firewall stuck in PENDING_DELETE forever, no rollback and no option to update/delete associated policy and rules Status in OpenStack Neutron (virtual network service): New Bug description: Version === Havana on RHEL, openstack-neutron-2013.2-0.3.3.b3.el6ost Description === I've tried to delete a firewal, the firewall changed to "PENDING_DELETE" status and remained in this status forever, it's impossible to delete or update it. I haven't documented my steps before trying to delete the firewall, but now the firewall, its associated policy and the rules under the policy can not be updated/deleted also. I'd expect a kind of rollback for the firewall deletion operation or even a mitigation of my environment status by letting other operation occur while the firewall is PENDING_DELETE. The log lines relevant to my firewall's uuid /var/log/neutron/l3-agent.log:2013-10-07 10:41:12.867 9987 ERROR neutron.services.firewall.agents.l3reference.firewall_l3_agent [-] FWaaS RPC failure in create_firewall for fw: d0cfdf7b-7caf-4f53-b1d1-83c72b28f1e8 /var/log/neutron/server.log:2013-10-08 10:28:09.372 2341 TRACE neutron.api.v2.resource FirewallInPendingState: Operation cannot be performed since associated Firewall d0cfdf7b-7caf- 4f53-b1d1-83c72b28f1e8 is in PENDING_DELETE. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1237363/+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 1231657] Re: DB2 disconnect not handled pessimistically
** Changed in: keystone Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1231657 Title: DB2 disconnect not handled pessimistically Status in Ceilometer: Triaged Status in Cinder: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: Only MySQL server disconnect is being handled pessimistically by adding a pool checkout listener to the sqlalchemy engine. Since DB2 connection pool is not handled pessimistically, we get the following error after a temporarily disconnect of DB2 server that is already up and running: 2013-09-15 13:49:48.274 1013 TRACE nova.api.openstack OperationalError: (OperationalError) ibm_db_dbi::OperationalError: [IBM][CLI Driver] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: "172.17.35.52". Communication function detecting the error: "send". Protocol specific error code(s): "110", "*", "*". SQLSTATE=08001 SQLCODE=-30081 To avoid this error DB2 needs to be included in the logic to handle the connections pessimistically. To recreate in glance: Run glance index and make sure it is working Restart DB2 server Run glance index again, you will see error above. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1231657/+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 1231130] Re: python-django-horizon doesn't build under havana
** Changed in: anvil Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to anvil. https://bugs.launchpad.net/bugs/1231130 Title: python-django-horizon doesn't build under havana Status in ANVIL for forging OpenStack.: Fix Released Bug description: Build always fails at the following area: + sed -i -e 's@^less_binary.*$@less_binary = "/home/anvil/openstack/deps/rpmbuild/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.src.rpm/BUILDROOT/python-dj ango-horizon-2013.2.a98.g2ed62bb-1.el6.x86_64/usr/lib/node_modules/less/bin/lessc"@' openstack_dashboard/settings.py + node_less_dir=/home/anvil/openstack/deps/rpmbuild/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.src.rpm/BUILDROOT/python-django-horizon-2013.2.a98.g2ed62 bb-1.el6.x86_64/usr/lib/node_modules/less + mkdir -p /home/anvil/openstack/deps/rpmbuild/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.src.rpm/BUILDROOT/python-django-horizon-2013.2.a98.g2ed62bb-1. el6.x86_64/usr/lib/node_modules/less + mv /home/anvil/openstack/deps/rpmbuild/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.src.rpm/BUILDROOT/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.x8 6_64/usr/lib/python2.6/site-packages/bin/less /home/anvil/openstack/deps/rpmbuild/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.src.rpm/BUILDROOT/python-dj ango-horizon-2013.2.a98.g2ed62bb-1.el6.x86_64/usr/lib/node_modules/less/bin mv: cannot stat `/home/anvil/openstack/deps/rpmbuild/python-django-horizon-2013.2.a98.g2ed62bb-1.el6.src.rpm/BUILDROOT/python-django-horizon-2013.2.a98.g2ed6 2bb-1.el6.x86_64/usr/lib/python2.6/site-packages/bin/less': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.jaSdlB (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.jaSdlB (%install) Per: https://blueprints.launchpad.net/horizon/+spec/remove-node-less- dependency nodejs-less is no longer needed in horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1231130/+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 1234012] Re: test_nexus_plugin.py duplicate values causes tests to fail.
Reviewed: https://review.openstack.org/50649 Committed: http://github.com/openstack/neutron/commit/b4c2db5ea0ed3116de49b69dae4c4f6c9114a152 Submitter: Jenkins Branch:milestone-proposed commit b4c2db5ea0ed3116de49b69dae4c4f6c9114a152 Author: Sean McCully Date: Wed Oct 2 02:36:05 2013 -0500 Add clear_db to cleanup for TestCiscoNexusPlugin Fixes Bug: #1234012 Change-Id: I0829f04ac1a0760d96babcb1154f4f569a0f848f (cherry picked from commit b4167ed095dbd47a137ff22674ae13aba3a50513) ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1234012 Title: test_nexus_plugin.py duplicate values causes tests to fail. Status in OpenStack Neutron (virtual network service): Fix Released Bug description: == ERROR: neutron.tests.unit.cisco.test_nexus_plugin.TestCiscoNexusPlugin.test_nexus_add_remove_router_interface -- _StringException: Empty attachments: pythonlogging:'' Traceback (most recent call last): File "/home/smccully/projects/launchpad-workflow/neutron/neutron/tests/unit/cisco/test_nexus_plugin.py", line 245, in test_nexus_add_remove_router_interface router_id) File "/home/smccully/projects/launchpad-workflow/neutron/neutron/plugins/cisco/nexus/cisco_nexus_plugin_v2.py", line 191, in add_router_interface router_id=router_id) SubnetInterfacePresent: Subnet 1 has an interface on 0R1. -- Ran 601 tests in 99.274s https://review.openstack.org/#/c/49023/6 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1234012/+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 1235308] Re: ML2 README needs updates for havana release
Reviewed: https://review.openstack.org/50391 Committed: http://github.com/openstack/neutron/commit/15d863acf3ef15ad1fa63fe136c4c7b804705d36 Submitter: Jenkins Branch:milestone-proposed commit 15d863acf3ef15ad1fa63fe136c4c7b804705d36 Author: Bob Kukura Date: Sun Oct 6 21:41:08 2013 -0400 Update ML2 README file for havana Closes-Bug: 1235308 Change-Id: I684581c00ff28bc9cdb36034a9a970275b0a0090 (cherry picked from commit 2d7e2756271fff6413a572e11f9248465f23f1bb) ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1235308 Title: ML2 README needs updates for havana release Status in OpenStack Neutron (virtual network service): Fix Released Bug description: The neutron/plugins/ml2/README file contains statements such as: * Support for mechanism drivers is currently a work-in-progress in pre-release Havana versions... * Note that the ml2 plugin is new and should be conidered experimental at this point. It is undergoing rapid development, so driver APIs and other details are likely to change during the havana development cycle. * The following MechanismDrivers are actively under development for the Havana release: that are clearly out of date. Also, a reference to https://wiki.openstack.org/wiki/Neutron/ML2 would be helpful. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1235308/+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 1202690] Re: Incorrect HTTP response while creating flavor without name
*** This bug is a duplicate of bug 1220087 ***
https://bugs.launchpad.net/bugs/1220087
Alex: You are correct, this issue is fixed.
If user pass only white spaces to flavor name, then it should give error.
{
"flavor": {
"name": " "
"ram": 1024,
"vcpus": 2,
"disk": 10,
"id": "10",
"os-flavor-access:is_public": false
}
}
Current behavior it creates flavor successfully. I will file a new bug to fix
this issue.
** This bug has been marked a duplicate of bug 1220087
nova api should raise badrequest when create flavor with incorrect format
of data in request body
--
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/1202690
Title:
Incorrect HTTP response while creating flavor without name
Status in OpenStack Compute (Nova):
In Progress
Bug description:
Bug reproduced on nova/master commit ID:
80ccf6dd956ce1b2754db276e8b40f058a7e32eb
When creating a new flavor if "name" key is not specified in JSON
request body, it returns status error response as 500. Ideally it
should return a badRequest(400) as status response.
Test data:
{
"flavor": {
"ram": 1024,
"vcpus": 2,
"disk": 10,
"id": "12354"
}
}
Current error response:
{
"computeFault":{
"message":"The server has either erred or is incapable of performing the
requested operation.",
"code":500
}
}
Expected output should return error response as shown below:
{
"badRequest":{
"message":"Invalid input received: 'name' argument is mandatory,
"code":400
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1202690/+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 1226374] Re: misused assertTrue in unit tests
** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1226374 Title: misused assertTrue in unit tests Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Orchestration API (Heat): Fix Released Status in Ironic (Bare Metal Provisioning): Fix Committed Status in OpenStack Identity (Keystone): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Fix Released Status in Tempest: Fix Committed Bug description: 1)signature for assertTure: def failUnless(self, expr, msg=None): """Fail the test unless the expression is true.""" if not expr: raise self.failureException, msg assert_ = assertTrue = failUnless 2) signature for assertEqual: def failUnlessEqual(self, first, second, msg=None): """Fail if the two objects are unequal as determined by the '==' operator. """ if not first == second: raise self.failureException, \ (msg or '%r != %r' % (first, second)) ... assertEqual = assertEquals = failUnlessEqual assertTrue used to evaluate one expression assertEqual used to compare two expressions If passed two expressions to assertTrue , it always evaluate first expression . That 's not expected . To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1226374/+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 1182861] Re: Switch to oslo.config 1.2.0 final
** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1182861 Title: Switch to oslo.config 1.2.0 final Status in Ceilometer: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Message Queuing Service (Marconi): Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in OpenStack Compute (Nova): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in Python client library for Keystone: Fix Released Status in Trove - Database as a Service: Fix Committed Bug description: These commits: https://review.openstack.org/#/q/I7826087147e0713edaaea85a72283998295e2281,n,z mean we're using an oslo.config tarball from http://tarballs.openstack.org/oslo.config/ Once oslo.config-1.2.0 has been published to pypi, we should switch to: oslo.config>=1.2.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1182861/+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 1213106] Re: TypeError: an integer is required
Reviewed: https://review.openstack.org/50664 Committed: http://github.com/openstack/keystone/commit/c14ebd668f00b1d0c0f3c94fa331b2080d5ec053 Submitter: Jenkins Branch:milestone-proposed commit c14ebd668f00b1d0c0f3c94fa331b2080d5ec053 Author: Jamie Lennox Date: Wed Oct 9 11:49:58 2013 +1000 Don't use default value in LimitingReader We can't simply pass the None default on to the read operation as this default is handled differently between different wsgi implementations. Change-Id: I337e797b8dee3dfcf9299fe361cf197a176c8fe2 Fixes: bug 1213106 ** Changed in: keystone Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1213106 Title: TypeError: an integer is required Status in OpenStack Identity (Keystone): Fix Released Bug description: 2013-08-16 13:20:10ERROR [keystone.common.wsgi] an integer is required Traceback (most recent call last): File "/opt/keystone/keystone/common/wsgi.py", line 372, in __call__ response = self.process_request(request) File "/opt/keystone/keystone/middleware/core.py", line 111, in process_request params_json = request.body File "/usr/lib/python2.7/dist-packages/webob/request.py", line 677, in _body__get self.make_body_seekable() # we need this to have content_length File "/usr/lib/python2.7/dist-packages/webob/request.py", line 922, in make_body_seekable self.copy_body() File "/usr/lib/python2.7/dist-packages/webob/request.py", line 938, in copy_body self.body = self.body_file_raw.read() File "/opt/keystone/keystone/common/utils.py", line 261, in read result = self.data.read(i) TypeError: an integer is required To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1213106/+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 1237574] Re: rpc_backend defaults to nova.openstack.common.rpc.impl_qpid
Probably needs to be addressed by canonical folks. Our git repo does have kombu: https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L1493 ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1237574 Title: rpc_backend defaults to nova.openstack.common.rpc.impl_qpid Status in OpenStack Compute (Nova): Invalid Bug description: Installed h3 bits from canonical but in RPM packages and found that nova defaults to qpid instead of kombu. You need to explicitly add the following line to force nova services to use rabbitmq: rpc_backend=nova.openstack.common.rpc.impl_kombu The description however is otherwise: # The messaging module to use, defaults to kombu. (string # value) #rpc_backend=nova.openstack.common.rpc.impl_qpid To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1237574/+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 1231914] Re: Midonet plug, add dhcp opt121 route when a new subnet is created
Reviewed: https://review.openstack.org/50661 Committed: http://github.com/openstack/neutron/commit/a7a4833e00eb86f44146771e429973a64fb04d9e Submitter: Jenkins Branch:milestone-proposed commit a7a4833e00eb86f44146771e429973a64fb04d9e Author: Rossella Sblendido Date: Wed Sep 25 14:55:04 2013 + Add a route to reach the MD server when a subnet is created When the first subnet is created, the dhcp port is created and midonet plugin correctly adds the static route to reach the MD server in create_port. When a second or following subnets are created, a new ip is added to the dhcp port. This patch takes care of adding the static route to correcly reach the MD server in update_port. This fixes the problem of VMs not being able to reach the MD if assigned to the second subnet Closes-bug: #1231914 Change-Id: Ifc95f901d4222b76a4254e21295829ac8d82493b (cherry picked from commit 3568a9cac73a2da19e86d82f561be10ae9dbe9a0) ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1231914 Title: Midonet plug, add dhcp opt121 route when a new subnet is created Status in OpenStack Neutron (virtual network service): Fix Released Bug description: When a subnet is created (except the first one) another ip is added to the dhcp port. Midonet plugin should react and add the correct route opt121 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1231914/+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 1237061] Re: identity-api doc: OAUTH1 API for roles are wrong
Github's markdown rendering appears to be insufficient. Copied straight
from the markdown:
### Get authorized access token: `GET /users/{user_id}/OS-
OAUTH1/access_tokens/{access_token_id}`
### List roles of an access token: `GET /users/{user_id}/OS-
OAUTH1/access_tokens/{access_token_id}/roles`
### Get a role of an access token: `GET /users/{user_id}/OS-
OAUTH1/access_tokens/{access_token_id}/roles/{role_id}`
Source: https://raw.github.com/openstack/identity-api/master/openstack-
identity-api/v3/src/markdown/identity-api-v3-os-oauth1-ext.md
** 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/1237061
Title:
identity-api doc: OAUTH1 API for roles are wrong
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
Get authorized access token: GET
/users/{user_id}/OS-OAUTH1/access_tokens/{access_token_id}
List roles of an access token:GET
/users/{user_id}/OS-OAUTH1/access_tokens/{access_token_id}
Get a role of an access token: GET
/users/{user_id}/OS-OAUTH1/access_tokens/{access_token_id}
All of them lists the same API
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1237061/+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 1226829] Re: Password Change needs to logout current user
** Changed in: horizon Status: In Progress => Fix Released -- 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/1226829 Title: Password Change needs to logout current user Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Password Change needs to logout current user after change is applied To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1226829/+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 1237334] Re: nova-api & nova-metadata-api services are using the same port
I think that this is not a valid case.
Please check your nova.conf to see if metadata was configured in
enabled_apis.
The default value of enabled_apis is "enabled_apis =
osapi_compute,metadata", this means that metadata was enabled by
default, it will be started by nova-api.
If you remove metadata from enabled_apis, you will be able to start up
your metadata api.
Thanks.
** Changed in: nova
Assignee: (unassigned) => Jay Lau (jay-lau-513)
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1237334
Title:
nova-api & nova-metadata-api services are using the same port
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Description of problem:
The services nova-api and the nova-metadata-api are both using the same port,
8775.
Thus, the services are 'competing' for the port and one of them will not
work.
Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.5 Beta (Santiago)
python-novaclient-2.15.0-1.el6ost.noarch
python-nova-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-network-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-common-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-console-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-compute-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-conductor-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-novncproxy-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-scheduler-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-api-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-cert-2013.2-0.24.rc1.el6ost.noarch
How reproducible:
everytime
Steps to Reproduce:
1. Install Havana on RHEL 6.5 AIO installation.
2.
3.
Actual results:
Either the openstack-nova-api or the openstack-nova-metadata-api service is
down.
Expected results:
Both services are up and running.
Additional info:
The error from /var/log/nova/metadata-api.log:
2013-10-09 10:54:21.975 4776 INFO nova.network.driver [-] Loading network
driver 'nova.network.linux_net'
2013-10-09 10:54:22.036 4776 DEBUG nova.wsgi [-] Loading app metadata from
/etc/nova/api-paste.ini load_app
/usr/lib/python2.6/site-packages/nova/wsgi.py:484
2013-10-09 10:54:22.076 4776 INFO nova.openstack.common.periodic_task [-]
Skipping periodic task _periodic_update_dns because its interval is negative
2013-10-09 10:54:22.079 4776 CRITICAL nova [-] [Errno 98] Address already in
use
2013-10-09 10:54:22.079 4776 TRACE nova Traceback (most recent call last):
2013-10-09 10:54:22.079 4776 TRACE nova File "/usr/bin/nova-api-metadata",
line 10, in
2013-10-09 10:54:22.079 4776 TRACE nova sys.exit(main())
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/cmd/api_metadata.py", line 33, in main
2013-10-09 10:54:22.079 4776 TRACE nova server =
service.WSGIService('metadata')
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/service.py", line 318, in __init__
2013-10-09 10:54:22.079 4776 TRACE nova max_url_len=max_url_len)
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/wsgi.py", line 123, in __init__
2013-10-09 10:54:22.079 4776 TRACE nova self._socket =
eventlet.listen(bind_addr, family, backlog=backlog)
2013-10-09 10:54:22.079 4776 TRACE nova File
"/usr/lib/python2.6/site-packages/eventlet/convenience.py", line 38, in listen
2013-10-09 10:54:22.079 4776 TRACE nova sock.bind(addr)
2013-10-09 10:54:22.079 4776 TRACE nova File "", line 1, in bind
2013-10-09 10:54:22.079 4776 TRACE nova error: [Errno 98] Address already in
use
2013-10-09 10:54:22.079 4776 TRACE nova
The error from the nova-api log:
2013-10-09 11:17:04.520 6048 CRITICAL nova [-] [Errno 98] Address already in
use
2013-10-09 11:17:04.520 6048 TRACE nova Traceback (most recent call last):
2013-10-09 11:17:04.520 6048 TRACE nova File "/usr/bin/nova-api", line 10,
in
2013-10-09 11:17:04.520 6048 TRACE nova sys.exit(main())
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/cmd/api.py", line 51, in main
2013-10-09 11:17:04.520 6048 TRACE nova server = service.WSGIService(api,
use_ssl=should_use_ssl)
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/service.py", line 318, in __init__
2013-10-09 11:17:04.520 6048 TRACE nova max_url_len=max_url_len)
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/nova/wsgi.py", line 124, in __init__
2013-10-09 11:17:04.520 6048 TRACE nova self._socket =
eventlet.listen(bind_addr, family, backlog=backlog)
2013-10-09 11:17:04.520 6048 TRACE nova File
"/usr/lib/python2.6/site-packages/eventlet/convenience.py", line 38, in listen
2013-10-09 11:1
