[Yahoo-eng-team] [Bug 1369239] [NEW] OpenDaylight MD should not ignore 400 errors
Public bug reported: 400 (Bad Request) errors are ignored in every create or update operation to OpenDaylight. Referring to the comment, it protects against conflicts with already existing resources. In case of update operations, it seems irrelevant and masks real bad requests. It could also be removed in create operations. ** Affects: neutron Importance: Undecided Status: New ** Tags: icehouse-backport-potential opendaylight -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1369239 Title: OpenDaylight MD should not ignore 400 errors Status in OpenStack Neutron (virtual network service): New Bug description: 400 (Bad Request) errors are ignored in every create or update operation to OpenDaylight. Referring to the comment, it protects against conflicts with already existing resources. In case of update operations, it seems irrelevant and masks real bad requests. It could also be removed in create operations. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1369239/+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 1369248] [NEW] No existing metadata in Available Metadata menu
Public bug reported: Admin - Image - Update Metadata menu was added in Juno-RC1. If all metadata items are added to Existing metadata, No existing metadata will be shown in Available Metadata menu. It should be No available metadata. ** Affects: horizon Importance: Low Status: New ** Tags: glance -- 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/1369248 Title: No existing metadata in Available Metadata menu Status in OpenStack Dashboard (Horizon): New Bug description: Admin - Image - Update Metadata menu was added in Juno-RC1. If all metadata items are added to Existing metadata, No existing metadata will be shown in Available Metadata menu. It should be No available metadata. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369248/+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 1369254] [NEW] VMware: driver does not create a ephemeral disk when disk is defined in flavor
Public bug reported: When a flavor contains a ephemeral disk definition the driver does not create the disk ** Affects: nova Importance: High Assignee: Gary Kotton (garyk) Status: In Progress ** Tags: vmware ** Changed in: nova Importance: Undecided = High ** Changed in: nova Assignee: (unassigned) = Gary Kotton (garyk) ** Tags added: vmware -- 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/1369254 Title: VMware: driver does not create a ephemeral disk when disk is defined in flavor Status in OpenStack Compute (Nova): In Progress Bug description: When a flavor contains a ephemeral disk definition the driver does not create the disk To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369254/+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 1369260] [NEW] network-vif-plugged events should be Info on nova compute
Public bug reported:
Version
===
IceHouse on rhel
Description
===
In order to track network-vif-plugged events across openetsack :
Nova-API send event network-vif-plugged under AUDIT level ,
AUDIT nova.api.openstack.compute.contrib.server_external_events [req-
7bd8ca07-a133-4b57-a6e3-a4340115475d ca48398ab5f244e3bdfb798f94920fd1
d7e1cf5e67804ef0b8e27329a38105ef] Creating event network-vif-plugged
Neutron server shos
INFO neutron.notifiers.nova [-] Nova event response: {u'status': u'completed',
u'tag': u'd883de4f-9c05-4f49-9125-316708d36d4d', u'name':
u'network-vif-plugged', u'server_uuid':
u'fea1a088-212a-4e08-baa5-f745d9bf2cca', u'code': 200}
BUT nova compute shows event network-vif-plugged only on DEBUG,
IMHO it should be Info/Audit level as well so we can track that NOVA-API
created event to neutron and compute processed that event
Current level on compute :
DEBUG nova.compute.manager [req-7bd8ca07-a133-4b57-a6e3-a4340115475d
ca48398ab5f244e3bdfb798f94920fd1 d7e1cf5e67804ef0b8e27329a38105ef] [instance:
fea1a088-212a-4e08-baa5-f745d9bf2cca] Processing event
network-vif-plugged-d883de4f-9c05-4f49-9125-316708d36d4d
_process_instance_event
/usr/lib/python2.7/site-packages/nova/compute/manager.py:5665
** 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/1369260
Title:
network-vif-plugged events should be Info on nova compute
Status in OpenStack Compute (Nova):
New
Bug description:
Version
===
IceHouse on rhel
Description
===
In order to track network-vif-plugged events across openetsack :
Nova-API send event network-vif-plugged under AUDIT level ,
AUDIT nova.api.openstack.compute.contrib.server_external_events
[req-7bd8ca07-a133-4b57-a6e3-a4340115475d
ca48398ab5f244e3bdfb798f94920fd1 d7e1cf5e67804ef0b8e27329a38105ef]
Creating event network-vif-plugged
Neutron server shos
INFO neutron.notifiers.nova [-] Nova event response: {u'status':
u'completed', u'tag': u'd883de4f-9c05-4f49-9125-316708d36d4d', u'name':
u'network-vif-plugged', u'server_uuid':
u'fea1a088-212a-4e08-baa5-f745d9bf2cca', u'code': 200}
BUT nova compute shows event network-vif-plugged only on DEBUG,
IMHO it should be Info/Audit level as well so we can track that NOVA-API
created event to neutron and compute processed that event
Current level on compute :
DEBUG nova.compute.manager [req-7bd8ca07-a133-4b57-a6e3-a4340115475d
ca48398ab5f244e3bdfb798f94920fd1 d7e1cf5e67804ef0b8e27329a38105ef] [instance:
fea1a088-212a-4e08-baa5-f745d9bf2cca] Processing event
network-vif-plugged-d883de4f-9c05-4f49-9125-316708d36d4d
_process_instance_event
/usr/lib/python2.7/site-packages/nova/compute/manager.py:5665
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1369260/+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 1369266] [NEW] HA router priority should be according to configurable priority of L3-agent
Public bug reported: Currently all instances have the same priority (hard coded 50) Admin should be able to assign priority to l3-agents so that Master will be chosen accordingly (suppose that you have an agent with smaller bandwidth than others, you would like it to have the least amount possible of active (Master) instances. This will require extending the L3-agent API This is blocked by bug: https://bugs.launchpad.net/neutron/+bug/1365429 ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ha ** Tags added: l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1369266 Title: HA router priority should be according to configurable priority of L3-agent Status in OpenStack Neutron (virtual network service): New Bug description: Currently all instances have the same priority (hard coded 50) Admin should be able to assign priority to l3-agents so that Master will be chosen accordingly (suppose that you have an agent with smaller bandwidth than others, you would like it to have the least amount possible of active (Master) instances. This will require extending the L3-agent API This is blocked by bug: https://bugs.launchpad.net/neutron/+bug/1365429 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1369266/+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 1369260] Re: network-vif-plugged events should be Info on nova compute
I disagree that we should move these out of DEBUG. I actually think we
probably need to put more of these down in DEBUG unless there are lost
messages, and we should info or warn on those.
** Changed in: nova
Status: New = Opinion
--
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/1369260
Title:
network-vif-plugged events should be Info on nova compute
Status in OpenStack Compute (Nova):
Opinion
Bug description:
Version
===
IceHouse on rhel
Description
===
In order to track network-vif-plugged events across openetsack :
Nova-API send event network-vif-plugged under AUDIT level ,
AUDIT nova.api.openstack.compute.contrib.server_external_events
[req-7bd8ca07-a133-4b57-a6e3-a4340115475d
ca48398ab5f244e3bdfb798f94920fd1 d7e1cf5e67804ef0b8e27329a38105ef]
Creating event network-vif-plugged
Neutron server shos
INFO neutron.notifiers.nova [-] Nova event response: {u'status':
u'completed', u'tag': u'd883de4f-9c05-4f49-9125-316708d36d4d', u'name':
u'network-vif-plugged', u'server_uuid':
u'fea1a088-212a-4e08-baa5-f745d9bf2cca', u'code': 200}
BUT nova compute shows event network-vif-plugged only on DEBUG,
IMHO it should be Info/Audit level as well so we can track that NOVA-API
created event to neutron and compute processed that event
Current level on compute :
DEBUG nova.compute.manager [req-7bd8ca07-a133-4b57-a6e3-a4340115475d
ca48398ab5f244e3bdfb798f94920fd1 d7e1cf5e67804ef0b8e27329a38105ef] [instance:
fea1a088-212a-4e08-baa5-f745d9bf2cca] Processing event
network-vif-plugged-d883de4f-9c05-4f49-9125-316708d36d4d
_process_instance_event
/usr/lib/python2.7/site-packages/nova/compute/manager.py:5665
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1369260/+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 1369317] [NEW] ironic_host_manager's consume_from_instance() takes exactly 2 arguments (3 given)
Public bug reported: https://review.openstack.org/#/c/118391/ Change-id I012ee5c118265e044ff41fb58b732728946ee85a included a change to the definition of nova/scheduler/host_manager.py HostState.consume_from_instance(), changing the method from requiring 2 to 3 parameters. This change did not update the ironic_host_manager's HostState class, thus breaking it. This has broken Ironic's tempest tests, resulting in all our CI tests failing. ** Affects: nova Importance: Undecided Assignee: Devananda van der Veen (devananda) Status: New ** Tags: ironic ** Tags added: ironic ** Description changed: - Change-id I012ee5c118265e044ff41fb58b732728946ee85a included a change - to the definition of nova/scheduler/host_manager.py + https://review.openstack.org/#/c/118391/ + Change-id I012ee5c118265e044ff41fb58b732728946ee85a + + included a change to the definition of nova/scheduler/host_manager.py HostState.consume_from_instance(), changing the method from requiring 2 to 3 parameters. This change did not update the ironic_host_manager's HostState class, thus breaking it. This has broken Ironic's tempest tests, resulting in all our CI tests failing. ** Changed in: nova Assignee: (unassigned) = Devananda van der Veen (devananda) -- 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/1369317 Title: ironic_host_manager's consume_from_instance() takes exactly 2 arguments (3 given) Status in OpenStack Compute (Nova): New Bug description: https://review.openstack.org/#/c/118391/ Change-id I012ee5c118265e044ff41fb58b732728946ee85a included a change to the definition of nova/scheduler/host_manager.py HostState.consume_from_instance(), changing the method from requiring 2 to 3 parameters. This change did not update the ironic_host_manager's HostState class, thus breaking it. This has broken Ironic's tempest tests, resulting in all our CI tests failing. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369317/+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 1369337] [NEW] Nuage delete_subnet doesn't delete the port created by the create_subnet
Public bug reported: The Nuage create_subnet will create a DHCP port as per the spec. However the delete_subnet doesn't cleanup the subnet and leave the port. The fix will the add the deletion of the port in the delete_subnet method ** Affects: neutron Importance: Undecided Assignee: Franck (franck110) Status: New ** Tags: nuage ** Changed in: neutron Assignee: (unassigned) = Franck (franck110) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1369337 Title: Nuage delete_subnet doesn't delete the port created by the create_subnet Status in OpenStack Neutron (virtual network service): New Bug description: The Nuage create_subnet will create a DHCP port as per the spec. However the delete_subnet doesn't cleanup the subnet and leave the port. The fix will the add the deletion of the port in the delete_subnet method To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1369337/+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 1333471] Re: Checking security group in nova immediately after instance is created results in error
Backport patch for this was merged actually merged afew days ago. https://review.openstack.org/#/c/106674/ Sorry should have linked to it earlier. ** Changed in: nova Status: Won't Fix = Fix Committed -- 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/1333471 Title: Checking security group in nova immediately after instance is created results in error Status in OpenStack Compute (Nova): Fix Committed Bug description: Environment: Openstack Havana with Neutron for networking and security groups Error: Response from nova: The server could not comply with the request since it is either malformed or otherwise incorrect., code: 400 In nova-api log 014-06-19 00:48:39.483 17462 ERROR nova.api.openstack.wsgi [req-60aa8941-d129-4018-a30f-f815f0770118 10764ccc2d154d0a919f5104872fb9a8 2b60ae3ba5bd41d893674d0e57ae4390] Exception handling resource: 'NoneType' object is not iterable 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi Traceback (most recent call last): 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi File /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 997, in _process_stack 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi action_result = self.dispatch(meth, request, action_args) 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi File /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 1078, in dispatch 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi return method(req=request, **action_args) 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi File /usr/lib/python2.7/dist-packages/nova/api/openstack/compute/contrib/security_groups.py, line 438, in index 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi for group in groups] 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi TypeError: 'NoneType' object is not iterable 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi 2014-06-19 00:48:39.485 17462 INFO nova.osapi_compute.wsgi.server [req-60aa8941-d129-4018-a30f-f815f0770118 10764ccc2d154d0a919f5104872fb9a8 2b60ae3ba5bd41d893674d0e57ae4390] 10.147.22.73,54.225.248.128 GET /v2/2b60ae3ba5bd41d893674d0e57ae4390/servers/c7e5f472-57fb-4a95-95cf-45c6506db0cd/os-security-groups HTTP/1.1 status: 400 len: 362 time: 0.0710380 Steps to reproduce: 1) Create new instance 2) Immediately check security group through nova (/v2/$tenant/servers/$server_id/os-security-groups 3) Wait several seconds and try again (Works if given a small delay between instance creation and checking sec group) Notes: This error did not come up in earlier versions of havana, but started after a recent upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1333471/+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 977192] Re: Error message not user friendly while creating security group
This is a novaclient bug not a nova bug (it never reaches Nova). But regardless I'm not convinced we should fix this. Its stock standard unix command line syntax that something starting with '-' would be interpreted as an option rather than an argument unless specially quoted. ** Also affects: python-novaclient Importance: Undecided Status: New ** Changed in: python-novaclient Status: New = Confirmed ** Changed in: python-novaclient Importance: Undecided = Wishlist ** Changed in: nova Status: Confirmed = 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/977192 Title: Error message not user friendly while creating security group Status in OpenStack Compute (Nova): Invalid Status in Python client library for Nova: Confirmed Bug description: While creating Security Group with a name which starts with '-' followed by an alphabet then the Error message is not user friendly Steps to reproduce: nova secgroup-create -A34f ghjk Expected Result: Error message which indicates name is not an appropriate name Actual Result: usage: nova secgroup-create name description error: too few arguments To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/977192/+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 1369358] [NEW] Improve secgroup create error message
Public bug reported: When secgroup-create is passed a name or description which is an empty string the error message does not specify which field is invalid. We should fix this. ** Affects: nova Importance: Undecided Assignee: Christopher Yeoh (cyeoh-0) Status: In Progress -- 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/1369358 Title: Improve secgroup create error message Status in OpenStack Compute (Nova): In Progress Bug description: When secgroup-create is passed a name or description which is an empty string the error message does not specify which field is invalid. We should fix this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369358/+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 1369385] [NEW] Fail to create instance to a server group with affinity policy.
Public bug reported: Failed to create a instance into a server group with affinity policy and the retry filter is enabled. The scheduler selected a host, say it's 'host2', but the host2's hypervisor has some problems and failed to boot the instance. Then scheduler retry to boot the instance. Scheduler failed to select host for the instance. As the group with affinity request boot instance to host2 but host2 is not OK. For this case, it's not make sense that the group affinity policy take effect when the first instance in the group is retrying to create. ** 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/1369385 Title: Fail to create instance to a server group with affinity policy. Status in OpenStack Compute (Nova): New Bug description: Failed to create a instance into a server group with affinity policy and the retry filter is enabled. The scheduler selected a host, say it's 'host2', but the host2's hypervisor has some problems and failed to boot the instance. Then scheduler retry to boot the instance. Scheduler failed to select host for the instance. As the group with affinity request boot instance to host2 but host2 is not OK. For this case, it's not make sense that the group affinity policy take effect when the first instance in the group is retrying to create. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369385/+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 1369386] [NEW] ipset_enabled = True default is not upgrade friendly
Public bug reported: Adds ipset support for Security Groups In commit 2562a9271c828e982a74593e8fd07be13b0cfc4a we recently added ipset support for Security Groups. The default is currently set to True which is not upgrade friendly in that anyone upgrading to the most recent Neutron code immediately has to have the ipset binary installed or their commands fail. It seems like we should set this to false by default (as a safe default) and allow users to opt in since it is really an optimization... ** Affects: neutron Importance: Undecided Assignee: Dan Prince (dan-prince) Status: In Progress ** Changed in: neutron Assignee: (unassigned) = Dan Prince (dan-prince) ** Changed in: neutron Status: New = 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/1369386 Title: ipset_enabled = True default is not upgrade friendly Status in OpenStack Neutron (virtual network service): In Progress Bug description: Adds ipset support for Security Groups In commit 2562a9271c828e982a74593e8fd07be13b0cfc4a we recently added ipset support for Security Groups. The default is currently set to True which is not upgrade friendly in that anyone upgrading to the most recent Neutron code immediately has to have the ipset binary installed or their commands fail. It seems like we should set this to false by default (as a safe default) and allow users to opt in since it is really an optimization... To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1369386/+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 1369388] [NEW] local configuration is not allowed in keystone-paste.ini
You have been subscribed to a public bug:
According to funcation docs in keystone/common/wsgi.py, local configuration is
allowed in the paste.deploy config files, such as redis_host.
380 @classmethod
381 def factory(cls, global_config, **local_config):
382 Used for paste app factories in paste.deploy config files.
383
384 Any local configuration (that is, values under the [filter:APPNAME]
385 section of the paste config) will be passed into the `__init__`
method
386 as kwargs.
387
388 A hypothetical configuration would look like:
389
390 [filter:analytics]
391 redis_host = 127.0.0.1
392 paste.filter_factory = keystone.analytics:Analytics.factory
393
394 which would result in a call to the `Analytics` class as
395
396 import keystone.analytics
397 keystone.analytics.Analytics(app, redis_host='127.0.0.1')
398
399 You could of course re-implement the `factory` method in subclasses,
400 but using the kwarg passing it shouldn't be necessary.
401
402
And in the following implemenation, local configuration is indeed readed from
paste.deploy config files.
406 return cls(app, **local_config)
But, the local_config is not allowed in the constructor where only app is
passed into the constructor.
409 def __init__(self, application):
410 super(Middleware, self).__init__()
411 self.application = application
So, if we configure paste.deploy config files like what the method docs says,
it will always fails as:
[Sun Sep 14 22:40:37.316517 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] mod_wsgi (pid=22196): Exception occurred processing
WSGI script '/var/www/keystone/admin'.
[Sun Sep 14 22:40:37.316554 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] Traceback (most recent call last):
[Sun Sep 14 22:40:37.316564 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File /var/www/keystone/admin, line 59, in
module
[Sun Sep 14 22:40:37.316626 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] name=name)
[Sun Sep 14 22:40:37.316644 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in
loadapp
[Sun Sep 14 22:40:37.316795 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] return loadobj(APP, uri, name=name, **kw)
[Sun Sep 14 22:40:37.316803 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in
loadobj
[Sun Sep 14 22:40:37.316822 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] return context.create()
[Sun Sep 14 22:40:37.316827 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create
[Sun Sep 14 22:40:37.316851 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] return self.object_type.invoke(self)
[Sun Sep 14 22:40:37.316856 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke
[Sun Sep 14 22:40:37.316863 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] **context.local_conf)
[Sun Sep 14 22:40:37.316868 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 58, in fix_call
[Sun Sep 14 22:40:37.316919 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] reraise(*exc_info)
[Sun Sep 14 22:40:37.316927 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/compat.py, line 23, in reraise
[Sun Sep 14 22:40:37.316979 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] exec('raise t, e, tb', dict(t=t, e=e, tb=tb))
[Sun Sep 14 22:40:37.316986 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 55, in fix_call
[Sun Sep 14 22:40:37.316995 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] val = callable(*args, **kw)
[Sun Sep 14 22:40:37.316999 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/urlmap.py, line 28, in urlmap_factory
[Sun Sep 14 22:40:37.317074 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] app = loader.get_app(app_name,
global_conf=global_conf)
[Sun Sep 14 22:40:37.317080 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
[Yahoo-eng-team] [Bug 1369390] [NEW] Fails to start a server providing the configuration file
Public bug reported:
Using glance-control api start etc/glance-api.conf or glance-control
registry start etc/glance-registry.conf, it's resulting in the
following error:
Traceback (most recent call last):
File /home/vagrant/glance/.venv/bin/glance-control, line 10, in module
sys.exit(main())
File /home/vagrant/glance/glance/cmd/control.py, line 354, in main
pid = do_start('Start', *args)
File /home/vagrant/glance/glance/cmd/control.py, line 199, in do_start
return launch(pid_file, conf_file, CONF.capture_output, CONF.await_child)
File /home/vagrant/glance/glance/cmd/control.py, line 163, in launch
msg += 'with %s' % conf_file
File
/home/vagrant/glance/.venv/local/lib/python2.7/site-packages/oslo/i18n/_message.py,
line 154, in __add__
raise TypeError(msg)
TypeError
This is because the variable msg is an instance of
oslo.i18n._message.Message which not support concatenation.
https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L163
https://github.com/openstack/oslo.i18n/blob/master/oslo/i18n/_message.py#L151-154
** 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/1369390
Title:
Fails to start a server providing the configuration file
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Bug description:
Using glance-control api start etc/glance-api.conf or glance-
control registry start etc/glance-registry.conf, it's resulting in
the following error:
Traceback (most recent call last):
File /home/vagrant/glance/.venv/bin/glance-control, line 10, in module
sys.exit(main())
File /home/vagrant/glance/glance/cmd/control.py, line 354, in main
pid = do_start('Start', *args)
File /home/vagrant/glance/glance/cmd/control.py, line 199, in do_start
return launch(pid_file, conf_file, CONF.capture_output, CONF.await_child)
File /home/vagrant/glance/glance/cmd/control.py, line 163, in launch
msg += 'with %s' % conf_file
File
/home/vagrant/glance/.venv/local/lib/python2.7/site-packages/oslo/i18n/_message.py,
line 154, in __add__
raise TypeError(msg)
TypeError
This is because the variable msg is an instance of
oslo.i18n._message.Message which not support concatenation.
https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L163
https://github.com/openstack/oslo.i18n/blob/master/oslo/i18n/_message.py#L151-154
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1369390/+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 1369388] [NEW] local configuration is not allowed in keystone-paste.ini
Public bug reported:
According to funcation docs in keystone/common/wsgi.py, local configuration is
allowed in the paste.deploy config files, such as redis_host.
380 @classmethod
381 def factory(cls, global_config, **local_config):
382 Used for paste app factories in paste.deploy config files.
383
384 Any local configuration (that is, values under the [filter:APPNAME]
385 section of the paste config) will be passed into the `__init__`
method
386 as kwargs.
387
388 A hypothetical configuration would look like:
389
390 [filter:analytics]
391 redis_host = 127.0.0.1
392 paste.filter_factory = keystone.analytics:Analytics.factory
393
394 which would result in a call to the `Analytics` class as
395
396 import keystone.analytics
397 keystone.analytics.Analytics(app, redis_host='127.0.0.1')
398
399 You could of course re-implement the `factory` method in subclasses,
400 but using the kwarg passing it shouldn't be necessary.
401
402
And in the following implemenation, local configuration is indeed readed from
paste.deploy config files.
406 return cls(app, **local_config)
But, the local_config is not allowed in the constructor where only app is
passed into the constructor.
409 def __init__(self, application):
410 super(Middleware, self).__init__()
411 self.application = application
So, if we configure paste.deploy config files like what the method docs says,
it will always fails as:
[Sun Sep 14 22:40:37.316517 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] mod_wsgi (pid=22196): Exception occurred processing
WSGI script '/var/www/keystone/admin'.
[Sun Sep 14 22:40:37.316554 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] Traceback (most recent call last):
[Sun Sep 14 22:40:37.316564 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File /var/www/keystone/admin, line 59, in
module
[Sun Sep 14 22:40:37.316626 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] name=name)
[Sun Sep 14 22:40:37.316644 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in
loadapp
[Sun Sep 14 22:40:37.316795 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] return loadobj(APP, uri, name=name, **kw)
[Sun Sep 14 22:40:37.316803 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in
loadobj
[Sun Sep 14 22:40:37.316822 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] return context.create()
[Sun Sep 14 22:40:37.316827 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create
[Sun Sep 14 22:40:37.316851 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] return self.object_type.invoke(self)
[Sun Sep 14 22:40:37.316856 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke
[Sun Sep 14 22:40:37.316863 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] **context.local_conf)
[Sun Sep 14 22:40:37.316868 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 58, in fix_call
[Sun Sep 14 22:40:37.316919 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] reraise(*exc_info)
[Sun Sep 14 22:40:37.316927 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/compat.py, line 23, in reraise
[Sun Sep 14 22:40:37.316979 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] exec('raise t, e, tb', dict(t=t, e=e, tb=tb))
[Sun Sep 14 22:40:37.316986 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 55, in fix_call
[Sun Sep 14 22:40:37.316995 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] val = callable(*args, **kw)
[Sun Sep 14 22:40:37.316999 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
/usr/lib/python2.7/dist-packages/paste/urlmap.py, line 28, in urlmap_factory
[Sun Sep 14 22:40:37.317074 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] app = loader.get_app(app_name,
global_conf=global_conf)
[Sun Sep 14 22:40:37.317080 2014] [:error] [pid 22196:tid 139709922383616]
[remote 10.239.4.160:27590] File
[Yahoo-eng-team] [Bug 1369394] [NEW] selecting a protected image makes delete image clickable
Public bug reported: When selecting a protected image from the Images list, the delete button becomes clickable. Deleting would fail here as expected, but the user should not see that option. Steps: 1. Define an image with property protected = True 2. Wait for the image to be displayed in the images list 3. Select the image's checkbox Expected: Delete Image button is grayed out Actual: Delete Image button is clickable Tested on: Fedora 20 x86_64 Devstack Horizon at commit cdd64c2f6169c0eb94024fc71840bed255ce6c96 ** 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/1369394 Title: selecting a protected image makes delete image clickable Status in OpenStack Dashboard (Horizon): New Bug description: When selecting a protected image from the Images list, the delete button becomes clickable. Deleting would fail here as expected, but the user should not see that option. Steps: 1. Define an image with property protected = True 2. Wait for the image to be displayed in the images list 3. Select the image's checkbox Expected: Delete Image button is grayed out Actual: Delete Image button is clickable Tested on: Fedora 20 x86_64 Devstack Horizon at commit cdd64c2f6169c0eb94024fc71840bed255ce6c96 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369394/+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 1369401] [NEW] Multiple services with same name and type
Public bug reported: I am working on the current devstack environment. keystone service-create allows creating multiple services with the same --name and --type. Is this expected ? $ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd service-create --name junk --type junk +-+--+ | Property | Value | +-+--+ | description | | | enabled | True | | id | 69a40a334b58433ea7440e6336240611 | | name| junk | | type| junk | +-+--+ $ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd service-create --name junk --type junk +-+--+ | Property | Value | +-+--+ | description | | | enabled | True | | id | e976635ceb9d4c47bf0763f7b3cdcec9 | | name| junk | | type| junk | +-+--+ I expected it to fail as the 'user-create' fails with conflict error. After creating multiple service with same name, keystone endpoint-create fails with the error $ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os-token Passw0rd endpoint-create --service junk --publicurl http://junk Multiple service matches found for 'junk', use an ID to be more specific. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1369401 Title: Multiple services with same name and type Status in OpenStack Identity (Keystone): New Bug description: I am working on the current devstack environment. keystone service-create allows creating multiple services with the same --name and --type. Is this expected ? $ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os- token Passw0rd service-create --name junk --type junk +-+--+ | Property | Value | +-+--+ | description | | | enabled | True | | id | 69a40a334b58433ea7440e6336240611 | | name| junk | | type| junk | +-+--+ $ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os- token Passw0rd service-create --name junk --type junk +-+--+ | Property | Value | +-+--+ | description | | | enabled | True | | id | e976635ceb9d4c47bf0763f7b3cdcec9 | | name| junk | | type| junk | +-+--+ I expected it to fail as the 'user-create' fails with conflict error. After creating multiple service with same name, keystone endpoint- create fails with the error $ keystone --debug --os-endpoint http://10.0.2.15:35357/v2.0 --os- token Passw0rd endpoint-create --service junk --publicurl http://junk Multiple service matches found for 'junk', use an ID to be more specific. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1369401/+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
