[Yahoo-eng-team] [Bug 1334323] Re: Check ips availability before adding network to DHCP agent
Hello mouadino, thanks for filing this bug. This is the expected behavior, every dhcp agent will have a port on a network. You should take this into account when you create the allocation pool. If you want to change this behavior I suggest you file a blueprint instead of a bug. ** Changed in: neutron Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334323 Title: Check ips availability before adding network to DHCP agent Status in OpenStack Neutron (virtual network service): Opinion Bug description: Hi there, How to reproduce ? === First of all it's better to use HA DHCP agent, i.e. running more than one DHCP agent, and setting the dhcp_agents_per_network to the number of DHCP agent that you're running. Now for the sake of this example let's say that dhcp_agents_per_network=3. Now create a network with a subnet /30 for example or big subnet e..g /24 but with a smaller allocation pool e.g that contain only 1 or 2 ips.. What happen ? A lot of exception start showing up in the logs in the form: IpAddressGenerationFailure: No more IP addresses available on network What happen really ? Our small network was basically scheduled to all DHCP agents that are up and active and each one of them will try to create a port for him self, but because our small network has less IPs than dhcp_agents_per_network, then some of this port will fail to be created, and this will happen each iteration of the DHCP agent main loop. Another case where if you have more than one subnet in a network, and one of them is pretty small e.g. net1 -> subnet1 10.0.0.0/24 subnet2 10.10.0.0/30 Than errors also start to happen in every iteration of the dhcp agent. What is expected ? === IMHO only agent that can handle the network should hold this later, and a direct call to add a network to a DHCP agent should also fail if there is no IPs left to satisfy the new DHCP port creation. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334323/+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 1334563] [NEW] nova-network allow creating network with invalid vlan number
Public bug reported:
My openstack use nova network service, I create network with "vlan" parameter.
I can create network with vlan 4097. As we known, this is a invalid vlan number.
This is my request body:
{
"network": {
"cidr": "192.168.50.0/24",
"vlan": "4097",
"label": "testnetwork01"
}
}
This is response:
{
"network": {
"bridge": "br4097",
"vpn_public_port": 1006,
"dhcp_start": "192.168.50.3",
"bridge_interface": "brcps",
"updated_at": null,
"id": "c5bd9589-5310-4cd2-8d2a-413db609e88b",
"cidr_v6": null,
"deleted_at": null,
"gateway": "192.168.50.1",
"rxtx_base": null,
"label": "testnetwork01",
"priority": null,
"project_id": null,
"vpn_private_address": "192.168.50.2",
"deleted": 0,
"vlan": "4097",
"broadcast": "192.168.50.255",
"netmask": "255.255.255.0",
"injected": false,
"cidr": "192.168.50.0/24",
"vpn_public_address": null,
"multi_host": false,
"dns2": null,
"created_at": "2014-06-26T16:23:01.309176",
"host": null,
"gateway_v6": null,
"netmask_v6": null,
"dns1": "8.8.4.4"
}
}
I think we should check this parameter.
** Affects: nova
Importance: Undecided
Assignee: Dong Liu (liudong78)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Dong Liu (liudong78)
** Project changed: neutron => nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1334563
Title:
nova-network allow creating network with invalid vlan number
Status in OpenStack Compute (Nova):
New
Bug description:
My openstack use nova network service, I create network with "vlan" parameter.
I can create network with vlan 4097. As we known, this is a invalid vlan
number.
This is my request body:
{
"network": {
"cidr": "192.168.50.0/24",
"vlan": "4097",
"label": "testnetwork01"
}
}
This is response:
{
"network": {
"bridge": "br4097",
"vpn_public_port": 1006,
"dhcp_start": "192.168.50.3",
"bridge_interface": "brcps",
"updated_at": null,
"id": "c5bd9589-5310-4cd2-8d2a-413db609e88b",
"cidr_v6": null,
"deleted_at": null,
"gateway": "192.168.50.1",
"rxtx_base": null,
"label": "testnetwork01",
"priority": null,
"project_id": null,
"vpn_private_address": "192.168.50.2",
"deleted": 0,
"vlan": "4097",
"broadcast": "192.168.50.255",
"netmask": "255.255.255.0",
"injected": false,
"cidr": "192.168.50.0/24",
"vpn_public_address": null,
"multi_host": false,
"dns2": null,
"created_at": "2014-06-26T16:23:01.309176",
"host": null,
"gateway_v6": null,
"netmask_v6": null,
"dns1": "8.8.4.4"
}
}
I think we should check this parameter.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1334563/+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 1334608] [NEW] Project Volumes page could be more optimised
Public bug reported: With a large number of volumes, the project volume page can take a very long time to load. It seems we call volumes_list() 3 times when loading the page. 1. Once to get the volumes list for populating the table - OK https://github.com/openstack/horizon/blob/e790ac070e/openstack_dashboard/dashboards/project/volumes/tabs.py#L65 2. Once when we retrieve the snapshots, to show the volumes they're associated with. The snapshots are hidden in a tab so we shouldn't need to get to them so early, this could easily be prevented by not preloading the tab https://github.com/openstack/horizon/blob/e790ac070e/openstack_dashboard/dashboards/project/volumes/tabs.py#L65 3. Another time when rendering the tabbed response, not quite sure why yet ** Affects: horizon Importance: Medium Assignee: Julie Pichon (jpichon) Status: New ** Tags: volume ** Tags added: volume -- 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/1334608 Title: Project Volumes page could be more optimised Status in OpenStack Dashboard (Horizon): New Bug description: With a large number of volumes, the project volume page can take a very long time to load. It seems we call volumes_list() 3 times when loading the page. 1. Once to get the volumes list for populating the table - OK https://github.com/openstack/horizon/blob/e790ac070e/openstack_dashboard/dashboards/project/volumes/tabs.py#L65 2. Once when we retrieve the snapshots, to show the volumes they're associated with. The snapshots are hidden in a tab so we shouldn't need to get to them so early, this could easily be prevented by not preloading the tab https://github.com/openstack/horizon/blob/e790ac070e/openstack_dashboard/dashboards/project/volumes/tabs.py#L65 3. Another time when rendering the tabbed response, not quite sure why yet To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334608/+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 1334622] [NEW] Javascript issues found by jshint
Public bug reported: Running the jshint codeanalysis tool for javascript on the horizon codebase found 10 errors: horizon/static/horizon/js/horizon.d3linechart.js: line 415, col 11, It's not necessary to initialize 'last_point' to 'undefined'. horizon/static/horizon/js/horizon.d3linechart.js: line 415, col 35, It's not necessary to initialize 'last_point_color' to 'undefined'. horizon/static/horizon/js/horizon.d3piechart.js: line 145, col 10, ['key'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 146, col 10, ['value'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 162, col 44, ['value'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 236, col 27, ['key'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 237, col 33, ['value'] is better written in dot notation. horizon/static/horizon/js/horizon.forms.js: line 8, col 26, Use '===' to compare with ''. horizon/static/horizon/js/horizon.forms.js: line 25, col 26, Use '===' to compare with ''. horizon/static/horizon/js/horizon.forms.js: line 42, col 26, Use '===' to compare with ''. The exact commands: jshint horizon/static/horizon/js jshint horizon/static/horizon/tests ** 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/1334622 Title: Javascript issues found by jshint Status in OpenStack Dashboard (Horizon): New Bug description: Running the jshint codeanalysis tool for javascript on the horizon codebase found 10 errors: horizon/static/horizon/js/horizon.d3linechart.js: line 415, col 11, It's not necessary to initialize 'last_point' to 'undefined'. horizon/static/horizon/js/horizon.d3linechart.js: line 415, col 35, It's not necessary to initialize 'last_point_color' to 'undefined'. horizon/static/horizon/js/horizon.d3piechart.js: line 145, col 10, ['key'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 146, col 10, ['value'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 162, col 44, ['value'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 236, col 27, ['key'] is better written in dot notation. horizon/static/horizon/js/horizon.d3piechart.js: line 237, col 33, ['value'] is better written in dot notation. horizon/static/horizon/js/horizon.forms.js: line 8, col 26, Use '===' to compare with ''. horizon/static/horizon/js/horizon.forms.js: line 25, col 26, Use '===' to compare with ''. horizon/static/horizon/js/horizon.forms.js: line 42, col 26, Use '===' to compare with ''. The exact commands: jshint horizon/static/horizon/js jshint horizon/static/horizon/tests To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334622/+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 1334634] [NEW] linuxbridge agent delete a physcial interface
Public bug reported: How to reproduce ? === 1. Use Linux bridge agent. 2. Set the physical interface to something like: physical_interface_mappings= physnet1:eth0,physnet2:eth0.4000 3. Start using the physnet2 by creating a port for example ... What happen ? === As soon as no one is using the bridge anymore and that the bridge need to be deleted, eth0.4000 is also deleted. What is Expected ? === eth0.4000 to not be deleted, it's a physcial interface afterward, neutron didn't create it, neither he should delete it. ** Affects: neutron Importance: Undecided Assignee: mouadino (mouadino) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334634 Title: linuxbridge agent delete a physcial interface Status in OpenStack Neutron (virtual network service): In Progress Bug description: How to reproduce ? === 1. Use Linux bridge agent. 2. Set the physical interface to something like: physical_interface_mappings= physnet1:eth0,physnet2:eth0.4000 3. Start using the physnet2 by creating a port for example ... What happen ? === As soon as no one is using the bridge anymore and that the bridge need to be deleted, eth0.4000 is also deleted. What is Expected ? === eth0.4000 to not be deleted, it's a physcial interface afterward, neutron didn't create it, neither he should delete it. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334634/+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 1334647] [NEW] Nova api service doesn't handle SIGHUP signal properly
Public bug reported: When SIGHUP signal is send to nova-api service, it doesn't complete processing of all pending requests before terminating all the processes. Steps to reproduce: 1. Run nova-api service as a daemon. 2. Send SIGHUP signal to nova-api service. kill -1 After getting SIGHUP signal all the processes of nova-api stops instantly, without completing existing request, which might cause failure. Ideally after getting the SIGHUP signal nova-api process should stop getting new requests and wait for existing requests to complete before terminating all the processes and restarting all nova-api processes. ** Affects: nova Importance: Undecided Assignee: Rajesh Tailor (rajesh-tailor) Status: New ** Tags: ntt -- 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/1334647 Title: Nova api service doesn't handle SIGHUP signal properly Status in OpenStack Compute (Nova): New Bug description: When SIGHUP signal is send to nova-api service, it doesn't complete processing of all pending requests before terminating all the processes. Steps to reproduce: 1. Run nova-api service as a daemon. 2. Send SIGHUP signal to nova-api service. kill -1 After getting SIGHUP signal all the processes of nova-api stops instantly, without completing existing request, which might cause failure. Ideally after getting the SIGHUP signal nova-api process should stop getting new requests and wait for existing requests to complete before terminating all the processes and restarting all nova-api processes. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334647/+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 1334651] [NEW] Nova api service outputs error messages when SIGHUP signal is sent
Public bug reported: When SIGHUP signal is send to nova-api service, it stops all the nova- api processes and while restarting the nova-api processes, it throws AttributeError: 'WSGIService' object has no attribute 'reset'. 2014-06-24 15:52:55.185 CRITICAL nova [-] AttributeError: 'WSGIService' object has no attribute 'reset' 2014-06-24 15:52:55.185 TRACE nova Traceback (most recent call last): 2014-06-24 15:52:55.185 TRACE nova File "/usr/local/bin/nova-api", line 10, in 2014-06-24 15:52:55.185 TRACE nova sys.exit(main()) 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/cmd/api.py", line 56, in main 2014-06-24 15:52:55.185 TRACE nova launcher.launch_service(server, workers=server.workers or 1) 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 340, in launch_service 2014-06-24 15:52:55.185 TRACE nova self._start_child(wrap) 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 324, in _start_child 2014-06-24 15:52:55.185 TRACE nova launcher.restart() 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 145, in restart 2014-06-24 15:52:55.185 TRACE nova self.services.restart() 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 478, in restart 2014-06-24 15:52:55.185 TRACE nova restart_service.reset() 2014-06-24 15:52:55.185 TRACE nova AttributeError: 'WSGIService' object has no attribute 'reset' 2014-06-24 15:52:55.185 TRACE nova Steps to reproduce: 1. Run nova-api service as daemon. 2. Send SIGHUP signal to nova-api service kill -1 ** Affects: nova Importance: Undecided Assignee: Rajesh Tailor (rajesh-tailor) Status: New ** Tags: ntt ** Changed in: nova Assignee: (unassigned) => Rajesh Tailor (rajesh-tailor) -- 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/1334651 Title: Nova api service outputs error messages when SIGHUP signal is sent Status in OpenStack Compute (Nova): New Bug description: When SIGHUP signal is send to nova-api service, it stops all the nova- api processes and while restarting the nova-api processes, it throws AttributeError: 'WSGIService' object has no attribute 'reset'. 2014-06-24 15:52:55.185 CRITICAL nova [-] AttributeError: 'WSGIService' object has no attribute 'reset' 2014-06-24 15:52:55.185 TRACE nova Traceback (most recent call last): 2014-06-24 15:52:55.185 TRACE nova File "/usr/local/bin/nova-api", line 10, in 2014-06-24 15:52:55.185 TRACE nova sys.exit(main()) 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/cmd/api.py", line 56, in main 2014-06-24 15:52:55.185 TRACE nova launcher.launch_service(server, workers=server.workers or 1) 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 340, in launch_service 2014-06-24 15:52:55.185 TRACE nova self._start_child(wrap) 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 324, in _start_child 2014-06-24 15:52:55.185 TRACE nova launcher.restart() 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 145, in restart 2014-06-24 15:52:55.185 TRACE nova self.services.restart() 2014-06-24 15:52:55.185 TRACE nova File "/opt/stack/nova/nova/openstack/common/service.py", line 478, in restart 2014-06-24 15:52:55.185 TRACE nova restart_service.reset() 2014-06-24 15:52:55.185 TRACE nova AttributeError: 'WSGIService' object has no attribute 'reset' 2014-06-24 15:52:55.185 TRACE nova Steps to reproduce: 1. Run nova-api service as daemon. 2. Send SIGHUP signal to nova-api service kill -1 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334651/+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 1334677] [NEW] Flavor extra specs should be refactored
Public bug reported: The IndexView is extending from ModalFormMixin when there is no intention to display a modal or allow form actions in the Index. The index only displays a table of the key/value pairs so extending from DataTableView should be enough The template _index.html is unnecessarily extending form _modal.html when there is no intention to display a modal ** 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/1334677 Title: Flavor extra specs should be refactored Status in OpenStack Dashboard (Horizon): New Bug description: The IndexView is extending from ModalFormMixin when there is no intention to display a modal or allow form actions in the Index. The index only displays a table of the key/value pairs so extending from DataTableView should be enough The template _index.html is unnecessarily extending form _modal.html when there is no intention to display a modal To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334677/+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 1334661] Re: rpc.cleanup method is not reachable due to wrong import of rpc module
** Changed in: oslo
Status: Invalid => Triaged
** Changed in: oslo
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1334661
Title:
rpc.cleanup method is not reachable due to wrong import of rpc module
Status in OpenStack Compute (Nova):
New
Status in Oslo - a Library of Common OpenStack Code:
Triaged
Bug description:
In nova service rpc.cleanup method is not getting called because 'rpc'
is not imported properly.
rpc = importutils.try_import('nova.openstack.common.rpc')
It should be
rpc = importutils.try_import('nova.rpc')
'rpc' module is not present in nova/openstack/common package.
As it is present in nova package it should be imported from there only.
Also rpc cleanup method should not be called while restarting the
service as ideally cleanup task should be done only while exiting from
the service. In case of SIGHUP signal, service gets restarted and
tries to cleanup the rpc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1334661/+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 1334708] [NEW] NSX VMWare Mine-Sweeper fails to update status of Floating ip
Public bug reported: This patch verifies Floating IP status is updated correctly according to blue print. https://review.openstack.org/#/c/102700/ https://blueprints.launchpad.net/neutron/+spec/fip-op-status VMWWare-Minesweeper fails consistently. The Jenkins gates pass ok Please check ** Affects: neutron Importance: Undecided Status: New ** Tags: nicira ** Tags added: vmware -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334708 Title: NSX VMWare Mine-Sweeper fails to update status of Floating ip Status in OpenStack Neutron (virtual network service): New Bug description: This patch verifies Floating IP status is updated correctly according to blue print. https://review.openstack.org/#/c/102700/ https://blueprints.launchpad.net/neutron/+spec/fip-op-status VMWWare-Minesweeper fails consistently. The Jenkins gates pass ok Please check To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334708/+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 1334661] Re: rpc.cleanup method is not reachable due to wrong import of rpc module
This is not a bug in Oslo AFAICT. It sounds like an Oslo rpc reference
wasn't cleaned up in Nova when it converted to oslo.messaging. I'm not
even sure where this bad import is happening (it would be good to link
to the file where you see this), but it's likely that something needs to
be imported from oslo.messaging.
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: oslo
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1334661
Title:
rpc.cleanup method is not reachable due to wrong import of rpc module
Status in OpenStack Compute (Nova):
New
Status in Oslo - a Library of Common OpenStack Code:
Invalid
Bug description:
In nova service rpc.cleanup method is not getting called because 'rpc'
is not imported properly.
rpc = importutils.try_import('nova.openstack.common.rpc')
It should be
rpc = importutils.try_import('nova.rpc')
'rpc' module is not present in nova/openstack/common package.
As it is present in nova package it should be imported from there only.
Also rpc cleanup method should not be called while restarting the
service as ideally cleanup task should be done only while exiting from
the service. In case of SIGHUP signal, service gets restarted and
tries to cleanup the rpc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1334661/+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 1334711] [NEW] Document workers parameter for the registry
Public bug reported: The workers parameter applies to the registry as well as the api, ie adding workers=N to glance-registry.conf will increase the number of registry processes. ** Affects: glance Importance: Undecided Assignee: Stuart McLaren (stuart-mclaren) Status: New ** Changed in: glance Assignee: (unassigned) => Stuart McLaren (stuart-mclaren) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1334711 Title: Document workers parameter for the registry Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: The workers parameter applies to the registry as well as the api, ie adding workers=N to glance-registry.conf will increase the number of registry processes. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1334711/+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 1246308] Re: AttributeError in Redis Matchmaker ack_alive()
Not sure if this is still an issue but it needs to be fixed in oslo.messaging first and the proposed patch was abandoned awhile ago. ** Changed in: oslo Status: In Progress => Triaged ** Changed in: oslo Assignee: Rohit Karajgi (rohitk) => (unassigned) ** Changed in: nova Assignee: Rohit Karajgi (rohitk) => (unassigned) ** Also affects: oslo.messaging Importance: Undecided Status: New ** No longer affects: oslo ** Tags added: oslo -- 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/1246308 Title: AttributeError in Redis Matchmaker ack_alive() Status in OpenStack Compute (Nova): Triaged Status in Messaging API for OpenStack: New Bug description: The attribute name while re-registering a topic should be "self.host_topic" instead of "self.topic_host" in https://github.com/openstack/nova/blob/master/nova/openstack/common/rpc/matchmaker_redis.py#L113 Otherwise, the following error is seen while starting the conductor service: 2013-10-30 18:02:32.849 ERROR nova.openstack.common.threadgroup [-] 'MatchMakerRedis' object has no attribute 'topic_host' 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup Traceback (most recent call last): 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/openstack/common/threadgroup.py", line 117, in wait 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup x.wait() 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/openstack/common/threadgroup.py", line 49, in wait 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup return self.thread.wait() 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in wait 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup return self._exit_event.wait() 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup return hubs.get_hub().switch() 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in swi tch 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup return self.greenlet.switch() 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in main 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup result = function(*args, **kwargs) 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/openstack/common/service.py", line 448, in run_service 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup service.start() 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/service.py", line 176, in start 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup self.conn.create_consumer(self.topic, rpc_dispatcher, fanout=False) 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/openstack/common/rpc/impl_zmq.py", line 578, in create_consumer 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup _get_matchmaker().register(topic, CONF.rpc_zmq_host) 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/openstack/common/rpc/matchmaker.py", line 207, in register 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup self.ack_alive(key, host) 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup File "/opt/stack/nova/nova/openstack/common/rpc/matchmaker_redis.py", line 113, in ack_alive 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup self.register(self.topic_host[host], host) 2013-10-30 18:02:32.849 TRACE nova.openstack.common.threadgroup AttributeError: 'MatchMakerRedis' object has no attribute 'topic_host' To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246308/+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 1334734] [NEW] User creation error not descriptive
Public bug reported: When the creation of a user fails by some exceptions within Keystone, the error message given by Horizon is "Error: Unable to create user." The error message within Keystone CLI shows detailed description of error. To replicate: 1. Raise an exception within keystone/keystone/identity/controllers.py by adding this line: def create_user(...): ... self.assert_admin(context) # Add this line raise exception.ValidationTimeStampError() ... 2. Restart keystone service 3a. Within CLI: > keystone user-create --name=example --pass=examplepass > --email=exam...@example.com Output: > Timestamp not in expected format. The server could not comply with the > request since it is either malformed or otherwise incorrect. The client is > assumed to be in error. (HTTP 400) 3b. Within Horizon: Create user with same information as CLI (add to any project and role) Output: Error: Unable to create user ** 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/1334734 Title: User creation error not descriptive Status in OpenStack Dashboard (Horizon): New Bug description: When the creation of a user fails by some exceptions within Keystone, the error message given by Horizon is "Error: Unable to create user." The error message within Keystone CLI shows detailed description of error. To replicate: 1. Raise an exception within keystone/keystone/identity/controllers.py by adding this line: def create_user(...): ... self.assert_admin(context) # Add this line raise exception.ValidationTimeStampError() ... 2. Restart keystone service 3a. Within CLI: > keystone user-create --name=example --pass=examplepass --email=exam...@example.com Output: > Timestamp not in expected format. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) 3b. Within Horizon: Create user with same information as CLI (add to any project and role) Output: Error: Unable to create user To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334734/+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 1334739] [NEW] A bug for test(ignore it)
Public bug reported: description: A bug for test(ignore it) ** Affects: keystone Importance: Undecided Assignee: Amandeep Chhabra (amanchhabra) Status: New ** Changed in: keystone Assignee: (unassigned) => Amandeep Chhabra (amanchhabra) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1334739 Title: A bug for test(ignore it) Status in OpenStack Identity (Keystone): New Bug description: description: A bug for test(ignore it) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1334739/+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 1334739] Re: A bug for test(ignore it)
** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1334739 Title: A bug for test(ignore it) Status in OpenStack Identity (Keystone): Invalid Bug description: description: A bug for test(ignore it) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1334739/+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 1334766] [NEW] More button on tables isn't translated
Public bug reported: On the Project->Compute->Instances table (and likely many others) the More link at the bottom for pagination is not translated. ** Affects: horizon Importance: Undecided Assignee: Doug Fish (drfish) Status: New ** Changed in: horizon Assignee: (unassigned) => Doug Fish (drfish) -- 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/1334766 Title: More button on tables isn't translated Status in OpenStack Dashboard (Horizon): New Bug description: On the Project->Compute->Instances table (and likely many others) the More link at the bottom for pagination is not translated. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334766/+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 1334774] [NEW] test_quota unit tests failing with UnicodeError from oslo gettextutils
Public bug reported:
I'm seeing something like this in many unrelated changes:
2014-06-26 15:55:57.452 | FAIL:
glance.tests.unit.test_quota.TestImageLocationQuotas.test_add_too_many_image_locations
2014-06-26 15:55:57.452 | tags: worker-0
2014-06-26 15:55:57.452 |
--
2014-06-26 15:55:57.452 | Traceback (most recent call last):
2014-06-26 15:55:57.452 | File "glance/tests/unit/test_quota.py", line 568,
in test_add_too_many_image_locations
2014-06-26 15:55:57.452 | self.assertIn('Attempted: 2, Maximum: 1',
str(exc))
2014-06-26 15:55:57.452 | File "glance/openstack/common/gettextutils.py",
line 333, in __str__
2014-06-26 15:55:57.452 | raise UnicodeError(msg)
2014-06-26 15:55:57.452 | UnicodeError: Message objects do not support str()
because they may contain non-ascii characters. Please use unicode() or
translate() instead.
http://logs.openstack.org/63/102863/1/check/gate-glance-
python27/6ad16a3/console.html
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVW5pY29kZUVycm9yOiBNZXNzYWdlIG9iamVjdHMgZG8gbm90IHN1cHBvcnQgc3RyKCkgYmVjYXVzZSB0aGV5IG1heSBjb250YWluIG5vbi1hc2NpaSBjaGFyYWN0ZXJzLiBQbGVhc2UgdXNlIHVuaWNvZGUoKSBvciB0cmFuc2xhdGUoKSBpbnN0ZWFkLlwiIEFORCB0YWdzOmNvbnNvbGUgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svZ2xhbmNlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDM4MDQ5ODkwMDZ9
There is a gettextutils sync here:
https://review.openstack.org/#/c/91047/
But that didn't hit this in the check queue, but hit it after being
approved.
** 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/1334774
Title:
test_quota unit tests failing with UnicodeError from oslo gettextutils
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Bug description:
I'm seeing something like this in many unrelated changes:
2014-06-26 15:55:57.452 | FAIL:
glance.tests.unit.test_quota.TestImageLocationQuotas.test_add_too_many_image_locations
2014-06-26 15:55:57.452 | tags: worker-0
2014-06-26 15:55:57.452 |
--
2014-06-26 15:55:57.452 | Traceback (most recent call last):
2014-06-26 15:55:57.452 | File "glance/tests/unit/test_quota.py", line 568,
in test_add_too_many_image_locations
2014-06-26 15:55:57.452 | self.assertIn('Attempted: 2, Maximum: 1',
str(exc))
2014-06-26 15:55:57.452 | File "glance/openstack/common/gettextutils.py",
line 333, in __str__
2014-06-26 15:55:57.452 | raise UnicodeError(msg)
2014-06-26 15:55:57.452 | UnicodeError: Message objects do not support str()
because they may contain non-ascii characters. Please use unicode() or
translate() instead.
http://logs.openstack.org/63/102863/1/check/gate-glance-
python27/6ad16a3/console.html
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVW5pY29kZUVycm9yOiBNZXNzYWdlIG9iamVjdHMgZG8gbm90IHN1cHBvcnQgc3RyKCkgYmVjYXVzZSB0aGV5IG1heSBjb250YWluIG5vbi1hc2NpaSBjaGFyYWN0ZXJzLiBQbGVhc2UgdXNlIHVuaWNvZGUoKSBvciB0cmFuc2xhdGUoKSBpbnN0ZWFkLlwiIEFORCB0YWdzOmNvbnNvbGUgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svZ2xhbmNlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDM4MDQ5ODkwMDZ9
There is a gettextutils sync here:
https://review.openstack.org/#/c/91047/
But that didn't hit this in the check queue, but hit it after being
approved.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1334774/+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 1334779] [NEW] db_sync breaks in non-utf8 databases on region table
Public bug reported: The migration that creates the region table does not explicitly set utf8 so if the database default is not set, then db_sync fails with the following error: 2014-06-26 17:00:48.231 965 CRITICAL keystone [-] ValueError: Tables "region" have non utf8 collation, please make sure all tables are CHARSET=utf8 2014-06-26 17:00:48.231 965 TRACE keystone Traceback (most recent call last): 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/bin/keystone-manage", line 51, in 2014-06-26 17:00:48.231 965 TRACE keystone cli.main(argv=sys.argv, config_files=config_files) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 191, in main 2014-06-26 17:00:48.231 965 TRACE keystone CONF.command.cmd_class.main() 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 67, in main 2014-06-26 17:00:48.231 965 TRACE keystone migration_helpers.sync_database_to_version(extension, version) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration_helpers.py", line 139, in sync_database_to_version 2014-06-26 17:00:48.231 965 TRACE keystone migration.db_sync(sql.get_engine(), abs_path, version=version) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/db/sqlalchemy/migration.py", line 195, in db_sync 2014-06-26 17:00:48.231 965 TRACE keystone _db_schema_sanity_check(engine) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/db/sqlalchemy/migration.py", line 228, in _db_schema_sanity_check 2014-06-26 17:00:48.231 965 TRACE keystone ) % ','.join(table_names)) 2014-06-26 17:00:48.231 965 TRACE keystone ValueError: Tables "region" have non utf8 collation, please make sure all tables are CHARSET=utf8 2014-06-26 17:00:48.231 965 TRACE keystone ** Affects: keystone Importance: Undecided Status: New ** Tags: icehouse-backport-potential ** Tags added: icehouse-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1334779 Title: db_sync breaks in non-utf8 databases on region table Status in OpenStack Identity (Keystone): New Bug description: The migration that creates the region table does not explicitly set utf8 so if the database default is not set, then db_sync fails with the following error: 2014-06-26 17:00:48.231 965 CRITICAL keystone [-] ValueError: Tables "region" have non utf8 collation, please make sure all tables are CHARSET=utf8 2014-06-26 17:00:48.231 965 TRACE keystone Traceback (most recent call last): 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/bin/keystone-manage", line 51, in 2014-06-26 17:00:48.231 965 TRACE keystone cli.main(argv=sys.argv, config_files=config_files) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 191, in main 2014-06-26 17:00:48.231 965 TRACE keystone CONF.command.cmd_class.main() 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 67, in main 2014-06-26 17:00:48.231 965 TRACE keystone migration_helpers.sync_database_to_version(extension, version) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration_helpers.py", line 139, in sync_database_to_version 2014-06-26 17:00:48.231 965 TRACE keystone migration.db_sync(sql.get_engine(), abs_path, version=version) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/db/sqlalchemy/migration.py", line 195, in db_sync 2014-06-26 17:00:48.231 965 TRACE keystone _db_schema_sanity_check(engine) 2014-06-26 17:00:48.231 965 TRACE keystone File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/db/sqlalchemy/migration.py", line 228, in _db_schema_sanity_check 2014-06-26 17:00:48.231 965 TRACE keystone ) % ','.join(table_names)) 2014-06-26 17:00:48.231 965 TRACE keystone ValueError: Tables "region" have non utf8 collation, please make sure all tables are CHARSET=utf8 2014-06-26 17:00:48.231 965 TRACE keystone To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1334779/+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 1334791] [NEW] horizon not writing region when generating openrc file
Public bug reported: When generating the openrc file, Horizon is not setting the OS_REGION_NAME. It's not even in the template file, which explains why it doesn't work. openstack_dashboard/dashboards/project/access_and_security/templates/access_and_security/api_access/openrc.sh.template ** 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/1334791 Title: horizon not writing region when generating openrc file Status in OpenStack Dashboard (Horizon): New Bug description: When generating the openrc file, Horizon is not setting the OS_REGION_NAME. It's not even in the template file, which explains why it doesn't work. openstack_dashboard/dashboards/project/access_and_security/templates/access_and_security/api_access/openrc.sh.template To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334791/+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 1334798] [NEW] Gate test is masking failure details
Public bug reported:
Both the 2.6 and 2.7 gate tests are failing, console log indicating two
failures, but only showing one failure 'process-retcode'. When looking
at testr_results it shows a fail and only mentions:
ft1.12873:
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used_StringException
Here is 2.7 logs: http://logs.openstack.org/51/102351/4/check/gate-
neutron-python27/a757b36/
Upon future investigation, it was found that there was non-printable
characters in an oslo file. With manual testing, it shows the error:
$ python -m neutron.openstack.common.lockutils python -m unittest
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
F
==
FAIL: test_reference_driver_used
(neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection)
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
--
_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
traceback-1: {{{
Traceback (most recent call last):
File "neutron/common/rpc.py", line 63, in cleanup
assert TRANSPORT is not None
AssertionError
}}}
Traceback (most recent call last):
File "neutron/tests/unit/services/vpn/service_drivers/test_ipsec.py", line
52, in setUp
super(TestValidatorSelection, self).setUp()
File "neutron/tests/base.py", line 188, in setUp
n_rpc.init(CONF)
File "neutron/common/rpc.py", line 56, in init
aliases=TRANSPORT_ALIASES)
File "/opt/stack/oslo.messaging/oslo/messaging/transport.py", line 185, in
get_transport
invoke_kwds=kwargs)
File "/opt/stack/stevedore/stevedore/driver.py", line 45, in __init__
verify_requirements=verify_requirements,
File "/opt/stack/stevedore/stevedore/named.py", line 55, in __init__
verify_requirements)
File "/opt/stack/stevedore/stevedore/extension.py", line 170, in _load_plugins
self._on_load_failure_callback(self, ep, err)
File "/opt/stack/stevedore/stevedore/driver.py", line 50, in
_default_on_load_failure
raise err
File "/opt/stack/oslo.messaging/oslo/messaging/_drivers/impl_fake.py", line 48
SyntaxError: Non-ASCII character '\xc2' in file
/opt/stack/oslo.messaging/oslo/messaging/_drivers/impl_fake.py on line 48, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for details
A fix will be done for the oslo error, but we need to investigate why
the gate test does not show any information on the error.
** 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/1334798
Title:
Gate test is masking failure details
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Both the 2.6 and 2.7 gate tests are failing, console log indicating
two failures, but only showing one failure 'process-retcode'. When
looking at testr_results it shows a fail and only mentions:
ft1.12873:
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used_StringException
Here is 2.7 logs: http://logs.openstack.org/51/102351/4/check/gate-
neutron-python27/a757b36/
Upon future investigation, it was found that there was non-printable
characters in an oslo file. With manual testing, it shows the error:
$ python -m neutron.openstack.common.lockutils python -m unittest
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
F
==
FAIL: test_reference_driver_used
(neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection)
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
--
_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
traceback-1: {{{
Traceback (most recent call last):
File "neutron/common/rpc.py", line 63, in cleanup
assert TRANSPORT is not None
AssertionError
}}}
Traceback (most recent call last):
File "neutron/tests/unit/services/vpn/service_drivers/test_ipsec.py", line
52, in setUp
super(TestValidatorSelection, self).setUp()
File "neutron/tests/base.py", line 188, in setUp
n_rpc.init(CONF)
File "neutron/common/rpc.py", line 56, in init
aliases=TRANSPORT_ALIASES)
File "/opt/stack/oslo.messaging/oslo/messaging/transport.py", line 185, in
get_transport
invoke_kwds=kwargs)
File "/opt/stack/stevedore/stevedore/driver.py", line 45,
[Yahoo-eng-team] [Bug 1334466] Re: Eventlet Log Spamming on Client Disconnect (Broken Pipe)
Targeted to Icehouse based upon original request from -infra.
** Also affects: keystone/icehouse
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1334466
Title:
Eventlet Log Spamming on Client Disconnect (Broken Pipe)
Status in OpenStack Identity (Keystone):
In Progress
Status in Keystone icehouse series:
In Progress
Bug description:
If a client makes a request to keystone, and then disconnects before
keystone responds, it is possible to fill up the logs (INFO) with
eventlet tracebacks due to broken pipe:
2014-06-24 23:30:29.729 31440 INFO eventlet.wsgi.server [-] 127.0.0.1 - -
[24/Jun/2014 23:30:29] "POST /v3/auth/tokens HTTP/1.1" 201 0 100.313719
2014-06-24 23:30:29.731 31440 INFO eventlet.wsgi.server [-] Traceback (most
recent call last):
File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 399, in
handle_one_response
write(''.join(towrite))
File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 349, in write
_writelines(towrite)
File "/usr/lib/python2.7/socket.py", line 334, in writelines
self.flush()
File "/usr/lib/python2.7/socket.py", line 303, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
File "/usr/lib/python2.7/dist-packages/eventlet/greenio.py", line 307, in
sendall
tail = self.send(data, flags)
File "/usr/lib/python2.7/dist-packages/eventlet/greenio.py", line 293, in
send
total_sent += fd.send(data[total_sent:], flags)
error: [Errno 32] Broken pipe
Example (900k line file) due to this [WARNING THIS LINK MIGHT KILL YOUR
BROWSER]:
http://logs.openstack.org/66/99766/2/check/check-grenade-dsvm/9fd33e1/logs/old/screen-key.txt.gz?level=INFO
We should override the required HTTPProtocol class and gracefully
handle the traceback. If we would like to keep the information, a
single log-line per incident would be sufficient instead of ~14.
This should be considered for a backport to Icehouse to help limit log
spam there as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1334466/+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 1334846] [NEW] can not delete metadata key using aggregate-set-metadata
Public bug reported: before i updated to latest code base ( my branch was i guess 20 days old) i was able to delete metadata from the list using nova aggregate-set-metadata id "key" and add metadata by nova aggregate-set-metadata id "key=value" I am still abel to add but seems like the recent changes have messed up the delete this is what is see now:- njain@njain3:~/projects/devstack$ nova aggregate-set-metadata 2 "s=9" Metadata has been successfully updated for aggregate 2. ++--+---+---+-+ | Id | Name | Availability Zone | Hosts | Metadata| ++--+---+---+-+ | 2 | 2| - | | 'k=9', 's=9', 't=k' | ++--+---+---+-+ njain@njain3:~/projects/devstack$ nova aggregate-set-metadata 2 "s" ERROR (BadRequest): metadata.value is not a string or unicode (HTTP 400) (Request-ID: req-bf6dca91-d89e-4956-997c-1248c50fda56) njain@njain3:~/projects/devstack$ nova aggregate-set-metadata 2 s ERROR (BadRequest): metadata.value is not a string or unicode (HTTP 400) (Request-ID: req-14b9a48d-8e96-4a54-861a-fd52ea693abe) ** Affects: nova Importance: Undecided Status: New ** Tags: nova-api -- 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/1334846 Title: can not delete metadata key using aggregate-set-metadata Status in OpenStack Compute (Nova): New Bug description: before i updated to latest code base ( my branch was i guess 20 days old) i was able to delete metadata from the list using nova aggregate-set-metadata id "key" and add metadata by nova aggregate-set-metadata id "key=value" I am still abel to add but seems like the recent changes have messed up the delete this is what is see now:- njain@njain3:~/projects/devstack$ nova aggregate-set-metadata 2 "s=9" Metadata has been successfully updated for aggregate 2. ++--+---+---+-+ | Id | Name | Availability Zone | Hosts | Metadata| ++--+---+---+-+ | 2 | 2| - | | 'k=9', 's=9', 't=k' | ++--+---+---+-+ njain@njain3:~/projects/devstack$ nova aggregate-set-metadata 2 "s" ERROR (BadRequest): metadata.value is not a string or unicode (HTTP 400) (Request-ID: req-bf6dca91-d89e-4956-997c-1248c50fda56) njain@njain3:~/projects/devstack$ nova aggregate-set-metadata 2 s ERROR (BadRequest): metadata.value is not a string or unicode (HTTP 400) (Request-ID: req-14b9a48d-8e96-4a54-861a-fd52ea693abe) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334846/+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 1334857] [NEW] EC2 metadata retuns ip of instance and ip of nova-api service node
Public bug reported: curl -vL http://169.254.169.254/latest/meta-data/local-ipv4/ * About to connect() to 169.254.169.254 port 80 (#0) * Trying 169.254.169.254... connected * Connected to 169.254.169.254 (169.254.169.254) port 80 (#0) > GET /latest/meta-data/local-ipv4/ HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 > zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: 169.254.169.254 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/html; charset=UTF-8 < Content-Length: 12 < Date: Sun, 22 Jun 2014 15:15:52 GMT < * Connection #0 to host 169.254.169.254 left intact * Closing connection #0 192.168.0.22, 10.2.0.50 192.168.0.22 - instance ip 10.2.0.50 - controller ip Happens only for /latest/meta-data/local-ipv4/ Quick investigation shows that the issue is caused by https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L243 (https://github.com/openstack/nova/blo...) 'local-ipv4': self.address or fixed_ip, string self.address variable contains "192.168.0.22, 10.2.0.50" while fixed_ip contains correct "192.168.0.22" value. The workaround is: swapping those two variables: 'local-ipv4': fixed_ip or self.address, and restart of all nova-compute services ** Affects: nova Importance: Undecided Status: New ** Tags: ec2 -- 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/1334857 Title: EC2 metadata retuns ip of instance and ip of nova-api service node Status in OpenStack Compute (Nova): New Bug description: curl -vL http://169.254.169.254/latest/meta-data/local-ipv4/ * About to connect() to 169.254.169.254 port 80 (#0) * Trying 169.254.169.254... connected * Connected to 169.254.169.254 (169.254.169.254) port 80 (#0) > GET /latest/meta-data/local-ipv4/ HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: 169.254.169.254 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/html; charset=UTF-8 < Content-Length: 12 < Date: Sun, 22 Jun 2014 15:15:52 GMT < * Connection #0 to host 169.254.169.254 left intact * Closing connection #0 192.168.0.22, 10.2.0.50 192.168.0.22 - instance ip 10.2.0.50 - controller ip Happens only for /latest/meta-data/local-ipv4/ Quick investigation shows that the issue is caused by https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L243 (https://github.com/openstack/nova/blo...) 'local-ipv4': self.address or fixed_ip, string self.address variable contains "192.168.0.22, 10.2.0.50" while fixed_ip contains correct "192.168.0.22" value. The workaround is: swapping those two variables: 'local-ipv4': fixed_ip or self.address, and restart of all nova-compute services To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334857/+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 856764] Re: RabbitMQ connections lack heartbeat or TCP keepalives
** Also affects: cinder 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/856764 Title: RabbitMQ connections lack heartbeat or TCP keepalives Status in OpenStack Telemetry (Ceilometer): In Progress Status in Ceilometer icehouse series: Fix Released Status in Cinder: New Status in Orchestration API (Heat): Confirmed Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Invalid Status in Oslo - a Library of Common OpenStack Code: In Progress Status in Messaging API for OpenStack: In Progress Bug description: There is currently no method built into Nova to keep connections from various components into RabbitMQ alive. As a result, placing a stateful firewall (such as a Cisco ASA) between the connection can/does result in idle connections being terminated without either endpoint being aware. This issue can be mitigated a few different ways: 1. Connections to RabbitMQ set socket options to enable TCP keepalives. 2. Rabbit has heartbeat functionality. If the client requests heartbeats on connection, rabbit server will regularly send messages to each connections with the expectation of a response. 3. Other? To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/856764/+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 1219658] Re: Wrong image size using rbd backend for libvirt
** Project changed: nova => nova (Ubuntu) -- 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/1219658 Title: Wrong image size using rbd backend for libvirt Status in OpenStack Compute (nova) havana series: In Progress Status in “nova” package in Ubuntu: In Progress Bug description: [Impact] * [2cebfd2] libvirt: convert cpu features attribute from list to a set (LP: #1267191) cpu features list which is being sent to libvirt, when creating a domain or calling compareCPU, must contain only unique entries. Multiple issues arise when we are updating the features attribute in LibvirtConfigCPU class (for example during migration). * [b86a0e5] Fixes rdb backend image size (LP: #1219658) -> THIS! The original fix for bug 1219658 introduced a factor of 1024 error in the resulting rbd image size -> real urgent to be fixed. [Test Case] LP: #1267191 * systemctl restart openstack-nova-compute Observe /var/log/nova/compute.log LP: #1219658 * Testing this fix implies only in having rdb backend. [Regression Potential] * Tests indicate fix is running in a big production without any problem. LP: #1267191 * A regression would continue to cause nova not to start (as is happening today with this bug under described conditions). LP: #1219658 * RDB backend could stop working (keeping the bug will eventualy cause an outage for those who use rdb backend) [Other Info] For rbd image backend for libvirt, the root partition will use the image size not 'disk' size. It lack of resize root volume in the codes. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/havana/+bug/1219658/+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 1334876] [NEW] Horizon: Launch Instance dialog doesn't fit window size
Public bug reported: Description of problem: == 'Launch Instance' dialog doesn't fit window size, so user need to scrole Version-Release number of selected component: = python-django-horizon-2014.1-7.el7ost.noarch openstack-dashboard-2014.1-7.el7ost.noarch openstack-dashboard-theme-2014.1-7.el7ost.noarch How reproducible: === 100% Steps to Reproduce: 1. Click 'Project' --> 'Compute' --> 'Instances' 2. Click 'Launch Instance' 3. From 'Instance Boot Source' select 'Boot from image (create a new volume)' Actual results: = Dialog doesn't fit window size A screenshot is enclosed Expected results: === The dialog should fit window size ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Screenshot-Launch Instances.png" https://bugs.launchpad.net/bugs/1334876/+attachment/4140054/+files/Screenshot-Launch%20Instances.png -- 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/1334876 Title: Horizon: Launch Instance dialog doesn't fit window size Status in OpenStack Dashboard (Horizon): New Bug description: Description of problem: == 'Launch Instance' dialog doesn't fit window size, so user need to scrole Version-Release number of selected component: = python-django-horizon-2014.1-7.el7ost.noarch openstack-dashboard-2014.1-7.el7ost.noarch openstack-dashboard-theme-2014.1-7.el7ost.noarch How reproducible: === 100% Steps to Reproduce: 1. Click 'Project' --> 'Compute' --> 'Instances' 2. Click 'Launch Instance' 3. From 'Instance Boot Source' select 'Boot from image (create a new volume)' Actual results: = Dialog doesn't fit window size A screenshot is enclosed Expected results: === The dialog should fit window size To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334876/+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 1334897] [NEW] Horizon: Edit Project dialog doesn't fit window size
Public bug reported: Description of problem: === 'Edit Project' dialog doesn't fit window size, so user need to scrole Version-Release number of selected component: = python-django-horizon-2014.1-7.el7ost.noarch openstack-dashboard-2014.1-7.el7ost.noarch openstack-dashboard-theme-2014.1-7.el7ost.noarch How reproducible: = 100% Steps to Reproduce: === 1. Login to Horizon 1. Click 'Admin' --> 'Identity Panel' --> 'Projects' 2. On created project click 'More' --> 'Edit Project' 3. On 'Edit Project' click 'Quota' Actual results: === 1. Dialog doesn't fit window size 2. There is no scroll bar on the dialog. 3. scrolling done on both dialog and the background window Expected results: = 1. The dialog should fit window size. 2. If it is large there should be a scroll bar on the right size. 3. Scrolling done on upper window only. Additional info: A screenshot is enclosed ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "'Edit Project' dialog" https://bugs.launchpad.net/bugs/1334897/+attachment/4140089/+files/Screenshot-Projects.png -- 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/1334897 Title: Horizon: Edit Project dialog doesn't fit window size Status in OpenStack Dashboard (Horizon): New Bug description: Description of problem: === 'Edit Project' dialog doesn't fit window size, so user need to scrole Version-Release number of selected component: = python-django-horizon-2014.1-7.el7ost.noarch openstack-dashboard-2014.1-7.el7ost.noarch openstack-dashboard-theme-2014.1-7.el7ost.noarch How reproducible: = 100% Steps to Reproduce: === 1. Login to Horizon 1. Click 'Admin' --> 'Identity Panel' --> 'Projects' 2. On created project click 'More' --> 'Edit Project' 3. On 'Edit Project' click 'Quota' Actual results: === 1. Dialog doesn't fit window size 2. There is no scroll bar on the dialog. 3. scrolling done on both dialog and the background window Expected results: = 1. The dialog should fit window size. 2. If it is large there should be a scroll bar on the right size. 3. Scrolling done on upper window only. Additional info: A screenshot is enclosed To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334897/+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 1334903] [NEW] Should use 403 status code instead of 413 when out of quota
Public bug reported: We should fix the remaining API cases where the 413 status code is used instead of 403 when the failure is due to running out of quota ** Affects: nova Importance: Low Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1334903 Title: Should use 403 status code instead of 413 when out of quota Status in OpenStack Compute (Nova): New Bug description: We should fix the remaining API cases where the 413 status code is used instead of 403 when the failure is due to running out of quota To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334903/+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 1334904] [NEW] Add required libs in requirements.txt to enable sphinx doc generation
Public bug reported: There are additional python libraries missing in the requirements.txt inside the root of the horizon repo. I had to install these libraries in order for the "make html" build script to work on the docs/ repo. Let's put those libraries inside the requirements.txt. ** Affects: horizon Importance: Undecided Status: New ** Tags: documentation -- 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/1334904 Title: Add required libs in requirements.txt to enable sphinx doc generation Status in OpenStack Dashboard (Horizon): New Bug description: There are additional python libraries missing in the requirements.txt inside the root of the horizon repo. I had to install these libraries in order for the "make html" build script to work on the docs/ repo. Let's put those libraries inside the requirements.txt. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334904/+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 1334910] [NEW] read-only form text fields should be more apparent
Public bug reported: For example: Projects > Volumes > Extend Volume modal The 'Current Size' field is readonly/disabled, but it looks the same as the 'New Size' field unless you hover over it (you will see a red cancel cursor) Admin > Images > Update Image modal Kernel ID Ramdisk ID Architecture Format ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Untitled.png" https://bugs.launchpad.net/bugs/1334910/+attachment/4140101/+files/Untitled.png ** Summary changed: - disabled form text fields should be more apparent + read-only form text fields should be more apparent ** Description changed: For example: Projects > Volumes > Extend Volume modal - The 'Current Size' field is disabled, but it looks the same as the 'New Size' field unless you hover over it (you will see a red cancel cursor) - + The 'Current Size' field is readonly/disabled, but it looks the same as the 'New Size' field unless you hover over it (you will see a red cancel cursor) Admin > Images > Update Image modal Kernel ID Ramdisk ID Architecture Format -- 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/1334910 Title: read-only form text fields should be more apparent Status in OpenStack Dashboard (Horizon): New Bug description: For example: Projects > Volumes > Extend Volume modal The 'Current Size' field is readonly/disabled, but it looks the same as the 'New Size' field unless you hover over it (you will see a red cancel cursor) Admin > Images > Update Image modal Kernel ID Ramdisk ID Architecture Format To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334910/+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 1334915] [NEW] Minor grammatical error in using-api-v2.rst
Public bug reported: In the Introduction section, the sentence "You obtain access to managers through via attributes of the keystoneclient.v2_0.client.Client object. " contains an extra word. ** Affects: keystone Importance: Undecided Status: New ** Tags: documentation low-hanging-fruit -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1334915 Title: Minor grammatical error in using-api-v2.rst Status in OpenStack Identity (Keystone): New Bug description: In the Introduction section, the sentence "You obtain access to managers through via attributes of the keystoneclient.v2_0.client.Client object. " contains an extra word. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1334915/+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 1334922] [NEW] agent functional tests reference incorrect MAX_LEN constant
Public bug reported: File "neutron/neutron/tests/functional/agent/linux/base.py", line 59, in create_resource name = self.get_rand_name(n_const.DEV_NAME_MAX_LEN, name_prefix) AttributeError: 'module' object has no attribute 'DEV_NAME_MAX_LEN' ** Affects: neutron Importance: Undecided Assignee: Henry Gessau (gessau) Status: New ** Changed in: neutron Assignee: (unassigned) => Henry Gessau (gessau) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334922 Title: agent functional tests reference incorrect MAX_LEN constant Status in OpenStack Neutron (virtual network service): New Bug description: File "neutron/neutron/tests/functional/agent/linux/base.py", line 59, in create_resource name = self.get_rand_name(n_const.DEV_NAME_MAX_LEN, name_prefix) AttributeError: 'module' object has no attribute 'DEV_NAME_MAX_LEN' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334922/+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 1334923] [NEW] No need to backup instance when 'rotation' equals to 0
Public bug reported: Nova will delete all backup images according the 'backup_type' parameter when 'rotation' equals to 0. But according the logic now, Nova will generate one new backup, and then delete it.. So It's weird to snapshot a useless backup firstly IMO. We need to add one new branch here: if 'rotation' is equal to 0, no need to backup, just rotate it. The related discussion can be found here: http://lists.openstack.org/pipermail/openstack-dev/2014-June/038760.html ** Affects: nova Importance: Undecided Assignee: wingwj (wingwj) Status: New ** Changed in: nova Assignee: (unassigned) => wingwj (wingwj) ** Description changed: Nova will delete all backup images according the 'backup_type' parameter when 'rotation' equals to 0. But according the logic now, Nova will generate one new backup, and then delete it.. - So It's weird to snapshot a useless backup firstly IMO. + So It's weird to snapshot a useless backup firstly IMO. We need to add one new branch here: if 'rotation' is equal to 0, no need to backup, just rotate it. - Relate discussions can be found here: + The related discussion can be found here: http://lists.openstack.org/pipermail/openstack-dev/2014-June/038760.html -- 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/1334923 Title: No need to backup instance when 'rotation' equals to 0 Status in OpenStack Compute (Nova): New Bug description: Nova will delete all backup images according the 'backup_type' parameter when 'rotation' equals to 0. But according the logic now, Nova will generate one new backup, and then delete it.. So It's weird to snapshot a useless backup firstly IMO. We need to add one new branch here: if 'rotation' is equal to 0, no need to backup, just rotate it. The related discussion can be found here: http://lists.openstack.org/pipermail/openstack-dev/2014-June/038760.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334923/+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 1334926] [NEW] floatingip still working once connected even after it is disociated
Public bug reported: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid ** Affects: neutron Importance: Undecided Assignee: yong sheng gong (gongysh) Status: New ** Changed in: neutron Assignee: (unassigned) => yong sheng gong (gongysh) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+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 1334929] [NEW] Need to add a new task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'
Public bug reported: Now there's a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'. So if compute node is rebooted after that procession, all building VMs on it will always stay in 'None' task_state. And it's useless and not convenient for locating problems. Therefore, we need to add one new task_state(like 'STARTING_BUILD') for that period. This new task_state also needs to be added in the Doc. The related discussion could be found here: http://lists.openstack.org/pipermail/openstack-dev/2014-June/038638.html ** Affects: nova Importance: Undecided Assignee: wingwj (wingwj) Status: New ** Changed in: nova Assignee: (unassigned) => wingwj (wingwj) -- 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/1334929 Title: Need to add a new task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING' Status in OpenStack Compute (Nova): New Bug description: Now there's a 'None' task_state between 'SCHEDULING' & 'BLOCK_DEVICE_MAPPING'. So if compute node is rebooted after that procession, all building VMs on it will always stay in 'None' task_state. And it's useless and not convenient for locating problems. Therefore, we need to add one new task_state(like 'STARTING_BUILD') for that period. This new task_state also needs to be added in the Doc. The related discussion could be found here: http://lists.openstack.org/pipermail/openstack-dev/2014-June/038638.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334929/+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 1334938] [NEW] established floating ip connection won't get disconnected after disassociating floating ip
Public bug reported: Established connections via floating ip won't get disconnected after we disassociating that floating ip. As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to remove_floating_ip. https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575 ** Affects: nova Importance: Undecided Assignee: stanzgy (stanzgy) Status: New ** Tags: network ** Changed in: nova Assignee: (unassigned) => stanzgy (stanzgy) ** Tags added: network -- 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/1334938 Title: established floating ip connection won't get disconnected after disassociating floating ip Status in OpenStack Compute (Nova): New Bug description: Established connections via floating ip won't get disconnected after we disassociating that floating ip. As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to remove_floating_ip. https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334938/+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 1334941] [NEW] Send error notifications on reschedule failures
Public bug reported: No error notifications are sent when VMs are re-scheduled. However when re-schedule failed three times or the specified times, it will lead to NoValidHost errors.select_destinations function also lead to NoValidHost errors, For user, they can not distinguish. ** Affects: nova Importance: Undecided Assignee: lizheming (lizheming-li) Status: New ** Changed in: nova Assignee: (unassigned) => lizheming (lizheming-li) -- 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/1334941 Title: Send error notifications on reschedule failures Status in OpenStack Compute (Nova): New Bug description: No error notifications are sent when VMs are re-scheduled. However when re-schedule failed three times or the specified times, it will lead to NoValidHost errors.select_destinations function also lead to NoValidHost errors, For user, they can not distinguish. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334941/+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 1334965] [NEW] the headroom infomation is wrong in the method of limit_check
Public bug reported:
If multiple resources beyond the quotas , the headroom information about the
resources beyond the quotas is incomplete(quota.py).
for example:
If the lens of path and content of the injected files exceed the limits, the
above situation will appear.
2014-06-27 12:14:04.241 4547 INFO nova.quota
[req-a94185e5-779f-4455-ba45-230eb70fb774 None] overs:
['injected_file_content_bytes', 'injected_file_path_bytes']
2014-06-27 12:14:04.241 4547 INFO nova.quota
[req-a94185e5-779f-4455-ba45-230eb70fb774 None] headroom:
{'injected_file_path_bytes': 255}
** Affects: nova
Importance: Undecided
Status: New
** Tags: quota
--
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/1334965
Title:
the headroom infomation is wrong in the method of limit_check
Status in OpenStack Compute (Nova):
New
Bug description:
If multiple resources beyond the quotas , the headroom information about
the resources beyond the quotas is incomplete(quota.py).
for example:
If the lens of path and content of the injected files exceed the limits,
the above situation will appear.
2014-06-27 12:14:04.241 4547 INFO nova.quota
[req-a94185e5-779f-4455-ba45-230eb70fb774 None] overs:
['injected_file_content_bytes', 'injected_file_path_bytes']
2014-06-27 12:14:04.241 4547 INFO nova.quota
[req-a94185e5-779f-4455-ba45-230eb70fb774 None] headroom:
{'injected_file_path_bytes': 255}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1334965/+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 1334974] [NEW] create vm fail by volume when use diskfilter
Public bug reported: I configed the diskfilter in nova.conf,i created vm by a bootable volume and use the back-end storage , the vm flavor is following: cpu 1 mem 2G root_gb 2T In fact , the local disk in computer node is 80G, so i create vm that remind no available host; I think , i create vm by volume and use back-end storage, the diskfilter should not be chose the host by local disk size. In addition,the compute node report the resource info that shoud check the instance status, if it createdby a volume ,the local_gb_used shoud not add the flavor's root_db size. ** Affects: nova Importance: Undecided Status: New ** Tags: filter -- 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/1334974 Title: create vm fail by volume when use diskfilter Status in OpenStack Compute (Nova): New Bug description: I configed the diskfilter in nova.conf,i created vm by a bootable volume and use the back-end storage , the vm flavor is following: cpu 1 mem 2G root_gb 2T In fact , the local disk in computer node is 80G, so i create vm that remind no available host; I think , i create vm by volume and use back-end storage, the diskfilter should not be chose the host by local disk size. In addition,the compute node report the resource info that shoud check the instance status, if it createdby a volume ,the local_gb_used shoud not add the flavor's root_db size. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334974/+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 1334981] [NEW] [FWaaS]: Not able to delete the firewall with shared policy and unshared rule
Public bug reported:
Steps to reproduce:
1. As admin, create a rule r1(unshared) and associate it to the shared policy
p1
2. As a tenant1, try to create firewall f1 with policy p1
3. It thows error but f1 got created
4. We cann't even delete the created firewall f1
console:
===
root@koti-icega-osc:/usr/share/pyshared/neutron# echo $OS_USERNAME
user1
root@koti-icega-osc:/usr/share/pyshared/neutron#
root@koti-icega-osc:/usr/share/pyshared/neutron# neutron firewall-policy-list
+--+--++
| id | name | firewall_rules
|
+--+--++
| 367ff338-1014-4788-9cd9-d9d60035dd52 | p1 |
[d9247da7-b885-4a16-974a-2b56e76f89d1] |
+--+--++
root@koti-icega-osc:/usr/share/pyshared/neutron# neutron firewall-create p1
--name f1
404-{u'NeutronError': {u'message': u'Firewall Rule
d9247da7-b885-4a16-974a-2b56e76f89d1 could not be found.', u'type':
u'FirewallRuleNotFound', u'detail': u''}}<
