| *** henrynash has joined #openstack-keystone | 00:03 | |
| *** masber has joined #openstack-keystone | 00:05 | |
| *** aojea has joined #openstack-keystone | 00:30 | |
| *** aojea has quit IRC | 00:35 | |
| *** erlon has quit IRC | 00:45 | |
| *** jamielennox|away is now known as jamielennox | 01:06 | |
| *** richm has quit IRC | 01:15 | |
| *** stradling has quit IRC | 01:22 | |
| *** thorst has joined #openstack-keystone | 01:37 | |
| *** thorst has quit IRC | 01:42 | |
| *** namnh has joined #openstack-keystone | 01:48 | |
| *** tovin07 has joined #openstack-keystone | 01:50 | |
| *** rcernin has joined #openstack-keystone | 01:58 | |
| openstackgerrit | Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585 | 02:21 |
|---|---|---|
| *** thorst has joined #openstack-keystone | 02:38 | |
| *** rcernin has quit IRC | 02:45 | |
| *** catintheroof has joined #openstack-keystone | 02:55 | |
| *** dave-mccowan has joined #openstack-keystone | 02:55 | |
| *** thorst has quit IRC | 02:57 | |
| *** dave-mcc_ has quit IRC | 02:57 | |
| *** dave-mccowan has quit IRC | 03:05 | |
| *** namnh has quit IRC | 03:06 | |
| openstackgerrit | Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585 | 03:10 |
| *** thorst has joined #openstack-keystone | 03:54 | |
| *** thorst has quit IRC | 03:58 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 04:01 | |
| *** catintheroof has quit IRC | 04:10 | |
| *** thorst has joined #openstack-keystone | 04:54 | |
| *** rcernin has joined #openstack-keystone | 04:56 | |
| *** thorst has quit IRC | 04:59 | |
| openstackgerrit | Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585 | 05:06 |
| *** knangia has joined #openstack-keystone | 05:07 | |
| *** lamt has quit IRC | 05:14 | |
| *** rcernin has quit IRC | 05:18 | |
| *** rcernin has joined #openstack-keystone | 05:31 | |
| *** IRCFrEAK has joined #openstack-keystone | 05:49 | |
| *** IRCFrEAK has left #openstack-keystone | 05:50 | |
| *** Aqsa has joined #openstack-keystone | 05:54 | |
| *** adriant has quit IRC | 05:55 | |
| *** thorst has joined #openstack-keystone | 05:55 | |
| *** thorst has quit IRC | 05:59 | |
| *** oomichi has quit IRC | 06:03 | |
| *** oomichi has joined #openstack-keystone | 06:04 | |
| openstackgerrit | Sean McCully proposed openstack/keystoneauth master: KeystoneAuth should default to system CAFile. https://review.openstack.org/452585 | 06:26 |
| *** oomichi has quit IRC | 06:29 | |
| *** oomichi has joined #openstack-keystone | 06:30 | |
| *** voelzmo has joined #openstack-keystone | 06:31 | |
| *** tesseract has joined #openstack-keystone | 06:34 | |
| *** Elaine_wu has joined #openstack-keystone | 06:35 | |
| *** hoonetorg has quit IRC | 06:37 | |
| *** wuyanjun has quit IRC | 06:38 | |
| *** voelzmo has quit IRC | 06:38 | |
| *** voelzmo has joined #openstack-keystone | 06:42 | |
| *** belmoreira has joined #openstack-keystone | 06:50 | |
| *** thorst has joined #openstack-keystone | 06:56 | |
| *** pcaruana has joined #openstack-keystone | 06:57 | |
| *** jaosorior has joined #openstack-keystone | 06:57 | |
| *** thorst has quit IRC | 07:00 | |
| *** Aqsa has quit IRC | 07:21 | |
| *** aojea has joined #openstack-keystone | 07:21 | |
| openstackgerrit | Merged openstack/keystone master: Differentiate between dpkg and rpm for libssl-dev https://review.openstack.org/450891 | 07:25 |
| *** knangia has quit IRC | 07:31 | |
| openstackgerrit | Merged openstack/keystone master: Remove unnecessary setUp function in testcase https://review.openstack.org/451666 | 07:55 |
| *** thorst has joined #openstack-keystone | 07:56 | |
| *** zzzeek has quit IRC | 08:00 | |
| *** zzzeek has joined #openstack-keystone | 08:00 | |
| *** bjornar_ has joined #openstack-keystone | 08:01 | |
| *** openstackgerrit has quit IRC | 08:03 | |
| *** tuan_ has joined #openstack-keystone | 08:09 | |
| tuan_ | Morning guys | 08:10 |
| tuan_ | i have had a look to the patch of "allow fetching an expired token" in keystone | 08:11 |
| tuan_ | https://blueprints.launchpad.net/keystone/+spec/allow-expired | 08:11 |
| tuan_ | it is merged in octaka | 08:11 |
| tuan_ | does it mean that with the service-token fetched in request, from Octaka, keystone allows this feature | 08:11 |
| tuan_ | therefore with the deffered actions later, we do not need to worry about the expired tokens | 08:12 |
| *** Aqsa has joined #openstack-keystone | 08:12 | |
| *** thorst has quit IRC | 08:16 | |
| *** aojea_ has joined #openstack-keystone | 08:21 | |
| *** aojea has quit IRC | 08:24 | |
| *** lxnch_ has joined #openstack-keystone | 08:51 | |
| *** mtreinish has quit IRC | 08:53 | |
| *** lxnch has quit IRC | 08:55 | |
| *** sjain has joined #openstack-keystone | 08:57 | |
| *** mtreinish has joined #openstack-keystone | 08:57 | |
| *** sjain has quit IRC | 09:04 | |
| *** Aqsa has quit IRC | 09:04 | |
| *** henrynash has quit IRC | 09:04 | |
| *** openstackgerrit has joined #openstack-keystone | 09:13 | |
| openstackgerrit | Samriddhi proposed openstack/keystoneauth master: Updated inconsistent value of scope parameter https://review.openstack.org/452652 | 09:13 |
| *** thorst has joined #openstack-keystone | 09:13 | |
| *** thorst has quit IRC | 09:17 | |
| *** szaher has quit IRC | 09:25 | |
| *** szaher has joined #openstack-keystone | 09:30 | |
| *** szaher has quit IRC | 09:33 | |
| *** szaher has joined #openstack-keystone | 09:39 | |
| *** Aqsa has joined #openstack-keystone | 10:00 | |
| *** tovin07 has quit IRC | 10:01 | |
| *** szaher has quit IRC | 10:01 | |
| *** szaher has joined #openstack-keystone | 10:04 | |
| *** rcernin has quit IRC | 10:05 | |
| *** hoonetorg has joined #openstack-keystone | 10:07 | |
| *** szaher has quit IRC | 10:10 | |
| *** szaher has joined #openstack-keystone | 10:11 | |
| *** nicolasbock has joined #openstack-keystone | 10:23 | |
| *** rcernin has joined #openstack-keystone | 10:24 | |
| *** raildo has joined #openstack-keystone | 10:45 | |
| *** ayoung has quit IRC | 11:05 | |
| *** ayoung has joined #openstack-keystone | 11:07 | |
| *** tuan_ has quit IRC | 11:11 | |
| *** Aqsa has quit IRC | 11:13 | |
| *** Aqsa has joined #openstack-keystone | 11:14 | |
| *** 07EAANV6F has joined #openstack-keystone | 11:16 | |
| *** thorst has joined #openstack-keystone | 11:34 | |
| *** thorst has quit IRC | 11:36 | |
| *** ma9_ has joined #openstack-keystone | 11:45 | |
| *** jgr is now known as jgrassler | 11:49 | |
| *** voelzmo has quit IRC | 11:52 | |
| *** voelzmo has joined #openstack-keystone | 11:53 | |
| openstackgerrit | M V P Nitesh proposed openstack/keystonemiddleware master: replace_six_iteritems https://review.openstack.org/452729 | 12:00 |
| *** thorst has joined #openstack-keystone | 12:00 | |
| *** henrynash has joined #openstack-keystone | 12:01 | |
| *** Aqsam has joined #openstack-keystone | 12:01 | |
| *** Aqsa has quit IRC | 12:03 | |
| *** henrynash has quit IRC | 12:04 | |
| *** henrynash has joined #openstack-keystone | 12:05 | |
| *** henrynash has quit IRC | 12:06 | |
| *** nle5223__ has joined #openstack-keystone | 12:25 | |
| *** Aqsam has quit IRC | 12:27 | |
| *** henrynash has joined #openstack-keystone | 12:31 | |
| *** edmondsw has joined #openstack-keystone | 12:32 | |
| *** jaosorior is now known as jaosorior_brb | 12:36 | |
| dolphm | if anyone is interested in reviewing this nova-spec, i think it would benefit from feedback from the keystone community https://review.openstack.org/#/c/438134/ | 12:47 |
| dolphm | cc- lbragstad ^ | 12:47 |
| dolphm | lbragstad: would be relevant to rderose and jamielennox, for sure | 12:48 |
| lbragstad | dolphm nice - i just starred it | 12:49 |
| *** ravelar has joined #openstack-keystone | 12:50 | |
| openstackgerrit | M V P Nitesh proposed openstack/python-keystoneclient master: Replace six.iteritems() with .items() https://review.openstack.org/452741 | 12:51 |
| *** spilla has joined #openstack-keystone | 12:57 | |
| *** voelzmo has quit IRC | 13:03 | |
| *** cristicalin has joined #openstack-keystone | 13:08 | |
| cristicalin | does anybody have a config example for keystone with redis as the caching backend ? | 13:09 |
| *** adu has quit IRC | 13:13 | |
| *** mordred has left #openstack-keystone | 13:15 | |
| *** mordred has joined #openstack-keystone | 13:16 | |
| *** stradling has joined #openstack-keystone | 13:18 | |
| dstanek | dolphm: do you know what the usecase is for that? | 13:19 |
| ma9_ | Does the Openstack CLI support a Keystone which uses OIDC as backend? | 13:21 |
| *** bjornar_ has quit IRC | 13:24 | |
| *** ayoung has quit IRC | 13:26 | |
| openstackgerrit | M V P Nitesh proposed openstack/keystonemiddleware master: replace_six_iteritems https://review.openstack.org/452729 | 13:27 |
| *** catintheroof has joined #openstack-keystone | 13:31 | |
| *** belmorei_ has joined #openstack-keystone | 13:31 | |
| *** jaosorior_brb is now known as jaosorior | 13:33 | |
| *** belmoreira has quit IRC | 13:33 | |
| *** voelzmo has joined #openstack-keystone | 13:33 | |
| *** ma9_1 has joined #openstack-keystone | 13:37 | |
| *** ma9_ has quit IRC | 13:39 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Remove unused methods in unit test test_revoke https://review.openstack.org/452769 | 13:45 |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Refactor test_revoke to call check_token directly https://review.openstack.org/451874 | 13:47 |
| *** stradling has quit IRC | 13:48 | |
| *** cristicalin has quit IRC | 13:53 | |
| *** knangia has joined #openstack-keystone | 13:56 | |
| *** henrynash has quit IRC | 13:58 | |
| *** belmorei_ has quit IRC | 13:58 | |
| dolphm | dstanek: there were a few that came up, and there's a few already in openstack. for example, glance creates a container in swift to store your images, but you shouldn't be able to mess with them through swift | 13:59 |
| *** voelzmo has quit IRC | 14:00 | |
| dolphm | dstanek: same for snapshots, etc. | 14:00 |
| dolphm | dstanek: and a bunch of the services that layer on top of openstack IaaS don't want you to be able to mess with those resources without going through them | 14:01 |
| *** belmoreira has joined #openstack-keystone | 14:01 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Remove unused method _sample_data in test_revoke https://review.openstack.org/452772 | 14:02 |
| dstanek | dolphm: gotcha...the spec was lacking examples when i did a quick pass-thru | 14:04 |
| dolphm | dstanek: kubernetes VMs, maybe octavia VMs (although they don't want to consume the user's VM quota) | 14:04 |
| dolphm | dstanek: it definitely is | 14:05 |
| dolphm | dstanek: my high level criticism of the spec is that there seems to be an opportunity to create a generalized solution for all openstack services, rather than something nova-specific and having to generalize later | 14:06 |
| *** belmoreira has quit IRC | 14:06 | |
| dolphm | i.e. the problem is not limited in scope to nova | 14:06 |
| *** lucasxu has joined #openstack-keystone | 14:06 | |
| *** voelzmo has joined #openstack-keystone | 14:08 | |
| *** voelzmo has quit IRC | 14:08 | |
| *** henrynash has joined #openstack-keystone | 14:11 | |
| *** voelzmo has joined #openstack-keystone | 14:14 | |
| knikolla | o/ | 14:32 |
| ma9_1 | about my previous question on whether OpenStack CLI work with OpenID Connect, I found this blueprint: https://blueprints.launchpad.net/keystone/+spec/improved-oidc-support | 14:37 |
| ma9_1 | I guess it means it's not implemented yet. | 14:37 |
| lbragstad | ma9_1 keystone supports oidc, that spec is specifically to improve certain aspects of it. | 14:40 |
| lbragstad | ma9_1 which is laid out in more detail here - https://review.openstack.org/#/c/373983/4/specs/keystone/ocata/oidc-improved-support.rst | 14:40 |
| lbragstad | but that's all keystone server related work | 14:40 |
| lbragstad | and doesn't really consist of any client changes | 14:40 |
| *** nicolasbock has quit IRC | 14:41 | |
| lbragstad | ma9_1 it looks like python-keystoneclient does have an oidc authentication method - which might be exposed through python-openstackclient | 14:42 |
| lbragstad | ma9_1 https://github.com/openstack/python-keystoneclient/blob/71af540c81ecb933d912ef5ecde128afcc0deeeb/keystoneclient/contrib/auth/v3/oidc.py | 14:42 |
| *** chlong has joined #openstack-keystone | 14:45 | |
| *** nicolasbock has joined #openstack-keystone | 14:48 | |
| *** rderose has joined #openstack-keystone | 14:56 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_user https://review.openstack.org/452783 | 14:58 |
| *** stradling has joined #openstack-keystone | 15:01 | |
| *** voelzmo has quit IRC | 15:01 | |
| *** voelzmo has joined #openstack-keystone | 15:02 | |
| *** voelzmo has quit IRC | 15:02 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_project https://review.openstack.org/452788 | 15:06 |
| *** agrebennikov has joined #openstack-keystone | 15:17 | |
| *** dave-mccowan has joined #openstack-keystone | 15:20 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_domain https://review.openstack.org/452801 | 15:22 |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Remove unused methods in unit test test_revoke https://review.openstack.org/452802 | 15:24 |
| *** adrian_otto has joined #openstack-keystone | 15:26 | |
| *** agrebennikov has quit IRC | 15:27 | |
| *** henrynash has quit IRC | 15:31 | |
| *** tesseract has quit IRC | 15:31 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Move and refactor test_by_domain_domain https://review.openstack.org/452801 | 15:33 |
| *** thorst is now known as thorst_afk | 15:33 | |
| *** 07EAANV6F has quit IRC | 15:36 | |
| *** aojea_ has quit IRC | 15:45 | |
| *** richm has joined #openstack-keystone | 15:46 | |
| *** mvk has quit IRC | 15:47 | |
| *** nle5223__ has quit IRC | 15:52 | |
| *** pcaruana has quit IRC | 15:53 | |
| *** stradling has quit IRC | 16:00 | |
| *** adrian_otto has quit IRC | 16:05 | |
| *** ma9_1 has quit IRC | 16:17 | |
| *** ma9_ has joined #openstack-keystone | 16:18 | |
| *** d0ugal has quit IRC | 16:19 | |
| *** ma9_ has quit IRC | 16:22 | |
| *** lucasxu has quit IRC | 16:25 | |
| *** ma9_ has joined #openstack-keystone | 16:28 | |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: URL pattern based RBAC Management Interface https://review.openstack.org/401808 | 16:34 |
| *** stradling has joined #openstack-keystone | 16:35 | |
| *** thorst_afk is now known as thorst | 16:42 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone master: Updated from global requirements https://review.openstack.org/452472 | 16:49 |
| jaosorior | Hey guys, were these options deprecated? https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_auth.py#L143-L180 | 16:50 |
| *** ma9_ has quit IRC | 16:55 | |
| knikolla | jaosorior: yep | 16:56 |
| jaosorior | thanks | 16:56 |
| knikolla | jaosorior: some of them, so read the help | 16:56 |
| *** stradling has quit IRC | 16:57 | |
| jaosorior | knikolla: what about identity_uri? | 16:57 |
| lbragstad | that one shouldn't be deprecated | 16:57 |
| knikolla | jaosorior: identity_uri is not deprecated. | 16:57 |
| lbragstad | jaosorior is it advertised as deprecated? | 16:57 |
| lbragstad | jaosorior or are you seeing it as deprecated somewhere? | 16:57 |
| jaosorior | EmilienM: ^^ | 16:59 |
| jaosorior | lbragstad: it's not advertised. Just wondering cause it was unclear. Thanks for the info. | 16:59 |
| EmilienM | jaosorior: ok thanks. Sorry for confusion | 17:00 |
| EmilienM | I don't know why but I always believed that auth_uri and auth_url was enough | 17:00 |
| lbragstad | jaosorior which part was unclear specifically, the usage of identity_uri? | 17:00 |
| jaosorior | lbragstad: identity_uri isn't mentioned in the keystonemiddleware docs. So it's a bit confusing | 17:00 |
| lbragstad | jaosorior ah - sure | 17:01 |
| jaosorior | actually, the deprecated options are still there. | 17:01 |
| * lbragstad goes to pull up the ksm docs | 17:01 | |
| EmilienM | when do we need identity_uri? | 17:02 |
| lbragstad | EmilienM jaosorior knikolla so in the configuration section we have a section that uses the deprecated options - https://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html#configuration | 17:03 |
| lbragstad | for example - http://cdn.pasteraw.com/4s90qzvd0vpexjmjslcnvtktf0wpwug | 17:03 |
| knikolla | lbragstad: adding it on my todo list | 17:04 |
| knikolla | should be a quick fix | 17:04 |
| lbragstad | knikolla ++ | 17:04 |
| lbragstad | knikolla i'm creating a bug report so we can track it | 17:05 |
| knikolla | lbragstad: sounds good. assign me. | 17:05 |
| *** chlong has quit IRC | 17:05 | |
| *** stradling has joined #openstack-keystone | 17:09 | |
| *** adrian_otto has joined #openstack-keystone | 17:10 | |
| lbragstad | knikolla EmilienM jaosorior https://bugs.launchpad.net/keystonemiddleware/+bug/1679238 | 17:10 |
| openstack | Launchpad bug 1679238 in keystonemiddleware "documented config options are deprecated" [Medium,Confirmed] - Assigned to Kristi Nikolla (knikolla) | 17:10 |
| knikolla | roger | 17:10 |
| EmilienM | but we don't need identity_uri if we use auth_url and auth_uri, right? | 17:11 |
| jaosorior | lbragstad: ^^ | 17:12 |
| knikolla | EmilienM: IIRC, those options were not in the authtoken group. but in some other section of the service conf | 17:13 |
| lbragstad | knikolla correct | 17:13 |
| lbragstad | instead of using auth_admin_prefix, auth_host, auth_port, and auth_protocol, identity_uri should be used | 17:14 |
| jaosorior | knikolla, lbragstad https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_auth.py#L184 it is in the keystone_authtoken group as far as I can see | 17:14 |
| *** d0ugal has joined #openstack-keystone | 17:14 | |
| knikolla | yes, but there is no auth_uri, url there. so the docs are probably wrong. | 17:15 |
| jaosorior | aah | 17:15 |
| *** chlong has joined #openstack-keystone | 17:21 | |
| EmilienM | we have been using auth_uri and auth_url for some time now and everything is fine | 17:21 |
| EmilienM | we don't use identity_uri for long time | 17:21 |
| jaosorior | under the kestone_authtoken group | 17:21 |
| EmilienM | that is what our nova deployment is using: http://paste.openstack.org/show/605278/ | 17:22 |
| EmilienM | and it works perfectly fine | 17:23 |
| EmilienM | the whole config file is here: http://logs.openstack.org/30/452630/4/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/3c9feb5/logs/etc/nova/nova.conf.txt.gz | 17:23 |
| lbragstad | knikolla we should make a note to look into auht_url/auth_uri and see what the differences are from identity_uri | 17:25 |
| *** jaosorior is now known as jaosorior_away | 17:29 | |
| jaosorior_away | lbragstad, knikolla: Thanks for looking into it. | 17:29 |
| lbragstad | jaosorior_away thanks for bringing it to our attention | 17:30 |
| EmilienM | lbragstad: is there anything wrong in our config? | 17:30 |
| * lbragstad EmilienM this is your auth_token section specifically - http://cdn.pasteraw.com/mpzr3yaa9xbt7kqecw3e1a2e49x15kw | 17:31 | |
| EmilienM | lbragstad: yes, it is. And is it good? | 17:32 |
| *** nicolasbock has quit IRC | 17:35 | |
| lbragstad | EmilienM double checking it against whats in keystonemiddleware | 17:36 |
| lbragstad | EmilienM aha - so I think I'm getting things figured out here | 17:38 |
| lbragstad | we shouldn't be using identity_uri either | 17:38 |
| lbragstad | cc knikolla ^ | 17:38 |
| EmilienM | ah :) | 17:38 |
| EmilienM | I KNEW IT lol | 17:38 |
| lbragstad | knikolla those directions really need to be updated with some context around the fact that ksm *now* relies on keystoneauth for all the plugin bits | 17:38 |
| EmilienM | can I get my keystone sticker now? | 17:39 |
| lbragstad | EmilienM i thought you already had one! | 17:39 |
| EmilienM | nope :( | 17:39 |
| notmorgan | EmilienM: the keystone sticker is a lie (just like the cake) | 17:39 |
| notmorgan | :P | 17:39 |
| * lbragstad writes EmilienM's name on a sticker | 17:40 | |
| lbragstad | EmilienM here is where we ask for a plugin name - https://github.com/openstack/keystonemiddleware/blob/a2e3d60644aadb4ecb3d49dadbcd5d4c1dec2176/keystonemiddleware/auth_token/__init__.py#L880-L884 | 17:41 |
| SamYaple | with keystone v3, do keystone-wsgi-admin and keystone-wsgi-public do the same thing? | 17:41 |
| lbragstad | SamYaple yes | 17:41 |
| SamYaple | so i can safely jut run one of them? sweet | 17:41 |
| lbragstad | SamYaple correct - in v2.0 we had two separate endpoints, one for admin things and one for user things (basically just authenticate and validate) | 17:42 |
| lbragstad | so it was a way to use two separate applications to enforce policy | 17:42 |
| SamYaple | right. im doing a uwsgi deploy orchestration for the first time and wanted to make sure i had my facts straight | 17:43 |
| SamYaple | thanks. always helpful in here | 17:43 |
| lbragstad | with one of the goals of v3 to provide/implement a better policy model, the two separate API endpoints were merged together into a single application | 17:43 |
| lbragstad | SamYaple good deal! | 17:43 |
| lbragstad | EmilienM so if you look at https://github.com/openstack/keystonemiddleware/blob/a2e3d60644aadb4ecb3d49dadbcd5d4c1dec2176/keystonemiddleware/auth_token/__init__.py#L880-L884 | 17:43 |
| lbragstad | EmilienM you'll see that we use keystoneauth to load a plugin, and only if we can't do that do we actually rely on the AuthTokenPlugin module | 17:44 |
| lbragstad | EmilienM which is using/defining some of those deprecated options | 17:44 |
| EmilienM | ok | 17:46 |
| *** lucasxu has joined #openstack-keystone | 17:47 | |
| *** ayoung has joined #openstack-keystone | 17:49 | |
| *** stradling has quit IRC | 17:49 | |
| *** jamielennox is now known as jamielennox|away | 17:50 | |
| *** nicolasbock has joined #openstack-keystone | 17:51 | |
| *** d0ugal has quit IRC | 17:59 | |
| knikolla | lbragstad: oooo right. i remember now. | 18:09 |
| knikolla | lbragstad: so should we deprecate the others too? | 18:09 |
| *** harlowja has joined #openstack-keystone | 18:12 | |
| knikolla | ayoung: https://review.openstack.org/#/c/401808/ is passing now. had to fix a few small things. | 18:13 |
| *** TravT has quit IRC | 18:14 | |
| ayoung | knikolla, Merge it! | 18:16 |
| ayoung | knikolla, ModelDictMixinWithExtras. Lovely | 18:17 |
| knikolla | ayoung: sounds like a plan. i'll also play a bit around with the api. | 18:18 |
| knikolla | ayoung: should i start on the ksm change in the meanwhile? | 18:18 |
| ayoung | knikolla, need the client change first | 18:19 |
| knikolla | right. s/play around with the api/write a client for the api/g | 18:19 |
| *** d0ugal has joined #openstack-keystone | 18:20 | |
| knikolla | ayoung: argh, i messed up the bp name again. it's role-check-from-middleware | 18:21 |
| ayoung | heh | 18:22 |
| ayoung | knikolla, you can edit that right in the web browser | 18:22 |
| knikolla | ayoung: yep, gonna do that now. | 18:22 |
| openstackgerrit | Kristi Nikolla proposed openstack/keystone master: URL pattern based RBAC Management Interface https://review.openstack.org/401808 | 18:23 |
| knikolla | ayoung: done. you can reiterate your +1. | 18:23 |
| *** ravelar has quit IRC | 18:25 | |
| *** victorssilva_ has joined #openstack-keystone | 18:26 | |
| *** ravelar has joined #openstack-keystone | 18:28 | |
| *** stingaci has joined #openstack-keystone | 18:33 | |
| *** victorssilva_ has quit IRC | 18:37 | |
| *** bjornar_ has joined #openstack-keystone | 18:39 | |
| openstackgerrit | Kristi Nikolla proposed openstack/python-keystoneclient master: WIP - Client functions for url_patterns https://review.openstack.org/452893 | 18:40 |
| *** rmascena has joined #openstack-keystone | 18:41 | |
| *** raildo has quit IRC | 18:41 | |
| *** ravelar1 has joined #openstack-keystone | 18:42 | |
| *** ravelar1 has quit IRC | 18:42 | |
| *** ravelar1 has joined #openstack-keystone | 18:42 | |
| *** ravelar has quit IRC | 18:42 | |
| *** ravelar1 is now known as ravelar | 18:43 | |
| *** ravelar1 has joined #openstack-keystone | 18:48 | |
| *** aojea has joined #openstack-keystone | 19:01 | |
| *** rderose has quit IRC | 19:02 | |
| *** adrian_otto has quit IRC | 19:04 | |
| *** agrebennikov has joined #openstack-keystone | 19:06 | |
| ayoung | dstanek, would appreciate a review on https://review.openstack.org/401808 | 19:17 |
| ayoung | Or I could just merge now :) | 19:18 |
| lbragstad | ayoung the spec hasn't even been proposed to pike yet | 19:18 |
| ayoung | lbragstad, yes it has | 19:18 |
| lbragstad | s/proposed/merged | 19:18 |
| ayoung | lbragstad, so what. Spec was approved. Just merging it for pike is just a commitment to releasing it in Pike | 19:19 |
| ayoung | lbragstad, undercommit and oversomethingsomething | 19:19 |
| lbragstad | ayoung there are several parts of that spec that are out-dated an misleading | 19:19 |
| ayoung | lbragstad, eyebrows? | 19:20 |
| ayoung | lbragstad, primary assignee is still me. Other contributors listed just for citation sake | 19:21 |
| ayoung | lbragstad, do you have any real objections to the approach? | 19:21 |
| lbragstad | ayoung my primary objection is that most of the conversations we had around the approach were never finished | 19:22 |
| lbragstad | we *just* started getting into discussions with other projects on the approach when the spec merged to ongoing | 19:22 |
| ayoung | lbragstad, were there any other proposals on the table? has anyone actually either proposed a solution to RBAC, or provided a criticism of a problem with this approach? | 19:23 |
| *** d0ugal has quit IRC | 19:23 | |
| lbragstad | ayoung no one is telling you this can't happen | 19:23 |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Move and refactor project_and_user_and_role https://review.openstack.org/452908 | 19:24 |
| ayoung | lbragstad, is there any other effort being made? | 19:24 |
| lbragstad | ayoung sure | 19:24 |
| lbragstad | antwash and ravelar did a whole bunch of work to improve the policy we have | 19:24 |
| ayoung | lbragstad, I know, this is a bit of a rush, as it has only been out for review since November. Kindof fast by Keystone standards. | 19:24 |
| ayoung | lbragstad, the RBAC side or just policy-in-code for scope check? | 19:25 |
| lbragstad | ayoung did you ever follow up with johnthetubaguy and oomichi about their concerns here? https://review.openstack.org/#/c/391624/ | 19:25 |
| ayoung | lbragstad, I'm not really planning on merging it myself. But some actual review of the change would be nice. | 19:25 |
| *** d0ugal has joined #openstack-keystone | 19:25 | |
| ayoung | lbragstad, yeah. The biggest issue is that the Nova API sucks and RBAC would be of limited value there | 19:26 |
| ayoung | lbragstad, but they accepted that they could always do more finegrained checks inside nova if they wanted | 19:26 |
| lbragstad | ayoung just because another project made a mistake in their implementation doesn't mean we just write their usecases off | 19:26 |
| ayoung | lbragstad, exactly | 19:27 |
| lbragstad | that's what we're doing | 19:27 |
| ayoung | lbragstad, they could still make use of the RBAC stuff, just it would take additioanl code | 19:27 |
| ayoung | inside Nova | 19:27 |
| lbragstad | we're going to commit to a whole bunch of work that will no benefit several projects | 19:27 |
| ayoung | No, you have that backwards | 19:27 |
| ayoung | we can't do anything about Nova. Its their code, and they have to chose how to do it | 19:27 |
| ayoung | this benefits nova, just jnot a specific chunk of the API | 19:27 |
| ayoung | and it benefits everyone else | 19:28 |
| lbragstad | it doesn't benefit anyone who has made that mistake | 19:28 |
| ayoung | and it does not prevent the Nova folks from making use of it, it just requires *additional* work on their part | 19:28 |
| lbragstad | and i believe there are a couple projects that have done that | 19:28 |
| ayoung | lbragstad, and that is OK | 19:28 |
| *** stradling has joined #openstack-keystone | 19:28 | |
| ayoung | we cannot solve everythimng for everyone, but it still has benefit | 19:28 |
| lbragstad | ayoung i think you're confusing my objections with needing a proposal that makes everyone happy | 19:29 |
| lbragstad | which i'm not proposing | 19:29 |
| ayoung | lbragstad, remember ,this is just *in addition* to existing policy, so the existing stuff for nova still takes effect | 19:29 |
| lbragstad | instead, I want to make sure we take the time and due diligence to *finish* the conversations we started before we start adding APIs to keystone | 19:30 |
| ayoung | lbragstad, just trying to give a summary of the discussion with johnthetubaguy . We basically went over this exact patjh | 19:30 |
| ayoung | path | 19:30 |
| lbragstad | i completely understand the fact that this is additional work, but it's also something we'll have to maintain forever | 19:30 |
| ayoung | lbragstad, I was thinking about that. THere really is no reason it has to be inside Keystone except that we've made it quite painful to add additional services. I'd even be OK with it being served by the Keystone server, but being a separate service in the catalog | 19:31 |
| ayoung | The more I see of Kubernetes, the more I hate our service catalog approach | 19:32 |
| ayoung | lbragstad, I would absolutely love it if someone could poke holes in the actual approach. THe problem is that no one has actually taken the time to understand the problem to the degree necessary to do that. | 19:33 |
| ayoung | I've done what I could to lay it out. It is, I think, the longest spec we've had in Keystone | 19:34 |
| ayoung | https://developer.openstack.org/api-ref/compute/?expanded=resize-server-resize-action-detail#resize-server-resize-action | 19:35 |
| *** d0ugal has quit IRC | 19:36 | |
| ayoung | lbragstad, the issue is commands like ^^ which cannot be RBAced at the URL level need to have introspection of the payload. But that is the exception | 19:36 |
| lbragstad | ayoung so what would it take to make it so that could be enforced with what you're proposing? | 19:37 |
| ayoung | If they really want RBAC at the URL level after that, they could always provide an alternative API like this: /servers/{server_id}/actions/action-name | 19:37 |
| *** chlong has quit IRC | 19:37 | |
| *** harlowja has quit IRC | 19:37 | |
| ayoung | lbragstad, well, inside of Nova's handler for the URL, they could look at the method in the payload, and use a hacked version of the URL that happened to match the pattern above | 19:37 |
| ayoung | so if the payload had the action `resume` pull the policy for /servers/{server_id}/actions/resume and apply that | 19:38 |
| lbragstad | so why not just have the service maintain the url -> operation mapping and only store the operations in keystone instead of the urls? | 19:39 |
| ayoung | but prior to that, all the addition of the RBAC in middleware would do would be to enforce a least-common-denominator rule like "in order to execute any action under the url, you need to have at least the Member role" | 19:39 |
| * knikolla lurks | 19:40 | |
| ayoung | lbragstad, because that fails one of the requirements of this proposal: | 19:40 |
| lbragstad | which is? | 19:40 |
| ayoung | namely, to tell a user what roles they need to have in order to perform an operation | 19:40 |
| ayoung | the operation names are not discoverable | 19:40 |
| ayoung | only the URLs are discoverable | 19:40 |
| ayoung | and are actually documented fairly standardly | 19:40 |
| lbragstad | that sounds like a capabilities API | 19:41 |
| ayoung | lbragstad, be carfgul throwing that term around. It means different things to different people | 19:41 |
| ayoung | in computing, a capability is a pre-authorization to perform an actiomn./ I'm not going that far | 19:41 |
| ayoung | nor am I willing to | 19:41 |
| ayoung | https://en.wikipedia.org/wiki/Capability-based_security | 19:42 |
| lbragstad | ayoung several people i've talked to have a good understanding what that term means | 19:42 |
| lbragstad | specific in nova and cinder | 19:42 |
| lbragstad | since both of those projects have either proposed or merged specs for a capabilities API | 19:42 |
| lbragstad | in the openstack sense, i think the term means considering not only the policy for an operation but the state of the deployment | 19:44 |
| ayoung | lbragstad, If either the cinder or Nova teams have a generally applicable Capabilites model that we should apply to OpenStack in general, we should get it written up as a Spec. I somehow suspect that what they have is not generally applicable. | 19:45 |
| ayoung | And, so, no, I am not proposing a capabilies API. I am proposing Scoped RBAC, with discoverability | 19:46 |
| ayoung | I am attempting to solve the long-existent shortcomings of our current model by applying the design decisions we've discussed for several years: | 19:46 |
| lbragstad | ayoung i never said you were opposed to a capabilities API, but what you're proposing sounds like a keystone specific one | 19:46 |
| ayoung | lbragstad, nope. It is not Keystone specific. It isimlemented in the Middleware layer that is managed by keystone, but it is a general URL based security scheme, pretty common in the Web world, very similar to the one in Kubernetes for excample | 19:47 |
| ravelar | knikolla can you tell me how/where the test framework runs this method? https://review.openstack.org/#/c/452802/1/keystone/tests/unit/test_revoke.py just so I can understand for future reference? | 19:47 |
| ayoung | ravelar, anything in a test_*.py file is treated as a potentiakl test Suite. The unit test framework does some matching, and if the function name starte with test_ it gets exectued | 19:49 |
| knikolla | ravelar: anything starting with test in a file that starts with test | 19:49 |
| lbragstad | ayoung you're proposing we have an API in keystone that returns all operations a user can do based on a token | 19:49 |
| ayoung | lbragstad, only because we messed up our service catalog, but yes | 19:50 |
| * ravelar smacks forehead | 19:50 | |
| ayoung | ideally, you would be able to ask that on reference | 19:50 |
| ravelar | knikolla but the test it self will no longer be needed once we do away with add_event remove_event lists right? | 19:51 |
| * ayoung applies bacitracin to ravelar 's wounded forehead | 19:51 | |
| lbragstad | ideally that something that you should be asking the service you're curious about | 19:51 |
| ravelar | ayoung lol | 19:51 |
| *** chlong has joined #openstack-keystone | 19:51 | |
| ayoung | lbragstad, So, there is no standard way to do that in REST | 19:51 |
| ayoung | lbragstad, and asking every service to respond in a consistent manner is...well, just look how successful we've been at that kind of thing in the past | 19:52 |
| lbragstad | at the same time, it makes absolutely no sense for keystone to be responsible for project specific information | 19:52 |
| knikolla | ravelar: yes. if you remove the thing which it tests, you can remove the test. but the commit message was wrong saying that the test was unused. | 19:53 |
| ayoung | lbragstad, you have two choices. Do it in keystone. Leave it broken. I really wish there was an alternative, but when you have a family of related services like we do, delegating security like this to the remote services does not work. | 19:53 |
| ayoung | lbragstad, its not. | 19:53 |
| openstackgerrit | Merged openstack/keystone master: Updated from global requirements https://review.openstack.org/452472 | 19:53 |
| ayoung | lbragstad, a URL is a random string. | 19:53 |
| ravelar | knikolla ah of course, just checking since I planned to remove it but got caught ahead of myself. Thanks! | 19:53 |
| ayoung | Keystone does not care what is in that string. It just says "that string matches this role" | 19:53 |
| lbragstad | if a user has a role that allows them to live migrate all day long, it still doesn't matter at all if nova isn't deployed with a virt driver that doesn't support live migrate | 19:54 |
| knikolla | ravelar: :) | 19:54 |
| ayoung | lbragstad, its no different than having many different buildings in a compound call in to the central registry to see if a VIP is on the guest list | 19:54 |
| lbragstad | ayoung why should keystone have to care about that mapping for every project when the project has to maintain it already? | 19:54 |
| ayoung | lbragstad, strawman | 19:54 |
| ayoung | keystone cares about nothing except what the Sys admin tells it to care about in these cases | 19:55 |
| ayoung | by default: make sure the user has a token, like it does now | 19:55 |
| ayoung | allow the sys admin to crank down the security for a specific URL | 19:55 |
| * ayoung feels like he's had this discussion before. | 19:56 | |
| ayoung | lbragstad, so, take it from day 1. | 19:57 |
| ayoung | Lets assume that the mechanism I've proposed is implemented and deployed as part of an upgrade | 19:57 |
| ayoung | there are no rules in the Database, config says ignore RBAC-in-middleware...nothing changes from how policy is done today | 19:58 |
| ayoung | then and admin wants to take advantage of it. | 19:58 |
| ayoung | They enable it, and the only rule in place is that for all APIs for, say, Nova, the user has to have token wuith the Member rule in it. An admin token is valid everywhere still | 19:59 |
| ayoung | all other services are left alone. They don't bother even fetching RBAC at middleware | 19:59 |
| ayoung | Sys admin rectifies this by enabling it, one by one, for services. | 19:59 |
| lbragstad | yeah - makes sense | 20:02 |
| lbragstad | what happens when an admin wants to change the policy of an operation? | 20:03 |
| lbragstad | or what's the upgrade case look like when a deployer has this enabled and they upgrade a service that registers new policies in code? | 20:04 |
| ayoung | lbragstad, so, if it is an operation they have not touched before, they add a new rule: PUT /url/thing/ | 20:04 |
| ayoung | and add a ROLE | 20:05 |
| ayoung | so, to start, probably make it, Member | 20:05 |
| *** jamielennox|away is now known as jamielennox | 20:05 | |
| ayoung | or, they could create a new Role first, then add an implied roles rule | 20:05 |
| ayoung | so, say they add "Reader" | 20:05 |
| ayoung | make "Member" imply "Reader" | 20:05 |
| lbragstad | sure | 20:06 |
| ayoung | then add an explcit rule that says "GET /this/url/thing" requires Reader | 20:06 |
| ayoung | everyone with member still works the same | 20:06 |
| ayoung | but now you could create a new user and add the REader role to that person, and they could execute only that URL | 20:06 |
| lbragstad | yeah - that makes sense.. i get that flow | 20:06 |
| ayoung | of course, any other system that did not enforce RBAC would also be accessable to the user | 20:06 |
| lbragstad | my question was more about what order the admin has to take if they want to change an operation | 20:07 |
| ayoung | which is why you would want a default rule defined for each of the service that use tokens before make more speficif API rules | 20:07 |
| lbragstad | which would require a change to keystone and a change to a policy file somewhere | 20:07 |
| ayoung | so, no changes to policy files | 20:08 |
| *** adrian_otto has joined #openstack-keystone | 20:08 | |
| ayoung | the default rule would be in the config for the services auth_token section | 20:08 |
| ayoung | no | 20:08 |
| lbragstad | if I wanted to change the default boot instance policy to something more strict | 20:08 |
| ayoung | that is wrong | 20:08 |
| ayoung | the default rule is in keystoone | 20:08 |
| ayoung | the trigger to lookup the rules is in the auth_token secion | 20:08 |
| ayoung | lbragstad, right, you would want to make sure that all existing services that assumed "Member" was the default role made that check explicit first | 20:09 |
| ayoung | then create a new role "Bootme" | 20:09 |
| ayoung | Member implied Bootme | 20:09 |
| ayoung | then add the rule for PUT /url/to/boot | 20:09 |
| ayoung | or whatever it is | 20:09 |
| ayoung | as you can see, it won't work by default for the /actions urls because there is not enough to go onm | 20:10 |
| ayoung | but... | 20:10 |
| ayoung | if people really wanted, we could do an extension that says "check this in the payload" using jq type syntax or something, in the future | 20:10 |
| ayoung | I don't want to commit to that today, but the potential is there | 20:10 |
| lbragstad | what happens when a service releases a new API and registers the default in code? | 20:12 |
| lbragstad | how is that default propagated into keystone? | 20:13 |
| lbragstad | during the upgrade? | 20:13 |
| ayoung | lbragstad, and now you know why I don't want any defaults in code | 20:14 |
| ayoung | and they can't | 20:14 |
| ayoung | we make no promises about the set of roles | 20:14 |
| ayoung | there is admin and that is it | 20:14 |
| ayoung | all they can do is screw the operators on that one... | 20:14 |
| notmorgan | and i have long since conceeded the "do everything with any role in any configuration" is not going to work | 20:15 |
| ayoung | notmorgan, I can't tell if that is a supporting statement or not. | 20:17 |
| notmorgan | it is saying I'm certain RBAC is going into "Defaults in Code" in OpenStack | 20:18 |
| lbragstad | several projects have already started doing it | 20:18 |
| notmorgan | this is similar to microversions, like it or not.. it's a thing and the direction taken by the community | 20:19 |
| * notmorgan goes back to the thing he was working on unrelated to rbac things now. | 20:19 | |
| ayoung | notmorgan, lbragstad links? | 20:21 |
| notmorgan | Nova is well on that path | 20:21 |
| lbragstad | nova implemented defaults in code after austin | 20:21 |
| ayoung | lbragstad, for Roles? | 20:22 |
| notmorgan | and not sure which other projects are working on it. but i know some have considered it | 20:22 |
| notmorgan | ayoung: for all policy checks. | 20:22 |
| ayoung | pretty sure they are just checking scope | 20:22 |
| ayoung | I looked at their code | 20:22 |
| *** lucasxu has quit IRC | 20:22 | |
| ayoung | some admin checks, but they already had that | 20:22 |
| notmorgan | it was scope *and* base role stuff iirc | 20:22 |
| notmorgan | or intending more in depth role stuff | 20:22 |
| lbragstad | it's the same thing the policy files did, just in code | 20:22 |
| notmorgan | they've move the policy file 100% into code | 20:23 |
| ayoung | not that I've seen | 20:23 |
| notmorgan | what lbragstad said | 20:23 |
| ayoung | they are only checking scope | 20:23 |
| ayoung | policy files never checked role, except for Admin | 20:23 |
| ayoung | see https://review.openstack.org/#/c/384148/ | 20:24 |
| ayoung | base rule ADMIN_OR_OWNDER | 20:24 |
| ayoung | OWNER | 20:24 |
| ayoung | OWNER defined as scope match | 20:24 |
| ayoung | https://review.openstack.org/#/c/384148/13/nova/policies/base.py | 20:25 |
| ayoung | So...unless you have another example, notmorgan I think we are OK | 20:28 |
| lbragstad | so... the upgrade case? | 20:28 |
| ayoung | lbragstad, what about it? new apis fall; under the default rules | 20:29 |
| lbragstad | so a new api gets rolled out and it fails because the admin hasn't added it to keystone yet? | 20:30 |
| ayoung | Nope | 20:31 |
| ayoung | lbragstad, the default rule catches any API for a service that does not get covered by an\y specific rule | 20:32 |
| lbragstad | oh - but that's not exactly a fix | 20:32 |
| ayoung | in general, assume the default rule will be "all vers" "url" "Role" | 20:32 |
| lbragstad | because the default in code could be different than some arbitrary default rule | 20:32 |
| ayoung | And the Role will likely be "Member" | 20:32 |
| ayoung | lbragstad, if they make it an "admin only" api then it gets enforceb by policy anyway | 20:33 |
| lbragstad | ayoung those are two assumption we're actively trying to move away from | 20:33 |
| ayoung | it is no different than how things work today | 20:33 |
| ayoung | then make the default rule something more stringent | 20:33 |
| ayoung | but then you need an explicit rule for every other API | 20:33 |
| ayoung | no magic bullet there | 20:33 |
| lbragstad | which sounds messy | 20:33 |
| ayoung | lbragstad, you can edge case anyhting to make it messy | 20:34 |
| ayoung | but the default, which is what is supported today, is pretty simple: | 20:35 |
| lbragstad | ayoung an upgrade isn't an edge case | 20:35 |
| ayoung | if it is a new API expected to be used by end users, it gets the member role | 20:35 |
| ayoung | if you need it to be admin only, make it admin only | 20:35 |
| lbragstad | sure - that's done by the project when they determine what that default should be in code | 20:35 |
| lbragstad | which they own | 20:35 |
| ayoung | lbragstad, you want to build *more* on top of my API, be my guest | 20:35 |
| ayoung | the "Perfect" is the enemy of the "A hell of a lot better than what we have now" | 20:36 |
| lbragstad | ayoung i'm certainly not saying your proposal needs to be perfect, like i've already stated several times in this conversation | 20:36 |
| lbragstad | but upgrades are a thing we should care about | 20:37 |
| lbragstad | and one of the main goals for moving policy into code was to make upgrades easier for operators | 20:37 |
| ayoung | lbragstad, of course they are, and I've covered that in the normal case, to the same degree that it is covered today | 20:37 |
| ayoung | we can, if necessary, do additional work beyond what I've proposed. | 20:37 |
| lbragstad | but it degrades the upgrade case | 20:37 |
| lbragstad | because by default, as things are today, if a new api is added to a service, the default rule for that policy is honored | 20:38 |
| ayoung | I'm not certain how we would support "we have a new API, but we don't want anyone to execute it until we give it an explicit role" without making it an explicit match | 20:38 |
| lbragstad | when the service is upgrade | 20:38 |
| lbragstad | upgraded* | 20:38 |
| ayoung | could do something in the policy level to support that, I supposed, though | 20:38 |
| ayoung | like, in the scope check, enforce that there has to be some role other than the default role? | 20:38 |
| ayoung | yuck | 20:39 |
| knikolla | could have some sort of migrations mechanism | 20:39 |
| ayoung | anyway, we don't have ANY of those right now. | 20:39 |
| knikolla | where new apis are defined and you run a script to prepopulate. | 20:39 |
| ayoung | Everything is either member or admin...or a one off like the service roles in Keystone, but those are Keystone specific | 20:39 |
| ayoung | knikolla, yep. | 20:39 |
| lbragstad | knikolla that could work | 20:40 |
| ayoung | knikolla, we can also use the existing documentation generation code to generate the defaults | 20:40 |
| ayoung | or the known set of rules for a given service | 20:40 |
| ayoung | I see all that is a hallmark of success. If people start asking us for that kind of stuff, then RBAC in Middleware is working | 20:40 |
| lbragstad | so that's a similar experience when an admin wants to supply and override | 20:40 |
| *** stradling has quit IRC | 20:43 | |
| ayoung | lbragstad, so, you see where I am headed with this, right? The goal is to stay out of people's ways unless they want it, but then to provide the right tooling, based on the common patterns | 20:44 |
| ayoung | it is not going to be all things to all people, but it gives a reasonable approach for the most demanded use cases | 20:45 |
| lbragstad | ayoung what is the most demanding case? | 20:45 |
| lbragstad | IYO | 20:45 |
| *** david-lyle has quit IRC | 20:51 | |
| *** david-lyle has joined #openstack-keystone | 20:51 | |
| *** mvk has joined #openstack-keystone | 20:52 | |
| *** harlowja has joined #openstack-keystone | 20:53 | |
| ayoung | lbragstad, "Read only role" | 20:54 |
| ayoung | lbragstad, followed by "roles that can do a subset of what the user needs to do" | 20:54 |
| lbragstad | ayoung have you reviewed https://review.openstack.org/#/c/427872/ ? | 20:55 |
| *** thorst has quit IRC | 20:59 | |
| *** ayoung is now known as ayoung_dadmode | 21:00 | |
| *** thorst has joined #openstack-keystone | 21:00 | |
| ayoung_dadmode | lbragstad, not yet, but without a way to implement, we can't add new roles anyway | 21:00 |
| ayoung_dadmode | that is what shut jamielennox and dolphm down when they proposed | 21:00 |
| *** d0ugal has joined #openstack-keystone | 21:00 | |
| ayoung_dadmode | but I'll review it shortly | 21:00 |
| *** rderose has joined #openstack-keystone | 21:00 | |
| *** swatson has joined #openstack-keystone | 21:02 | |
| *** thorst has quit IRC | 21:04 | |
| *** edmondsw has quit IRC | 21:12 | |
| *** edmondsw has joined #openstack-keystone | 21:14 | |
| *** sjain has joined #openstack-keystone | 21:17 | |
| *** edmondsw has quit IRC | 21:19 | |
| *** spilla has quit IRC | 21:20 | |
| *** aojea has quit IRC | 21:20 | |
| *** aojea has joined #openstack-keystone | 21:20 | |
| *** darrenc has quit IRC | 21:24 | |
| *** darrenc has joined #openstack-keystone | 21:24 | |
| *** aojea has quit IRC | 21:25 | |
| *** thorst has joined #openstack-keystone | 21:26 | |
| *** thorst has quit IRC | 21:30 | |
| *** thorst has joined #openstack-keystone | 21:47 | |
| *** lamt has joined #openstack-keystone | 21:51 | |
| *** bjornar_ has quit IRC | 21:52 | |
| *** rderose has quit IRC | 22:00 | |
| *** rcernin has quit IRC | 22:12 | |
| *** rderose has joined #openstack-keystone | 22:24 | |
| *** stradling has joined #openstack-keystone | 22:25 | |
| *** stradling has quit IRC | 22:27 | |
| *** chlong has quit IRC | 22:38 | |
| *** catintheroof has quit IRC | 22:44 | |
| *** edmondsw has joined #openstack-keystone | 22:45 | |
| *** sjain has quit IRC | 22:47 | |
| *** edmondsw has quit IRC | 22:49 | |
| *** lbragstad changes topic to "Pike release schedule: https://releases.openstack.org/pike/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h" | 22:51 | |
| openstackgerrit | Richard Avelar proposed openstack/keystone master: Move and refactor project_and_user_and_role https://review.openstack.org/452908 | 22:59 |
| *** lamt has quit IRC | 23:01 | |
| *** adriant has joined #openstack-keystone | 23:01 | |
| *** adrian_otto has quit IRC | 23:38 | |
| *** bjornar_ has joined #openstack-keystone | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!