[Yahoo-eng-team] [Bug 1659730] [NEW] Invalid parameter name on interface
Public bug reported: Invalid parameter name on interface There are several classes that inherit from the abstract method AuthMethodHandler.authenticate. In some cases those classes are not using matching parameter names. This patch changes all classes such that the signatures match. Prior to this there were four different signatures: authenticate(self, context, auth_payload, auth_context) authenticate(self, request, auth_info, auth_context) authenticate(self, request, auth_payload, auth_context) authenticate(self, request, auth_payload, user_context) The new common signature should be: authenticate(self, request, auth_payload, auth_context) ** Affects: keystone Importance: Medium Assignee: Eric Brown (ericwb) Status: Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1659730 Title: Invalid parameter name on interface Status in OpenStack Identity (keystone): Fix Released Bug description: Invalid parameter name on interface There are several classes that inherit from the abstract method AuthMethodHandler.authenticate. In some cases those classes are not using matching parameter names. This patch changes all classes such that the signatures match. Prior to this there were four different signatures: authenticate(self, context, auth_payload, auth_context) authenticate(self, request, auth_info, auth_context) authenticate(self, request, auth_payload, auth_context) authenticate(self, request, auth_payload, user_context) The new common signature should be: authenticate(self, request, auth_payload, auth_context) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1659730/+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 1604924] Re: [RFE] add support for vhost-user reconnect to the ovs neutron agent
Reviewed: https://review.openstack.org/344997 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ca60a91cbd3668c469313a3bd6c0c99aeff30a74 Submitter: Jenkins Branch:master commit ca60a91cbd3668c469313a3bd6c0c99aeff30a74 Author: Sean Mooney Date: Mon Jul 18 04:19:04 2016 + adds support for vhost user reconnect. - vhost-user reconnect is a new feature added in dpdk 16.07 and qemu 2.7. - vhost-user reconnect allows VMs using vhost-user interfaces to reconnect to the vhost-user backend if the backend terminates either as a result of a graceful shutdown or a crash with out requiring the vm to reboot. - vhost-user reconnect requires qemu to be the vhost-user server and ovs to be the client. - dpdk prior to 16.07 only supports qemu client/ dpdk server mode. - This change extends the ovs mech driver to select the correct qemu vhost user socket mode based on the available interface types reported by the agent. Change-Id: Iec89eaa597311e086c5f6e8d67308d446b07ac33 Closes-Bug: #1604924 Depends-on: Ia5da5b3ef28d1b23b217adc5196199df47b54ed9 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1604924 Title: [RFE] add support for vhost-user reconnect to the ovs neutron agent Status in neutron: Fix Released Bug description: vhost-user reconnect is a new feature added in dpdk 16.07 and qemu 2.7 vhost-user reconnect is a mechanism which allow a vhost-user frontend to reconnect to a vhost-user backend in the event the backend terminates. This enable a vm utilising a vhost-user interface to reconnect automatically to the backend e.g. a vswitch without requiring the vm to reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1604924/+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 1659710] [NEW] Transition qos notification driver into qos driver
Public bug reported: https://review.openstack.org/396651 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 38c1812015b6977f8212723d08cefb0926e6 Author: Miguel Angel Ajo Date: Thu Nov 17 09:17:29 2016 -0500 Transition qos notification driver into qos driver This will deprecate the notification_driver config setting, and no config setting will be needed. Also it lays down the foundation for a more decoupled interaction with mechanism drivers. Closes-Bug: #1657379 Related-Bug: #1627749 DocImpact Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48 ** Affects: neutron Importance: Undecided Status: New ** Tags: doc neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1659710 Title: Transition qos notification driver into qos driver Status in neutron: New Bug description: https://review.openstack.org/396651 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 38c1812015b6977f8212723d08cefb0926e6 Author: Miguel Angel Ajo Date: Thu Nov 17 09:17:29 2016 -0500 Transition qos notification driver into qos driver This will deprecate the notification_driver config setting, and no config setting will be needed. Also it lays down the foundation for a more decoupled interaction with mechanism drivers. Closes-Bug: #1657379 Related-Bug: #1627749 DocImpact Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659710/+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 1657379] Re: Refactor the QoS "notification_drivers" into QoS drivers
Reviewed: https://review.openstack.org/396651 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=38c1812015b6977f8212723d08cefb0926e6 Submitter: Jenkins Branch:master commit 38c1812015b6977f8212723d08cefb0926e6 Author: Miguel Angel Ajo Date: Thu Nov 17 09:17:29 2016 -0500 Transition qos notification driver into qos driver This will deprecate the notification_driver config setting, and no config setting will be needed. Also it lays down the foundation for a more decoupled interaction with mechanism drivers. Closes-Bug: #1657379 Related-Bug: #1627749 DocImpact Change-Id: I2f166a43f0b980ad22617f8a3f7b4cc7f4786c48 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1657379 Title: Refactor the QoS "notification_drivers" into QoS drivers Status in neutron: Fix Released Bug description: Beyond doing a decoupling refactor from the mechanism drivers and the core plugin this change will removes the need to define a notification_driver in the [qos] section of the neutron config file, being those drivers automatically exposed by the loaded mechanism drivers or the loaded core plugin. This is also a preliminary step to make https://bugs.launchpad.net/neutron/+bug/1586056 ( Improved validation mechanism for QoS rules with port types) possible. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1657379/+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 1659215] Re: Should not allow assign floating IPs that are already assigned to another port
This is not a bug either in Nova. Please take a look at this Tempest API test: https://github.com/openstack/tempest/blob/master/tempest/api/compute/floating_ips/test_floating_ips_actions.py#L109 and its failure as a consequence of the proposed Neutron fix: https://github.com/openstack/tempest/blob/master/tempest/api/compute/floating_ips/test_floating_ips_actions.py#L109 ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1659215 Title: Should not allow assign floating IPs that are already assigned to another port Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Bug description: While associate floating ip to instance, we did not check the floating IP is already assigned to another port or not: http://git.openstack.org/cgit/openstack/nova/tree/nova/network/neutronv2/api.py#n1684 It is understandable to allow re-assign to the same port, but we should not re-assgin if it is already assigned to other ports. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659215/+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 1659691] [NEW] neutron-vpnaas tempest job improvement
Public bug reported: gate-neutron-dsvm-tempest-vpnaas-ubuntu-xenial is completely broken. (it doesn't even configure vpnaas) it needs to be fixed and made voting. i plan to fold gate-neutron-vpnaas-dsvm-api-ubuntu-xenial-nv into the above job once it gets ready. ** 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/1659691 Title: neutron-vpnaas tempest job improvement Status in neutron: New Bug description: gate-neutron-dsvm-tempest-vpnaas-ubuntu-xenial is completely broken. (it doesn't even configure vpnaas) it needs to be fixed and made voting. i plan to fold gate-neutron-vpnaas-dsvm-api-ubuntu-xenial-nv into the above job once it gets ready. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659691/+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 1659215] Re: Should not allow assign floating IPs that are already assigned to another port
This is not a bug, this is the expected behavior of the floating ip API in Neutron. Please look at this Tempest test case failure that was triggered by the proposed fix (https://review.openstack.org/#/c/425563/): http://logs.openstack.org/63/425563/1/check/gate-tempest-dsvm-neutron- linuxbridge-ubuntu- xenial/4601f1d/console.html#_2017-01-26_08_51_05_811634 The source of this test is the following: https://github.com/openstack/tempest/blob/master/tempest/api/network/test_floating_ips.py#L65 We are clearly saying in this test case's code that we allow to change a floating ip association without disassociating if before ** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1659215 Title: Should not allow assign floating IPs that are already assigned to another port Status in neutron: Invalid Status in OpenStack Compute (nova): In Progress Bug description: While associate floating ip to instance, we did not check the floating IP is already assigned to another port or not: http://git.openstack.org/cgit/openstack/nova/tree/nova/network/neutronv2/api.py#n1684 It is understandable to allow re-assign to the same port, but we should not re-assgin if it is already assigned to other ports. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659215/+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 1291157] Re: idp deletion should trigger token revocation
https://review.openstack.org/#/c/414720/29 -- Fixed issue. ** Changed in: keystone Status: Confirmed => Invalid ** Changed in: keystone Assignee: Anthony Washington (anthony-washington) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1291157 Title: idp deletion should trigger token revocation Status in OpenStack Identity (keystone): Invalid Bug description: When a federation IdP is deleted, the tokens that were issued (and still active) and associated with the IdP should be deleted. To prevent unwarranted access. The fix should delete any tokens that are associated with the idp, upon deletion (and possibly update, too). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291157/+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 1659655] [NEW] test fails with a bogus message: 'WaitTimeout' object has no attribute 'seconds'
Public bug reported:
On some timeouts, the following is seen in test logs (e.g. [1]):
Traceback (most recent call last):
File "neutron/tests/base.py", line 117, in func
self.fail('Execution of this test timed out: %s' % e)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/timeout.py",
line 108, in __str__
if self.seconds is None:
AttributeError: 'WaitTimeout' object has no attribute 'seconds'
This seems to be due to WaitTimeout inheriting from eventlet.timeout.Timeout
but not using its constructor [2] which initiates self.seconds.
[1]
http://logs.openstack.org/56/425756/1/check/gate-neutron-dsvm-functional-ubuntu-xenial/c6bb644/console.html#_2017-01-26_15_57_28_297978
[2] https://github.com/eventlet/eventlet/blob/master/eventlet/timeout.py#L51
** 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/1659655
Title:
test fails with a bogus message: 'WaitTimeout' object has no attribute
'seconds'
Status in neutron:
New
Bug description:
On some timeouts, the following is seen in test logs (e.g. [1]):
Traceback (most recent call last):
File "neutron/tests/base.py", line 117, in func
self.fail('Execution of this test timed out: %s' % e)
File
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/timeout.py",
line 108, in __str__
if self.seconds is None:
AttributeError: 'WaitTimeout' object has no attribute 'seconds'
This seems to be due to WaitTimeout inheriting from eventlet.timeout.Timeout
but not using its constructor [2] which initiates self.seconds.
[1]
http://logs.openstack.org/56/425756/1/check/gate-neutron-dsvm-functional-ubuntu-xenial/c6bb644/console.html#_2017-01-26_15_57_28_297978
[2] https://github.com/eventlet/eventlet/blob/master/eventlet/timeout.py#L51
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1659655/+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 1659647] [NEW] The resource tracker clears the tracked_instances dictionary on every periodic job
Public bug reported: The resource tracker has a dict, named 'tracked_instances' which based on the name is used to keep track of the instances that the resource tracker is tracking. However, on every run of the 'update_available_resource' method, the '_update_usage_from_instances' method is called and in there the tracked_instances dict is cleared. This means that the conditionals in the '_update_usage_from_instance' (singular) method always indicate that the current instance is considered new and the various update methods for that instance will always be called. In the case of the calls to the placement API, this means there are many extra calls which could be avoided. Removing the clear() call results in no unit or functional test failures. A test run the gate will be tried. ** Affects: nova Importance: Undecided Status: New ** Tags: resource-tracker scheduler -- 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/1659647 Title: The resource tracker clears the tracked_instances dictionary on every periodic job Status in OpenStack Compute (nova): New Bug description: The resource tracker has a dict, named 'tracked_instances' which based on the name is used to keep track of the instances that the resource tracker is tracking. However, on every run of the 'update_available_resource' method, the '_update_usage_from_instances' method is called and in there the tracked_instances dict is cleared. This means that the conditionals in the '_update_usage_from_instance' (singular) method always indicate that the current instance is considered new and the various update methods for that instance will always be called. In the case of the calls to the placement API, this means there are many extra calls which could be avoided. Removing the clear() call results in no unit or functional test failures. A test run the gate will be tried. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1659647/+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 1659416] Re: RFE: extend security group rules to support logging
** Changed in: neutron Importance: Undecided => Wishlist ** Changed in: neutron Status: New => Confirmed ** Changed in: neutron Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1659416 Title: RFE: extend security group rules to support logging Status in neutron: Won't Fix Bug description: It is important for operators to have visibility for security rule enforcements, as described in [1]. A specific requirement is to be able to control logging behaviour at rule level. A typical use case is, when defining rules for a new application, or when an application has new clients, the user wants to observe/learn what are the active flows in "monitoring" phase, to avoid missing rules. During this phase, a "allow any" rule can be added to the security group for that application, and packets hitting that rule can be logged (with rate limiting). For this purpose, rule level logging enabling/disabling is required. Instead of a generic logging API, this RFE propose a simple extension to security rule resource, to add a "log" property. It will be each plugin's choice whether and how to support it. Take networking-ovn as an example, it will be straightforward to translate this into the "log" keyword in OVN ACL. [1] https://bugs.launchpad.net/neutron/+bug/1468366 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659416/+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 1659648] [NEW] Instance hung on first start, but works after being killed and restarted
Public bug reported: Description === A instance did not come up properly the first time it was started and had to be manually killed and then restarted through the API to get it to work. Steps To Reproduce == * I started an instance through the API * I noticed I coudln't connect to its floating IP. * I checked the nova compute node and the qemu-kvm process was running at 100% cpu, and its console log was empty. * I tried to shut it down through virsh on the compute node, but it didn't respond to that. * I had to kill it with kill . * After that I started the instance again through the API and it came up properly and everything is working. Expected Result === The instance starts correctly the first time. Actual Result = I had to kill and restart the instance. This doesn't happen everytime, seems to be some kind of race. I'm at a bit of a loss as to how to debug this. Environment === This is with mitaka running on xenial using libvirt+kvm hypervisor, openvswitch networking, and no attached volumes. Package versions: ii nova-common 2:13.1.2-0ubuntu2 all OpenStack Compute - common files ii nova-compute 2:13.1.2-0ubuntu2 all OpenStack Compute - compute node base ii nova-compute-kvm 2:13.1.2-0ubuntu2 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt 2:13.1.2-0ubuntu2 all OpenStack Compute - compute node libvirt support ii python-nova 2:13.1.2-0ubuntu2 all OpenStack Compute Python libraries ii python-novaclient2:3.3.1-2ubuntu1 all client library for OpenStack Compute API - Python 2.7 ii libvirt-bin 1.3.1-1ubuntu10.6 amd64programs for the libvirt library ii libvirt0:amd64 1.3.1-1ubuntu10.6 amd64library for interfacing with different virtualization systems ii python-libvirt 1.3.1-1ubuntu1 amd64libvirt Python bindings Linux hayward-44 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ** Affects: nova Importance: Undecided Status: New ** Tags: oil-guestos-fail ** Attachment added: "sosreport-hayward-44-20170126201325.tar.xz" https://bugs.launchpad.net/bugs/1659648/+attachment/4809483/+files/sosreport-hayward-44-20170126201325.tar.xz -- 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/1659648 Title: Instance hung on first start, but works after being killed and restarted Status in OpenStack Compute (nova): New Bug description: Description === A instance did not come up properly the first time it was started and had to be manually killed and then restarted through the API to get it to work. Steps To Reproduce == * I started an instance through the API * I noticed I coudln't connect to its floating IP. * I checked the nova compute node and the qemu-kvm process was running at 100% cpu, and its console log was empty. * I tried to shut it down through virsh on the compute node, but it didn't respond to that. * I had to kill it with kill . * After that I started the instance again through the API and it came up properly and everything is working. Expected Result === The instance starts correctly the first time. Actual Result = I had to kill and restart the instance. This doesn't happen everytime, seems to be some kind of race. I'm at a bit of a loss as to how to debug this. Environment === This is with mitaka running on xenial using libvirt+kvm hypervisor, openvswitch networking, and no attached volumes. Package versions: ii nova-common 2:13.1.2-0ubuntu2 all OpenStack Compute - common files ii nova-compute 2:13.1.2-0ubuntu2 all OpenStack Compute - compute node base ii nova-compute-kvm 2:13.1.2-0ubuntu2 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt 2:13.1.2-0ubuntu2 all OpenStack Compute - compute node libvirt support ii python-nova 2:13.1.2-0ubuntu2 all OpenStack Compute Python libraries ii python-novaclient2:3.3.1-2ubuntu1 all client library for OpenStack Compute API - Python 2.7 ii libvirt-bin 1.3.1-1ubuntu10.6
[Yahoo-eng-team] [Bug 1657978] Re: Internal Server Error: KeyError: 'domain'
Eric, per your comment in #7, i will mark this as fix released for
Mitaka and Newton and invalid for Ocata. see
https://review.openstack.org/#/q/I213876e30fc0521195848479278080bdac8387de,n,z
for details.
** Also affects: keystone/newton
Importance: Undecided
Status: New
** Also affects: keystone/mitaka
Importance: Undecided
Status: New
** Also affects: keystone/ocata
Importance: Medium
Assignee: Eric Brown (ericwb)
Status: New
** Changed in: keystone/ocata
Status: New => Invalid
** Changed in: keystone/newton
Status: New => Fix Released
** Changed in: keystone/newton
Importance: Undecided => Medium
** Changed in: keystone/mitaka
Status: New => Fix Released
** Changed in: keystone/ocata
Assignee: Eric Brown (ericwb) => (unassigned)
** Changed in: keystone/mitaka
Importance: Undecided => Medium
** Changed in: keystone/ocata
Importance: Medium => Undecided
** Changed in: keystone/newton
Assignee: (unassigned) => Eric Brown (ericwb)
** Changed in: keystone/mitaka
Assignee: (unassigned) => Eric Brown (ericwb)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1657978
Title:
Internal Server Error: KeyError: 'domain'
Status in OpenStack Identity (keystone):
Invalid
Status in OpenStack Identity (keystone) mitaka series:
Fix Released
Status in OpenStack Identity (keystone) newton series:
Fix Released
Status in OpenStack Identity (keystone) ocata series:
Invalid
Bug description:
I get the following message in Horizon when trying to authenticate a
federated user with a misconfigured mapping (in Mitaka)
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request: 'domain' (Disable insecure_debug mode to
suppress these details.)", "code": 500, "title": "Internal Server
Error"}}
This is my mapping.json. Notice no domain is part of the "group" parameter
(even though there is one at one level higher).
[
{
"local": [
{
"domain": {
"name": "Default"
},
"group": {
"name": "Federated Users"
},
"user": {
"name": "{0}",
"email": "{1}"
},
"groups": "{2}"
}
],
"remote": [
{
"type": "REMOTE_USER"
},
{
"type": "MELLON_userEmail"
},
{
"type": "MELLON_groups"
}
]
}
]
This is the log output of the keyerror containing the assertion.
http://paste.openstack.org/show/595730/
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1657978/+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 1657935] Re: intermittent failures in setup_physical_bridges
This is gone away. ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1657935 Title: intermittent failures in setup_physical_bridges Status in neutron: Invalid Bug description: http://logs.openstack.org/39/388939/18/check/gate-neutron-dsvm- functional-ubuntu-xenial/71d901a/testr_results.html.gz http://logs.openstack.org/50/402750/31/check/gate-neutron-dsvm- functional-ubuntu-xenial/6c1d7b4/testr_results.html.gz http://logs.openstack.org/04/395504/15/check/gate-neutron-dsvm- functional-ubuntu-xenial/dc17d0b/testr_results.html.gz http://logs.openstack.org/09/422309/1/check/gate-neutron-dsvm- functional-ubuntu-xenial/e0c8a6c/testr_results.html.gz http://logs.openstack.org/04/395504/13/check/gate-neutron-dsvm- functional-ubuntu-xenial/ea7661f/testr_results.html.gz http://logs.openstack.org/28/340228/30/check/gate-neutron-dsvm- functional-ubuntu-xenial/f229bb2/testr_results.html.gz http://logs.openstack.org/02/416302/13/check/gate-neutron-dsvm- functional-ubuntu-xenial/d4d757f/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1657935/+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 1630416] Re: Issues on admin create network modal
Reviewed: https://review.openstack.org/383960 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=2f5a2585827a281f086c8a94e1da497e0821f701 Submitter: Jenkins Branch:master commit 2f5a2585827a281f086c8a94e1da497e0821f701 Author: Ying Zuo Date: Fri Oct 7 13:40:27 2016 -0700 Fix issues on create network and create port modals Only delete the error for required field when segmentation id is not required for the network provider. Set string values as the choices for admin state field. Change-Id: Ie5d62960b85b9a1b9e0caf8fa51761d950cf430b Closes-bug: #1630416 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1630416 Title: Issues on admin create network modal Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Steps to reproduce: 1. go to admin/system/networks panel 2. click create network 3. click the submit button without putting in any data You will notice these issues on the modal: 1. Segmentation ID field should be validated if the input is a whole number even when it's not required for the network. 2. The value in Admin State field is changed from "UP" to "True". (This can also be reproduced on the same field on create port modal from admin -> networks -> network details -> ports tab) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1630416/+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 1659596] [NEW] Reuse already registered group in tempest config
Public bug reported: Instead of registering new groups in tempest plugin use the already registered group since the tempest config which is being used in plugin is the same as the upstream tempest. Also registering the same group twice would lead to duplicate opt error. ** Affects: keystone Importance: Undecided Assignee: Nishant Kumar (nishant-tech07) Status: New ** Changed in: keystone Assignee: (unassigned) => Nishant Kumar (nishant-tech07) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1659596 Title: Reuse already registered group in tempest config Status in OpenStack Identity (keystone): New Bug description: Instead of registering new groups in tempest plugin use the already registered group since the tempest config which is being used in plugin is the same as the upstream tempest. Also registering the same group twice would lead to duplicate opt error. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1659596/+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 1652944] Re: Broken links
** Changed in: openstack-manuals
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1652944
Title:
Broken links
Status in neutron:
Confirmed
Status in openstack-manuals:
Fix Released
Bug description:
The documentation of neutron (see referer below) contains links to
pages that do not exist. This was found by a global check of pages on
docs.openstack.org using scrapy.
{"url":
"http://docs.openstack.org/developer/neutron/devref/l2_agent_extensions";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/quality_of_service.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/scenario_legacy_ovs.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/layer3.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/deploy_scenario4b.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/deploy_scenario1b.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/deploy_scenario3b.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/scenario_legacy_lb.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/adv_config_ipv6.html";,
"status": 404, "referer":
"http://docs.openstack.org/releasenotes/neutron/liberty.html"},
{"url":
"http://docs.openstack.org/developer/neutron/devref/l2_agent_extensions";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/quality_of_service.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/scenario_legacy_lb.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/deploy_scenario4b.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/deploy_scenario1b.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/deploy_scenario3b.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/linuxbridge_agent.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/scenario_legacy_ovs.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron/devref/layer3.html"},
{"url":
"http://docs.openstack.org/newton/networking-guide/adv_config_ipv6.html";,
"status": 404, "referer":
"http://docs.openstack.org/releasenotes/neutron/liberty.html"},
{"url":
"http://docs.openstack.org/developer/openstack-ansible/install-guide-revised-draft/targethosts-networkconfig.html";,
"status": 404, "referer":
"http://docs.openstack.org/developer/openstack-ansible-os_neutron/newton/app-openvswitch.html"},
{"url":
"http://docs.openstack.org/developer/neutron-dynamic-routing/others/testing.rst";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"},
{"url":
"http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/route-advertisement.rst";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"},
{"url":
"http://docs.openstack.org/developer/neutron-dynamic-routing/design/drivers.rst";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"},
{"url":
"http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/dynamic-routing-agent.rst";,
"status": 404, "referer":
"http://docs.openstack.org/developer/neutron-dynamic-routing/functionality/bgp-speaker.html"},
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1652944/+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 1632538] Re: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova
This bug was fixed in the package python-rfc3986 - 0.2.2-0ubuntu0.16.10.1 --- python-rfc3986 (0.2.2-0ubuntu0.16.10.1) yakkety; urgency=medium * New upstream point release, resolving issue which causes valid URLS to be rejected (LP: #1632538). -- James Page Thu, 20 Oct 2016 09:55:32 +0100 ** Changed in: python-rfc3986 (Ubuntu Yakkety) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1632538 Title: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova Status in OpenStack Compute (nova): Incomplete Status in OpenStack Compute (nova) newton series: Incomplete Status in tripleo: Invalid Status in python-rfc3986 package in Ubuntu: Fix Released Status in python-rfc3986 source package in Xenial: Fix Released Status in python-rfc3986 source package in Yakkety: Fix Released Status in python-rfc3986 source package in Zesty: Fix Released Bug description: Enabling SSL on the Undercloud using generate_service_certificate results in all Nova services on the undercloud (api, cert, compute, conductor, scheduler), all failing with errors similar to the following: 2016-10-11 22:28:27.327 66082 CRITICAL nova [req-b5f37af3-96fc-42e2-aaa6-52815aca07fe - - - - -] ConfigFileValueError: Value for option url is not valid: invalid URI: 'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696' 2016-10-11 22:28:27.327 66082 ERROR nova Traceback (most recent call last): 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/bin/nova-cert", line 10, in 2016-10-11 22:28:27.327 66082 ERROR nova sys.exit(main()) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/nova/cmd/cert.py", line 49, in main 2016-10-11 22:28:27.327 66082 ERROR nova service.wait() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait 2016-10-11 22:28:27.327 66082 ERROR nova _launcher.wait() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait 2016-10-11 22:28:27.327 66082 ERROR nova status, signo = self._wait_for_exit_or_signal() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 303, in _wait_for_exit_or_signal 2016-10-11 22:28:27.327 66082 ERROR nova self.conf.log_opt_values(LOG, logging.DEBUG) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2630, in log_opt_values 2016-10-11 22:28:27.327 66082 ERROR nova _sanitize(opt, getattr(group_attr, opt_name))) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3061, in __getattr__ 2016-10-11 22:28:27.327 66082 ERROR nova return self._conf._get(name, self._group) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2672, in _get 2016-10-11 22:28:27.327 66082 ERROR nova value = self._do_get(name, group, namespace) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2715, in _do_get 2016-10-11 22:28:27.327 66082 ERROR nova % (opt.name, str(ve))) 2016-10-11 22:28:27.327 66082 ERROR nova ConfigFileValueError: Value for option url is not valid: invalid URI: 'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696' 2016-10-11 22:28:27.327 66082 ERROR nova I believe the failure happens inside the [neutron] section of /etc/nova/nova.conf. This does not look related to the scheme (https) being used as the result of enabling SSL because doing a one-off test with the openstack-nova-conductor service after changing the schema to http results in the same startup failure. Another one-off test substituting an IP address instead of a FQDN inside of nova.conf with the openstack-nova-conductor service as before results in openstack-nova-conductor starting properly but eventually failing with a connection-related failure due to the one- off data used (an IP address of 1.2.3.4). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1632538/+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 1593436] Re: Fix designate dns driver for SSL based endpoints
This was a dev ref addition. CLosing. ** Changed in: openstack-manuals Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1593436 Title: Fix designate dns driver for SSL based endpoints Status in neutron: Invalid Status in openstack-manuals: Invalid Bug description: https://review.openstack.org/326958 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 9cd95366a035b29001ce75515d291cf72d07d0c3 Author: imran malik Date: Wed Jun 8 02:45:32 2016 -0700 Fix designate dns driver for SSL based endpoints Allow setting options in designate section to specify if want to skip SSL cert check. This makes it possible to work with HTTPS based endpoints, the default behavior of keystoneclient is to always set verify=True however in current code, one cannot either provide a valid CA cert or skip the verification. DocImpact: Introduce two additional options for `[designate]` section in neutron.conf CONF.designate.insecure to allow insecure connections over SSL. CONF.designate.ca_cert for a valid cert when connecting over SSL Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e Closes-Bug: #1588067 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1593436/+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 1567009] Re: Remove flavor seeding from the base migration
** Tags removed: doc nova ** Tags added: install-guide ops-guide ** Also affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1567009 Title: Remove flavor seeding from the base migration Status in OpenStack Dashboard (Horizon): New Status in OpenStack Compute (nova): Invalid Status in openstack-manuals: In Progress Bug description: https://review.openstack.org/300127 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/nova" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 1a1a41bdbe0dc16ca594236925e77ce99f432b9d Author: Dan Smith Date: Thu Mar 31 10:57:14 2016 -0700 Remove flavor seeding from the base migration In a time long ago and a land far far away, someone thought it was a good idea to populate the database with default flavors. That was probably reasonable at the time, but it no longer makes sense and in fact causes us some pain now. This patch removes those default flavors from the database. That means that new deploys will not have them, but doesn't actually rewrite history in any way. This will require changes to our docs, which largely assume the presence of these default flavors from time zero. DocImpact Depends-On: Ic275887e97221d9ce5ce6f12cdcfb5ac94e300b0 Change-Id: I80b63ce1ebca01be61ac0f43d26a2992ecf16678 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1567009/+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 1632538] Re: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova
This bug was fixed in the package python-rfc3986 - 0.2.2-0ubuntu0.16.04.1 --- python-rfc3986 (0.2.2-0ubuntu0.16.04.1) xenial; urgency=medium * New upstream point release, resolving issue which causes valid URLS to be rejected (LP: #1632538). -- James Page Thu, 20 Oct 2016 09:55:32 +0100 ** Changed in: python-rfc3986 (Ubuntu Xenial) Status: Fix Committed => Fix Released ** Changed in: python-rfc3986 (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1632538 Title: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova Status in OpenStack Compute (nova): Incomplete Status in OpenStack Compute (nova) newton series: Incomplete Status in tripleo: Invalid Status in python-rfc3986 package in Ubuntu: Fix Released Status in python-rfc3986 source package in Xenial: Fix Released Status in python-rfc3986 source package in Yakkety: Fix Committed Status in python-rfc3986 source package in Zesty: Fix Released Bug description: Enabling SSL on the Undercloud using generate_service_certificate results in all Nova services on the undercloud (api, cert, compute, conductor, scheduler), all failing with errors similar to the following: 2016-10-11 22:28:27.327 66082 CRITICAL nova [req-b5f37af3-96fc-42e2-aaa6-52815aca07fe - - - - -] ConfigFileValueError: Value for option url is not valid: invalid URI: 'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696' 2016-10-11 22:28:27.327 66082 ERROR nova Traceback (most recent call last): 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/bin/nova-cert", line 10, in 2016-10-11 22:28:27.327 66082 ERROR nova sys.exit(main()) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/nova/cmd/cert.py", line 49, in main 2016-10-11 22:28:27.327 66082 ERROR nova service.wait() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait 2016-10-11 22:28:27.327 66082 ERROR nova _launcher.wait() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait 2016-10-11 22:28:27.327 66082 ERROR nova status, signo = self._wait_for_exit_or_signal() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 303, in _wait_for_exit_or_signal 2016-10-11 22:28:27.327 66082 ERROR nova self.conf.log_opt_values(LOG, logging.DEBUG) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2630, in log_opt_values 2016-10-11 22:28:27.327 66082 ERROR nova _sanitize(opt, getattr(group_attr, opt_name))) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3061, in __getattr__ 2016-10-11 22:28:27.327 66082 ERROR nova return self._conf._get(name, self._group) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2672, in _get 2016-10-11 22:28:27.327 66082 ERROR nova value = self._do_get(name, group, namespace) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2715, in _do_get 2016-10-11 22:28:27.327 66082 ERROR nova % (opt.name, str(ve))) 2016-10-11 22:28:27.327 66082 ERROR nova ConfigFileValueError: Value for option url is not valid: invalid URI: 'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696' 2016-10-11 22:28:27.327 66082 ERROR nova I believe the failure happens inside the [neutron] section of /etc/nova/nova.conf. This does not look related to the scheme (https) being used as the result of enabling SSL because doing a one-off test with the openstack-nova-conductor service after changing the schema to http results in the same startup failure. Another one-off test substituting an IP address instead of a FQDN inside of nova.conf with the openstack-nova-conductor service as before results in openstack-nova-conductor starting properly but eventually failing with a connection-related failure due to the one- off data used (an IP address of 1.2.3.4). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1632538/+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 1498529] Re: VPNaaS: VPN connection shown "pending create" status after it created successfully
This seems horizon, please explain any reasoning to bump it back to neutron. Cheers. ** Project changed: neutron => horizon -- 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/1498529 Title: VPNaaS: VPN connection shown "pending create" status after it created successfully Status in OpenStack Dashboard (Horizon): Expired Bug description: It's a display issue. After create VPN connection on openstack dashboard, the vpn connection is shown as "pending create". No matter create done or not. walk around: manually refresh openstack dashboard webpage. Juno version To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1498529/+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 1641383] Re: Uploading OVA to Glance via Horizon Fails
Reviewed: https://review.openstack.org/407847 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=3f1e0fad92ec6031e17b556609ca940c8a20a165 Submitter: Jenkins Branch:master commit 3f1e0fad92ec6031e17b556609ca940c8a20a165 Author: Jay Jahns Date: Tue Dec 6 20:41:04 2016 -0800 Allow OVA upload for images The OpenStack CLI allows the upload of OVA for images if the container format is set to ova. This patch allows a user to upload a OVA to Glance through the UI, changing the container_format to ova and the disk_format to vmdk. Change-Id: I1483b28ae4a1918a03798c4ef1bb94540fdb3386 Closes-Bug: #1641383 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1641383 Title: Uploading OVA to Glance via Horizon Fails Status in OpenStack Dashboard (Horizon): Fix Released Bug description: If a user wishes to upload an image to Glance that is an OVA file, the import fails because the disk_format gets marked as "bare" and the container_format is not taken into account. I've checked the dashboard for images and found this problem can be very easily fixed by checking if the user specified ova in the form and updating these 2 settings. dashboards/project/images/images/forms.py after line 63 elif disk_format == 'ova': # The ova format requires glance to set the disk format to vmdk and # the container format to ova in order for glance to accept the image # and to allow successful launch of the image. OVA does not support # a container format of bare. container_format = 'ova' disk_format = 'vmdk' Upon adding this change, OVAs can be added via the UI without error, and Glance can launch the OVA as expected. This only impacts single- disk OVA. Can someone verify this for me so we know on our side this is the correct action? I'm not totally familiar with contributing to the project, so I'm working on that internally as well. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1641383/+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 1629446] Re: federated login fails after user is removed from group
Reviewed: https://review.openstack.org/421616
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=9e1e2c2156f365078085db54dfbbfff50e2c2b84
Submitter: Jenkins
Branch:master
commit 9e1e2c2156f365078085db54dfbbfff50e2c2b84
Author: Eric Brown
Date: Tue Jan 17 17:42:52 2017 -0800
Catch potential SyntaxError in federation mapping
When using the 'groups' keyword in a federation mapping, the value
passed in the assertion map be a simple string with a space. For
example, "ALL USERS". This results in ast.literal_eval() raising
a SyntaxError and not ValueError, which bubbles up to the API as
an uncaught 500 Internal Server Error.
Change-Id: I61f93a6c54b62ba8719d2603f93dc18c33b581ce
Closes-Bug: #1629446
** Changed in: keystone
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1629446
Title:
federated login fails after user is removed from group
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) mitaka series:
New
Status in OpenStack Identity (keystone) newton series:
New
Bug description:
A user part of a group in auth0 tries to login in using the mapping
below just fine
[
{
"local": [
{
"user": {
"name": "{1}::{0}"
}
},
{
"domain": {
"id": "default"
},
"groups": "{1}"
}
],
"remote": [
{
"type": "HTTP_OIDC_CLAIM_EMAIL"
},
{
"type": "HTTP_OIDC_CLAIM_GROUPS"
}
]
}
]
Once the user is removed from the group in auth0 and tries to login :
Expected Result:
Failed to log on to horizon as federation user using OpenID Connect protocol
and got 401 code:
{"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}
Actual Result:
Got 500 instead of 401
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request.", "code": 500, "title": "Internal Server
Error"}}
error in keystone-all.logs:
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi
[req-f5f27f59-788b-494b-9719-bcdbb6b628c0 - - - - -] unexpected EOF while
parsing (, line 0)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi Traceback (most
recent call last):
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/common/wsgi.py",
line 249, in __call__
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi result =
method(context, **params)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/controllers.py",
line 329, in federated_idp_specific_sso_auth
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi res =
self.federated_authentication(context, idp_id, protocol_id)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/controllers.py",
line 302, in federated_authentication
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi return
self.authenticate_for_token(context, auth=auth)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/controllers.py",
line 396, in authenticate_for_token
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi
self.authenticate(context, auth_info, auth_context)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/controllers.py",
line 520, in authenticate
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi auth_context)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
line 65, in authenticate
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi
self.identity_api)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
line 141, in handle_unscoped_token
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi federation_api,
identity_api)
2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi File
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
line
[Yahoo-eng-team] [Bug 1658078] Re: AttributeError: 'NoneType' object has no attribute 'support_requests'
Reviewed: https://review.openstack.org/423608 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=8d11cba5edcb71b530ea9af3afa697870bcfac3a Submitter: Jenkins Branch:master commit 8d11cba5edcb71b530ea9af3afa697870bcfac3a Author: Moshe Levi Date: Sat Jan 21 11:27:36 2017 +0200 PCI: Check pci_requests object is empty before passing to support_requests This commit checks that InstancePCIRequests is empty before passing it to the pci_stats.support_requests. This prevents doing the support request check for host_state which don't have pci_stats like ironic host. Closes-Bug: #1658078 Change-Id: Ie6d870729883e2bbdc3278c52e88d147613712f6 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1658078 Title: AttributeError: 'NoneType' object has no attribute 'support_requests' Status in OpenStack Compute (nova): Fix Released Bug description: When the compute is ironic driver and the shceduler is configured with pci passthrough filter the vm get to an error state and we can see the following error in the scheduler 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server [req-d627c45c-a5cf-47bc-a8d1-fe4669516380 admin admin] Exception during message handling 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 155, in _process_incoming 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 222, in dispatch 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 192, in _do_dispatch 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 218, in inner 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server return func(*args, **kwargs) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/manager.py", line 84, in select_destinations 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server dests = self.driver.select_destinations(ctxt, spec_obj) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/filter_scheduler.py", line 51, in select_destinations 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server selected_hosts = self._schedule(context, spec_obj) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/filter_scheduler.py", line 103, in _schedule 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server spec_obj, index=num) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/host_manager.py", line 572, in get_filtered_hosts 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server hosts, spec_obj, index) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/filters.py", line 89, in get_filtered_objects 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server list_objs = list(objs) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/filters.py", line 44, in filter_all 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server if self._filter_one(obj, spec_obj): 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/filters/__init__.py", line 26, in _filter_one 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server return self.host_passes(obj, filter_properties) 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server File "/opt/stack/nova/nova/scheduler/filters/pci_passthrough_filter.py", line 48, in host_passes 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server if not host_state.pci_stats.support_requests(pci_requests.requests): 2017-01-19 06:00:35.887 105364 ERROR oslo_messaging.rpc.server AttributeError: 'NoneType' object has no attribute 'support_requests' To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1658078/+subscriptio
[Yahoo-eng-team] [Bug 1659146] Re: Broken neutron dsvm functional gate
Reviewed: https://review.openstack.org/424906 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f8a224a63fbb350454cbc31dd20fea0111eb814f Submitter: Jenkins Branch:master commit f8a224a63fbb350454cbc31dd20fea0111eb814f Author: Dirk Mueller Date: Wed Jan 25 00:54:26 2017 +0100 Adjust psutil usage for psutil > 2 psutil 2.x and above has a lot of API changes as described in: https://github.com/giampaolo/psutil/blob/master/HISTORY.rst Change-Id: I1380f488390c83a44d91b84218f1b1ba826d03a0 Closes-Bug: 1659146 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1659146 Title: Broken neutron dsvm functional gate Status in neutron: Fix Released Bug description: Neutron dsvm functional gate is broken. There are functional test failures: 1. neutron.tests.functional.test_server.TestRPCServer.test_restart_rpc_on_sighup_multiple_workers Trace: http://paste.openstack.org/show/596323/ 2. neutron.tests.functional.test_server.TestWsgiServer.test_restart_wsgi_on_sighup_multiple_workers Trace: http://paste.openstack.org/show/596324/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1659146/+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 1659499] [NEW] API Access View Credentials form is semantically incorrect
Public bug reported: There are some simple improvements we can make to UX/a11y on the View Credentials form on the API Access panel, like correctly labelling inputs. ** Affects: horizon Importance: Low Assignee: Rob Cresswell (robcresswell) Status: New ** Changed in: horizon Milestone: None => ocata-rc1 ** Changed in: horizon Assignee: (unassigned) => Rob Cresswell (robcresswell) ** Changed in: horizon Importance: Undecided => Wishlist ** Changed in: horizon Importance: Wishlist => Low -- 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/1659499 Title: API Access View Credentials form is semantically incorrect Status in OpenStack Dashboard (Horizon): New Bug description: There are some simple improvements we can make to UX/a11y on the View Credentials form on the API Access panel, like correctly labelling inputs. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1659499/+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 1642687] Re: Missing domain for federated users
Reviewed: https://review.openstack.org/423708 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=c19f2431524be224b4c027b2a56398d7c3e5e18b Submitter: Jenkins Branch:master commit c19f2431524be224b4c027b2a56398d7c3e5e18b Author: Ronald De Rose Date: Sat Jan 21 21:10:56 2017 + Set the domain for federated users This patch updates the domain for federated users to be the domain of the Identity Provider (IdP). Closes-Bug: #1642687 Partially-Implements: bp support-federated-attr Depends-On: If8c8ad39c4c55a2d800bf4432411db59799e84e6 Change-Id: Iccfad6f39dc339ca054bedf3c6882c3701dcf0ec ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1642687 Title: Missing domain for federated users Status in OpenStack Identity (keystone): Fix Released Bug description: When creating federated users, as part of shadowing users, the user's domain_id is not set. An Identity Provider (IdP) should be mapped to a domain and users from that IdP should be created within that domain. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1642687/+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
