| lbragstad | but that might be a good question for them (zaneb or ricolin) | 00:00 |
|---|---|---|
| brtknr | hmmm | 00:02 |
| *** opetrenko__ has quit IRC | 00:25 | |
| *** N3l1x has joined #openstack-keystone | 00:32 | |
| *** Nel1x has quit IRC | 00:32 | |
| *** whoami-rajat has joined #openstack-keystone | 01:18 | |
| openstackgerrit | Merged openstack/keystone master: Update endpoint policies for system admin https://review.openstack.org/619331 | 02:17 |
| openstackgerrit | guang-yee proposed openstack/keystone master: Fixes incorrect params passing https://review.openstack.org/634816 | 02:23 |
| *** Dinesh_Bhor has joined #openstack-keystone | 02:32 | |
| *** gyee has quit IRC | 02:35 | |
| *** awalende has joined #openstack-keystone | 02:44 | |
| openstackgerrit | guang-yee proposed openstack/keystone master: Fixes incorrect params https://review.openstack.org/634816 | 02:46 |
| *** awalende has quit IRC | 02:49 | |
| *** Dinesh_Bhor has quit IRC | 02:58 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 03:04 | |
| *** dave-mccowan has quit IRC | 03:44 | |
| *** Dinesh_Bhor has quit IRC | 03:54 | |
| *** lbragstad has quit IRC | 03:59 | |
| openstackgerrit | Merged openstack/keystone master: Replace 'tenant_id' with 'project_id' https://review.openstack.org/631706 | 04:04 |
| *** Dinesh_Bhor has joined #openstack-keystone | 04:42 | |
| *** dims has quit IRC | 04:58 | |
| *** shyamb has joined #openstack-keystone | 05:06 | |
| *** N3l1x has quit IRC | 05:19 | |
| *** shyamb has quit IRC | 05:48 | |
| *** shyamb has joined #openstack-keystone | 06:01 | |
| *** shyamb has quit IRC | 06:10 | |
| *** shyamb has joined #openstack-keystone | 06:10 | |
| *** markvoelker has joined #openstack-keystone | 06:45 | |
| *** dims has joined #openstack-keystone | 06:48 | |
| *** dims has quit IRC | 06:52 | |
| *** dims has joined #openstack-keystone | 06:54 | |
| *** dims has quit IRC | 06:59 | |
| *** dims has joined #openstack-keystone | 07:02 | |
| *** markvoelker has quit IRC | 07:18 | |
| *** Emine has joined #openstack-keystone | 07:43 | |
| *** pcaruana has joined #openstack-keystone | 07:45 | |
| *** shyamb has quit IRC | 07:58 | |
| *** tkajinam has quit IRC | 08:06 | |
| *** awalende has joined #openstack-keystone | 08:08 | |
| *** markvoelker has joined #openstack-keystone | 08:15 | |
| *** shyamb has joined #openstack-keystone | 08:45 | |
| *** markvoelker has quit IRC | 08:49 | |
| *** xek__ has joined #openstack-keystone | 09:01 | |
| *** Dinesh_Bhor has quit IRC | 09:35 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 09:36 | |
| *** markvoelker has joined #openstack-keystone | 09:46 | |
| *** markvoelker has quit IRC | 10:19 | |
| opetrenko | Hi all. Is there any possibility to add ability to use one scoped token in several keystones with single idp? | 10:30 |
| *** shyamb has quit IRC | 10:32 | |
| brtknr | zaneb? ricolin? | 10:32 |
| *** shyamb has joined #openstack-keystone | 10:43 | |
| *** aloga has quit IRC | 11:05 | |
| *** Dinesh_Bhor has quit IRC | 11:11 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 11:13 | |
| *** markvoelker has joined #openstack-keystone | 11:15 | |
| *** erus1 has joined #openstack-keystone | 11:30 | |
| brtknr | Anyone here can tell me why I am able to create a heat stack only as a trustor, not | 11:39 |
| brtknr | as the trustee but then able to make changes and delete a stack even as a trustee as | 11:39 |
| brtknr | expected? | 11:39 |
| cmurphy | opetrenko: no that is not possible and we're probably not going to add it, what's your use case for it? | 11:48 |
| cmurphy | brtknr: that sounds like it may be due to the policy configuration, you might ask the heat team in #openstack-heat | 11:48 |
| *** markvoelker has quit IRC | 11:48 | |
| brtknr | Thanks for getting back cmurphy, I am also trying to get hold of somebody in #heat to answer the question but its pretty quiet in there today | 11:50 |
| opetrenko | cmurphy: We have deployment with severals regions, spread worldwide. The thing is, user can use horizon and then switch region. After this user is being logged out. It's not user-friendly. | 11:51 |
| *** aloga has joined #openstack-keystone | 11:52 | |
| opetrenko | cmurphy: another possible solution is to add horizon an ability to store both scoped and unscoped tokens, so when you change region, horizon can scope unscoped token in another region. This way, from keystone side consistent uuids for federated users should be added. | 12:02 |
| cmurphy | opetrenko: the word region is a little overloaded, a single keystone can have multiple regions and the same token should work on all of them. are you using keystone-to-keystone and switching keystone service providers? | 12:04 |
| opetrenko | cmurphy: I have this test setup: 2 keystones both look into one shibboleth as IdP that uses openldap. | 12:06 |
| cmurphy | opetrenko: oh got it, so you mean that the user has to log out explicitly so they can choose another IdP in the login screen | 12:07 |
| opetrenko | No. We have one IdP, where both keystones looks into | 12:08 |
| opetrenko | keystones are bootstraped as two different regions. | 12:08 |
| opetrenko | but this is test setup. | 12:08 |
| opetrenko | The use case of this, is when you use horizon with multiple keystones configured to use one IdP. | 12:09 |
| opetrenko | When user tries to change the region, he's being force logged out from horizon, since it can't use the same scoped token for different keystone, despite both keystones are configured to use the same shibboleth(IdP). | 12:12 |
| *** erus1 has quit IRC | 12:12 | |
| opetrenko | cmurphy: that's it | 12:12 |
| *** erus1 has joined #openstack-keystone | 12:12 | |
| cmurphy | I see. You can't use an unscoped token from one keystone on another keystone so I don't think that would solve the issue. | 12:13 |
| opetrenko | If we can add some consistency in user uuids, we would be able to use the same unscoped token | 12:14 |
| opetrenko | imagine, we have shared fernet repo, so both keystones use the same fernet keys; both looks into the same idp. | 12:15 |
| opetrenko | The problem is, when you want to scope in one keystone unscoped token that you got in another one, keystone will response with "cant find user with `#####` id" | 12:16 |
| opetrenko | if we can set up the same federated users in both keystones, the token will have all needed information to identify who is this user, and later scope this token to some project. | 12:20 |
| cmurphy | opetrenko: yeah I think that would work | 12:20 |
| opetrenko | cmurphy:So consistent uuids and reworks from horizon side is preferred to use one scoped token in several keystones? | 12:22 |
| *** raildo has joined #openstack-keystone | 12:22 | |
| cmurphy | opetrenko: the thing is you could already achieve this now if you configure your keystones as a keystone-to-keystone configuration, while still also having the external IdP, then you wouldn't have to use the same token on multiple keystones | 12:25 |
| cmurphy | I think with predictable uuids we will be able to use the same token but i'm not sure we want to encourage that | 12:25 |
| opetrenko | As I can see, Adam Young have 2 patches for consistent uuids | 12:26 |
| cmurphy | he will probably be around later today so we can discuss it more with him | 12:26 |
| opetrenko | https://review.openstack.org/#/c/623117/ and https://review.openstack.org/#/c/605169/ | 12:26 |
| opetrenko | Yeah, I would like to discuss possibilities to add this in keystone | 12:27 |
| *** markvoelker has joined #openstack-keystone | 12:46 | |
| *** shyamb has quit IRC | 13:03 | |
| *** lbragstad has joined #openstack-keystone | 13:05 | |
| *** ChanServ sets mode: +o lbragstad | 13:05 | |
| *** jmlowe has quit IRC | 13:17 | |
| *** markvoelker has quit IRC | 13:19 | |
| *** Dinesh_Bhor has quit IRC | 13:30 | |
| *** jmlowe has joined #openstack-keystone | 13:35 | |
| *** mvkr has quit IRC | 13:52 | |
| *** dave-mccowan has joined #openstack-keystone | 14:09 | |
| *** dave-mccowan has quit IRC | 14:13 | |
| *** markvoelker has joined #openstack-keystone | 14:16 | |
| *** mvkr has joined #openstack-keystone | 14:20 | |
| brtknr | Revisiting this patch https://review.openstack.org/#/c/126897/31/keystone/tests/test_v3_auth.py, does allow_redelegation flag have a CLI toggle? | 14:32 |
| *** markvoelker has quit IRC | 14:49 | |
| *** awalende has quit IRC | 14:54 | |
| *** erus1 has quit IRC | 14:54 | |
| *** awalende has joined #openstack-keystone | 14:55 | |
| *** erus1 has joined #openstack-keystone | 14:55 | |
| *** Nel1x has joined #openstack-keystone | 14:59 | |
| *** awalende has quit IRC | 14:59 | |
| *** lbragstad has quit IRC | 15:35 | |
| *** lbragstad has joined #openstack-keystone | 15:35 | |
| *** ChanServ sets mode: +o lbragstad | 15:35 | |
| brtknr | cmurphy: have you much experience with devstack? | 15:39 |
| brtknr | i'd like to know how I can edit keystone.conf file | 15:39 |
| cmurphy | brtknr: it's in /etc/keystone/keystone.conf, you can edit that and then `systemctl restart devstack@keystone` | 15:40 |
| brtknr | ive just run `tox -e genconfig` which claims to have generated /opt/stack/keystone/etc/keystone.conf | 15:40 |
| cmurphy | devstack puts its own config file in /etc/keystone/keystone.conf, tox -egenconfig just creates a sample file | 15:41 |
| *** vishakha has joined #openstack-keystone | 15:45 | |
| *** markvoelker has joined #openstack-keystone | 15:46 | |
| brtknr | cool, that explains why putting keystone.conf inside /opt/stack/keystone/etc/keystone.conf was causing errors | 15:47 |
| brtknr | how do i check what is the currently loaded configuration? | 15:47 |
| *** Emine has quit IRC | 15:47 | |
| brtknr | i am inspecting keystone.conf.CONF.items() but that does not show the boolean value that I modified | 15:56 |
| cmurphy | brtknr: if you have debug enabled then it shows up in the logs | 15:56 |
| brtknr | cmurphy: ah yes, in the debug logs, it allow_redelegation does appear to be enabled. | 15:58 |
| *** gyee has joined #openstack-keystone | 16:02 | |
| brtknr | cmurphy: however, its not having the effect I was expecting, heat stacks still refuse to be created as a redelegated user | 16:14 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Converting the application tests to use flask's test_client https://review.openstack.org/631255 | 16:15 |
| openstackgerrit | Morgan Fainberg proposed openstack/keystone master: Converting the application tests to use flask's test_client https://review.openstack.org/631255 | 16:16 |
| *** Emine has joined #openstack-keystone | 16:19 | |
| *** erus1 has quit IRC | 16:19 | |
| *** markvoelker has quit IRC | 16:19 | |
| *** erus1 has joined #openstack-keystone | 16:19 | |
| brtknr | I dont understand why the point of allow_redelegation is if I cant use it to create heat stack... | 16:31 |
| *** erus1 has quit IRC | 16:31 | |
| *** erus1 has joined #openstack-keystone | 16:32 | |
| *** openstackgerrit has quit IRC | 16:35 | |
| lbragstad | cmurphy vishakha sorry - i didn't mean to cut you off there | 16:41 |
| cmurphy | no worries | 16:41 |
| vishakha | yeah no worries | 16:41 |
| cmurphy | kmalloc: lbragstad: opetrenko brought something up a few hours ago in scrollback, where once user IDs are predictable then tokens could be used on different keystones, is that something we want? | 16:42 |
| kmalloc | that is a fine thing | 16:43 |
| kmalloc | as long as the keys are shared. | 16:43 |
| kmalloc | (fernet/jse) | 16:43 |
| cmurphy | I recall we were pushing back on that for a while | 16:43 |
| *** jmlowe has quit IRC | 16:44 | |
| kmalloc | right. but with the move towards the edge bits, looking at the oath model, it works to our favor | 16:44 |
| kmalloc | oath effectively uses a token to generate user data in the distributed keystone with a predictable id | 16:44 |
| kmalloc | we've changed tack on this as the needs have changed. we're still requiring a keystone-provided bit to generate the id | 16:44 |
| kmalloc | so it's not strictly "give me an id" and using that, the major concern was that without a keystone-provided data set for the hash, someone could squat on the id or worse setup a malicious user via another idp | 16:45 |
| *** erus1 has quit IRC | 16:45 | |
| kmalloc | with the keystone-supplied data, that is less of a concern, as all ids from given sources should be unique when hashed (if not, it's a misconfiguration) | 16:46 |
| cmurphy | that was one concern but the other was that allowing the token to be used on more than one keystone increases the attack surface | 16:46 |
| kmalloc | it does. | 16:46 |
| *** erus1 has joined #openstack-keystone | 16:46 | |
| kmalloc | but that is now a configuration choice. | 16:46 |
| kmalloc | if keys are not shared (and legitimately should not be shared if the token is not meant to be consumed by the remote keystone) | 16:46 |
| kmalloc | it's the same as today | 16:46 |
| lbragstad | iirc - the attack surface was the main reason for not pursuing that approach | 16:47 |
| kmalloc | i would still recommend never configuring it that way and force local tokens to a given keystone | 16:47 |
| kmalloc | however, predictable IDs are more useful than "prevent someone from doing something somewhat silly" | 16:47 |
| kmalloc | especially leaning towards and into the edge use-cases. | 16:47 |
| cmurphy | kmalloc: that opetrenko wants to do is enhance horizon so that it can use the same token on multiple keystones | 16:48 |
| cmurphy | i suggested k2k is a better approach | 16:48 |
| kmalloc | i would really push for k2k | 16:48 |
| lbragstad | doesn't opetrenko want to have all users in a single idp, though? | 16:48 |
| kmalloc | so, if an IDP is truely shared, and single source with multiple discrete keystones i could see the benefit | 16:49 |
| cmurphy | I am pretty sure you could do both - external idp + k2k | 16:49 |
| kmalloc | really i would probably not even do k2k | 16:49 |
| kmalloc | i would do a re-auth to the local region | 16:49 |
| opetrenko | k2k has several problems | 16:49 |
| cmurphy | it's not a local region, it's another keystone | 16:50 |
| kmalloc | it's about the same amount of work to automate / make happen | 16:50 |
| kmalloc | cmurphy: the distributed keystone* ignore my region | 16:50 |
| kmalloc | i know ayoung has requests in for this same usecase | 16:51 |
| kmalloc | tokens issued from one keystone usable elsewhere because idp is mirrored | 16:51 |
| kmalloc | opetrenko: note, you still must make sure domain id, and project ids, etc are replicated in the remote keystones | 16:51 |
| kmalloc | even if you wanted to do this. | 16:51 |
| kmalloc | it's a major hurdle that really just is easier if you create one identity control plane that all the sites use. | 16:52 |
| opetrenko | kmalloc: I guess, domain_id is not encoded in unscoped token | 16:52 |
| kmalloc | and in that case -- shared tokens across deployments make a lot of sense. | 16:52 |
| lbragstad | if you're using a domain-scoped token, it will be | 16:52 |
| lbragstad | (because it's the scope target of the token) | 16:53 |
| kmalloc | lbragstad: right but for that token to work in a remote keystone, the domain information must be there | 16:53 |
| kmalloc | in the keystone db | 16:53 |
| kmalloc | it's easier to setup a replicated or centralized keystone | 16:53 |
| opetrenko | centralized keystone is not a solution | 16:53 |
| *** mvkr has quit IRC | 16:53 | |
| opetrenko | imagine we have 2 keystones in different parts of the world | 16:54 |
| kmalloc | you can replicate between those. | 16:54 |
| opetrenko | replicate db? | 16:54 |
| kmalloc | a small set of keystones can totally be replicated globally on a wan | 16:54 |
| kmalloc | yes. | 16:54 |
| opetrenko | it's too expensive and sometime hard to sync db's | 16:54 |
| kmalloc | usually performance can tolerate, due to low transaction rate on identity sources, ~9-10 sites with galera | 16:55 |
| kmalloc | as in, i wouldn't feel awful recommending a sub 10 site replicated galera db for production if it meets the needs | 16:56 |
| *** erus1 has quit IRC | 16:56 | |
| kmalloc | and in that case you share keys and all data is consistent. | 16:56 |
| kmalloc | tokens work anywhere. | 16:56 |
| kmalloc | deployments become regions in keystone parlance. | 16:56 |
| *** erus1 has joined #openstack-keystone | 16:56 | |
| kmalloc | now, if you can't do that, you are better treating the keystones as nothing shared, even if the identity source is the same. don't share keys and force re-auth to each keystone. | 16:57 |
| kmalloc | that way you aren't running into issues where ids/full data sets are not consistent | 16:57 |
| opetrenko | that creates bad UX with horizon | 16:57 |
| kmalloc | k2k helps smooth that over. | 16:58 |
| opetrenko | when all the time you have to relogin | 16:58 |
| opetrenko | k2k means one master keystone? | 16:58 |
| kmalloc | no, k2k means keystones are idps for eachother | 16:58 |
| opetrenko | that's not the best solution for prod | 16:58 |
| kmalloc | it's bi-directional | 16:58 |
| opetrenko | ok, but what if I want shibboleth as id[? | 16:59 |
| opetrenko | idp* | 16:59 |
| kmalloc | k2k relies on shibboleth in most deployments | 16:59 |
| kmalloc | it's that keystone can also be an idp for another keystone | 16:59 |
| opetrenko | that will be like that?: keystone ->keystone -> idp? | 16:59 |
| kmalloc | idp [SSO workflow]-> keystone [SSO workflow]-> keystone | 17:00 |
| kmalloc | where the second case the first keysotne becomes the IDP and the second keystone is the SP | 17:00 |
| kmalloc | you really have 3 options today: | 17:00 |
| kmalloc | 1) Share Nothing | 17:00 |
| kmalloc | (4 options) | 17:00 |
| kmalloc | and in share-nothing you said UX sucks. | 17:00 |
| kmalloc | 2) Autoprovisioning (limited support), use oath model or similar, (3rd party code) | 17:01 |
| kmalloc | 3) K2K | 17:01 |
| kmalloc | -- ok maybe just those 3. | 17:01 |
| opetrenko | well | 17:01 |
| kmalloc | in the future it will get better. | 17:02 |
| opetrenko | le me ask about k2k since I do not understand this model | 17:02 |
| kmalloc | we are working on improving the #2 option | 17:02 |
| kmalloc | sure, think of k2k as chained SSO | 17:02 |
| kmalloc | and any keystone could be configured to be an IDP for another keystone. | 17:02 |
| opetrenko | we have 2 keystones, where one is idp and another one is sp? | 17:02 |
| opetrenko | ok got | 17:03 |
| opetrenko | so they both can be configured as idps for each other? | 17:03 |
| kmalloc | yes. | 17:03 |
| opetrenko | and then I can configure them to use shibboleth as idp? | 17:03 |
| kmalloc | IDs are, unfortunately different, but the k2k workflow helps to smooth the transition | 17:03 |
| kmalloc | yes, you can use shibboleth as the original IDP on either side. | 17:04 |
| opetrenko | well | 17:04 |
| kmalloc | in the future we will work to make this easier where keystone can act as a IDP-broker/proxy. | 17:04 |
| kmalloc | it will be much smoother. | 17:04 |
| kmalloc | but that is a ways down the line | 17:04 |
| opetrenko | Still can't get how this works. If one keystone asks another(idp for first ks), and the second is configured to have first ks as idp, how can second keystone decide what to use as idp: shibboleth or first ks? | 17:06 |
| kmalloc | in k2k it's always idp-initiated workflow | 17:07 |
| kmalloc | rather than SP initiated | 17:07 |
| opetrenko | what do you mean? | 17:07 |
| kmalloc | you tell keystone1: I want to go to keystone2, keystone1 starts the process | 17:07 |
| kmalloc | most SSO forms you reach out to the SP and the SP redirects you to the IDP for auth | 17:08 |
| kmalloc | IDP-initiated means you start from the IDP | 17:08 |
| kmalloc | you don't ask the second keystone what IDP to use, you explicitly supply the information because you started from the IDP side. | 17:08 |
| opetrenko | so, I can setup two keystones with shibboleth with ldap, then go to first ks ask for unscoped token and then scope it in another keystone? | 17:09 |
| kmalloc | lbragstad, cmurphy: ^ can you step in and help with some of this workflow, i need to go eat food -- going to fall over. | 17:10 |
| kmalloc | opetrenko: i can try and help further if neither of them are available | 17:10 |
| kmalloc | but i need to eat first :) | 17:10 |
| opetrenko | sure | 17:10 |
| opetrenko | thx | 17:10 |
| * cmurphy reads back | 17:11 | |
| lbragstad | i'll be honest, i'm not as familiar with the federated flows as kmalloc and cmurphy are | 17:11 |
| cmurphy | oh i have a picture for this | 17:12 |
| *** erus1 has quit IRC | 17:12 | |
| lbragstad | that documentation is already paying off | 17:12 |
| cmurphy | https://docs.openstack.org/keystone/latest/admin/federation/introduction.html#id3 | 17:12 |
| *** erus1 has joined #openstack-keystone | 17:13 | |
| cmurphy | so regular flow is you ask the keystone sp for a token, keystone forwards you to the idp to auth, you take your saml assertion back to keystone and then you get a token | 17:14 |
| cmurphy | with k2k you start at the idp, which is keystone, and get an assertion first | 17:14 |
| cmurphy | and then take that to your other keystone to get a token | 17:14 |
| cmurphy | so with this chained model you would start at say keystone A and treat it like an SP, get your assertion from your external IdP to get a token on keystone A, then turn the token on keystone A into an assertion and then take it to keystone B to get a token | 17:15 |
| cmurphy | and keystone A and keystone B could be configured as IdPs for each other so it wouldn't matter whether you started with A or B | 17:15 |
| *** markvoelker has joined #openstack-keystone | 17:16 | |
| opetrenko | ok, does this somehow affects time/load? | 17:16 |
| cmurphy | there are a few round trips involved so it would take a bit of time to get your final token | 17:18 |
| opetrenko | ok, do any db syncs needed? | 17:19 |
| *** erus1 has quit IRC | 17:19 | |
| cmurphy | no, the keystones would be completely independent from each other | 17:19 |
| *** erus1 has joined #openstack-keystone | 17:19 | |
| opetrenko | ok, there will be no master as I understood? | 17:20 |
| opetrenko | not master keystone* | 17:20 |
| opetrenko | no master keystone* | 17:20 |
| cmurphy | no there would be no need for one to be a master i don't think | 17:20 |
| opetrenko | ok, thanks for help | 17:21 |
| cmurphy | no problem | 17:22 |
| *** jmlowe has joined #openstack-keystone | 17:27 | |
| *** jmlowe has quit IRC | 17:36 | |
| *** markvoelker has quit IRC | 17:48 | |
| *** erus1 has quit IRC | 17:50 | |
| *** erus1 has joined #openstack-keystone | 17:50 | |
| *** jmlowe has joined #openstack-keystone | 17:57 | |
| *** dims has quit IRC | 18:06 | |
| *** openstackgerrit has joined #openstack-keystone | 18:09 | |
| openstackgerrit | Merged openstack/keystone master: Converting the API tests to use flask's test_client https://review.openstack.org/630301 | 18:09 |
| *** dims has joined #openstack-keystone | 18:26 | |
| *** erus1 has quit IRC | 18:27 | |
| *** Nel1x has quit IRC | 18:29 | |
| *** erus has joined #openstack-keystone | 18:37 | |
| *** markvoelker has joined #openstack-keystone | 18:46 | |
| *** itlinux has joined #openstack-keystone | 18:49 | |
| lbragstad | gyee i was able to verify https://bugs.launchpad.net/keystone/+bug/1814589 manually, but when i apply https://review.openstack.org/#/c/634816/ i get https://pasted.tech/pastes/990ff74d14542e7fbec84413854ebe7c42bbd4b7.raw | 18:49 |
| openstack | Launchpad bug 1814589 in OpenStack Identity (keystone) "Tokenless auth: ephemeral user mapping is broken" [High,In progress] - Assigned to Guang Yee (guang-yee) | 18:49 |
| lbragstad | is that true for you, too? | 18:49 |
| lbragstad | that's the same error as https://bugs.launchpad.net/keystone/+bug/1811605 | 18:51 |
| openstack | Launchpad bug 1811605 in OpenStack Identity (keystone) "Tokenless authentication is broken" [High,Triaged] | 18:51 |
| lbragstad | so i assume we'll fix that separately | 18:51 |
| gyee | lbragstad, sorry, I haven't try master branch yet | 18:57 |
| gyee | still waiting on the devstack fix | 18:57 |
| gyee | https://review.openstack.org/#/c/634833/ | 18:57 |
| gyee | I'll fix that part after I get devstack working again on master branch | 18:57 |
| lbragstad | oh - ncie | 18:58 |
| lbragstad | nice* | 18:58 |
| gyee | lbragstad, meanwhile I've pushed what I have to my github if you want to give it a spin | 18:58 |
| gyee | lbragstad, https://github.com/guangyee/keystone-devel | 18:59 |
| gyee | that'll setup everything in one go | 18:59 |
| lbragstad | sweet | 19:00 |
| gyee | I'll wire up the x.509 federation bit later today | 19:00 |
| lbragstad | reading through the plays now | 19:12 |
| *** vishakha has quit IRC | 19:12 | |
| *** dims has quit IRC | 19:16 | |
| *** markvoelker has quit IRC | 19:19 | |
| *** dims has joined #openstack-keystone | 19:25 | |
| *** pcaruana has quit IRC | 19:27 | |
| *** mvkr has joined #openstack-keystone | 20:09 | |
| *** markvoelker has joined #openstack-keystone | 20:16 | |
| *** jmlowe has quit IRC | 20:29 | |
| *** markvoelker has quit IRC | 20:48 | |
| *** xek__ has quit IRC | 21:20 | |
| *** itlinux has quit IRC | 21:29 | |
| *** erus has quit IRC | 21:30 | |
| *** erus has joined #openstack-keystone | 21:34 | |
| *** raildo has quit IRC | 21:36 | |
| *** markvoelker has joined #openstack-keystone | 21:46 | |
| *** mchlumsky has quit IRC | 21:52 | |
| *** markvoelker has quit IRC | 22:20 | |
| *** tkajinam has joined #openstack-keystone | 22:55 | |
| *** erus has quit IRC | 22:58 | |
| *** erus has joined #openstack-keystone | 23:01 | |
| *** erus has quit IRC | 23:08 | |
| *** erus has joined #openstack-keystone | 23:13 | |
| *** markvoelker has joined #openstack-keystone | 23:16 | |
| *** erus has quit IRC | 23:45 | |
| *** erus has joined #openstack-keystone | 23:46 | |
| *** erus has quit IRC | 23:48 | |
| *** erus has joined #openstack-keystone | 23:48 | |
| *** imacdonn has quit IRC | 23:48 | |
| *** imacdonn has joined #openstack-keystone | 23:49 | |
| *** markvoelker has quit IRC | 23:50 | |
| *** erus has quit IRC | 23:52 | |
| *** erus has joined #openstack-keystone | 23:57 | |
| *** gagehugo has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!