[Yahoo-eng-team] [Bug 1337769] Re: Failure when creating a volume from an existing image and using it to boot an instance.
It seems to me this problem is solved with the new (as of Juno) config
parameters "block_device_allocate_retries" and
"block_device_allocate_retries_interval". See
http://docs.openstack.org/juno/config-reference/content/nova-conf-
changes-juno.html.
The code in nova/compute/manager.py (_await_block_device_mape_created())
still contains a small mistake - it outputs a warning about
"block_device_retries" instead of "block_device_allocate_retries".
---
If anybody still wants to reproduce the situation, use a large image in an http
store: "glance image-create --location ". This
ensures a long load time.
You should then find a message like this in the nova compute log:
"VolumeNotCreated: Volume 1cf1c991-6f61-4072-9e80-0161d6ee0574 did not finish
being created even after we waited 193 seconds or 61 attempts. And its status
is downloading."
** Changed in: nova
Status: Confirmed => 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/1337769
Title:
Failure when creating a volume from an existing image and using it to
boot an instance.
Status in OpenStack Compute (Nova):
Fix Released
Bug description:
Running CLI as below to create a volume from an existing image and
using it to boot an instance.
nova --debug boot --flavor m1.medium --block-device
source=image,id=8c7ae799-a61c-4015-86af-
ca8544691399,dest=volume,size=40,shutdown=remove,bootindex=0 --nic
net-id=861b4e6b-126d-4302-a2b2-58fd0bb72f03 my-testvm
This will fail now and then depends on the images size.
API trace from operation:
REQ: curl -i http://cic-pub-
api:38774/v2/ae132c7a5c0f49efa126c133039b28ab/os-volumes_boot -X POST
-H "X-Auth-Project-Id: ericsson" -H "User-Agent: python-novaclient" -H
"Content-Type: application/json" -H "Accept: application/json" -H "X
-Auth-Token: bcce2c7f828743859d9cf1134085a422" -d '{"server": {"name":
"for-anton", "imageRef": "", "block_device_mapping_v2":
[{"boot_index": "0", "uuid": "8c7ae799-a61c-4015-86af-ca8544691399",
"volume_size": "40", "source_type": "image", "destination_type":
"volume", "delete_on_termination": true}], "flavorRef": "3",
"max_count": 1, "min_count": 1, "networks": [{"uuid": "861b4e6b-
126d-4302-a2b2-58fd0bb72f03"}]}}'
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1337769/+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 1444108] Re: Upgrade of services from Juno to Kilo fails
[Expired for Keystone because there has been no activity for 60 days.] ** Changed in: keystone Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1444108 Title: Upgrade of services from Juno to Kilo fails Status in OpenStack Identity (Keystone): Expired Bug description: Steps to reproduce: 1. Install glance, cinder, nova and keystone services on Stable/Juno branch. 2. Update the branch to master, do 'sudo python setup.py install’ on all the services and do a db sync on all the services. 3. Restart all the services. 4. The nova and cinder services restart properly. In fact, I am able to do all sanity testing operations. Keystone though intermittently stops working. And doing cinder-list or nova-list gives either http://paste.openstack.org/show/yR4bFyzry9Lrhfp6nPWg/ or gives the listing of the volumes and instances on the host. 5. What I concluded was that Upgrading from Juno to Kilo has not been documented anywhere yet. I think I might be missing some secret sauce for keystone to start working correctly and stop giving intermittent errors. So, is there an official documentation like the one that exists for Icehouse to Kilo upgrade (http://docs.openstack.org/openstack-ops/content/upgrade-icehouse-juno.html) ? If not, then am I missing something in /etc/keystone/keystone.conf ? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1444108/+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 1465616] Re: Documentation is contradictory on whether GET /v2/images/{image_id}/file has a response body
** Changed in: glance
Status: New => Confirmed
** Project changed: glance => openstack-api-site
** Changed in: openstack-api-site
Assignee: (unassigned) => wangxiyuan (wangxiyuan)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1465616
Title:
Documentation is contradictory on whether GET
/v2/images/{image_id}/file has a response body
Status in OpenStack API documentation site:
Confirmed
Bug description:
See http://developer.openstack.org/api-ref-
image-v2.html#getImageFile-v2
This section first says: "The response body contains the raw binary
data that represents the actual virtual disk."
It then later says: "This operation does not accept a request body and
does not return a response body."
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-api-site/+bug/1465616/+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 1469942] [NEW] Error message of quota exceeded don't contain enough information
Public bug reported: 1. base version stack@devstack:/opt/stack/nova$ [master]$ git log -1 commit 6969f270c5035325c603ce7a98b1647b72bf5eaa Merge: ae4ae93 930da44 Author: Jenkins Date: Sat Jun 27 08:40:25 2015 + Merge "Fix typos detected by toolkit misspellings." 2. nova-api.log 2015-06-30 10:55:26.637 DEBUG nova.compute.api [req-2bba2e1b-da00-477a-94e8-01eee8e17401 admin demo] cores,ram quota exceeded for 08751f5a95464f5db73d9f57d55fa6b9, tried to run 1 instances. Cannot run any mo re instances of this type. _check_num_instances_quota /opt/stack/nova/nova/compute/api.py:442 2015-06-30 10:55:26.638 INFO nova.api.openstack.wsgi [req-2bba2e1b-da00-477a-94e8-01eee8e17401 admin demo] HTTP exception thrown: Quota exceeded for cores,ram: Requested 1, but already used 1 of 1 cores 3. reproduce steps: * set the tenant qouta, core=1, ram=512 * boot instance with flavor m1.tiny (1 core, 512 ram) * boot instance again with flavor m1.tiny Expected result: * booting instance failed in the second time, and user should know which resource is limited, core and ram. Actual result: * the raised exception message only contain core limit details, but no ram details. stack@devstack:/home/devstack/logs$ [master]$ nova boot --image cirros-0.3.2-x86_64-disk --flavor m1.tiny --nic net-id=00d3142f-f2d1-4427-a0d3-d31c089f3c7e chenrui_demo ERROR (Forbidden): Quota exceeded for cores,ram: Requested 1, but already used 1 of 1 cores (HTTP 403) (Request-ID: req-2bba2e1b-da00-477a-94e8-01eee8e17401) As a End user, he should get the full information from the exception message, he don't know the ram limit detail, so he has no idea which flavor can be used to boot instance successfully. ** Affects: nova Importance: Undecided Assignee: Rui Chen (kiwik-chenrui) Status: New ** Changed in: nova Assignee: (unassigned) => Rui Chen (kiwik-chenrui) -- 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/1469942 Title: Error message of quota exceeded don't contain enough information Status in OpenStack Compute (Nova): New Bug description: 1. base version stack@devstack:/opt/stack/nova$ [master]$ git log -1 commit 6969f270c5035325c603ce7a98b1647b72bf5eaa Merge: ae4ae93 930da44 Author: Jenkins Date: Sat Jun 27 08:40:25 2015 + Merge "Fix typos detected by toolkit misspellings." 2. nova-api.log 2015-06-30 10:55:26.637 DEBUG nova.compute.api [req-2bba2e1b-da00-477a-94e8-01eee8e17401 admin demo] cores,ram quota exceeded for 08751f5a95464f5db73d9f57d55fa6b9, tried to run 1 instances. Cannot run any mo re instances of this type. _check_num_instances_quota /opt/stack/nova/nova/compute/api.py:442 2015-06-30 10:55:26.638 INFO nova.api.openstack.wsgi [req-2bba2e1b-da00-477a-94e8-01eee8e17401 admin demo] HTTP exception thrown: Quota exceeded for cores,ram: Requested 1, but already used 1 of 1 cores 3. reproduce steps: * set the tenant qouta, core=1, ram=512 * boot instance with flavor m1.tiny (1 core, 512 ram) * boot instance again with flavor m1.tiny Expected result: * booting instance failed in the second time, and user should know which resource is limited, core and ram. Actual result: * the raised exception message only contain core limit details, but no ram details. stack@devstack:/home/devstack/logs$ [master]$ nova boot --image cirros-0.3.2-x86_64-disk --flavor m1.tiny --nic net-id=00d3142f-f2d1-4427-a0d3-d31c089f3c7e chenrui_demo ERROR (Forbidden): Quota exceeded for cores,ram: Requested 1, but already used 1 of 1 cores (HTTP 403) (Request-ID: req-2bba2e1b-da00-477a-94e8-01eee8e17401) As a End user, he should get the full information from the exception message, he don't know the ram limit detail, so he has no idea which flavor can be used to boot instance successfully. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1469942/+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 1467781] Re: Stack resources not work in horizon
** Also affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1467781 Title: Stack resources not work in horizon Status in OpenStack Dashboard (Horizon): New Status in Python client library for heat: New Bug description: Steps to reproduce the problem: 1. files list # filename: f.yaml heat_template_version: 2013-05-23 resources: s: type: s.yaml # filename: s.yaml heat_template_version: 2013-05-23 2. Put above two files in a http server, use horizon to create stack Beside the tempalte-validate error, horizon will say `s.yaml' not found so can not create stack. While below command works: heat stack-create -u http://.../f.yaml f The same situation for get file found in horizon Yes, the bug can be fixed in horizon side but if we can fix it in heat client side it will benefit all the application based on heat. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1467781/+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 1466900] Re: get_base_properties in v2/images.py missing 'shared' image visibility
'shared' is a valid value for the visibility *filter*, but it is not a
value that's used to populate the 'visibility' field of any image. It
will be fixed by this blueprint
https://blueprints.launchpad.net/glance/+spec/community-level-v2-image-
sharing
** Changed in: glance
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1466900
Title:
get_base_properties in v2/images.py missing 'shared' image visibility
Status in OpenStack Image Registry and Delivery Service (Glance):
Invalid
Bug description:
https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L830
'visibility': {
'type': 'string',
'description': _('Scope of image accessibility'),
'enum': ['public', 'private'],
},
Should include 'shared' in the list of visibility options
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1466900/+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 1469883] [NEW] Unit tests fail with Routes==2.1
Public bug reported: Don't know yet why we are not seeing this in CI as Routes has been out since Jan. our g-r does exclude 2.0, but not 2.1 dims@dims-mac:~/openstack/openstack/nova$ . .tox/py27/bin/activate (py27)dims@dims-mac:~/openstack/openstack/nova$ pip freeze | grep Route Routes==1.13 (py27)dims@dims-mac:~/openstack/openstack/nova$ python Python 2.7.9 (default, Feb 10 2015, 03:28:08) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from nova.api.ec2 import apirequest >>> (py27)dims@dims-mac:~/openstack/openstack/nova$ pip install -U Routes==2.1 Collecting Routes==2.1 Requirement already up-to-date: repoze.lru>=0.3 in ./.tox/py27/lib/python2.7/site-packages (from Routes==2.1) Installing collected packages: Routes Found existing installation: Routes 1.13 Uninstalling Routes-1.13: Successfully uninstalled Routes-1.13 Successfully installed Routes-2.1 (py27)dims@dims-mac:~/openstack/openstack/nova$ python Python 2.7.9 (default, Feb 10 2015, 03:28:08) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from nova.api.ec2 import apirequest Traceback (most recent call last): File "", line 1, in File "nova/api/ec2/__init__.py", line 47, in from nova import wsgi File "nova/wsgi.py", line 34, in import routes.middleware File "/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/routes/__init__.py", line 145, in from routes.mapper import Mapper File "/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/routes/mapper.py", line 8, in from routes.util import ( File "/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/routes/util.py", line 10, in import urllib.request, urllib.parse, urllib.error ImportError: No module named request >>> ** 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/1469883 Title: Unit tests fail with Routes==2.1 Status in OpenStack Compute (Nova): New Bug description: Don't know yet why we are not seeing this in CI as Routes has been out since Jan. our g-r does exclude 2.0, but not 2.1 dims@dims-mac:~/openstack/openstack/nova$ . .tox/py27/bin/activate (py27)dims@dims-mac:~/openstack/openstack/nova$ pip freeze | grep Route Routes==1.13 (py27)dims@dims-mac:~/openstack/openstack/nova$ python Python 2.7.9 (default, Feb 10 2015, 03:28:08) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from nova.api.ec2 import apirequest >>> (py27)dims@dims-mac:~/openstack/openstack/nova$ pip install -U Routes==2.1 Collecting Routes==2.1 Requirement already up-to-date: repoze.lru>=0.3 in ./.tox/py27/lib/python2.7/site-packages (from Routes==2.1) Installing collected packages: Routes Found existing installation: Routes 1.13 Uninstalling Routes-1.13: Successfully uninstalled Routes-1.13 Successfully installed Routes-2.1 (py27)dims@dims-mac:~/openstack/openstack/nova$ python Python 2.7.9 (default, Feb 10 2015, 03:28:08) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from nova.api.ec2 import apirequest Traceback (most recent call last): File "", line 1, in File "nova/api/ec2/__init__.py", line 47, in from nova import wsgi File "nova/wsgi.py", line 34, in import routes.middleware File "/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/routes/__init__.py", line 145, in from routes.mapper import Mapper File "/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/routes/mapper.py", line 8, in from routes.util import ( File "/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/routes/util.py", line 10, in import urllib.request, urllib.parse, urllib.error ImportError: No module named request >>> To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1469883/+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 1469867] Re: Stop using deprecated oslo_utils.timeutils.strtime
** Also affects: keystonemiddleware Importance: Undecided Status: New ** Changed in: keystonemiddleware Assignee: (unassigned) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1469867 Title: Stop using deprecated oslo_utils.timeutils.strtime Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Identity (Keystone) Middleware: New Status in Python client library for Keystone: In Progress Bug description: Keystone unit tests are failing because they're still using the deprecated oslo_utils.timeutils.strtime function. We need to stop using the function. DeprecationWarning: Using function/method 'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and will be removed in a future version: use either datetime.datetime.isoformat() or datetime.datetime.strftime() instead To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1469867/+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 1469867] Re: Stop using deprecated oslo_utils.timeutils.strtime
** Also affects: python-keystoneclient Importance: Undecided Status: New ** Changed in: python-keystoneclient Assignee: (unassigned) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1469867 Title: Stop using deprecated oslo_utils.timeutils.strtime Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: Keystone unit tests are failing because they're still using the deprecated oslo_utils.timeutils.strtime function. We need to stop using the function. DeprecationWarning: Using function/method 'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and will be removed in a future version: use either datetime.datetime.isoformat() or datetime.datetime.strftime() instead To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1469867/+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 1469871] [NEW] OVS Neutron Agent support for ovs+dpdk netdev datapath
Public bug reported:
The OVS Neuton Agent currently supports managing 2 datapaths.
the linux kernel data path and the newly added openvswitch windows datapath.
Based on feedback from the summit this whishlist bug has been created in
place of a blueprint to capture the changes required to enable the ovs
l2 agent to managed the userspace netdev datapath.
2 new config should be added to allow configuation of ovs and the ovs l2
agent.
cfg.StrOpt('ovs_datapath', default='system', choices=['system','netdev'],
help=_("ovs datapath to use.")),
and
cfg.StrOpt('agent_type', default=q_const.AGENT_TYPE_OVS,
choices=[q_const.AGENT_TYPE_OVS,
q_const.AGENT_TYPE_OVS_DPDK],
help=_("Selects the Agent Type
reported"))
the ovs_datapath config option will provided a mechanism at deploy time to
select which datapath to enable.
the 'system'(kernel) datapath will be enabled by default as it is today. the
netdev(userspace) datapath option will enabled the ovs agent to configure and
manage the netdev data path. this config option will be added to the ovs
section of the ml2_conf.ini
the agent_type config option will provided a mechanism to enable coexistence of
dpdk enabled ovs nodes and vanilla ovs nodes.
by allowing a configurable agent_type both the standard openvswitch ml2
mechanism driver and the ovsdpdk mechanism driver can be used. by default the
agent_type reported will be unchanged 'Open vSwitch agent'. during deployment
an operator can chose to spcify an agent_type of 'DPDK OVS Agent' if they have
deployed a dpdk enabled.
these are the only changes required to extent the ovs agent to suport
the netdev datapath.
documentation and unit tests will be provided to cover these changes.
a new job can be added to the intel-networking-ci to continue to validate this
configuration if additional 3rd party
testing is desired.
** Affects: neutron
Importance: Undecided
Assignee: sean mooney (sean-k-mooney)
Status: New
** Changed in: neutron
Assignee: (unassigned) => sean mooney (sean-k-mooney)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1469871
Title:
OVS Neutron Agent support for ovs+dpdk netdev datapath
Status in OpenStack Neutron (virtual network service):
New
Bug description:
The OVS Neuton Agent currently supports managing 2 datapaths.
the linux kernel data path and the newly added openvswitch windows datapath.
Based on feedback from the summit this whishlist bug has been created
in place of a blueprint to capture the changes required to enable
the ovs l2 agent to managed the userspace netdev datapath.
2 new config should be added to allow configuation of ovs and the ovs
l2 agent.
cfg.StrOpt('ovs_datapath', default='system', choices=['system','netdev'],
help=_("ovs datapath to use.")),
and
cfg.StrOpt('agent_type', default=q_const.AGENT_TYPE_OVS,
choices=[q_const.AGENT_TYPE_OVS,
q_const.AGENT_TYPE_OVS_DPDK],
help=_("Selects the Agent Type
reported"))
the ovs_datapath config option will provided a mechanism at deploy time to
select which datapath to enable.
the 'system'(kernel) datapath will be enabled by default as it is today. the
netdev(userspace) datapath option will enabled the ovs agent to configure and
manage the netdev data path. this config option will be added to the ovs
section of the ml2_conf.ini
the agent_type config option will provided a mechanism to enable coexistence
of dpdk enabled ovs nodes and vanilla ovs nodes.
by allowing a configurable agent_type both the standard openvswitch ml2
mechanism driver and the ovsdpdk mechanism driver can be used. by default the
agent_type reported will be unchanged 'Open vSwitch agent'. during deployment
an operator can chose to spcify an agent_type of 'DPDK OVS Agent' if they have
deployed a dpdk enabled.
these are the only changes required to extent the ovs agent to suport
the netdev datapath.
documentation and unit tests will be provided to cover these changes.
a new job can be added to the intel-networking-ci to continue to validate
this configuration if additional 3rd party
testing is desired.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1469871/+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 1469869] [NEW] Metadata defintions in etc/metadefs are not included in Python packages
Public bug reported: The files in etc/metadefs in the Glance repository are not included in either the tarball or wheel when one runs python setup.py sdist bdist_wheel These should be included by default and installed so they can be used. Since wheels should not be allowed to write to paths outside of the directory the package is installed in, glance-manage db_load_metadefs Should also look in the installed directory path for etc/metadefs when loading them. This is a problem in every version of Glance that was meant to include those metadata definitions. Since this does not prevent functionality from working (since a user could download the files to /etc/metadefs and run the command), I do not think this has backport potential. ** Affects: glance Importance: Undecided Status: New ** Tags: metadef ** Description changed: The files in etc/metadefs in the Glance repository are not included in either the tarball or wheel when one runs - python setup.py sdist bdist_wheel + python setup.py sdist bdist_wheel These should be included by default and installed so they can be used. Since wheels should not be allowed to write to paths outside of the directory the package is installed in, - glance-manage db_load_metadefs + glance-manage db_load_metadefs Should also look in the installed directory path for etc/metadefs when loading them. + + This is a problem in every version of Glance that was meant to include + those metadata definitions. Since this does not prevent functionality + from working (since a user could download the files to /etc/metadefs and + run the command), I do not think this has backport potential. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1469869 Title: Metadata defintions in etc/metadefs are not included in Python packages Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: The files in etc/metadefs in the Glance repository are not included in either the tarball or wheel when one runs python setup.py sdist bdist_wheel These should be included by default and installed so they can be used. Since wheels should not be allowed to write to paths outside of the directory the package is installed in, glance-manage db_load_metadefs Should also look in the installed directory path for etc/metadefs when loading them. This is a problem in every version of Glance that was meant to include those metadata definitions. Since this does not prevent functionality from working (since a user could download the files to /etc/metadefs and run the command), I do not think this has backport potential. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1469869/+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 1469865] [NEW] oslo.versionedobjects breaks nova/cinder tests
Public bug reported: Version 0.5.0 cut today broke Nova: http://logs.openstack.org/40/193240/3/check/gate-nova- python27/98212cb/testr_results.html.gz ** Affects: cinder Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Affects: oslo.versionedobjects Importance: High Status: Confirmed ** Also affects: nova Importance: Undecided Status: New ** Also affects: cinder Importance: Undecided Status: New ** Summary changed: - oslo.versionedobjects breaks nova tests + oslo.versionedobjects breaks nova/cinder tests -- 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/1469865 Title: oslo.versionedobjects breaks nova/cinder tests Status in Cinder: New Status in OpenStack Compute (Nova): New Status in Oslo Versioned Objects: Confirmed Bug description: Version 0.5.0 cut today broke Nova: http://logs.openstack.org/40/193240/3/check/gate-nova- python27/98212cb/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1469865/+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 1469867] [NEW] Stop using deprecated oslo_utils.timeutils.strtime
Public bug reported: Keystone unit tests are failing because they're still using the deprecated oslo_utils.timeutils.strtime function. We need to stop using the function. DeprecationWarning: Using function/method 'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and will be removed in a future version: use either datetime.datetime.isoformat() or datetime.datetime.strftime() instead ** Affects: keystone Importance: Undecided Assignee: Brant Knudson (blk-u) Status: New ** Changed in: keystone Assignee: (unassigned) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1469867 Title: Stop using deprecated oslo_utils.timeutils.strtime Status in OpenStack Identity (Keystone): New Bug description: Keystone unit tests are failing because they're still using the deprecated oslo_utils.timeutils.strtime function. We need to stop using the function. DeprecationWarning: Using function/method 'oslo_utils.timeutils.strtime()' is deprecated in version '1.6' and will be removed in a future version: use either datetime.datetime.isoformat() or datetime.datetime.strftime() instead To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1469867/+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 1467791] Re: Specific ipv4 subnet to create port and return port contains ipv4 and ipv6 address
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1467791
Title:
Specific ipv4 subnet to create port and return port contains ipv4 and
ipv6 address
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
neutron --version
2.6.0
When a network named 'A' contains a ipv4 subnet and a ipv6 subnet with
ipv6_address_mode and ipv6_ra_mode are 'slaac'/'dhcpv6-stateless'. I
specify the ipv4 subnet without ipv4 addr to create a port based on
this network 'A'. The returned port contains 2 addresses (both ipv4
and ipv6).
It just like:
| fixed_ips | {"subnet_id":
"990f3f53-ee5b-4a6f-b362-34fc339ab6e5", "ip_address": "10.0.0.5"}
| | {"subnet_id":
"59464306-6781-4d33-b10c-214f4ba30e6c", "ip_address": "fd00:dd95:d03f:0:f81
But the result which expected is just :
| fixed_ips | {"subnet_id":
"990f3f53-ee5b-4a6f-b362-34fc339ab6e5", "ip_address": "10.0.0.5"}
repo:
1.create a network
2.create a ipv4 subnet and a ipv6 subnet into this network.And specify
ipv6_address_mode and ipv6_ra_mode are 'slaac'/'dhcpv6-stateless'.
3.run the command
neutron port-create --fixed-ip subnet_id=$[ipv4_subnet_id]
$[network_id/name]
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1467791/+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 1469858] [NEW] Update contributing.rst for eslint
Public bug reported: In our contributing documentation (doc/source/contributing.rst) we discuss and give instructions for installing and setting up JSHint for development. This is not a bad thing, but with the switch in Horizon to use eslint instead of jscs and jshint in our tool chain (https://review.openstack.org/#/c/192327/) we should give instructions on how to setup and install eslint in your development environment instead to match what the gate is checking for. ** Affects: horizon Importance: Undecided Status: New ** Description changed: In our contributing documentation (doc/source/contributing.rst) we discuss and give instructions for installing and setting up JSHint for development. This is not a bad thing, but with the switch in Horizon to use eslint instead of jscs and jshint in our tool chain (https://review.openstack.org/#/c/192327/) we should give instructions - on how to setup and install eslint in you development environment + on how to setup and install eslint in your development environment instead to match what the gate is checking for. -- 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/1469858 Title: Update contributing.rst for eslint Status in OpenStack Dashboard (Horizon): New Bug description: In our contributing documentation (doc/source/contributing.rst) we discuss and give instructions for installing and setting up JSHint for development. This is not a bad thing, but with the switch in Horizon to use eslint instead of jscs and jshint in our tool chain (https://review.openstack.org/#/c/192327/) we should give instructions on how to setup and install eslint in your development environment instead to match what the gate is checking for. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1469858/+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 1469817] Re: Glance doesn't handle exceptions from glance_store
** Changed in: glance Importance: Undecided => High ** Changed in: glance Status: New => Confirmed ** Also affects: glance/kilo Importance: Undecided Status: New ** Also affects: glance/juno Importance: Undecided Status: New ** Also affects: glance/liberty Importance: High Status: Confirmed ** Changed in: glance/kilo Importance: Undecided => High ** Changed in: glance/juno Importance: Undecided => High ** Changed in: glance/kilo Status: New => Confirmed ** Changed in: glance/juno Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1469817 Title: Glance doesn't handle exceptions from glance_store Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Status in Glance juno series: Confirmed Status in Glance kilo series: Confirmed Status in Glance liberty series: Confirmed Bug description: Server API expects to catch exception declared at glance/common/exception.py, but actually risen exceptions have the same names but are declared at different module, glance_store/exceptions.py and thus are never caught. For example, If exception is raised here: https://github.com/openstack/glance_store/blob/stable/kilo/glance_store/_drivers/rbd.py#L316 , it will never be caught here https://github.com/openstack/glance/blob/stable/kilo/glance/api/v1/images.py#L1107 , because first one is instance of https://github.com/openstack/glance_store/blob/stable/kilo/glance_store/exceptions.py#L198 , but Glance waits for https://github.com/openstack/glance/blob/stable/kilo/glance/common/exception.py#L293 There are many cases of that issue. The investigation continues. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1469817/+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 1430681] Re: object value errors do not all indicate which field was involved
** Changed in: oslo.versionedobjects
Status: Fix Committed => Fix Released
** Changed in: oslo.versionedobjects
Milestone: None => 0.5.0
--
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/1430681
Title:
object value errors do not all indicate which field was involved
Status in OpenStack Compute (Nova):
Fix Released
Status in Oslo Versioned Objects:
Fix Released
Bug description:
When a value is assigned to an object field it is type checked in the
coerce() method for the field and a ValueError exception is raised if
it is not of the appropriate type. The name of the field involved in
the check is known in the coerce() method, but in most cases it is not
mentioned in the error message. When constructing an object with a
list of field values it is hard to know which one caused the error.
Adding the name of the field that generated the error would help.
For example, this test:
def test_my_dummy_test(self):
i = instance.Instance(uuid='my id', system_metadata='metadata')
This would this would result in a ValueError exception as follows:
Traceback (most recent call last):
File "/home/ptm/code/nova/nova/tests/unit/objects/test_instance.py", line
1514, in test_my_dummy_test
i = instance.Instance(uuid='my id', system_metadata='metadata')
File "/home/ptm/code/nova/nova/objects/instance.py", line 270, in __init__
super(Instance, self).__init__(*args, **kwargs)
File "/home/ptm/code/nova/nova/objects/base.py", line 282, in __init__
setattr(self, key, kwargs[key])
File "/home/ptm/code/nova/nova/objects/base.py", line 77, in setter
field_value = field.coerce(self, name, value)
File "/home/ptm/code/nova/nova/objects/fields.py", line 191, in coerce
return self._type.coerce(obj, attr, value)
File "/home/ptm/code/nova/nova/objects/fields.py", line 433, in coerce
raise ValueError(_('A dict is required in field %s') % attr)
ValueError: A dict is required here
This does not give any clue which of the two values supplied is
incorrect. Adding the field name to error message could give an error
like this:
ValueError: A dict is required in field system_metadata
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1430681/+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 1469817] [NEW] Glance doesn't handle exceptions from glance_store
Public bug reported: Server API expects to catch exception declared at glance/common/exception.py, but actually risen exceptions have the same names but are declared at different module, glance_store/exceptions.py and thus are never caught. For example, If exception is raised here: https://github.com/openstack/glance_store/blob/stable/kilo/glance_store/_drivers/rbd.py#L316 , it will never be caught here https://github.com/openstack/glance/blob/stable/kilo/glance/api/v1/images.py#L1107 , because first one is instance of https://github.com/openstack/glance_store/blob/stable/kilo/glance_store/exceptions.py#L198 , but Glance waits for https://github.com/openstack/glance/blob/stable/kilo/glance/common/exception.py#L293 There are many cases of that issue. The investigation continues. ** 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/1469817 Title: Glance doesn't handle exceptions from glance_store Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Server API expects to catch exception declared at glance/common/exception.py, but actually risen exceptions have the same names but are declared at different module, glance_store/exceptions.py and thus are never caught. For example, If exception is raised here: https://github.com/openstack/glance_store/blob/stable/kilo/glance_store/_drivers/rbd.py#L316 , it will never be caught here https://github.com/openstack/glance/blob/stable/kilo/glance/api/v1/images.py#L1107 , because first one is instance of https://github.com/openstack/glance_store/blob/stable/kilo/glance_store/exceptions.py#L198 , but Glance waits for https://github.com/openstack/glance/blob/stable/kilo/glance/common/exception.py#L293 There are many cases of that issue. The investigation continues. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1469817/+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 1468828] Re: HA router-create breaks ML2 drivers that implement create_network such as Arista
** Also affects: neutron/kilo Importance: Undecided Status: New ** Changed in: neutron/kilo Importance: Undecided => Medium ** Changed in: neutron/kilo Status: New => In Progress ** Changed in: neutron/kilo Assignee: (unassigned) => Sukhdev Kapur (sukhdev-8) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468828 Title: HA router-create breaks ML2 drivers that implement create_network such as Arista Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron kilo series: In Progress Bug description: This issue was discovered with Arista ML2 driver, when an HA router was created. However, this will impact any ML2 driver that implements create_network. When an admin creates HA router (neutron router-create --ha ), the HA framework invokes network_create() and sets tenant-id to '' (The empty string). network_create() ML2 mech driver API expects tenant-id to be set to a valid ID. Any ML2 driver, which relies on tenant-id, will fail/reject network_create() request, resulting in router-create to fail. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468828/+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 1395122] Re: ML2 Cisco Nexus MD: Fail Cfg VLAN when none exists
** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1395122 Title: ML2 Cisco Nexus MD: Fail Cfg VLAN when none exists Status in OpenStack Neutron (virtual network service): Fix Released Bug description: This is the fix due to a regression as a result of committing bug # 1330597. Bug #1330597 expected an error returned when the CLI 'switchport trunk allowed vlan add' is applied. It seems though that not all Nexus switches will return an error. The fix is to perform a 'get interface' to determine if 'switchport trunk allowed vlan' already exists. It it does, then use the 'add' keyword to 'switchport trunk allowed vlan' otherwise leave it out. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1395122/+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 1461728] Re: V2.0 API not calling defined external auth
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1461728
Title:
V2.0 API not calling defined external auth
Status in OpenStack Identity (Keystone):
Won't Fix
Status in OpenStack Security Advisories:
Won't Fix
Bug description:
When keystone.conf is defined with external auth , all V2.0 API calls
do not get intercepted by the defined external auth.
this is my keystone.conf
[auth]
methods=password,token,external
external=keystone.auth.plugins.idm_external.IDMDefaultDomain
V.20 CURL to initiate external auth.
curl -X POST -d '{"auth":{}}' -H "Content-type: application/json" -H
"REMOTE_USER: admin" http://localhost:5000/v2.0/tokens
What I'm seeing is the call gets to the keystone/token/controller.py,
where it checks for the auth{} and executes the external
authentication
if "token" in auth:
# Try to authenticate using a token
auth_info = self._authenticate_token(
context, auth)
else:
# Try external authentication
try:
auth_info = self._authenticate_external(
context, auth)
except ExternalAuthNotApplicable:
# Try local authentication
auth_info = self._authenticate_local(
context, auth)
...
def _authenticate_external(self, context, auth):
"""Try to authenticate an external user via REMOTE_USER variable.
Returns auth_token_data, (user_ref, tenant_ref, metadata_ref)
"""
if 'REMOTE_USER' not in context.get('environment', {}):
raise ExternalAuthNotApplicable()
#NOTE(jamielennox): xml and json differ and get confused about what
# empty auth should look like so just reset it.
if not auth:
auth = {}
username = context['environment']['REMOTE_USER']
try:
user_ref = self.identity_api.get_user_by_name(
username, CONF.identity.default_domain_id)
user_id = user_ref['id']
except exception.UserNotFound as e:
raise exception.Unauthorized(e)
metadata_ref = {}
tenant_id = self._get_project_id_from_auth(auth)
tenant_ref, metadata_ref['roles'] = self._get_project_roles_and_ref(
user_id, tenant_id)
expiry = core.default_expire_time()
bind = None
if ('kerberos' in CONF.token.bind and
context['environment'].
get('AUTH_TYPE', '').lower() == 'negotiate'):
bind = {'kerberos': username}
return (user_ref, tenant_ref, metadata_ref, expiry, bind)
The _authenticate_external should not assume and have its own
REMOTE_USER implementation, instead it should look for the external
method defined in keystone.conf and appropriately call the defined
external class.
The V3 call works fine and calls the right external class defined.
curl -X POST -d
'{"auth":{"identity":{"methods":["external"],"external":{' -H
"REMOTE_USER:admin" -H "Content-type: application/json"
http://localhost:5000/v3/auth/tokens
This is potentially a security hole as well, which will allow all V2
API's to get Keystone token w/o password.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1461728/+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 1469755] [NEW] Adding quota for subnet pools
Public bug reported: There is no quota option for subnet pools currently. Similar to the existing quota for subnets, it is necessary to have a quota for number of subnet pools as well. ** Affects: neutron Importance: Undecided Assignee: Mohammad Banikazemi (mb-s) Status: New ** Changed in: neutron Assignee: (unassigned) => Mohammad Banikazemi (mb-s) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1469755 Title: Adding quota for subnet pools Status in OpenStack Neutron (virtual network service): New Bug description: There is no quota option for subnet pools currently. Similar to the existing quota for subnets, it is necessary to have a quota for number of subnet pools as well. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1469755/+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 1469754] [NEW] tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes fails with SSHTimeout
Public bug reported:
http://logs.openstack.org/23/193223/3/check/check-tempest-dsvm-
nova-v21-full/5f73178/console.html.gz#_2015-06-26_23_49_24_797
2015-06-26 23:49:24.797 |
tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes[id-ab836c29-737b-4101-9fb9-87045eaf89e9]
2015-06-26 23:49:24.797 |
2015-06-26 23:49:24.797 |
2015-06-26 23:49:24.798 | Captured traceback:
2015-06-26 23:49:24.798 | ~~~
2015-06-26 23:49:24.798 | Traceback (most recent call last):
2015-06-26 23:49:24.798 | File
"tempest/thirdparty/boto/test_ec2_instance_run.py", line 338, in
test_compute_with_volumes
2015-06-26 23:49:24.798 | wait.state_wait(_part_state, 'INCREASE')
2015-06-26 23:49:24.798 | File "tempest/thirdparty/boto/utils/wait.py",
line 36, in state_wait
2015-06-26 23:49:24.798 | old_status = status = lfunction()
2015-06-26 23:49:24.799 | File
"tempest/thirdparty/boto/test_ec2_instance_run.py", line 330, in _part_state
2015-06-26 23:49:24.799 | current = ssh.get_partitions().split('\n')
2015-06-26 23:49:24.799 | File
"tempest/common/utils/linux/remote_client.py", line 82, in get_partitions
2015-06-26 23:49:24.799 | output = self.exec_command(command)
2015-06-26 23:49:24.799 | File
"tempest/common/utils/linux/remote_client.py", line 56, in exec_command
2015-06-26 23:49:24.799 | return self.ssh_client.exec_command(cmd)
2015-06-26 23:49:24.800 | File
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
line 111, in exec_command
2015-06-26 23:49:24.800 | ssh = self._get_ssh_connection()
2015-06-26 23:49:24.800 | File
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
line 87, in _get_ssh_connection
2015-06-26 23:49:24.800 | password=self.password)
2015-06-26 23:49:24.800 | tempest_lib.exceptions.SSHTimeout: Connection to
the 172.24.5.1 via SSH timed out.
2015-06-26 23:49:24.800 | User: cirros, Password: None
This is a job with nova-network and in tracing through the calls we
definitely need some more debug logging in this path to see that we have
security groups associated with the instance to refresh the sg rules.
nw_info and instance uuid for the instance:
2015-06-26 23:49:24.883 | === network info ===
2015-06-26 23:49:24.883 | if-info: lo,up,127.0.0.1,8,::1
2015-06-26 23:49:24.883 | if-info:
eth0,up,10.1.0.2,20,fe80::f816:3eff:fefd:78bd
2015-06-26 23:49:24.883 | ip-route:default via 10.1.0.1 dev eth0
2015-06-26 23:49:24.883 | ip-route:10.1.0.0/20 dev eth0 src 10.1.0.2
2015-06-26 23:49:24.883 | === datasource: configdrive local ===
2015-06-26 23:49:24.884 | instance-id: 7377fb75-089e-4a7f-aa13-42073ca4d981
2015-06-26 23:49:24.884 | name: Server 7377fb75-089e-4a7f-aa13-42073ca4d981
2015-06-26 23:49:24.884 | availability-zone: test_az-1643222956
2015-06-26 23:49:24.884 | local-hostname:
server-7377fb75-089e-4a7f-aa13-42073ca4d981.novalocal
2015-06-26 23:49:24.884 | launch-index: 0
We see that the fixed IP is associated with the instance here:
http://logs.openstack.org/23/193223/3/check/check-tempest-dsvm-
nova-v21-full/5f73178/logs/screen-n-net.txt.gz#_2015-06-26_23_41_39_500
The request ID is req-3b037057-5783-4160-a320-248eb4f2e724.
We see it refresh security groups and there are several messages about
skipping duplicate iptables rule additions:
2015-06-26 23:41:39.685 DEBUG nova.network.linux_net [req-
3b037057-5783-4160-a320-248eb4f2e724 InstanceRunTest-1951055199
InstanceRunTest-702105106] Skipping duplicate iptables rule addition.
[0:0] -A nova-network-snat -s 10.1.0.0/20 -d 0.0.0.0/0 -j SNAT --to-
source 10.0.4.130 -o br100 already in [[0:0] -A PREROUTING -j nova-
network-PREROUTING, [0:0] -A OUTPUT -j nova-network-OUTPUT, [0:0] -A
POSTROUTING -j nova-network-POSTROUTING, [0:0] -A POSTROUTING -j nova-
postrouting-bottom, [0:0] -A nova-postrouting-bottom -j nova-network-
snat, [0:0] -A nova-network-snat -j nova-network-float-snat, [0:0] -A
nova-network-PREROUTING -s 0.0.0.0/0 -d 169.254.169.254/32 -p tcp -m tcp
--dport 80 -j DNAT --to-destination 10.0.4.130:8775, [0:0] -A nova-
network-snat -s 10.1.0.0/20 -d 0.0.0.0/0 -j SNAT --to-source 10.0.4.130
-o br100, [0:0] -A nova-network-POSTROUTING -s 10.1.0.0/20 -d
10.0.4.130/32 -j ACCEPT, [0:0] -A nova-network-POSTROUTING -s
10.1.0.0/20 -d 10.1.0.0/20 -m conntrack ! --ctstate DNAT -j ACCEPT]
add_rule /opt/stack/new/nova/nova/network/linux_net.py:285
2015-06-26 23:41:39.685 DEBUG nova.network.linux_net [req-
3b037057-5783-4160-a320-248eb4f2e724 InstanceRunTest-1951055199
InstanceRunTest-702105106] Skipping apply due to lack of new rules apply
/opt/stack/new/nova/nova/network/linux_net.py:444
I'm sure this is probably a duplicate, maybe of
[Yahoo-eng-team] [Bug 1469749] [NEW] RamFilter logging partially considers ram-allocation-ratio
Public bug reported: Package: nova-scheduler Version: 1:2014.1.4-0ubuntu2.1 RamFilter accurately skips a host because RAM resource is not enough for requested VM. However, I think log should be more explicit on numbers, taking into account ram-allocation-ratio can be different from 1.0. Log excerpt: 2015-06-29 12:04:21.422 15708 DEBUG nova.scheduler.filters.ram_filter [req-d14d9f04-c2b1-42be-b5b9-669318bb0030 3cca8ee6898e42f287adbd4f5dac1801 a0ae7f82f577413ab0d73f3dc09fb906] (hostname, hostname.tld) ram:10148 disk:264192 io_ops:0 instances:39 does not have 2048 MB usable ram, it only has 480.4 MB usable ram. host_passes /usr/lib/python2.7/dist-packages/nova/scheduler/filters/ram_filter.py:60 On log above, RAM says 10148 (MB), which seems enough for a 2048MB VM. First number (10148) is calculated as: TotalMB - UsedMB. Additional (real) number should be: TotalMB * RamAllocRatio - UsedMB. In this case, ram-allocatioin-ratio is 0.9, which results in 480.4MB. Please let me know if you'd need more details. Cheers, -Alvaro. ** Affects: nova Importance: Undecided Status: New ** Tags: canonical-bootstack -- 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/1469749 Title: RamFilter logging partially considers ram-allocation-ratio Status in OpenStack Compute (Nova): New Bug description: Package: nova-scheduler Version: 1:2014.1.4-0ubuntu2.1 RamFilter accurately skips a host because RAM resource is not enough for requested VM. However, I think log should be more explicit on numbers, taking into account ram-allocation-ratio can be different from 1.0. Log excerpt: 2015-06-29 12:04:21.422 15708 DEBUG nova.scheduler.filters.ram_filter [req-d14d9f04-c2b1-42be-b5b9-669318bb0030 3cca8ee6898e42f287adbd4f5dac1801 a0ae7f82f577413ab0d73f3dc09fb906] (hostname, hostname.tld) ram:10148 disk:264192 io_ops:0 instances:39 does not have 2048 MB usable ram, it only has 480.4 MB usable ram. host_passes /usr/lib/python2.7/dist-packages/nova/scheduler/filters/ram_filter.py:60 On log above, RAM says 10148 (MB), which seems enough for a 2048MB VM. First number (10148) is calculated as: TotalMB - UsedMB. Additional (real) number should be: TotalMB * RamAllocRatio - UsedMB. In this case, ram-allocatioin-ratio is 0.9, which results in 480.4MB. Please let me know if you'd need more details. Cheers, -Alvaro. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1469749/+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 1468395] Re: Versions of oslo.i18n higher than 1.17.0 cause ImportError
** Also affects: django-openstack-auth Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1468395 Title: Versions of oslo.i18n higher than 1.17.0 cause ImportError Status in Django OpenStack Auth: New Status in OpenStack Dashboard (Horizon): Incomplete Status in Oslo Internationalization Library: Invalid Status in Python client library for Keystone: Confirmed Bug description: oslo.i18n version 2.0.0 was release <24h ago, and it breaks Horizon. If I pin the version of oslo.i18n to <2.0.0, it works. Here's the trace from tests script: ➜ ~ git clone g...@github.com:openstack/horizon.git Cloning into 'horizon'... remote: Counting objects: 97245, done. remote: Compressing objects: 100% (9/9), done. remote: Total 97245 (delta 3), reused 0 (delta 0), pack-reused 97236 Receiving objects: 100% (97245/97245), 147.90 MiB | 4.73 MiB/s, done. Resolving deltas: 100% (62610/62610), done. Checking connectivity... done. ➜ ~ cd horizon ➜ horizon git:(master) git checkout -t origin/stable/juno Branch stable/juno set up to track remote branch stable/juno from origin. Switched to a new branch 'stable/juno' ➜ horizon git:(stable/juno) ./run_tests.sh Checking environment. Environment not found. Install? (Y/n) Y Fetching new src packages... Creating venv... done. Installing dependencies with pip (this can take a while)... You are using pip version 7.0.1, however version 7.0.3 is available. You should consider upgrading via the 'pip install --upgrade pip' command. DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting pip>=1.4 Using cached pip-7.0.3-py2.py3-none-any.whl Installing collected packages: pip Found existing installation: pip 7.0.1 Uninstalling pip-7.0.1: Successfully uninstalled pip-7.0.1 Successfully installed pip-7.0.3 DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting setuptools Using cached setuptools-18.0-py2.py3-none-any.whl Installing collected packages: setuptools Found existing installation: setuptools 16.0 Uninstalling setuptools-16.0: Successfully uninstalled setuptools-16.0 Successfully installed setuptools-18.0 DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting pbr Using cached pbr-1.2.0-py2.py3-none-any.whl Installing collected packages: pbr Successfully installed pbr-1.2.0 DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting pbr!=0.7,<1.0,>=0.6 (from -r /home/javier/horizon/requirements.txt (line 1)) Using cached pbr-0.11.0-py2.py3-none-any.whl Collecting Django<1.7,>=1.4.2 (from -r /home/javier/horizon/requirements.txt (line 2)) Using cached Django-1.6.11-py2.py3-none-any.whl Collecting django-compressor<=1.4,>=1.4 (from -r /home/javier/horizon/requirements.txt (line 3)) Using cached django_compressor-1.4-py2.py3-none-any.whl Collecting django-openstack-auth!=1.1.8,<=1.1.9,>=1.1.7 (from -r /home/javier/horizon/requirements.txt (line 4)) Using cached django_openstack_auth-1.1.9-py2-none-any.whl Collecting django-pyscss<=1.0.6,>=1.0.3 (from -r /home/javier/horizon/requirements.txt (line 5)) Collecting eventlet<=0.15.2,>=0.15.1 (from -r /home/javier/horizon/requirements.txt (line 6)) Using cached eventlet-0.15.2-py2.py3-none-any.whl Collecting httplib2<=0.9,>=0.7.5 (from -r /home/javier/horizon/requirements.txt (line 7)) Collecting iso8601<=0.1.10,>=0.1.9 (from -r /home/javier/horizon/requirements.txt (line 8)) Collecting kombu<=3.0.7,>=2.5.0 (from -r /home/javier/horizon/requirements.txt (line 9)) Collecting lockfile<=0.8,>=0.8 (from -r /home/javier/horizon/requirements.txt (line 10)) Collecting netaddr<=0.7.13,>=0.7.12 (from -r /home/javier/horizon/requirements.txt (line 11)) Using cached netaddr-0.7.13-py2.py3-none-any.whl Collecting pyScss<1.3,>=1.2.1 (from -r /home/javier/horizon/requirements.txt (line 12)) Collecting python-ceilometerclient<1.0.13,>=1.0.6 (from -r /home/javier/horizon/requirements.txt (line 13)) Using cached python_ceilometerclient-1.0.12-py2.py3-none-any.whl Collecting python-cinderclient<=1.1.1,>=1.1.0 (from -r /home/javier/horizon/requirements.txt (line 14)) Using cached python_cinderclient-1.1.1-py2.py3-none-any.whl Collecting python-glanceclient<=0.15.0,>=0.14.0 (from -r /home/javier/horizon/requirements.txt (line 15)) Using cached python_glanceclient-0.15.0-py2.py3-none-any.whl Collecting python-heatclie
[Yahoo-eng-team] [Bug 1469738] [NEW] The operation of create image has failed with not enough free quota storage although sufficient space was available
Public bug reported: Description of problem: Creating an image has failed with error message:"Denying attempt to upload image because it exceeds the quota", although there was enough space for upload the image Version-Release number of selected component (if applicable): python-glanceclient-0.17.0-2.el7ost.noarch python-glance-2015.1.0-6.el7ost.noarch python-glance-store-0.4.0-1.el7ost.noarch openstack-glance-2015.1.0-6.el7ost.noarch How reproducible: 100% Steps to Reproduce: With only cirros image(size=12.6MB) run those steps 1. Edit /etc/glance/glance-api.conf set user_storage_quota =1536000 2. openstack-service restart glance 3. Try to upload an image less than 1536000MB Actual results: Failed with 'Denying attempt to upload image because it exceeds the quota' Expected results: Creating an image should succeed Additional info: It is similar to bug id=1043929 Glance logs ** Affects: glance Importance: Undecided Status: New ** Attachment added: "Glance image" https://bugs.launchpad.net/bugs/1469738/+attachment/4421963/+files/glance_logs.tar.gz -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1469738 Title: The operation of create image has failed with not enough free quota storage although sufficient space was available Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Description of problem: Creating an image has failed with error message:"Denying attempt to upload image because it exceeds the quota", although there was enough space for upload the image Version-Release number of selected component (if applicable): python-glanceclient-0.17.0-2.el7ost.noarch python-glance-2015.1.0-6.el7ost.noarch python-glance-store-0.4.0-1.el7ost.noarch openstack-glance-2015.1.0-6.el7ost.noarch How reproducible: 100% Steps to Reproduce: With only cirros image(size=12.6MB) run those steps 1. Edit /etc/glance/glance-api.conf set user_storage_quota =1536000 2. openstack-service restart glance 3. Try to upload an image less than 1536000MB Actual results: Failed with 'Denying attempt to upload image because it exceeds the quota' Expected results: Creating an image should succeed Additional info: It is similar to bug id=1043929 Glance logs To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1469738/+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 1469734] [NEW] neutron.tests.functional.test_tools.TestSafeFixture.test_error_after_root_setup fails due to new fixture 1.3.0 release
Public bug reported:
Today, June 29th was fixtures 1.3.0 released that introduced commit
https://github.com/testing-
cabal/fixtures/commit/354acf568aa86bb7d43a01c23d73c750f601b335 that
causes our new SafeFixture to fail test from Summary.
ft1.158:
neutron.tests.functional.test_tools.TestSafeFixture.test_error_after_root_setup(testtools
useFixture)_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
stderr
stdout
traceback-1: {{{
Traceback (most recent call last):
File "neutron/tests/functional/test_tools.py", line 73, in
test_error_after_root_setup
self.assertRaises(ValueError, self.parent.useFixture, fixture)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 422, in assertRaises
self.assertThat(our_callable, matcher)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 433, in assertThat
mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 483, in _matchHelper
mismatch = matcher.match(matchee)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/matchers/_exception.py",
line 108, in match
mismatch = self.exception_matcher.match(exc_info)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/matchers/_higherorder.py",
line 62, in match
mismatch = matcher.match(matchee)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 414, in match
reraise(*matchee)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/matchers/_exception.py",
line 101, in match
result = matchee()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 969, in __call__
return self._callable_object(*self._args, **self._kwargs)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 670, in useFixture
gather_details(fixture.getDetails(), self.getDetails())
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/fixtures/fixture.py",
line 169, in getDetails
result = dict(self._details)
TypeError: 'NoneType' object is not iterable
}}}
Traceback (most recent call last):
File "neutron/tests/tools.py", line 33, in
self.setUp = lambda: self.safe_setUp(unsafe_setup)
File "neutron/tests/tools.py", line 46, in safe_setUp
self.safe_cleanUp()
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 119, in __exit__
six.reraise(self.type_, self.value, self.tb)
File "neutron/tests/tools.py", line 43, in safe_setUp
unsafe_setup()
File "neutron/tests/functional/test_tools.py", line 43, in setUp
raise ValueError
ValueError
** 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/1469734
Title:
neutron.tests.functional.test_tools.TestSafeFixture.test_error_after_root_setup
fails due to new fixture 1.3.0 release
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Today, June 29th was fixtures 1.3.0 released that introduced commit
https://github.com/testing-
cabal/fixtures/commit/354acf568aa86bb7d43a01c23d73c750f601b335 that
causes our new SafeFixture to fail test from Summary.
ft1.158:
neutron.tests.functional.test_tools.TestSafeFixture.test_error_after_root_setup(testtools
useFixture)_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
stderr
stdout
traceback-1: {{{
Traceback (most recent call last):
File "neutron/tests/functional/test_tools.py", line 73, in
test_error_after_root_setup
self.assertRaises(ValueError, self.parent.useFixture, fixture)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 422, in assertRaises
self.assertThat(our_callable, matcher)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 433, in assertThat
mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/testcase.py",
line 483, in _matchHelper
mismatch = matcher.match(matchee)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/testtools/matchers/_exception.py",
line 108, in match
mismatch = self.e
[Yahoo-eng-team] [Bug 1468698] Re: Image-update api returns 500 while passing --min-ram and --min-disk greater than 2^(31) max value
** This bug is no longer a duplicate of bug 1460060 Glance v1 and v2 api returns 500 while passing --min-ram and --min-disk greater than 2^(31) max value ** Changed in: glance Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1468698 Title: Image-update api returns 500 while passing --min-ram and --min-disk greater than 2^(31) max value Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Bug description: $ glance image-update b3886698-04c3-4621-9a04-4a587d3288d1 --min-ram 234578 HTTPInternalServerError (HTTP 500) $ glance image-update b3886698-04c3-4621-9a04-4a587d3288d1 --min-disk 234578 HTTPInternalServerError (HTTP 500) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1468698/+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 1464461] Re: delete action always cause error ( in kilo)
Can someone provide a justification explaining why this bug was switched to a suspected security vulnerability report? What is the exploit scenario and associated risk? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- 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/1464461 Title: delete action always cause error ( in kilo) Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Security Advisories: Incomplete Bug description: When i did any delete actions (delete router, delete network etc...) in japanese environment , always get a error page. horizon error logs: - Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 36, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 52, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 36, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 84, in dec return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 89, in dispatch return handler(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 223, in post return self.get(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 159, in get handled = self.construct_tables() File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 150, in construct_tables handled = self.handle_table(table) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py", line 125, in handle_table handled = self._tables[name].maybe_handle() File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 1640, in maybe_handle return self.take_action(action_name, obj_id) File "/usr/lib/python2.7/site-packages/horizon/tables/base.py", line 1482, in take_action response = action.multiple(self, self.request, obj_ids) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line 302, in multiple return self.handle(data_table, request, object_ids) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line 828, in handle exceptions.handle(request, ignore=ignore) File "/usr/lib/python2.7/site-packages/horizon/exceptions.py", line 364, in handle six.reraise(exc_type, exc_value, exc_traceback) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py", line 817, in handle (self._get_action_name(past=True), datum_display)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 0: ordinal not in range(128) - It occurs in japanese,korean,chinese,french and deutsche, not occurs in english and spanish. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464461/+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 1468395] Re: Versions of oslo.i18n higher than 1.17.0 cause ImportError
** Changed in: oslo.i18n Status: New => Invalid -- 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/1468395 Title: Versions of oslo.i18n higher than 1.17.0 cause ImportError Status in OpenStack Dashboard (Horizon): Incomplete Status in Oslo Internationalization Library: Invalid Status in Python client library for Keystone: Confirmed Bug description: oslo.i18n version 2.0.0 was release <24h ago, and it breaks Horizon. If I pin the version of oslo.i18n to <2.0.0, it works. Here's the trace from tests script: ➜ ~ git clone g...@github.com:openstack/horizon.git Cloning into 'horizon'... remote: Counting objects: 97245, done. remote: Compressing objects: 100% (9/9), done. remote: Total 97245 (delta 3), reused 0 (delta 0), pack-reused 97236 Receiving objects: 100% (97245/97245), 147.90 MiB | 4.73 MiB/s, done. Resolving deltas: 100% (62610/62610), done. Checking connectivity... done. ➜ ~ cd horizon ➜ horizon git:(master) git checkout -t origin/stable/juno Branch stable/juno set up to track remote branch stable/juno from origin. Switched to a new branch 'stable/juno' ➜ horizon git:(stable/juno) ./run_tests.sh Checking environment. Environment not found. Install? (Y/n) Y Fetching new src packages... Creating venv... done. Installing dependencies with pip (this can take a while)... You are using pip version 7.0.1, however version 7.0.3 is available. You should consider upgrading via the 'pip install --upgrade pip' command. DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting pip>=1.4 Using cached pip-7.0.3-py2.py3-none-any.whl Installing collected packages: pip Found existing installation: pip 7.0.1 Uninstalling pip-7.0.1: Successfully uninstalled pip-7.0.1 Successfully installed pip-7.0.3 DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting setuptools Using cached setuptools-18.0-py2.py3-none-any.whl Installing collected packages: setuptools Found existing installation: setuptools 16.0 Uninstalling setuptools-16.0: Successfully uninstalled setuptools-16.0 Successfully installed setuptools-18.0 DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting pbr Using cached pbr-1.2.0-py2.py3-none-any.whl Installing collected packages: pbr Successfully installed pbr-1.2.0 DEPRECATION: --download-cache has been deprecated and will be removed in the future. Pip now automatically uses and configures its cache. Collecting pbr!=0.7,<1.0,>=0.6 (from -r /home/javier/horizon/requirements.txt (line 1)) Using cached pbr-0.11.0-py2.py3-none-any.whl Collecting Django<1.7,>=1.4.2 (from -r /home/javier/horizon/requirements.txt (line 2)) Using cached Django-1.6.11-py2.py3-none-any.whl Collecting django-compressor<=1.4,>=1.4 (from -r /home/javier/horizon/requirements.txt (line 3)) Using cached django_compressor-1.4-py2.py3-none-any.whl Collecting django-openstack-auth!=1.1.8,<=1.1.9,>=1.1.7 (from -r /home/javier/horizon/requirements.txt (line 4)) Using cached django_openstack_auth-1.1.9-py2-none-any.whl Collecting django-pyscss<=1.0.6,>=1.0.3 (from -r /home/javier/horizon/requirements.txt (line 5)) Collecting eventlet<=0.15.2,>=0.15.1 (from -r /home/javier/horizon/requirements.txt (line 6)) Using cached eventlet-0.15.2-py2.py3-none-any.whl Collecting httplib2<=0.9,>=0.7.5 (from -r /home/javier/horizon/requirements.txt (line 7)) Collecting iso8601<=0.1.10,>=0.1.9 (from -r /home/javier/horizon/requirements.txt (line 8)) Collecting kombu<=3.0.7,>=2.5.0 (from -r /home/javier/horizon/requirements.txt (line 9)) Collecting lockfile<=0.8,>=0.8 (from -r /home/javier/horizon/requirements.txt (line 10)) Collecting netaddr<=0.7.13,>=0.7.12 (from -r /home/javier/horizon/requirements.txt (line 11)) Using cached netaddr-0.7.13-py2.py3-none-any.whl Collecting pyScss<1.3,>=1.2.1 (from -r /home/javier/horizon/requirements.txt (line 12)) Collecting python-ceilometerclient<1.0.13,>=1.0.6 (from -r /home/javier/horizon/requirements.txt (line 13)) Using cached python_ceilometerclient-1.0.12-py2.py3-none-any.whl Collecting python-cinderclient<=1.1.1,>=1.1.0 (from -r /home/javier/horizon/requirements.txt (line 14)) Using cached python_cinderclient-1.1.1-py2.py3-none-any.whl Collecting python-glanceclient<=0.15.0,>=0.14.0 (from -r /home/javier/horizon/requirements.txt (line 15)) Using cached python_glanceclient-0.15.0-py2.py3-none-any.whl Collecting python-heatclient<0.3.0,>=0.2.9 (from -r /home/javier/horizon/requirements.txt (l
[Yahoo-eng-team] [Bug 1456192] Re: Extend glance-manage with new version command
As Stuart noted on the review - we already provide such functionality by using: glance-manage --version We don't need to provide it as a separate command. ** Changed in: glance Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1456192 Title: Extend glance-manage with new version command Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Bug description: Currently there is no way to check what version of Glance is installed using the CLI. It would be great if we can add this information to the current glance-manage command (just like Cinder or Nova for example). Something like: $ glance-manage version 2015.2.0 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1456192/+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 1469668] [NEW] Add a neutron port-scheduler component
Public bug reported: Both the get-me-a-network spec and the use cases laid out by several large deployers (Neutron networks limited to a single rack or other subset of datacenter) could benefit from a port scheduler. This port scheduler would allow Nova (or another caller) to request a port via port create without providing a network ID. The port scheduler would then populate the appropriate network ID depending on the request details and port creation would continue as normal. In lieu of the network ID, the client can pass optional hints to constrain the network selection (e.g. an external network that the network can reach). If the client doesn't pass any hints, this would become the 'get-me-a-network' use case where it's entirely up to Neutron. In order to satisfy the use case where not all Neutron networks are available everywhere, this scheduler should also expose an API that allows a Nova scheduling filter to be written that can ask Neutron which hosts can be used for the Neutron port details it was given. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Tags: rfe ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1469668 Title: Add a neutron port-scheduler component Status in OpenStack Neutron (virtual network service): New Bug description: Both the get-me-a-network spec and the use cases laid out by several large deployers (Neutron networks limited to a single rack or other subset of datacenter) could benefit from a port scheduler. This port scheduler would allow Nova (or another caller) to request a port via port create without providing a network ID. The port scheduler would then populate the appropriate network ID depending on the request details and port creation would continue as normal. In lieu of the network ID, the client can pass optional hints to constrain the network selection (e.g. an external network that the network can reach). If the client doesn't pass any hints, this would become the 'get-me-a-network' use case where it's entirely up to Neutron. In order to satisfy the use case where not all Neutron networks are available everywhere, this scheduler should also expose an API that allows a Nova scheduling filter to be written that can ask Neutron which hosts can be used for the Neutron port details it was given. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1469668/+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 1469655] [NEW] VMware: Instance creation fails using block device mapping
Public bug reported: 2015-06-29 14:24:49.211 DEBUG oslo_vmware.exceptions [-] Fault InvalidDatastorePath not matched. from (pid=21558) get_fault_class /usr/local/lib/python2.7/dist-packages/oslo_vmware/exceptions.py:250 2015-06-29 14:24:49.212 ERROR oslo_vmware.common.loopingcall [-] in fixed duration looping call 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall Traceback (most recent call last): 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall File "/usr/local/lib/python2.7/dist-packages/oslo_vmware/common/loopingcall.py", line 76, in _inner 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall self.f(*self.args, **self.kw) 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall File "/usr/local/lib/python2.7/dist-packages/oslo_vmware/api.py", line 417, in _poll_task 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall raise task_ex 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall VMwareDriverException: Invalid datastore path '[localdatastore] volume-c279ad39-f1f9-4861-9d00-2de8f6df7756/volume-c279ad39-f1f9-4861-9d00-2de8f6df7756.vmdk'. 2015-06-29 14:24:49.212 TRACE oslo_vmware.common.loopingcall 2015-06-29 14:24:49.212 ERROR nova.compute.manager [-] [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] Instance failed to spawn 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] Traceback (most recent call last): 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/compute/manager.py", line 2442, in _build_resources 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] yield resources 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/compute/manager.py", line 2314, in _build_and_run_instance 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] block_device_info=block_device_info) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/driver.py", line 480, in spawn 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] admin_password, network_info, block_device_info) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/vmops.py", line 628, in spawn 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] instance, adapter_type) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/volumeops.py", line 371, in attach_volume 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] self._attach_volume_vmdk(connection_info, instance, adapter_type) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/volumeops.py", line 330, in _attach_volume_vmdk 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] vmdk_path=vmdk.path) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/volumeops.py", line 71, in attach_disk_to_vm 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] vm_util.reconfigure_vm(self._session, vm_ref, vmdk_attach_config_spec) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/vm_util.py", line 1377, in reconfigure_vm 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] session._wait_for_task(reconfig_task) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/opt/stack/nova/nova/virt/vmwareapi/driver.py", line 680, in _wait_for_task 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] return self.wait_for_task(task_ref) 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/usr/local/lib/python2.7/dist-packages/oslo_vmware/api.py", line 380, in wait_for_task 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] return evt.wait() 2015-06-29 14:24:49.212 TRACE nova.compute.manager [instance: 0a55fe16-3a21-40f0-85f3-777d6254f215] File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 121, in wait 2015-06-29 14:24:49.212 TRACE nova.compute.manage
[Yahoo-eng-team] [Bug 1469661] [NEW] 'volumes_attached' included the volume_id which is actually available
Public bug reported:
[Env]
Ubuntu 14.04
OpenStack Icehouse
[Descrition]
I am usting pdb to debug nova attach_volume operation, due to the reason that
the command is timeout, the volume failed to be attached to the instance,
however, in the nova db, the attachment device is already recorded other than
fallback, which is completely not right from user's perspective.
For example, nova instance '1' shows "os-extended-
volumes:volumes_attached | [{"id":
"3c8205b9-5066-42ea-9180-601fac50a08e"}, {"id":
"3c8205b9-5066-42ea-9180-601fac50a08e"}, {"id":
"3c8205b9-5066-42ea-9180-601fac50a08e"}, {"id":
"3c8205b9-5066-42ea-9180-601fac50a08e"}] |" even if the volume
3c8205b9-5066-42ea-9180-601fac50a08e is actually available.
I am concerning there are some situations nova attach_volume would fail
in the middle procedure which would have this issue as well, is it
better to delay the db persistent step after the device is really being
attached?
ubuntu@xianghui-bastion:~/openstack-charm-testing/test$ nova list
+--+--+++-+--+
| ID | Name | Status | Task State | Power
State | Networks |
+--+--+++-+--+
| d58a3b25-0434-4b92-a3a8-8b4188c611c3 | 1| ACTIVE | - | Running
| private=192.168.21.4 |
+--+--+++-+--+
ubuntu@xianghui-bastion:~/openstack-charm-testing/test$ nova volume-list
+--+---+--+--+-+-+
| ID | Status| Display Name | Size |
Volume Type | Attached to |
+--+---+--+--+-+-+
| 3c8205b9-5066-42ea-9180-601fac50a08e | available | test | 2| None
| |
+--+---+--+--+-+-+
ubuntu@xianghui-bastion:~/openstack-charm-testing/test$ nova show 1
+--+---
---+
| Property | Value
|
+--+---
---+
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | juju-xianghui-machine-12
|
| OS-EXT-SRV-ATTR:hypervisor_hostname |
juju-xianghui-machine-12.openstacklocal
|
| OS-EXT-SRV-ATTR:instance_name| instance-0002
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2015-06-29T05:22:09.00
[Yahoo-eng-team] [Bug 1469651] [NEW] Boolean values displayed without 'yesno' filter in user and project detail page
Public bug reported: In Project and User detail page, enabled field is boolean. This is displayed as it is (True and False) It should displayed as Yes and No ** Affects: horizon Importance: Undecided Assignee: Masco Kaliyamoorthy (masco) Status: New ** Changed in: horizon Assignee: (unassigned) => Masco Kaliyamoorthy (masco) -- 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/1469651 Title: Boolean values displayed without 'yesno' filter in user and project detail page Status in OpenStack Dashboard (Horizon): New Bug description: In Project and User detail page, enabled field is boolean. This is displayed as it is (True and False) It should displayed as Yes and No To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1469651/+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 1451429] Re: Kilo: I/O error uploading image
** Also affects: horizon/kilo
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1451429
Title:
Kilo: I/O error uploading image
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) kilo series:
New
Bug description:
Using a Ceph backend. Same configuration works just fine on Juno.
Glance image creation from file using the API works. Horizon image
creation from URL works too, but using file upload does not.
Apache error.log:
Unhandled exception in thread started by
Traceback (most recent call last):
File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
line 112, in image_update
exceptions.handle(request, ignore=True)
File "/usr/lib/python2.7/dist-packages/horizon/exceptions.py", line 364, in
handle
six.reraise(exc_type, exc_value, exc_traceback)
File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
line 110, in image_update
image = glanceclient(request).images.update(image_id, **kwargs)
File "/usr/lib/python2.7/dist-packages/glanceclient/v1/images.py", line
329, in update
resp, body = self.client.put(url, headers=hdrs, data=image_data)
File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line
265, in put
return self._request('PUT', url, **kwargs)
File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line
206, in _request
**kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 455, in
request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 558, in
send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 350, in
send
for i in request.body:
File "/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line
170, in chunk_body
chunk = body.read(CHUNKSIZE)
ValueError: I/O operation on closed file
Horizon log:
[req-0e69bfd9-c6ab-4131-b445-aa57c1a455f7 87d1da7fba6f4f5a9d4e7f78da344e91
ba35660ba55b4a5283c691a4c6d99f23 - - -] Failed to upload image
90a30bfb-946c-489d-9a04-5f601af0f821
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/glance/api/v1/upload_utils.py", line
113, in upload_data_to_store
context=req.context)
File "/usr/lib/python2.7/dist-packages/glance_store/backend.py", line 339,
in store_add_to_backend
context=context)
File "/usr/lib/python2.7/dist-packages/glance_store/capabilities.py", line
226, in op_checker
return store_op_fun(store, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/glance_store/_drivers/rbd.py", line
384, in add
self._delete_image(loc.image, loc.snapshot)
File "/usr/lib/python2.7/dist-packages/glance_store/_drivers/rbd.py", line
290, in _delete_image
with conn.open_ioctx(target_pool) as ioctx:
File "/usr/lib/python2.7/dist-packages/rados.py", line 667, in open_ioctx
raise make_ex(ret, "error opening pool '%s'" % ioctx_name)
ObjectNotFound: error opening pool '90a30bfb-946c-489d-9a04-5f601af0f821'
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1451429/+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 1469634] [NEW] '' in xml is not recognized by libvirt.
Public bug reported: '' in xml is not recognized by libvirt. We should modify "nosharedpages" to "nosharepages". Because: [root@nail-SBCJ-5-3-3 libvirt]# virsh list IdName State 2 instance-0002 running 7 instance-0007 running [root@nail-SBCJ-5-3-3 libvirt]# [root@nail-SBCJ-5-3-3 libvirt]# [root@nail-SBCJ-5-3-3 libvirt]# virsh dumpxml 7 instance-0007 dda65962-5d55-403a-bdf3-462a17563a74 http://openstack.org/xmlns/libvirt/nova/1.0";> hanrong5 2015-06-29 07:30:51 100 10 0 0 1 admin admin 102400 102400 1 1024 /machine Fedora Project OpenStack Nova 2015.1.0-1.1.44 52c08ef4-27eb-422d-a840-7de43ca69827 dda65962-5d55-403a-bdf3-462a17563a74 hvm destroy restart destroy /usr/bin/qemu-system-x86_64 ** Affects: nova Importance: Undecided Status: New ** Tags: in-stable-kilo ** Tags added: in-stable-kilo -- 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/1469634 Title: '' in xml is not recognized by libvirt. Status in OpenStack Compute (Nova): New Bug description: '' in xml is not recognized by libvirt. We should modify "nosharedpages" to "nosharepages". Because: [root@nail-SBCJ-5-3-3 libvirt]# virsh list IdName State 2 instance-0002 running 7 instance-0007 running [root@nail-SBCJ-5-3-3 libvirt]# [root@nail-SBCJ-5-3-3 libvirt]# [root@nail-SBCJ-5-3-3 libvirt]# virsh dumpxml 7 instance-0007 dda65962-5d55-403a-bdf3-462a17563a74 http://openstack.org/xmlns/libvirt/nova/1.0";> hanrong5 2015-06-29 07:30:51 100 10 0 0 1 admin admin 102400 102400 1 1024 /machine Fedora Project OpenStack Nova 2015.1.0-1.1.44 52c08ef4-27eb-422d-a840-7de43ca69827 dda65962-5d55-403a-bdf3-462a17563a74 hvm destroy restart destroy /usr/bin/qemu-system-x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1469634/+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 1469615] [NEW] dhcp service is unavailable if we delete dhcp port
Public bug reported: if we delete the dhcp port, the dhcp service for corresponding network is unavailable, because dhcp port is deleted from neutron-server, but the TAP device on network node is not deleted, and the tag for this TAP is dead vlan 4095, and the dhcp service can' t be recoverd. reproduce steps: 1. create network, subnet 2. delete the dhcp port in this network I foud the TAP device on network node was not deleted, but its tag is 4095 ** Affects: neutron Importance: Undecided Assignee: shihanzhang (shihanzhang) Status: New ** Changed in: neutron Assignee: (unassigned) => shihanzhang (shihanzhang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1469615 Title: dhcp service is unavailable if we delete dhcp port Status in OpenStack Neutron (virtual network service): New Bug description: if we delete the dhcp port, the dhcp service for corresponding network is unavailable, because dhcp port is deleted from neutron- server, but the TAP device on network node is not deleted, and the tag for this TAP is dead vlan 4095, and the dhcp service can' t be recoverd. reproduce steps: 1. create network, subnet 2. delete the dhcp port in this network I foud the TAP device on network node was not deleted, but its tag is 4095 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1469615/+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
