[Yahoo-eng-team] [Bug 1600229] [NEW] With only one key pair it should be selected by default in AngularJS Launch Instance
Public bug reported: In the Launch Instance panel (not the new AngularJS version) when you create a new instance and you have only one key pair, that key pair is selected by default for the instance creation. If there is more than one, anyone is selected by default an you have to select one if you want. In the new Launch Instance panel in AngularJS this is not the behaviour. when you have only one key pair it's not selected by default, you have to selected it. This may cause some unexpected user experience, because a lot of users have only one key pair and they were used to not worry about to select key pair when they create a new instance. Now, with the new panel (AngularJS), they report issues because the instance was not created with their "default key pair" and they can not SSH it. I would like to suggest to come back to the same behaviour, for the key pair selection, that we have in the not AngularJs version of the Launch Instance panel. At least make it configurable via local_settings config file. ** 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/1600229 Title: With only one key pair it should be selected by default in AngularJS Launch Instance Status in OpenStack Dashboard (Horizon): New Bug description: In the Launch Instance panel (not the new AngularJS version) when you create a new instance and you have only one key pair, that key pair is selected by default for the instance creation. If there is more than one, anyone is selected by default an you have to select one if you want. In the new Launch Instance panel in AngularJS this is not the behaviour. when you have only one key pair it's not selected by default, you have to selected it. This may cause some unexpected user experience, because a lot of users have only one key pair and they were used to not worry about to select key pair when they create a new instance. Now, with the new panel (AngularJS), they report issues because the instance was not created with their "default key pair" and they can not SSH it. I would like to suggest to come back to the same behaviour, for the key pair selection, that we have in the not AngularJs version of the Launch Instance panel. At least make it configurable via local_settings config file. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1600229/+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 1587893] [NEW] Infinity quota values are not parsed by JSON.parse for getAbsoluteLimits
Public bug reported:
When some of the values for Cinder quota are set to -1 (which means,
"infinity" quota), REST API call for getAbsoluteLimits [1] crashes.
That JavaScript function makes a request to
http://localshost/api/cinder/tenantabsolutelimits/
That request, generates a response, like:
{"totalSnapshotsUsed": 0, "total_volumes_standard": 10,
"maxTotalBackups": 10, "totalBackupsUsed": 0, "maxTotalBackupGigabytes":
1000, "maxTotalVolumes": 10, "used_volumes_standard": 1,
"maxTotalVolumeGigabytes": 1000, "totalVolumesUsed": 1,
"total_gigabytes_standard": 1000, "totalBackupGigabytesUsed": 0,
"maxTotalSnapshots": 0, "used_gigabytes_standard": 1,
"totalGigabytesUsed": 1}
So far, so good.
Now, update the cinder quota for your project, for example, the
snapshots quota, to -1. The response changes to:
{"totalSnapshotsUsed": 0, "total_volumes_standard": 10,
"maxTotalBackups": 10, "totalBackupsUsed": 0, "maxTotalBackupGigabytes":
1000, "maxTotalVolumes": 10, "used_volumes_standard": 1,
"maxTotalVolumeGigabytes": 1000, "totalVolumesUsed": 1,
"total_gigabytes_standard": 1000, "totalBackupGigabytesUsed": 0,
"maxTotalSnapshots": Infinity, "used_gigabytes_standard": 1,
"totalGigabytesUsed": 1}
Please note that "maxTotalSnapshots": Infinity.
That dictionary, for python, is not a problem. But, for the JavaScript
parser, is a big issue.
Now, please open your browser, for example, Firefox and open the Console
(from Developers tool) and execute this in the console:
>> JSON.parse('{"totalSnapshotsUsed": 0, "total_volumes_standard": 10,
"maxTotalBackups": 10, "totalBackupsUsed": 0, "maxTotalBackupGigabytes":
1000, "maxTotalVolumes": 10, "used_volumes_standard": 1,
"maxTotalVolumeGigabytes": 1000, "totalVolumesUsed": 1,
"total_gigabytes_standard": 1000, "totalBackupGigabytesUsed": 0,
"maxTotalSnapshots": 0, "used_gigabytes_standard": 1,
"totalGigabytesUsed": 1}')
That worked fine, no issues, but now try this (with infinity quota for
snapshots):
>> JSON.parse('{"totalSnapshotsUsed": 0, "total_volumes_standard": 10,
"maxTotalBackups": 10, "totalBackupsUsed": 0, "maxTotalBackupGigabytes":
1000, "maxTotalVolumes": 10, "used_volumes_standard": 1,
"maxTotalVolumeGigabytes": 1000, "totalVolumesUsed": 1,
"total_gigabytes_standard": 1000, "totalBackupGigabytesUsed": 0,
"maxTotalSnapshots": Infinity, "used_gigabytes_standard": 1,
"totalGigabytesUsed": 1}')
It fails raising this message: SyntaxError: JSON.parse: unexpected
character at line 1 column 329 of the JSON data.
Summarizing, the issue in Horizon is due to -1 values in cinder quota,
which is translated to python to infinity values (see here [2]) and the
"Infinity" values are not a proper value for JSON.parse function.
[1]
https://github.com/openstack/horizon/blob/e1f07e27944b505dec57dda20d3c3b13eb3bb4d7/openstack_dashboard/static/app/core/openstack-service-api/cinder.service.js#L284
[2]
https://github.com/openstack/horizon/blob/e1f07e27944b505dec57dda20d3c3b13eb3bb4d7/openstack_dashboard/api/cinder.py#L779
** 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/1587893
Title:
Infinity quota values are not parsed by JSON.parse for
getAbsoluteLimits
Status in OpenStack Dashboard (Horizon):
New
Bug description:
When some of the values for Cinder quota are set to -1 (which means,
"infinity" quota), REST API call for getAbsoluteLimits [1] crashes.
That JavaScript function makes a request to
http://localshost/api/cinder/tenantabsolutelimits/
That request, generates a response, like:
{"totalSnapshotsUsed": 0, "total_volumes_standard": 10,
"maxTotalBackups": 10, "totalBackupsUsed": 0,
"maxTotalBackupGigabytes": 1000, "maxTotalVolumes": 10,
"used_volumes_standard": 1, "maxTotalVolumeGigabytes": 1000,
"totalVolumesUsed": 1, "total_gigabytes_standard": 1000,
"totalBackupGigabytesUsed": 0, "maxTotalSnapshots": 0,
"used_gigabytes_standard": 1, "totalGigabytesUsed": 1}
So far, so good.
Now, update the cinder quota for your project, for example, the
snapshots quota, to -1. The response changes to:
{"totalSnapshotsUsed": 0, "total_volumes_standard": 10,
"maxTotalBackups": 10, "totalBackupsUsed": 0,
"maxTotalBackupGigabytes": 1000, "maxTotalVolumes": 10,
"used_volumes_standard": 1, "maxTotalVolumeGigabytes": 1000,
"totalVolumesUsed": 1, "total_gigabytes_standard": 1000,
"totalBackupGigabytesUsed": 0, "maxTotalSnapshots": Infinity,
"used_gigabytes_standard": 1, "totalGigabytesUsed": 1}
Please note that "maxTotalSnapshots": Infinity.
That dictionary, for python, is not a problem. But, for the JavaScript
parser, is a big issue.
Now, please open your browser, for example, Firefox and open the
Console (from Developers tool) and execute this in the console:
>> JSON.parse('{"totalSnapshotsUsed": 0,
[Yahoo-eng-team] [Bug 1573566] [NEW] Instance actions displayed when instance is locked
Public bug reported: When you lock an instance some actions, like STOP, SOFT REBOOT, etc, can not be executed. In Horizon Liberty (8.0.0), when you lock an instance, the drop down actions button displays actions that can not be done in "LOCKED" state. How to reproduce: 1. Go to instance list 2. Click on the drop down button and click on "Lock" action for an instance 3. Refresh the browser 4. Click on the drop drop down button Actual result: It shows instance actions that can not done when the instance is locked Excepted result: do not show instance actions that can not done when the instance is locked I would say that this is an unexpected behaviour from user experience point of view, because if a user locks an instance and then clicks on START or STOP action, Horizon will rise the red bubble with the error message. ** 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/1573566 Title: Instance actions displayed when instance is locked Status in OpenStack Dashboard (Horizon): New Bug description: When you lock an instance some actions, like STOP, SOFT REBOOT, etc, can not be executed. In Horizon Liberty (8.0.0), when you lock an instance, the drop down actions button displays actions that can not be done in "LOCKED" state. How to reproduce: 1. Go to instance list 2. Click on the drop down button and click on "Lock" action for an instance 3. Refresh the browser 4. Click on the drop drop down button Actual result: It shows instance actions that can not done when the instance is locked Excepted result: do not show instance actions that can not done when the instance is locked I would say that this is an unexpected behaviour from user experience point of view, because if a user locks an instance and then clicks on START or STOP action, Horizon will rise the red bubble with the error message. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1573566/+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 1557353] [NEW] Delete servers in error state
Public bug reported:
In instance list, when we have one/multiple servers in error state,
Horizon does not display "Terminate instances" button in top-right side
(close to "Launch instance" button). So, Horizon does not allow
terminate instances in error state.
Since the CLI allows terminate instances in error state, I think we
should allow this in Horizon as well. I do not see any reason to not
allow delete multiple instances in error state from Horizon.
** Affects: horizon
Importance: Undecided
Assignee: Marcos Lobo (marcos-fermin-lobo)
Status: New
** Changed in: horizon
Assignee: (unassigned) => Marcos Lobo (marcos-fermin-lobo)
--
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/1557353
Title:
Delete servers in error state
Status in OpenStack Dashboard (Horizon):
New
Bug description:
In instance list, when we have one/multiple servers in error state,
Horizon does not display "Terminate instances" button in top-right
side (close to "Launch instance" button). So, Horizon does not allow
terminate instances in error state.
Since the CLI allows terminate instances in error state, I think we
should allow this in Horizon as well. I do not see any reason to not
allow delete multiple instances in error state from Horizon.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1557353/+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 1538089] [NEW] Add policy checks at TABs level
Public bug reported: In order to improve the configuration possibilities in Horizon, we could introduce policy checks at TAB level. TABs are elements that live in PANEL elements. Use cases: - Only enable Floating IPs TAB, in Access And Security panel, for user with "owner" role - Disable Volume Snapshots TAB, in Volumes panel, for all users except "admin" role. ** 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/1538089 Title: Add policy checks at TABs level Status in OpenStack Dashboard (Horizon): New Bug description: In order to improve the configuration possibilities in Horizon, we could introduce policy checks at TAB level. TABs are elements that live in PANEL elements. Use cases: - Only enable Floating IPs TAB, in Access And Security panel, for user with "owner" role - Disable Volume Snapshots TAB, in Volumes panel, for all users except "admin" role. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1538089/+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 1530864] Re: VolumeTypeList rest call is not implemented
This is already implemented in master https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/cinder.py#L98 ** Changed in: horizon Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1530864 Title: VolumeTypeList rest call is not implemented Status in OpenStack Dashboard (Horizon): Invalid Bug description: VolumeTypeList cinder API REST call is not implemented yet in Horizon To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1530864/+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 1535628] [NEW] Load drop-down tenant list via AJAX
Public bug reported: I found a performance issue login in Horizon with Admin user. If in your OpenStack cloud you have a lot of tenants, like > 1500, when you try to login Horizon using Admin credentials it takes a lot of time to load the main web page... Even it could rise a "time exception" error. This is because, when you login with Admin credential, the drop-down tenant list is gonna fill in with ALL tenants in the system. If OpenStack has a lot, this load is very high and it takes too much time. My proposal is: load the dropdown tenant list in asynchronous way. More specific: - Login Horizon with Admin - The drop-down tenant list shows "Admin" tenant as selected tenant, as it does now. - Only when you click in the drop-down list, the request to get all tenants, should be launched. Any thoughts or comments? ** 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/1535628 Title: Load drop-down tenant list via AJAX Status in OpenStack Dashboard (Horizon): New Bug description: I found a performance issue login in Horizon with Admin user. If in your OpenStack cloud you have a lot of tenants, like > 1500, when you try to login Horizon using Admin credentials it takes a lot of time to load the main web page... Even it could rise a "time exception" error. This is because, when you login with Admin credential, the drop-down tenant list is gonna fill in with ALL tenants in the system. If OpenStack has a lot, this load is very high and it takes too much time. My proposal is: load the dropdown tenant list in asynchronous way. More specific: - Login Horizon with Admin - The drop-down tenant list shows "Admin" tenant as selected tenant, as it does now. - Only when you click in the drop-down list, the request to get all tenants, should be launched. Any thoughts or comments? To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1535628/+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 1534168] [NEW] TenantAbsoluteLimits rest call do not return dict
Public bug reported: In the cinder REST api, all the get() methods do return always a dictionary or a list of dictionaries. But there is only one method that it does NOT: TenantAbsoluteLimits. You can check here https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/cinder.py#L204 My question is, why?. I did some checks and I think this is a bug. TenantAbsoluteLimits should return a list of dictionaries. ** 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/1534168 Title: TenantAbsoluteLimits rest call do not return dict Status in OpenStack Dashboard (Horizon): New Bug description: In the cinder REST api, all the get() methods do return always a dictionary or a list of dictionaries. But there is only one method that it does NOT: TenantAbsoluteLimits. You can check here https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/cinder.py#L204 My question is, why?. I did some checks and I think this is a bug. TenantAbsoluteLimits should return a list of dictionaries. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1534168/+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 1530864] [NEW] VolumeTypeList rest call is not implemented
Public bug reported: VolumeTypeList cinder API REST call is not implemented yet in Horizon ** 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/1530864 Title: VolumeTypeList rest call is not implemented Status in OpenStack Dashboard (Horizon): New Bug description: VolumeTypeList cinder API REST call is not implemented yet in Horizon To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1530864/+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 1490850] [NEW] No hostname validation in launch instance angularjs panel
Public bug reported: Horizon Juno does not have hostname validation in AngularJS launch instance form. For example, you can create a new instance with name: "#3r" That name will cause problems when Nova try to handle, but Horizon allow launch a new instance with a not valid hostname. A valid hostname is specified in RFC1123 (http://tools.ietf.org/html/rfc1123). This patch is quite similar to https://bugs.launchpad.net/horizon/+bug/1458800 but the validation happens in different layers. In my opinion, the same validation in those two different layers is not a problem, meanwhile Horizon supports "basic launch instance form" and the new AngularJS launch instance form. ** 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/1490850 Title: No hostname validation in launch instance angularjs panel Status in OpenStack Dashboard (Horizon): New Bug description: Horizon Juno does not have hostname validation in AngularJS launch instance form. For example, you can create a new instance with name: "#3r" That name will cause problems when Nova try to handle, but Horizon allow launch a new instance with a not valid hostname. A valid hostname is specified in RFC1123 (http://tools.ietf.org/html/rfc1123). This patch is quite similar to https://bugs.launchpad.net/horizon/+bug/1458800 but the validation happens in different layers. In my opinion, the same validation in those two different layers is not a problem, meanwhile Horizon supports "basic launch instance form" and the new AngularJS launch instance form. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1490850/+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 1458800] [NEW] No hostname validation
Public bug reported: Horizon Juno does not have hostname validation in instance creation form. For example, you can create a new instance with name: #3r That name will cause problems when Nova try to handle, but Horizon allow launch a new instance with a not valid hostname. A valid hostname is specified in RFC1123 (http://tools.ietf.org/html/rfc1123). I propose add hostname validation to create/edit instance form following the RFC1123. ** Affects: horizon Importance: Undecided Assignee: Ritesh (rsritesh) 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/1458800 Title: No hostname validation Status in OpenStack Dashboard (Horizon): New Bug description: Horizon Juno does not have hostname validation in instance creation form. For example, you can create a new instance with name: #3r That name will cause problems when Nova try to handle, but Horizon allow launch a new instance with a not valid hostname. A valid hostname is specified in RFC1123 (http://tools.ietf.org/html/rfc1123). I propose add hostname validation to create/edit instance form following the RFC1123. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1458800/+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 1425845] Re: Image list multiselection buttons allowed
I think it is already solved in K1 and J2 https://bugs.launchpad.net/horizon/+bug/1365803 More details https://github.com/openstack/horizon/commit/8ea177b67a28b328b571b1140b7db01e303f6abc Sorry for the noise. ** Changed in: horizon Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1425845 Title: Image list multiselection buttons allowed Status in OpenStack Dashboard (Horizon): Invalid Bug description: In Horizon Juno Name: openstack-dashboard Arch: noarch Version : 2014.2.1 Release : 2.el7.centos DESCRIPTION: In Project dashboard - Image list there is a problem with the CSS behavior in the buttons grouped (Project, Shared with me, Public). The problem is that you can active more than one button at same time. HOW TO REPRODUCE 1 - The start status is all with background color white. 2 - Click in one button, for example, Public. Now, public is active (it has active css class) 3 - Click in other button, for example, Shared with me. Now, Shared with me is active (it has active css class) as well. (see attachment horizon_images_multiselection_status.png) The miss-behavior is: only one button (that belongs to that group) can be active at the same time. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1425845/+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 1425845] [NEW] Image list multiselection buttons allowed
Public bug reported: In Horizon Juno Name: openstack-dashboard Arch: noarch Version : 2014.2.1 Release : 2.el7.centos DESCRIPTION: In Project dashboard - Image list there is a problem with the CSS behavior in the buttons grouped (Project, Shared with me, Public). The problem is that you can active more than one button at same time. HOW TO REPRODUCE 1 - The start status is all with background color white. 2 - Click in one button, for example, Public. Now, public is active (it has active css class) 3 - Click in other button, for example, Shared with me. Now, Shared with me is active (it has active css class) as well. (see attachment horizon_images_multiselection_status.png) The miss-behavior is: only one button (that belongs to that group) can be active at the same time. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: horizon_images_multiselection_status.png https://bugs.launchpad.net/bugs/1425845/+attachment/4328085/+files/horizon_images_multiselection_status.png -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1425845 Title: Image list multiselection buttons allowed Status in OpenStack Dashboard (Horizon): New Bug description: In Horizon Juno Name: openstack-dashboard Arch: noarch Version : 2014.2.1 Release : 2.el7.centos DESCRIPTION: In Project dashboard - Image list there is a problem with the CSS behavior in the buttons grouped (Project, Shared with me, Public). The problem is that you can active more than one button at same time. HOW TO REPRODUCE 1 - The start status is all with background color white. 2 - Click in one button, for example, Public. Now, public is active (it has active css class) 3 - Click in other button, for example, Shared with me. Now, Shared with me is active (it has active css class) as well. (see attachment horizon_images_multiselection_status.png) The miss-behavior is: only one button (that belongs to that group) can be active at the same time. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1425845/+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 1396650] Re: Duplicated tests for Catalog
Ok Steve, I understand the goal of each test file. My point is, now we have 3 different catalog backends. test_catalog.py is not be able to manage the different implementations from those backends. For example, in this patch https://review.openstack.org/#/c/120011/ I'm implementing methods for Templated backed. Some of the functionality makes no sense for Templated Catalog but it does in SQL Catalog (create regions, for example). So, in the (let's say) special case of create regions using Templated Catalog I'm raising NotImplemented exception. For this exception, test_catalog.py tests are not be able to manage it, because those tests think that the behavior should be the same from different backends. Maybe, the workaround, could be try to improve test_catalog.py tests... I really appreciate your feedback. ** Changed in: keystone Status: Invalid = 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/1396650 Title: Duplicated tests for Catalog Status in OpenStack Identity (Keystone): New Bug description: About testing the catalog backends (KVS, SQL and Templated). Now, we have to different test files to do the same things. keystone/tests/test_backend.py - Which has a lot of test related with Identity, Policy, Token, ... and Catalog keystone/tests/test_catalog.py - Which has a few tests only for the catalog backends. Those test are not enough to test everything in the catalog. In my opinion is not a good idea to have different test files for the same purpose because some people could implement test only in one of the test files, not in both. Also, it is a pain to maintain. I propose to remove all the test that we have right now in keystone/tests/test_catalog.py (please forget class V2CatalogTestCase(rest.RestfulTestCase)) and move the tests related with Catalog that, right now, we have in keystone/tests/test_backend.py to keystone/tests/test_catalog.py What do you think? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1396650/+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 1396650] [NEW] Duplicated tests for Catalog
Public bug reported: About testing the catalog backends (KVS, SQL and Templated). Now, we have to different test files to do the same things. keystone/tests/test_backend.py - Which has a lot of test related with Identity, Policy, Token, ... and Catalog keystone/tests/test_catalog.py - Which has a few tests only for the catalog backends. Those test are not enough to test everything in the catalog. In my opinion is not a good idea to have different test files for the same purpose because some people could implement test only in one of the test files, not in both. Also, it is a pain to maintain. I propose to remove all the test that we have right now in keystone/tests/test_catalog.py (please forget class V2CatalogTestCase(rest.RestfulTestCase)) and move the tests related with Catalog that, right now, we have in keystone/tests/test_backend.py to keystone/tests/test_catalog.py What do you think? ** 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/1396650 Title: Duplicated tests for Catalog Status in OpenStack Identity (Keystone): New Bug description: About testing the catalog backends (KVS, SQL and Templated). Now, we have to different test files to do the same things. keystone/tests/test_backend.py - Which has a lot of test related with Identity, Policy, Token, ... and Catalog keystone/tests/test_catalog.py - Which has a few tests only for the catalog backends. Those test are not enough to test everything in the catalog. In my opinion is not a good idea to have different test files for the same purpose because some people could implement test only in one of the test files, not in both. Also, it is a pain to maintain. I propose to remove all the test that we have right now in keystone/tests/test_catalog.py (please forget class V2CatalogTestCase(rest.RestfulTestCase)) and move the tests related with Catalog that, right now, we have in keystone/tests/test_backend.py to keystone/tests/test_catalog.py What do you think? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1396650/+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 1392721] [NEW] Documentation error in base tables
Public bug reported:
In /horizon/tables/base.py there is a mistake in the documentation here:
https://github.com/openstack/horizon/blob/master/horizon/tables/base.py#L197
An iterable of CSS classes which will be added when the column's text
is displayed as a link.
This is left for backward compatibility. Deprecated in favor of the
link_attributes attribute.
Example: ``classes=('link-foo', 'link-bar')``.
Defaults to ``None``
The name of the attribute is link_classes, not classes like the
example suggests. That could be confusing for developers.
For example, if you modify openstack-
dashboard/dashboards/project/images/images/tables.py file and add this:
name = tables.Column(get_image_name_version,
link=(horizon:project:images:images:detail),
verbose_name=_(Image Name),
classes=(css-foo,css-bar))
You expect something like:
a href=whatever class=css-foo css-barmy name/a
But doesn't work.
** Affects: horizon
Importance: Undecided
Assignee: Marcos Lobo (marcos-fermin-lobo)
Status: In Progress
--
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/1392721
Title:
Documentation error in base tables
Status in OpenStack Dashboard (Horizon):
In Progress
Bug description:
In /horizon/tables/base.py there is a mistake in the documentation
here:
https://github.com/openstack/horizon/blob/master/horizon/tables/base.py#L197
An iterable of CSS classes which will be added when the column's text
is displayed as a link.
This is left for backward compatibility. Deprecated in favor of the
link_attributes attribute.
Example: ``classes=('link-foo', 'link-bar')``.
Defaults to ``None``
The name of the attribute is link_classes, not classes like the
example suggests. That could be confusing for developers.
For example, if you modify openstack-
dashboard/dashboards/project/images/images/tables.py file and add
this:
name = tables.Column(get_image_name_version,
link=(horizon:project:images:images:detail),
verbose_name=_(Image Name),
classes=(css-foo,css-bar))
You expect something like:
a href=whatever class=css-foo css-barmy name/a
But doesn't work.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1392721/+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 1373439] [NEW] Django models.py bug already fixed
Public bug reported: In this file https://github.com/openstack/horizon/blob/master/horizon/models.py#L20 we have this message: Stub file to work around django bug: https://code.djangoproject.com/ticket/7198; And this bug was already fixed, so, in my opinion, we should to improve this models.py ** 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/1373439 Title: Django models.py bug already fixed Status in OpenStack Dashboard (Horizon): New Bug description: In this file https://github.com/openstack/horizon/blob/master/horizon/models.py#L20 we have this message: Stub file to work around django bug: https://code.djangoproject.com/ticket/7198; And this bug was already fixed, so, in my opinion, we should to improve this models.py To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1373439/+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 1367113] [NEW] Templated catalog backend V3 not implemented
Public bug reported: In Icehouse keystone 2014.1.1 and configuring default_catalog.templates (http://docs.openstack.org/developer/keystone/configuration.html #service-catalog). The templated catalog backend is not all implemented on V3. Functions like: - endpoint list - endpoint get (show) - region list - region get (show) - service list - service get (show) Are not implemented for V3. Examples: $ openstack --os-token ADMIN --os-url=http://localhost:5000/v3; --os-identity-api-version=3 --insecure region list $ openstack --os-token ADMIN --os-url=http://localhost:5000/v3; --os-identity-api-version=3 --insecure endpoint list $ openstack --os-token ADMIN --os-url=http://localhost:5000/v3; --os-identity-api-version=3 --insecure service list When you call them from python-keystoneclient or python-openstackclient, this calls are delegated on the Templated superclass, i.e., Kvs class. The problem is Templated backend has obtained all the info about the endpoints (reading default_catalog.templates file on __init__ function) but Kvs backend doesn't have any idea about that, so that calls always returns empty. ** Affects: keystone Importance: Undecided Assignee: Marcos Lobo (marcos-fermin-lobo) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1367113 Title: Templated catalog backend V3 not implemented Status in OpenStack Identity (Keystone): In Progress Bug description: In Icehouse keystone 2014.1.1 and configuring default_catalog.templates (http://docs.openstack.org/developer/keystone/configuration.html #service-catalog). The templated catalog backend is not all implemented on V3. Functions like: - endpoint list - endpoint get (show) - region list - region get (show) - service list - service get (show) Are not implemented for V3. Examples: $ openstack --os-token ADMIN --os-url=http://localhost:5000/v3; --os-identity-api-version=3 --insecure region list $ openstack --os-token ADMIN --os-url=http://localhost:5000/v3; --os-identity-api-version=3 --insecure endpoint list $ openstack --os-token ADMIN --os-url=http://localhost:5000/v3; --os-identity-api-version=3 --insecure service list When you call them from python-keystoneclient or python- openstackclient, this calls are delegated on the Templated superclass, i.e., Kvs class. The problem is Templated backend has obtained all the info about the endpoints (reading default_catalog.templates file on __init__ function) but Kvs backend doesn't have any idea about that, so that calls always returns empty. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1367113/+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 1363917] [NEW] Errors on Configuring Federation doumentation
Public bug reported: In Configuring Federation documentation section all the external links are break https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst#configuring-federation I think there is only one link (python-openstackclient) right, all other are break, I mean, linked to 404 Page Not Found. ** 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/1363917 Title: Errors on Configuring Federation doumentation Status in OpenStack Identity (Keystone): New Bug description: In Configuring Federation documentation section all the external links are break https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst#configuring-federation I think there is only one link (python-openstackclient) right, all other are break, I mean, linked to 404 Page Not Found. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363917/+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 1363932] [NEW] Internal error Enabling Federation Extension
Public bug reported: Following steps here http://docs.openstack.org/developer/keystone/extensions/federation.html I've realized of a possible bug, but I'm not sure, let me explain myself. Step 3 of http://docs.openstack.org/developer/keystone/extensions/federation.html [pipeline:api_v3] pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension s3_extension federation_extension service_v3 Ok, no problems. Restart keystone (under apache) and type keystone tenant-list command and every is fine, no problems. Now, modify again keystone-paste.ini file (by the way, on a fresh keystone installation this file is called keystone-dist-paste.ini by default) and put federation_extenstion at the end of the line, like: [pipeline:api_v3] pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension s3_extension service_v3 federation_extension Restart keystone and when you type keystone tenant-list command, keystone raises: Internal Server Error 500 This is the log information about this error: [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] mod_wsgi (pid=24803): Target WSGI script '/var/www/cgi-bin/keystone/main' cannot be loaded as Python module. [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] mod_wsgi (pid=24803): Exception occurred processing WSGI script '/var/www/cgi-bin/keystone/main'. [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] Traceback (most recent call last): [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /var/www/cgi-bin/keystone/main, line 58, in module [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] name=name) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] return loadobj(APP, uri, name=name, **kw) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 272, in loadobj [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] return context.create() [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 710, in create [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] return self.object_type.invoke(self) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] **context.local_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/util.py, line 56, in fix_call [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] val = callable(*args, **kw) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/urlmap.py, line 25, in urlmap_factory [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] app = loader.get_app(app_name, global_conf=global_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 350, in get_app [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] name=name, global_conf=global_conf).create() [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 362, in app_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] APP, name=name, global_conf=global_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] global_additions=global_additions) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] APP, pipeline[-1], global_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 408, in get_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] object_type, name=name) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 587, in find_config_section [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] self.filename)) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] LookupError: No section 'federation_extension' (prefixed by 'app' or 'application' or 'composite' or 'composit' or 'pipeline' or 'filter-app') found in config /usr/share/keystone/keystone-dist-paste.ini My question is: Is
[Yahoo-eng-team] [Bug 1362181] [NEW] Multi-domain has problems with domain drivers
Public bug reported:
My Environment
--
I've install RDO Openstack Icehouse, then I've upgrade to keystone-2014.2.b2
from launchpad tarball. I'm using SQL (not LDAP). With standard installation,
we have only 1 domain, the default domain. I did not configure nothing more.
What I want to achieve
--
Now, I want to configure multidomain feature on Keystone Juno 2 and I'm
following the official documentation
http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers
The problem
If I execute this command:
$ curl --insecure -H X-Auth-Token:ADMIN http://localhost:5000/v3/users
Ok, no problems, Keystone returns the json user list. Now, I'll
configure multi-domain feature.
1.- Edit /etc/keystone/keystone.conf file like
- # domain_specific_drivers_enabled=False
+ domain_specific_drivers_enabled=True
- # domain_config_dir=/etc/keystone/domains
+ domain_config_dir=/etc/keystone/domains
2.- Create default domain file.
2.1 cd /etc/keystone; mkdir domains; chown keystone:keystone domains; cd
domains;
2.2 vim keystone.default.conf
[identity]
driver = keystone.identity.backends.sql.Identity
[ldap]
2.3 chown keystone:keystone keystone.default.conf
3.- service openstack-keystone restart
Now, if try the same CURL command I obtain this error:
$ curl --insecure -H X-Auth-Token:ADMIN http://localhost:5000/v3/users
{
error: {
code: 401,
message: The request you have made requires authentication. (Disable
debug mode to suppress these details.),
title: Unauthorized
}
}
And, in the log file, I have 3 different errors:
2014-08-27 15:25:43.669 23078 DEBUG keystone.middleware.core [-] RBAC:
auth_context: {} process_request
/usr/lib/python2.6/site-packages/keystone/middleware/core.py:286
2014-08-27 15:25:43.764 23078 DEBUG keystone.common.wsgi [-] arg_dict: {}
__call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181
2014-08-27 15:25:43.765 23078 WARNING keystone.common.controller [-] RBAC:
Bypassing authorization
2014-08-27 15:25:48.051 23078 DEBUG oslo.db.sqlalchemy.session [-] MySQL server
mode set to
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
_mysql_check_effective_sql_mode
/usr/lib/python2.6/site-packages/oslo/db/sqlalchemy/session.py:401
2014-08-27 15:25:48.081 23078 WARNING keystone.common.controller [-] Invalid
token found while getting domain ID for list request
2014-08-27 15:25:48.084 23078 WARNING keystone.common.wsgi [-] Authorization
failed. The request you have made requires authentication. (Disable debug mode
to suppress these details.) (Disable debug mode to suppress these details.)
from 127.0.0.1
2014-08-27 15:25:48.090 23078 INFO eventlet.wsgi.server [-] 127.0.0.1 - -
[27/Aug/2014 15:25:48] GET /v3/users HTTP/1.1 401 357 4.421301
And some seconds later, keystone raises this error:
2014-08-27 15:26:35.707 23078 DEBUG keystone.middleware.core [-] Auth token not
in the request header. Will not build auth context. process_request
/usr/lib/python2.6/site-packages/keystone/middleware/core.py:276
2014-08-27 15:26:35.731 23078 DEBUG keystone.common.wsgi [-] arg_dict: {}
__call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181
2014-08-27 15:26:35.741 23078 ERROR keystone.common.wsgi [-] object.__init__()
takes no parameters
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi Traceback (most recent
call last):
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi File
/usr/lib/python2.6/site-packages/keystone/common/wsgi.py, line 212, in
__call__
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi result =
method(context, **params)
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi File
/usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 99, in
authenticate
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi context, auth)
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi File
/usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 279, in
_authenticate_local
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi username,
CONF.identity.default_domain_id)
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi File
/usr/lib/python2.6/site-packages/keystone/identity/core.py, line 181, in
wrapper
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi self.driver,
self.assignment_api)
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi File
/usr/lib/python2.6/site-packages/keystone/identity/core.py, line 137, in
setup_domain_drivers
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi
-len(DOMAIN_CONF_FTAIL)])
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi File
/usr/lib/python2.6/site-packages/keystone/identity/core.py, line 116, in
_load_config
2014-08-27 15:26:35.741 23078 TRACE keystone.common.wsgi
[Yahoo-eng-team] [Bug 1360244] [NEW] Heat - Select template doesn't check well template source method
Public bug reported: On Horizon Icehouse 2014.1.1 release and Heat Icehouse 2014.1.1 release. HOW TO REPRODUCE - 1.- Go to http://mydomain/dashboard/project/stacks/select_template 2.- Select URL template source 3.- Fill the URL field with an URL to a file with invalid syntax and click Next 3.- Horizon raises a correct error message about the syntax. OK 4.- Change template source to Direct input 5.- Fill textarea field with whatever characters (it doesn't matter) and click Next 6.- Horizon raises this error message: Please specify a template using only one source method. ? CONCLUSION So, the problem is: Horizon doesn't remove the data from HTML fields, on select template webpage, when something was wrong. Then, when you try another template source, Horizon doesn't remove the data from the other HTML fields before to execute the HTML form. My question, is this the behavior expected?. I was expecting that Horizon checks only the information about the template source that selected right now, not to check the previous selection. ** 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/1360244 Title: Heat - Select template doesn't check well template source method Status in OpenStack Dashboard (Horizon): New Bug description: On Horizon Icehouse 2014.1.1 release and Heat Icehouse 2014.1.1 release. HOW TO REPRODUCE - 1.- Go to http://mydomain/dashboard/project/stacks/select_template 2.- Select URL template source 3.- Fill the URL field with an URL to a file with invalid syntax and click Next 3.- Horizon raises a correct error message about the syntax. OK 4.- Change template source to Direct input 5.- Fill textarea field with whatever characters (it doesn't matter) and click Next 6.- Horizon raises this error message: Please specify a template using only one source method. ? CONCLUSION So, the problem is: Horizon doesn't remove the data from HTML fields, on select template webpage, when something was wrong. Then, when you try another template source, Horizon doesn't remove the data from the other HTML fields before to execute the HTML form. My question, is this the behavior expected?. I was expecting that Horizon checks only the information about the template source that selected right now, not to check the previous selection. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1360244/+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 1358330] [NEW] Error on _ldap_get_list without attrlist value
0x97 in position 2: invalid start byte The problem is attrlist attribute is not validated before to send it to LDAP search. ** Affects: keystone Importance: Undecided Assignee: Marcos Lobo (marcos-fermin-lobo) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1358330 Title: Error on _ldap_get_list without attrlist value Status in OpenStack Identity (Keystone): In Progress Bug description: Using keystone from master branch (keystone-2014.2.dev170.g2e49770) and configured with LDAP backend. Now, If you try this command: $ keystone tenant-list Authorization Failed: An unexpected error prevented the server from fulfilling your request: 'utf8' codec can't decode byte 0x97 in position 2: invalid start byte (Disable debug mode to suppress these details.) (HTTP 500) The _ldap_get_list (/keystone/common/ldap/core.py) function has a problem when the attrlist attribute is None. This function raises an error like: 2014-08-18 16:19:31.861 26110 ERROR keystone.common.wsgi [-] 'utf8' codec can't decode byte 0x97 in position 2: invalid start byte 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/wsgi.py, line 214, in __call__ 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi result = method(context, **params) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 99, in authenticate 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi context, auth) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 300, in _authenticate_local 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi user_id, tenant_id) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 379, in _get_project_roles_and_ref 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi user_id, tenant_id) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/core.py, line 186, in get_roles_for_user_and_project 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi user_role_list = _get_user_project_roles(user_id, project_ref) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/core.py, line 167, in _get_user_project_roles 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi tenant_id=project_ref['id']) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/backends/ldap.py, line 131, in _get_metadata 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi tenant_id) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/backends/ldap.py, line 107, in _get_roles_for_just_user_and_project 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi (self.project._id_to_dn(tenant_id)) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/assignment/backends/ldap.py, line 555, in get_role_assignments 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi roles = self._ldap_get_list(tenant_dn, ldap.SCOPE_ONELEVEL) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py, line 1422, in _ldap_get_list 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi return conn.search_s(search_base, scope, query, attrlist) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py, line 926, in search_s 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi py_result = convert_ldap_result(ldap_result) 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py, line 154, in convert_ldap_result 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi for kind, values in six.iteritems(attrs 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py, line 154, in genexpr 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi for kind, values in six.iteritems(attrs 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py, line 123, in ldap2py 2014-08-18 16:19:31.861 26110 TRACE keystone.common.wsgi return
[Yahoo-eng-team] [Bug 1343932] [NEW] CRUD grant don't check user_id and group_id
Public bug reported: In Icehouse release, CRUD grant functions[1] don't check if user_id and group_id exists. role_id, domain_id and project_id are checked and I don't see any reason why don't check user_id and group_id as well. I think we should change these functions to check if user_id and group_id exists. [1] https://github.com/openstack/keystone/blob/stable/icehouse/keystone/assignment/backends/ldap.py#L347 ** 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/1343932 Title: CRUD grant don't check user_id and group_id Status in OpenStack Identity (Keystone): New Bug description: In Icehouse release, CRUD grant functions[1] don't check if user_id and group_id exists. role_id, domain_id and project_id are checked and I don't see any reason why don't check user_id and group_id as well. I think we should change these functions to check if user_id and group_id exists. [1] https://github.com/openstack/keystone/blob/stable/icehouse/keystone/assignment/backends/ldap.py#L347 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1343932/+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 1336769] [NEW] LDAP additional attribute mappings do not care about model attribute
Public bug reported:
Additional attribute mappings can be used to map ldap attributes to
internal keystone attributes. This allows keystone to fulfill ldap
objectclass requirements. List of additional LDAP attributes used for
mapping additional attribute mappings for users (or projects). Attribute
mapping format is ldap_attr:model_attr, where ldap_attr is the
attribute in the LDAP entry and model_attr is the Identity API
attribute. (list value).
So far so good. Now, following next steps:
1- Apply this patch https://review.openstack.org/#/c/91490/
2- Add this parameter to keystone.conf file
tenant_additional_attribute_mapping = objectCategory:notexistingfield1,
whenChanged:notexistingfield2
3- Add 'objectCategory' and 'whenChanged' LDAP parameters to Project model on
keystone/common/models.py
class Project(Model):
required_keys = ('id', 'name', 'domain_id')
optional_keys = ('description', 'enabled', 'objectCategory', 'whenChanged')
4- Restart keystone
5- Execute this in command line:
curl -H X-Auth-Token:admin_token http://localhost:5000/v3/projects
Everything works perfectly!. you can see the info of 'objectCategory'
and 'whenChanged' LDAP parameters in the JSON string returned by CURL...
and it should not (I think) works, because notexistingfield1 and
notexistingfield2 are not real fields.
I have a mistake in the keystone.conf file and everything is working
properly.
** 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/1336769
Title:
LDAP additional attribute mappings do not care about model attribute
Status in OpenStack Identity (Keystone):
New
Bug description:
Additional attribute mappings can be used to map ldap attributes to
internal keystone attributes. This allows keystone to fulfill ldap
objectclass requirements. List of additional LDAP attributes used for
mapping additional attribute mappings for users (or projects).
Attribute mapping format is ldap_attr:model_attr, where ldap_attr
is the attribute in the LDAP entry and model_attr is the Identity API
attribute. (list value).
So far so good. Now, following next steps:
1- Apply this patch https://review.openstack.org/#/c/91490/
2- Add this parameter to keystone.conf file
tenant_additional_attribute_mapping = objectCategory:notexistingfield1,
whenChanged:notexistingfield2
3- Add 'objectCategory' and 'whenChanged' LDAP parameters to Project model
on keystone/common/models.py
class Project(Model):
required_keys = ('id', 'name', 'domain_id')
optional_keys = ('description', 'enabled', 'objectCategory',
'whenChanged')
4- Restart keystone
5- Execute this in command line:
curl -H X-Auth-Token:admin_token http://localhost:5000/v3/projects
Everything works perfectly!. you can see the info of 'objectCategory'
and 'whenChanged' LDAP parameters in the JSON string returned by
CURL... and it should not (I think) works, because notexistingfield1
and notexistingfield2 are not real fields.
I have a mistake in the keystone.conf file and everything is working
properly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1336769/+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 1335046] [NEW] project_additional_attribute_mapping not loaded on Havana
Public bug reported: On openstack-keystone-2013.2.3-2 keystone config file https://github.com/openstack/keystone/blob/stable/havana/etc/keystone.conf.sample#L416 there is a reference to project_additional_attribute_mapping parameter. This parameter is not loaded on Havana version. When Keystone is started, you can check the log file and you can realize that project_additional_attribute_mapping parameter is not checked to load its value. Instead of that, tenant_additional_attribute_mapping https://github.com/openstack/keystone/blob/stable/havana/keystone/common/config.py#L208 is the real name of this kind of parameter (whatever_additional_attribute_mapping kind) for Havana version, because you can see on the log file that keystone try to load the value of this parameter from keystone.conf. I propose to change this line https://github.com/openstack/keystone/blob/stable/havana/etc/keystone.conf.sample#L416 to the appropriate name, I mean, from project_additional_attribute_mapping to tenant_additional_attribute_mapping ** Affects: keystone Importance: Undecided Status: New ** Tags: havana-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1335046 Title: project_additional_attribute_mapping not loaded on Havana Status in OpenStack Identity (Keystone): New Bug description: On openstack-keystone-2013.2.3-2 keystone config file https://github.com/openstack/keystone/blob/stable/havana/etc/keystone.conf.sample#L416 there is a reference to project_additional_attribute_mapping parameter. This parameter is not loaded on Havana version. When Keystone is started, you can check the log file and you can realize that project_additional_attribute_mapping parameter is not checked to load its value. Instead of that, tenant_additional_attribute_mapping https://github.com/openstack/keystone/blob/stable/havana/keystone/common/config.py#L208 is the real name of this kind of parameter (whatever_additional_attribute_mapping kind) for Havana version, because you can see on the log file that keystone try to load the value of this parameter from keystone.conf. I propose to change this line https://github.com/openstack/keystone/blob/stable/havana/etc/keystone.conf.sample#L416 to the appropriate name, I mean, from project_additional_attribute_mapping to tenant_additional_attribute_mapping To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1335046/+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 1333712] [NEW] NotImplemented _for_groups functions on LDAP
Public bug reported: These functions are not implemented on assignment LDAP backend: - get_roles_for_groups - list_projects_for_groups - list_domains_for_groups ** Affects: keystone Importance: Undecided Assignee: Marcos Lobo (marcos-fermin-lobo) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1333712 Title: NotImplemented _for_groups functions on LDAP Status in OpenStack Identity (Keystone): In Progress Bug description: These functions are not implemented on assignment LDAP backend: - get_roles_for_groups - list_projects_for_groups - list_domains_for_groups To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1333712/+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 1327101] [NEW] Slash character missed on delete using V2
Public bug reported: Using openstack-glance-2013.2.3-2.el6.noarch and V2 API. If you execute the command below: $ glance --debug --os-image-api-version 2 image-delete IMAGE-ID You can see a lot of CURL operations, and the last one has a typo in the URL between the port number and v2. A slash character is missed. curl -i -X DELETE -H 'X-Auth-Token: THEBIGTOKEN' -H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' http://IPADDRESS:9292v2/images/IMAGE-ID However, the command works perfectly. ** 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/1327101 Title: Slash character missed on delete using V2 Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Using openstack-glance-2013.2.3-2.el6.noarch and V2 API. If you execute the command below: $ glance --debug --os-image-api-version 2 image-delete IMAGE-ID You can see a lot of CURL operations, and the last one has a typo in the URL between the port number and v2. A slash character is missed. curl -i -X DELETE -H 'X-Auth-Token: THEBIGTOKEN' -H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' http://IPADDRESS:9292v2/images/IMAGE-ID However, the command works perfectly. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1327101/+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 1323646] [NEW] Documentation Configuring Glance API to use Keystone without auth_version
Public bug reported: The official documentation to use keystone in Glance API has not information about the auth_version parameter. - https://github.com/openstack/glance/blob/master/doc/source/authentication.rst#configuring-glance-api-to-use-keystone - http://docs.openstack.org/havana/install-guide/install/apt-debian/content/debconf-keystone_authtoken.html auth_version parameter gives the opportunity, to glance API, to specify the keystone API version to communicate with keystone (v2 or v3). If auth_version is not on the glance-api.conf, v2 API is used by default to communicate with keystone. I didn't find any documentation about how to configure this parameter on Glance API (and maybe on Glance registry). ** 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/1323646 Title: Documentation Configuring Glance API to use Keystone without auth_version Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: The official documentation to use keystone in Glance API has not information about the auth_version parameter. - https://github.com/openstack/glance/blob/master/doc/source/authentication.rst#configuring-glance-api-to-use-keystone - http://docs.openstack.org/havana/install-guide/install/apt-debian/content/debconf-keystone_authtoken.html auth_version parameter gives the opportunity, to glance API, to specify the keystone API version to communicate with keystone (v2 or v3). If auth_version is not on the glance-api.conf, v2 API is used by default to communicate with keystone. I didn't find any documentation about how to configure this parameter on Glance API (and maybe on Glance registry). To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1323646/+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 1284430] Re: check the url format when create endpoint
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** No longer affects: python-openstackclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1284430
Title:
check the url format when create endpoint
Status in OpenStack Identity (Keystone):
In Progress
Bug description:
Currently, the url allows any parameters when create endpoint, such as:
curl -i -H X-Auth-Token:admin -H Content-Type:application/json
http://127.0.0.1:35357/v3/endpoints -d
'{endpoint:{interface:test,service_id:d893b85ae4f842d5bb1727e271cf5be3,url:111}}'
HTTP/1.1 201 Created
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 252
Date: Tue, 25 Feb 2014 03:13:30 GMT
{endpoint: {links: {self:
http://192.168.70.108:5000/v3/endpoints/81638ad18b9e4495aac576c006c1fed1},
url: 111, region: null, interface: test, service_id:
d893b85ae4f842d5bb1727e271cf5be3, id:
81638ad18b9e4495aac576c006c1fed1}}
Should we add a check that the url parameter must be url format like?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1284430/+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 1317815] [NEW] Documetation Keystone SSL configuration lack
Public bug reported: Trying to configuring SSL on OpenStack Havana I read the official documentation here https://github.com/openstack/keystone/blob/stable/havana/doc/source/configuration.rst#ssl But I think that configuration is not enough to configure SSL on OpenStack. As far I know, to configure SSL on OpenStack, besides the configuration above, it is necessary to modify endpoints protocol from http to https and this is not documented on the official SSL Configuration document. Please, confirm if I'm wrong. ** 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/1317815 Title: Documetation Keystone SSL configuration lack Status in OpenStack Identity (Keystone): New Bug description: Trying to configuring SSL on OpenStack Havana I read the official documentation here https://github.com/openstack/keystone/blob/stable/havana/doc/source/configuration.rst#ssl But I think that configuration is not enough to configure SSL on OpenStack. As far I know, to configure SSL on OpenStack, besides the configuration above, it is necessary to modify endpoints protocol from http to https and this is not documented on the official SSL Configuration document. Please, confirm if I'm wrong. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317815/+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 1308442] [NEW] The same tabindex value on each subnav-list item
Public bug reported: On left panel, in the dashboard, each link (overview, instances, volumes, etc.) has the same value for tabindex attribute on a tag. Tabindex attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#the-tabindex- attribute indicate that an element is supposed to be focusable and specifies the tab order of an element. If each link has the same tabindex value would not exist any kind of order. Each link should have a different value for tabindex. ** Affects: horizon Importance: Undecided Status: New ** Description changed: - On left panel, in the dashboard, each link has the same value for - tabindex attribute on a tag. + On left panel, in the dashboard, each link (overview, instances, + volumes, etc.) has the same value for tabindex attribute on a tag. Tabindex attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#the-tabindex- attribute indicate that an element is supposed to be focusable and specifies the tab order of an element. If each link has the same tabindex value would not exist any kind of order. Each link should have a different value for tabindex. -- 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/1308442 Title: The same tabindex value on each subnav-list item Status in OpenStack Dashboard (Horizon): New Bug description: On left panel, in the dashboard, each link (overview, instances, volumes, etc.) has the same value for tabindex attribute on a tag. Tabindex attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#the- tabindex-attribute indicate that an element is supposed to be focusable and specifies the tab order of an element. If each link has the same tabindex value would not exist any kind of order. Each link should have a different value for tabindex. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308442/+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 1285065] [NEW] list_role_assignments does not return group roles assignments
Public bug reported: The list_role_assignments() function on LDAP assignment backend only returns users roles assignments, not groups roles assignments. Allowing to obtain group role assignments too, we can achieve that a user can access to a project through a group. In the list_role_assignments() function on SQL assignment backend that is implemented. ** Affects: keystone Importance: Undecided Status: New ** Summary changed: - list_role_assignments does not returns group roles assignments + list_role_assignments does not return group roles assignments -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1285065 Title: list_role_assignments does not return group roles assignments Status in OpenStack Identity (Keystone): New Bug description: The list_role_assignments() function on LDAP assignment backend only returns users roles assignments, not groups roles assignments. Allowing to obtain group role assignments too, we can achieve that a user can access to a project through a group. In the list_role_assignments() function on SQL assignment backend that is implemented. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1285065/+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 1284639] [NEW] Unimplemented get roles by group for project list
Public bug reported: The list_projects_for_user() function on LDAP assignment backend only search projects with associations across user_id, not across group_ids. This function admits the group_ids parameter, but never is used on the body of the function. I think is necessary change this function to can search projects with associations across user_id and group_id. USE CASE: --- Check if user named 'u1' (inside group 'G2') has grants on project named 'p1'. We have this hierarchy: P1 - G1 - G2 - U1 In this use case, user 'U1' should have grants on project 'P1' because user 'U1' belongs to group 'G2', 'G2' belongs to 'G1', and 'G1' has grants on 'P1'. What happens to the current code: User 'U1' has not grants on project 'P1'. That is because list_projects_for_user() only search associations between user and project directly and not between groups and projects. ** Affects: keystone Importance: Undecided Assignee: Marcos Lobo (marcos-fermin-lobo) Status: New ** Changed in: keystone Assignee: (unassigned) = Marcos Lobo (marcos-fermin-lobo) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1284639 Title: Unimplemented get roles by group for project list Status in OpenStack Identity (Keystone): New Bug description: The list_projects_for_user() function on LDAP assignment backend only search projects with associations across user_id, not across group_ids. This function admits the group_ids parameter, but never is used on the body of the function. I think is necessary change this function to can search projects with associations across user_id and group_id. USE CASE: --- Check if user named 'u1' (inside group 'G2') has grants on project named 'p1'. We have this hierarchy: P1 - G1 - G2 - U1 In this use case, user 'U1' should have grants on project 'P1' because user 'U1' belongs to group 'G2', 'G2' belongs to 'G1', and 'G1' has grants on 'P1'. What happens to the current code: User 'U1' has not grants on project 'P1'. That is because list_projects_for_user() only search associations between user and project directly and not between groups and projects. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1284639/+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 1277463] [NEW] Unimplemented error on V3 get token
Public bug reported:
Configuring keystone on V3. If you try this curl command:
$ curl -i -X POST https://theserver:5000/v3/auth/tokens -H Content-
Type: application/json -d '{auth: {identity: {methods:
[password], password: {user: {domain: {name: Default},
name: USERNAME, password: PASSWORD}' --insecure
The response is:
{error: {message: The action you have requested has not been
implemented., code: 501, title: Not Implemented}}
** Affects: keystone
Importance: Undecided
Assignee: Marcos Lobo (marcos-fermin-lobo)
Status: New
** Changed in: keystone
Assignee: (unassigned) = Marcos Lobo (marcos-fermin-lobo)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1277463
Title:
Unimplemented error on V3 get token
Status in OpenStack Identity (Keystone):
New
Bug description:
Configuring keystone on V3. If you try this curl command:
$ curl -i -X POST https://theserver:5000/v3/auth/tokens -H Content-
Type: application/json -d '{auth: {identity: {methods:
[password], password: {user: {domain: {name: Default},
name: USERNAME, password: PASSWORD}' --insecure
The response is:
{error: {message: The action you have requested has not been
implemented., code: 501, title: Not Implemented}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1277463/+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 1274402] [NEW] Local variable 'domain_ref' referenced before assignment
Public bug reported: On keystone havana version. If you configure keystone.conf like this: ... domain_specific_drivers_enabled = True domain_config_dir = /etc/keystone/domains ... After restart openstack-keystone service, if you execute this command for the first: $keystone user-list System raises this error 2014-01-29 15:57:46.606 9939 WARNING keystone.identity.core [-] Running an experimental and unsupported configuration (domain_specific_drivers_enabled = True); this will result in known issues. 2014-01-29 15:57:46.659 9939 WARNING keystone.identity.core [-] Invalid domain name (dominioldap) found in config file name 2014-01-29 15:57:46.659 9939 ERROR keystone.common.wsgi [-] local variable 'domain_ref' referenced before assignment 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/wsgi.py, line 238, in __call__ 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi result = method(context, **params) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 94, in authenticate 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi context, auth) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 257, in _authenticate_local 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi username, DEFAULT_DOMAIN_ID) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/identity/core.py, line 176, in wrapper 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi self.driver, self.assignment_api) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/identity/core.py, line 128, in setup_domain_drivers 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi names[1]) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/identity/core.py, line 96, in _load_config 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi if domain_ref: 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi UnboundLocalError: local variable 'domain_ref' referenced before assignment This problem is derived from the previous WARNING about the invalid domain name. However, there is a codification problem on /usr/lib/python2.6/site-packages/keystone/identity/core.py line 104, because if the DomainNotFound is raised (whatever reason) the domain_ref variable will never been initialized. Therefore on line 110 an uncontrolled error local variable 'domain_ref' referenced before assignment will be raised. ** Affects: keystone Importance: Undecided Assignee: Marcos Lobo (marcos-fermin-lobo) Status: New ** Changed in: keystone Assignee: (unassigned) = Marcos Lobo (marcos-fermin-lobo) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1274402 Title: Local variable 'domain_ref' referenced before assignment Status in OpenStack Identity (Keystone): New Bug description: On keystone havana version. If you configure keystone.conf like this: ... domain_specific_drivers_enabled = True domain_config_dir = /etc/keystone/domains ... After restart openstack-keystone service, if you execute this command for the first: $keystone user-list System raises this error 2014-01-29 15:57:46.606 9939 WARNING keystone.identity.core [-] Running an experimental and unsupported configuration (domain_specific_drivers_enabled = True); this will result in known issues. 2014-01-29 15:57:46.659 9939 WARNING keystone.identity.core [-] Invalid domain name (dominioldap) found in config file name 2014-01-29 15:57:46.659 9939 ERROR keystone.common.wsgi [-] local variable 'domain_ref' referenced before assignment 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/common/wsgi.py, line 238, in __call__ 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi result = method(context, **params) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 94, in authenticate 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi context, auth) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6/site-packages/keystone/token/controllers.py, line 257, in _authenticate_local 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi username, DEFAULT_DOMAIN_ID) 2014-01-29 15:57:46.659 9939 TRACE keystone.common.wsgi File /usr/lib/python2.6
[Yahoo-eng-team] [Bug 1271948] [NEW] Unexpected response in agent-list command with --field param
Public bug reported: On Neutron Havana (server and client). If you read the documentation about agent-list command you can read this: # neutron help agent-list ... -F FIELD, --field FIELD specify the field(s) to be returned by server, can be repeated ... I think there is a problem with --field FIELD parameter. If you try this command you obtain an unexpected response: # neutron agent-list --field agent_type 'alive' I think 'alive' is NOT the expected response for that request. I was expected to obtain something like: # neutron agent-list --field agent_type ++ | agent_type | ++ | DHCP agent | | Open vSwitch agent | ++ But, if you try to obtain alive field, the response is the expected one. # neutron agent-list --field alive +---+ | alive | +---+ | :-) | | :-) | +---+ ** Affects: neutron Importance: Undecided Assignee: Marcos Lobo (marcos-fermin-lobo) Status: New ** Changed in: neutron Assignee: (unassigned) = Marcos Lobo (marcos-fermin-lobo) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1271948 Title: Unexpected response in agent-list command with --field param Status in OpenStack Neutron (virtual network service): New Bug description: On Neutron Havana (server and client). If you read the documentation about agent-list command you can read this: # neutron help agent-list ... -F FIELD, --field FIELD specify the field(s) to be returned by server, can be repeated ... I think there is a problem with --field FIELD parameter. If you try this command you obtain an unexpected response: # neutron agent-list --field agent_type 'alive' I think 'alive' is NOT the expected response for that request. I was expected to obtain something like: # neutron agent-list --field agent_type ++ | agent_type | ++ | DHCP agent | | Open vSwitch agent | ++ But, if you try to obtain alive field, the response is the expected one. # neutron agent-list --field alive +---+ | alive | +---+ | :-) | | :-) | +---+ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1271948/+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 1247142] Re: Live LDAP tests fail when trying to create user with an arbitrary attribute
** Changed in: keystone Status: New = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1247142 Title: Live LDAP tests fail when trying to create user with an arbitrary attribute Status in OpenStack Identity (Keystone): Fix Released Bug description: I ran _ldap_livetest and it failed with the following traceback: FAIL: keystone.tests.test_ldap_livetest.LiveLDAPIdentity.test_arbitrary_attributes_are_returned_from_create_user tags: worker-0 -- Traceback (most recent call last): File keystone/tests/test_backend.py, line 2646, in test_arbitrary_attributes_are_returned_from_create_user user = self.identity_api.create_user(user_data['id'], user_data) File keystone/notifications.py, line 44, in wrapper result = f(*args, **kwargs) File keystone/identity/core.py, line 179, in wrapper return f(self, *args, **kwargs) File keystone/identity/core.py, line 324, in create_user ref = driver.create_user(user_id, user) File keystone/identity/backends/ldap.py, line 95, in create_user user_ref = self.user.create(user) File keystone/identity/backends/ldap.py, line 229, in create values = super(UserApi, self).create(values) File keystone/common/ldap/core.py, line 738, in create ref = super(EnabledEmuMixIn, self).create(values) File keystone/common/ldap/core.py, line 342, in create conn.add_s(self._id_to_dn(values['id']), attrs) File keystone/common/ldap/core.py, line 565, in add_s return self.conn.add_s(dn, ldap_attrs) File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 194, in add_s return self.result(msgid,all=1,timeout=self.timeout) File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 96, in _ldap_call result = func(*args,**kwargs) There are four tests in total which work with arbitrary attributes, but three of them are skipped in test_backend_ldap: def test_arbitrary_attributes_are_returned_from_get_user(self): self.skipTest(Using arbitrary attributes doesn't work under LDAP) def test_new_arbitrary_attributes_are_returned_from_update_user(self): self.skipTest(Using arbitrary attributes doesn't work under LDAP) def test_updated_arbitrary_attributes_are_returned_from_update_user(self): self.skipTest(Using arbitrary attributes doesn't work under LDAP) So I find it strange that test_arbitrary_attributes_are_returned_from_create_user is not skipped like these three. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1247142/+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
