[Yahoo-eng-team] [Bug 1899115] [NEW] cached tokens prevent to validate modified assignments
Public bug reported:
Observed on Train.
4 units of Keystone deployed, each backed by shared mysql, with individual
memcached local daemon for caching.
The user is assigned the role "member" in the project, validating new token
returns proper assignment from every keystone unit:
[
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
},
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
}
]
Adding the role of "admin" within the same project, request succeeded,
database is adjusted, query of new roles list in the project for the
user works fine.
User issues new token, validation returns new role in the project only
from one unit of keystone, other 3 still show old list. Eventually
(around 10 minutes timeframe) they all pick up.
$ for i in 43 52 53 60; do curl --insecure -i -H "X-Auth-Token: " -H
"X-Subject-Token: " https://172.31.248.$i:35347/v3/auth/tokens |grep
\{ |jq .token.roles; done
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 12433 100 124330 0 311k 0 --:--:-- --:--:-- --:--:-- 311k
[
{
"id": "a2565b5e5bb440ac9a964f726ccd2f26",
"name": "admin"
},
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
},
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
}
]
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 12372 100 123720 0 294k 0 --:--:-- --:--:-- --:--:-- 294k
[
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
},
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
}
]
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 12372 100 123720 0 280k 0 --:--:-- --:--:-- --:--:-- 287k
[
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
},
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
}
]
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 12372 100 123720 0 246k 0 --:--:-- --:--:-- --:--:-- 246k
[
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
},
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
}
]
The root cause is the "expiration_time" in [cache] section to be set to 600
seconds. During this time the units of keystone which were not yet issuing the
token for the user with new assignments are returning old information.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1899115
Title:
cached tokens prevent to validate modified assignments
Status in OpenStack Identity (keystone):
New
Bug description:
Observed on Train.
4 units of Keystone deployed, each backed by shared mysql, with individual
memcached local daemon for caching.
The user is assigned the role "member" in the project, validating new token
returns proper assignment from every keystone unit:
[
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
},
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
}
]
Adding the role of "admin" within the same project, request succeeded,
database is adjusted, query of new roles list in the project for the
user works fine.
User issues new token, validation returns new role in the project only
from one unit of keystone, other 3 still show old list. Eventually
(around 10 minutes timeframe) they all pick up.
$ for i in 43 52 53 60; do curl --insecure -i -H "X-Auth-Token: "
-H "X-Subject-Token: " https://172.31.248.$i:35347/v3/auth/tokens
|grep \{ |jq .token.roles; done
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 12433 100 124330 0 311k 0 --:--:-- --:--:-- --:--:-- 311k
[
{
"id": "a2565b5e5bb440ac9a964f726ccd2f26",
"name": "admin"
},
{
"id": "758f4dc35c7b4377bfcba1ae083c2808",
"name": "member"
},
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name": "reader"
}
]
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 12372 100 123720 0 294k 0 --:--:-- --:--:-- --:--:-- 294k
[
{
"id": "d1ea6664378645a788f44b8a1a44e874",
"name":
[Yahoo-eng-team] [Bug 1663077] [NEW] [ipv6] when slaas is setup as ipv6_address_mode ipv6-icmp packets are rejected by iptables
Public bug reported: Mitaka and Newton Setting up subnet with ipv6 addressing for provider network (baremetal external router providing RA). Expecting the advertising packets to be able to reach out to instance so that the instance can pick the subnet from the external router. What happens: Iptables on the compute node is only set up to allow certain types of ipv6-icmp: -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j RETURN while RA type is 134. The list of available types most likely has to be extended in the Neutron constants or some deeper logic has to be implemented. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1663077 Title: [ipv6] when slaas is setup as ipv6_address_mode ipv6-icmp packets are rejected by iptables Status in neutron: New Bug description: Mitaka and Newton Setting up subnet with ipv6 addressing for provider network (baremetal external router providing RA). Expecting the advertising packets to be able to reach out to instance so that the instance can pick the subnet from the external router. What happens: Iptables on the compute node is only set up to allow certain types of ipv6-icmp: -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j RETURN -A neutron-linuxbri-i4d4602ea-3 -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j RETURN while RA type is 134. The list of available types most likely has to be extended in the Neutron constants or some deeper logic has to be implemented. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1663077/+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 1646563] [NEW] Allow user specify custom project ID on project create
Public bug reported: As the user I have to be able to specify project ID upon creation: "openstack project create --id xxxyyyzzz project1" The usecase covered by this functionality: Multi-site deployment with independent Keystone in each site and centralized authentication. In this case with the feature implemented it is possible to re-use the token from one environment in the other ones, allowing the users to switch between environments easily, as well as allowing any automated tools to manipulate with the workloads/collect statistics with no additional acts of authorization. ** Affects: keystone Importance: Undecided Assignee: Andrey Grebennikov (agrebennikov) Status: New ** Changed in: keystone Assignee: (unassigned) => Andrey Grebennikov (agrebennikov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1646563 Title: Allow user specify custom project ID on project create Status in OpenStack Identity (keystone): New Bug description: As the user I have to be able to specify project ID upon creation: "openstack project create --id xxxyyyzzz project1" The usecase covered by this functionality: Multi-site deployment with independent Keystone in each site and centralized authentication. In this case with the feature implemented it is possible to re-use the token from one environment in the other ones, allowing the users to switch between environments easily, as well as allowing any automated tools to manipulate with the workloads/collect statistics with no additional acts of authorization. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1646563/+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 1592940] [NEW] Horizon makes duclicated and extra requests
Public bug reported:
Horizon Liberty
User reports slowness of the dashboard for most of the tabs.
Investigation shows that Horizon makes duplicated requests when it is trying to
request information related to the networking. It also waits for about 4
seconds right after the initial user's successfull authentication before it
proceeds with the first API call.
Here is the log of Horizon representing the delay:
2016-06-15 18:24:16,385 113992 DEBUG openstack_auth.backend Beginning user
authentication
2016-06-15 18:24:16,387 113992 DEBUG openstack_auth.plugin.password Attempting
to authenticate for admin
2016-06-15 18:24:16,387 113992 DEBUG keystoneclient.auth.identity.v3.base
Making authentication request to http://192.168.210.69:5000/v3/auth/tokens
2016-06-15 18:24:16,481 113992 DEBUG keystoneclient.session REQ: curl -g -i
--insecure -X GET http://192.168.210.69:5000/v3/ -H "Accept: application/j
son" -H "User-Agent: python-keystoneclient"
2016-06-15 18:24:16,503 113992 DEBUG keystoneclient.session RESP: [200]
content-length: 253 vary: X-Auth-Token server: Apache connection: close date:
Wed, 15 Jun 2016 18:24:16 GMT content-type: application/json
x-openstack-request-id: req-258d4e76-6500-414d-a565-0788dc0d4f90
RESP BODY: {"version": {"status": "stable", "updated": "2015-03-30T00:00:00Z",
"media-types": [{"base": "application/json", "type": "application/vnd.o
penstack.identity-v3+json"}], "id": "v3.4", "links": [{"href":
"http://192.168.210.69:5000/v3/;, "rel": "self"}]}}
2016-06-15 18:24:16,503 113992 DEBUG keystoneclient.session REQ: curl -g -i
--insecure -X GET http://192.168.210.69:5000/v3/users/51e3873fe48f4948bef2
32865c7bc84f/projects -H "User-Agent: python-keystoneclient" -H "Accept:
application/json" -H "X-Auth-Token: {SHA1}561e3b22c0693b6ff8dfad099a2492d95ed
8e9c1"
2016-06-15 18:24:16,561 113992 DEBUG keystoneclient.session RESP: [200]
content-length: 412 vary: X-Auth-Token server: Apache connection: close date:
Wed, 15 Jun 2016 18:24:16 GMT content-type: application/json
x-openstack-request-id: req-765b3844-feb3-40b9-a843-f5cc2341afde
RESP BODY: {"links": {"self":
"http://192.168.210.69:5000/v3/users/51e3873fe48f4948bef232865c7bc84f/projects;,
"previous": null, "next": null}, "proje
cts": [{"is_domain": false, "description": "admin tenant", "links": {"self":
"http://192.168.210.69:5000/v3/projects/49cdffc876ca4927af2ea7505ad27264;
}, "enabled": true, "id": "49cdffc876ca4927af2ea7505ad27264", "parent_id":
null, "domain_id": "default", "name": "admin"}]}
2016-06-15 18:24:16,561 113992 DEBUG keystoneclient.auth.identity.v3.base
Making authentication request to http://192.168.210.69:5000/v3/auth/tokens
2016-06-15 18:24:16,657 113992 DEBUG openstack_auth.backend Authentication
completed.
2016-06-15 18:24:16,657 113992 INFO openstack_auth.forms Login successful for
user "admin".
2016-06-15 18:24:20,167 113996 DEBUG neutronclient.client REQ: curl -i
https://domain.com:9696/v2.0/extensions.json -X GET -H "User-Agent: pyt
hon-neutronclient" -H "X-Auth-Token:
{SHA1}04486c34b57ca19787b77e6d5e6e9fad48914b67"
Last 2 rows represent the issue.
I'll attach parsed logs for each tab opening in order to show duplicated
requests.
** 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/1592940
Title:
Horizon makes duclicated and extra requests
Status in OpenStack Dashboard (Horizon):
New
Bug description:
Horizon Liberty
User reports slowness of the dashboard for most of the tabs.
Investigation shows that Horizon makes duplicated requests when it is trying
to request information related to the networking. It also waits for about 4
seconds right after the initial user's successfull authentication before it
proceeds with the first API call.
Here is the log of Horizon representing the delay:
2016-06-15 18:24:16,385 113992 DEBUG openstack_auth.backend Beginning user
authentication
2016-06-15 18:24:16,387 113992 DEBUG openstack_auth.plugin.password
Attempting to authenticate for admin
2016-06-15 18:24:16,387 113992 DEBUG keystoneclient.auth.identity.v3.base
Making authentication request to http://192.168.210.69:5000/v3/auth/tokens
2016-06-15 18:24:16,481 113992 DEBUG keystoneclient.session REQ: curl -g -i
--insecure -X GET http://192.168.210.69:5000/v3/ -H "Accept: application/j
son" -H "User-Agent: python-keystoneclient"
2016-06-15 18:24:16,503 113992 DEBUG keystoneclient.session RESP: [200]
content-length: 253 vary: X-Auth-Token server: Apache connection: close date:
Wed, 15 Jun 2016 18:24:16 GMT content-type: application/json
x-openstack-request-id: req-258d4e76-6500-414d-a565-0788dc0d4f90
RESP BODY: {"version": {"status": "stable", "updated":
"2015-03-30T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.o
[Yahoo-eng-team] [Bug 1526462] Re: Need support for OpenDirectory in LDAP driver
** Changed in: keystone Status: Fix Released => In Progress ** Changed in: keystone Assignee: Alexander Makarov (amakarov) => Andrey Grebennikov (agrebennikov) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526462 Title: Need support for OpenDirectory in LDAP driver Status in OpenStack Identity (keystone): In Progress Bug description: It is necessary to support Apple OpenDirectory as the backend for Keystone Identity. OpenDirectory uses a concept of POSIX groups, when the entities of users in the groups are represented as UIDs, not full DNs: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: user1 memberUid: user2 while in the driver of LDAP it is hardcoded that the entities could be only full DNs, like: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: uid=user1,cn=users,dc=domain,dc=com memberUid: uid=user2,cn=users,dc=domain,dc=com Because of this reason it is impossible to use groups in Keystone and we cannot assign the roles to the Keystone groups - Keystone doesn't recognize any user to be a part of any group. When it checks the roles, it searches for the direct user's assignments, and then for any groups which the user can be a member of. So by default the search returns nothing. We have to have an additional parameter in the config where we specify the type of the entity in the groups - whether is it currently a dn or an id. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526462/+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 1526462] [NEW] Need support for OpenDirectory in LDAP driver
Public bug reported: It is necessary to support Apple OpenDirectory as the backend for Keystone Identity. OpenDirectory uses a concept of POSIX groups, when the entities of users in the groups are represented as UIDs, not full DNs: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: user1 memberUid: user2 while in the driver of LDAP it is hardcoded that the entities could be only full DNs, like: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: uid=user1,cn=users,dc=domain,dc=com memberUid: uid=user2,cn=users,dc=domain,dc=com Because of this reason it is impossible to use groups in Keystone and we cannot assign the roles to the Keystone groups - Keystone doesn't recognize any user to be a part of any group. When it checks the roles, it searches for the direct user's assignments, and then for any groups which the user can be a member of. So by default the search returns nothing. We have to have an additional parameter in the config where we specify the type of the entity in the groups - whether is it currently a dn or an id. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526462 Title: Need support for OpenDirectory in LDAP driver Status in OpenStack Identity (keystone): New Bug description: It is necessary to support Apple OpenDirectory as the backend for Keystone Identity. OpenDirectory uses a concept of POSIX groups, when the entities of users in the groups are represented as UIDs, not full DNs: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: user1 memberUid: user2 while in the driver of LDAP it is hardcoded that the entities could be only full DNs, like: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: uid=user1,cn=users,dc=domain,dc=com memberUid: uid=user2,cn=users,dc=domain,dc=com Because of this reason it is impossible to use groups in Keystone and we cannot assign the roles to the Keystone groups - Keystone doesn't recognize any user to be a part of any group. When it checks the roles, it searches for the direct user's assignments, and then for any groups which the user can be a member of. So by default the search returns nothing. We have to have an additional parameter in the config where we specify the type of the entity in the groups - whether is it currently a dn or an id. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526462/+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
