openstackgerrit | Merged openstack/keystone: Removes unused default_assignment_driver method https://review.openstack.org/404411 | 00:12 |
---|---|---|
openstackgerrit | Merged openstack/keystone: Removes unused method from assignment core https://review.openstack.org/404412 | 00:12 |
mordred | jamielennox: yah - I hear that. however, the mechanics of submitting a task to the task manager should generally speaking not be a thing users have to think about ever (and I think we can rework the general_request_class part for sure) | 00:22 |
mordred | for the basic case, nobody should ever know it exists - for the advanced case, the thing a user _might_ want to do is pass in a class that implements the TaskManager interface | 00:24 |
jamielennox | yep i see that, i commented on the review | 00:24 |
jamielennox | the taskmanager you have now is definitely intended to be outside the client interface | 00:24 |
jamielennox | so really if you want to do things like rate limit all you need is a context manager as per comment right? | 00:25 |
* mordred goes to read | 00:25 | |
jamielennox | looking through shade you are doing things like task_manager.submit(TheTask) | 00:25 |
openstackgerrit | Gage Hugo proposed openstack/keystone: Add reason to notifications for PCI-DSS https://review.openstack.org/396752 | 00:25 |
mordred | yah- nodepool has a different TaskManager it passes to shade's constructor currently | 00:25 |
jamielennox | ah, nodepool makes sens | 00:26 |
jamielennox | i'm learning more and more about the wonderous nodepool | 00:26 |
mordred | and then in https://review.openstack.org/#/c/384206/ is where I'm starting down the adapter wrapper path ... | 00:26 |
jamielennox | i wouldn't be surprised to find a sacrifice_kitten() rpc deep down there | 00:26 |
mordred | which leads to fun like this: https://review.openstack.org/#/c/384208/15 - where eventually we'll not have any submitTask calls in shade | 00:26 |
mordred | jamielennox: it's there for sure :) | 00:27 |
*** adu has joined #openstack-keystone | 00:27 | |
mordred | jamielennox: turns out, to use openstack at high volume, one must have a steady supply of kittens ... | 00:27 |
jamielennox | i mean $30 a month must buy more that 1 cpu and 512mb ram... | 00:27 |
* jamielennox didn't consult any providers for that price | 00:28 | |
mordred | :) | 00:28 |
mordred | jamielennox: honestly - I think the contextmanager idea could work from a ksa perspective in terms of execution - lemme circle back around on it and take a stab at that so I can either answer why it _won't_ work or it can be apath forwar | 00:30 |
mordred | (I have a thought in my head, but I need to sacrifice a few kittens to test it out) | 00:30 |
jamielennox | so looking at https://review.openstack.org/#/c/384206/12/shade/_adapter.py we're already starting to ignore the client to RequestTask.main() | 00:30 |
jamielennox | as in the only thing you're doing there really is wrapping request_method in a task | 00:31 |
jamielennox | i mean again the interesting thing here is that the only interface between ksa.session and requests.Session is the .request() method and you can pass in your own session to ksa | 00:32 |
jamielennox | so really the easiest way i can see to do it today is | 00:32 |
jamielennox | class ShadeSession(requests.Session): | 00:32 |
jamielennox | def request(*args, **kwargs): | 00:33 |
jamielennox | # something that rate limits | 00:33 |
jamielennox | return super(ShadeSession, self).request(*args, **kwargs) | 00:33 |
mordred | yah - I have a patch with that somewhere in the history - I needed to change to adapter for reasons I don't fully remember | 00:33 |
jamielennox | s = session.Session(session=ShadeSession()) | 00:33 |
jamielennox | oh yea, change adapter as well | 00:33 |
jamielennox | modifying adapter gives you a bunch of other capabilities | 00:34 |
jamielennox | but if you want to get underneath the covers and catch things like reauthentication that is handled behind the scenes you can catch it there | 00:34 |
jamielennox | not using the clients here will save much pain :) | 00:35 |
mordred | very very much pain | 00:35 |
mordred | oh right - that's why I did adapter | 00:35 |
mordred | when I did session ... | 00:35 |
mordred | it caught _everything_ | 00:35 |
mordred | but that means that there would be a running Task that would spin out an auth request | 00:35 |
mordred | but since we serialize tasks | 00:35 |
mordred | it meant essentially a deadlock | 00:36 |
mordred | whoops | 00:36 |
mordred | :) | 00:36 |
mordred | doing it at the adapter level meant that it didn't affect anything at the python-*client level that wasn't already wrapped in a Task | 00:36 |
mordred | so we could swap out calls piecewise | 00:36 |
mordred | which is, of course, preferrable | 00:36 |
*** adu has quit IRC | 00:40 | |
jamielennox | that would probably happen with the taskmanager as well im guessing | 00:41 |
mordred | yah | 00:52 |
mordred | morgan: when you're back online - I'm going to start drinking - but I have an idea of addressing the above conversation ^^ | 00:52 |
*** hoangcx has joined #openstack-keystone | 00:55 | |
*** adrian_otto has joined #openstack-keystone | 00:58 | |
morgan | mordred: o/ | 01:04 |
mordred | morgan: tl;dr - have the bits in ksa.Session be like what jamielennox suggests - with self._contextmanager: return self.request() | 01:06 |
*** guoshan has joined #openstack-keystone | 01:06 | |
morgan | ah | 01:06 |
mordred | morgan: then have a TaskContextManager object that takes a TaskManager and wraps it | 01:06 |
mordred | so that one could pass _that_ into ksa.Session and have the thing we're poking at | 01:07 |
mordred | but other people could just generally pass in context managers | 01:07 |
mordred | yah? | 01:07 |
morgan | interesting | 01:07 |
morgan | digesting the idea | 01:07 |
mordred | morgan: it may suck | 01:07 |
morgan | (and food) | 01:07 |
mordred | morgan: but seems worth poking at :) | 01:07 |
*** dave-mccowan has joined #openstack-keystone | 01:07 | |
morgan | trying to suss this out and reading backlog | 01:12 |
morgan | so we're just changing the session bit to make the taskManager run in a context manager? | 01:12 |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 01:14 |
*** gyee has quit IRC | 01:15 | |
*** adrian_otto has quit IRC | 01:17 | |
*** guoshan has quit IRC | 01:19 | |
*** guoshan has joined #openstack-keystone | 01:21 | |
*** liujiong has joined #openstack-keystone | 01:21 | |
*** guoshan has quit IRC | 01:22 | |
*** guoshan has joined #openstack-keystone | 01:22 | |
*** guoshan has quit IRC | 01:27 | |
*** spzala has quit IRC | 01:27 | |
*** guoshan has joined #openstack-keystone | 01:29 | |
mordred | morgan: well, to make the session interface a generic context manager interface | 01:33 |
*** adrian_otto has joined #openstack-keystone | 01:33 | |
*** guoshan has quit IRC | 01:34 | |
mordred | so that what you pass to the session constructor is any old context manager - and maybe something something about being able to pass informaiton about the specific call to the context manager | 01:34 |
morgan | right | 01:34 |
morgan | task manager just *happens* to be a context manager in this case | 01:34 |
* mordred waves hands furiously | 01:34 | |
mordred | yah | 01:34 |
morgan | sure. should be pretty straight forward. | 01:34 |
mordred | or we make a thing that takes a task manager and returns a context manager we can pass in | 01:34 |
mordred | or something | 01:34 |
morgan | and we can just make the basic taskcontext a do-nothing thing. | 01:35 |
mordred | maybe we just drink | 01:35 |
mordred | yah | 01:35 |
morgan | i would rather drink... | 01:35 |
*** Zer0Byte__ has quit IRC | 01:35 | |
mordred | ++ | 01:35 |
* mordred having caipirinha now | 01:35 | |
morgan | but seeing as it is better to drink *with* people... | 01:35 |
mordred | indeed | 01:35 |
morgan | I am going to refrain from drinking | 01:35 |
morgan | also... i'd totally drink one ot the caipirinhas you make. those are damn good | 01:36 |
*** adrian_otto has quit IRC | 01:37 | |
*** guoshan has joined #openstack-keystone | 01:39 | |
morgan | mordred: i think i can respin these patches to be context manager-style in a couple hours | 01:44 |
morgan | now that I see what is intended there | 01:45 |
*** chrisplo has quit IRC | 01:58 | |
*** anush has joined #openstack-keystone | 02:06 | |
*** tqtran has quit IRC | 02:07 | |
*** anush has quit IRC | 02:07 | |
*** stevemar__ has joined #openstack-keystone | 02:29 | |
*** topol has quit IRC | 02:46 | |
*** browne has quit IRC | 02:52 | |
*** ayoung has joined #openstack-keystone | 03:02 | |
*** ChanServ sets mode: +v ayoung | 03:02 | |
*** topol has joined #openstack-keystone | 03:14 | |
*** ChanServ sets mode: +v topol | 03:14 | |
*** code-R has joined #openstack-keystone | 03:20 | |
*** code-R_ has joined #openstack-keystone | 03:21 | |
*** guoshan has quit IRC | 03:22 | |
*** code-R has quit IRC | 03:25 | |
*** code-R_ has quit IRC | 03:25 | |
*** code-R has joined #openstack-keystone | 03:25 | |
*** links has joined #openstack-keystone | 03:28 | |
*** tlbr has quit IRC | 03:44 | |
*** tlbr has joined #openstack-keystone | 03:45 | |
*** zhangjl has joined #openstack-keystone | 03:48 | |
*** zhangjl1 has joined #openstack-keystone | 03:53 | |
*** zhangjl has quit IRC | 03:55 | |
*** nicolasbock has quit IRC | 03:57 | |
*** code-R_ has joined #openstack-keystone | 04:04 | |
*** code-R has quit IRC | 04:07 | |
*** Marcellin__ has quit IRC | 04:08 | |
*** dave-mccowan has quit IRC | 04:14 | |
openstackgerrit | Steve Martinelli proposed openstack/keystone: Deprecate the AdminTokenAuthMiddleware https://review.openstack.org/305287 | 04:17 |
*** stevemar__ has quit IRC | 04:19 | |
*** stevemar__ has joined #openstack-keystone | 04:19 | |
*** stevemar__ has quit IRC | 04:24 | |
*** adu has joined #openstack-keystone | 04:34 | |
*** adriant has quit IRC | 04:35 | |
*** hoangcx has quit IRC | 04:35 | |
*** hoangcx has joined #openstack-keystone | 04:35 | |
*** udesale has joined #openstack-keystone | 04:51 | |
*** adu has quit IRC | 05:06 | |
*** catinthe_ has quit IRC | 05:19 | |
*** catintheroof has joined #openstack-keystone | 05:21 | |
*** code-R_ has quit IRC | 05:26 | |
*** catintheroof has quit IRC | 05:26 | |
*** rha has quit IRC | 05:37 | |
*** rha has joined #openstack-keystone | 05:38 | |
*** guoshan has joined #openstack-keystone | 05:39 | |
*** jaosorior has joined #openstack-keystone | 06:06 | |
*** code-R has joined #openstack-keystone | 06:08 | |
*** masuberu has quit IRC | 06:13 | |
*** masuberu has joined #openstack-keystone | 06:24 | |
*** code-R_ has joined #openstack-keystone | 06:26 | |
*** masber has joined #openstack-keystone | 06:27 | |
*** stevemar__ has joined #openstack-keystone | 06:29 | |
*** masuberu has quit IRC | 06:29 | |
*** code-R has quit IRC | 06:30 | |
*** rha has quit IRC | 06:32 | |
*** stevemar__ has quit IRC | 06:33 | |
*** tsufiev has quit IRC | 06:35 | |
*** tsufiev has joined #openstack-keystone | 06:39 | |
*** richm has quit IRC | 06:42 | |
*** code-R_ has quit IRC | 06:42 | |
*** josecastroleon has joined #openstack-keystone | 06:57 | |
*** jaosorior has quit IRC | 07:08 | |
*** jaosorior has joined #openstack-keystone | 07:08 | |
*** hoonetorg has quit IRC | 07:21 | |
*** hoonetorg has joined #openstack-keystone | 07:21 | |
*** hoonetorg has quit IRC | 07:24 | |
*** hoonetorg has joined #openstack-keystone | 07:24 | |
*** rcernin has joined #openstack-keystone | 07:28 | |
*** tsufiev has quit IRC | 07:54 | |
*** tsufiev has joined #openstack-keystone | 07:58 | |
*** chrisplo has joined #openstack-keystone | 08:01 | |
*** josecastroleon has quit IRC | 08:02 | |
*** chrisplo has quit IRC | 08:06 | |
*** links has quit IRC | 08:06 | |
*** josecastroleon has joined #openstack-keystone | 08:09 | |
*** aloga_ has joined #openstack-keystone | 08:09 | |
*** rha has joined #openstack-keystone | 08:12 | |
*** aloga_ has quit IRC | 08:15 | |
*** links has joined #openstack-keystone | 08:19 | |
*** amoralej|off is now known as amoralej | 08:25 | |
*** stevemar__ has joined #openstack-keystone | 08:30 | |
*** stevemar__ has quit IRC | 08:34 | |
*** zzzeek has quit IRC | 09:00 | |
*** zzzeek has joined #openstack-keystone | 09:00 | |
*** aloga_ has joined #openstack-keystone | 09:08 | |
*** jaosorior is now known as jaosorior_lunch | 09:13 | |
guoshan | whois xuao | 09:13 |
guoshan | sorry, wrong msg sending | 09:14 |
*** zhangjl1 has quit IRC | 09:24 | |
*** aloga_ has quit IRC | 09:24 | |
*** 14WAANMV5 has joined #openstack-keystone | 09:35 | |
*** masuberu has joined #openstack-keystone | 09:36 | |
*** masber has quit IRC | 09:39 | |
*** 14WAANMV5 is now known as asettle | 09:41 | |
*** guoshan has quit IRC | 09:57 | |
*** guoshan has joined #openstack-keystone | 09:58 | |
*** guoshan has quit IRC | 10:03 | |
*** aloga_ has joined #openstack-keystone | 10:03 | |
*** code-R has joined #openstack-keystone | 10:04 | |
*** links has quit IRC | 10:05 | |
*** code-R_ has joined #openstack-keystone | 10:07 | |
*** code-R has quit IRC | 10:10 | |
*** hoonetorg has quit IRC | 10:15 | |
*** liujiong has quit IRC | 10:15 | |
*** andreaf has quit IRC | 10:17 | |
*** andreaf has joined #openstack-keystone | 10:18 | |
*** mkoderer___ has joined #openstack-keystone | 10:18 | |
*** jlwhite_ has joined #openstack-keystone | 10:18 | |
*** Krenair has quit IRC | 10:19 | |
*** mkoderer__ has quit IRC | 10:19 | |
*** htruta has quit IRC | 10:19 | |
*** anteaya has quit IRC | 10:19 | |
*** jlwhite has quit IRC | 10:19 | |
*** jlwhite_ is now known as jlwhite | 10:19 | |
*** jaosorior_lunch has quit IRC | 10:19 | |
*** ayoung has quit IRC | 10:19 | |
*** mrsoul has quit IRC | 10:19 | |
*** brad[] has quit IRC | 10:19 | |
*** rdo has quit IRC | 10:19 | |
*** g2 has quit IRC | 10:19 | |
*** briancurtin has quit IRC | 10:19 | |
*** Adri2000 has quit IRC | 10:19 | |
*** DinaBelova has quit IRC | 10:19 | |
*** darrenc has quit IRC | 10:19 | |
*** mfisch has quit IRC | 10:19 | |
*** dhellmann has quit IRC | 10:19 | |
*** darrenc has joined #openstack-keystone | 10:20 | |
*** DinaBelova has joined #openstack-keystone | 10:21 | |
*** links has joined #openstack-keystone | 10:22 | |
*** mfisch has joined #openstack-keystone | 10:23 | |
*** mfisch has quit IRC | 10:23 | |
*** mfisch has joined #openstack-keystone | 10:23 | |
*** htruta has joined #openstack-keystone | 10:23 | |
*** dhellmann has joined #openstack-keystone | 10:23 | |
*** briancurtin has joined #openstack-keystone | 10:24 | |
*** pnavarro has joined #openstack-keystone | 10:24 | |
*** mrsoul has joined #openstack-keystone | 10:24 | |
*** hoonetorg has joined #openstack-keystone | 10:24 | |
*** BrAsS_mOnKeY has joined #openstack-keystone | 10:24 | |
*** Krenair has joined #openstack-keystone | 10:24 | |
*** Krenair has joined #openstack-keystone | 10:24 | |
*** brad[] has joined #openstack-keystone | 10:24 | |
*** clsacramento_ has joined #openstack-keystone | 10:24 | |
*** clsacramento has quit IRC | 10:25 | |
*** Daviey has quit IRC | 10:25 | |
*** alex_xu has quit IRC | 10:25 | |
*** boris-42 has quit IRC | 10:25 | |
*** code-R_ has quit IRC | 10:25 | |
*** rdo has joined #openstack-keystone | 10:25 | |
*** hoangcx has quit IRC | 10:25 | |
*** code-R has joined #openstack-keystone | 10:26 | |
*** alex_xu has joined #openstack-keystone | 10:27 | |
*** Adri2000 has joined #openstack-keystone | 10:28 | |
*** boris-42 has joined #openstack-keystone | 10:28 | |
*** BrAsS_mOnKeY is now known as g2 | 10:28 | |
*** chrisplo has joined #openstack-keystone | 10:29 | |
*** slunkad has joined #openstack-keystone | 10:29 | |
*** anteaya has joined #openstack-keystone | 10:31 | |
*** jaosorior_lunch has joined #openstack-keystone | 10:31 | |
*** chrisplo has quit IRC | 10:33 | |
*** pcaruana has joined #openstack-keystone | 10:35 | |
*** Daviey has joined #openstack-keystone | 10:36 | |
*** jaosorior_lunch is now known as jaosorior | 10:41 | |
*** mvk has quit IRC | 10:50 | |
*** udesale has quit IRC | 10:57 | |
*** mahatic_ has joined #openstack-keystone | 11:05 | |
*** links has quit IRC | 11:07 | |
*** links has joined #openstack-keystone | 11:08 | |
*** tqtran has joined #openstack-keystone | 11:09 | |
*** aloga_ has quit IRC | 11:10 | |
*** richm has joined #openstack-keystone | 11:12 | |
*** tqtran has quit IRC | 11:13 | |
*** mvk has joined #openstack-keystone | 11:21 | |
*** mvk has quit IRC | 11:23 | |
*** mvk has joined #openstack-keystone | 11:24 | |
*** jlk has quit IRC | 11:31 | |
*** jlk has joined #openstack-keystone | 11:31 | |
*** jlk has quit IRC | 11:31 | |
*** jlk has joined #openstack-keystone | 11:31 | |
*** dave-mccowan has joined #openstack-keystone | 11:37 | |
*** josecastroleon has quit IRC | 11:37 | |
*** aloga_ has joined #openstack-keystone | 11:50 | |
*** nicolasbock has joined #openstack-keystone | 12:11 | |
*** josecastroleon has joined #openstack-keystone | 12:11 | |
*** raildo has joined #openstack-keystone | 12:15 | |
*** aloga_ has quit IRC | 12:19 | |
*** catintheroof has joined #openstack-keystone | 12:29 | |
*** guoshan has joined #openstack-keystone | 12:30 | |
*** catinthe_ has joined #openstack-keystone | 12:32 | |
*** links has quit IRC | 12:34 | |
*** catintheroof has quit IRC | 12:34 | |
*** jrist has joined #openstack-keystone | 12:37 | |
*** amoralej is now known as amoralej|lunch | 12:50 | |
*** aloga_ has joined #openstack-keystone | 12:52 | |
*** chrisplo has joined #openstack-keystone | 12:56 | |
*** guoshan has quit IRC | 12:56 | |
*** chrisplo has quit IRC | 13:01 | |
*** guoshan has joined #openstack-keystone | 13:05 | |
*** catintheroof has joined #openstack-keystone | 13:12 | |
*** catinthe_ has quit IRC | 13:16 | |
*** code-R_ has joined #openstack-keystone | 13:22 | |
*** code-R has quit IRC | 13:24 | |
*** links has joined #openstack-keystone | 13:36 | |
*** links has quit IRC | 13:36 | |
*** edmondsw has joined #openstack-keystone | 13:36 | |
*** stevemar__ has joined #openstack-keystone | 13:37 | |
*** pnavarro has quit IRC | 13:40 | |
*** lamt has joined #openstack-keystone | 13:41 | |
*** rodrigods is now known as rodrigods_ | 13:58 | |
*** hrybacki is now known as hrybacki|mtg | 14:00 | |
*** code-R has joined #openstack-keystone | 14:05 | |
breton | ugh, https://review.openstack.org/#/c/379905/ broke a lot of things for us in mitaka. | 14:05 |
*** code-R_ has quit IRC | 14:08 | |
samueldmq | morning keystone | 14:08 |
lbragstad | o/ | 14:08 |
*** amoralej|lunch is now known as amoralej | 14:11 | |
*** jperry has joined #openstack-keystone | 14:12 | |
samueldmq | lbragstad: o/ | 14:12 |
openstackgerrit | Andrey Grebennikov proposed openstack/keystone: Allow to specify ID on project creation https://review.openstack.org/403866 | 14:13 |
*** agrebennikov has joined #openstack-keystone | 14:14 | |
knikolla | o/ | 14:15 |
*** donnalezyty has joined #openstack-keystone | 14:22 | |
stevemar__ | o/ | 14:25 |
stevemar__ | breton: yes, thqt one has caused a few issues now | 14:26 |
*** ayoung has joined #openstack-keystone | 14:29 | |
*** ChanServ sets mode: +v ayoung | 14:29 | |
*** rodrigods_ is now known as rodrigods | 14:31 | |
*** tsufiev has quit IRC | 14:33 | |
*** donnalezyty_ has joined #openstack-keystone | 14:34 | |
*** donnalezyty has quit IRC | 14:34 | |
*** tsufiev has joined #openstack-keystone | 14:37 | |
dstanek | morning samueldmq | 14:42 |
*** bigjools has quit IRC | 14:44 | |
*** aloga_ has quit IRC | 14:47 | |
openstackgerrit | Brant Knudson proposed openstack/keystone: Validate token issue input https://review.openstack.org/404806 | 14:49 |
*** spzala has joined #openstack-keystone | 14:50 | |
bknudson | breton: you should set up 3rd party CI to prevent upstream changes from breaking stuff for you. | 14:53 |
*** pnavarro has joined #openstack-keystone | 14:53 | |
*** guoshan has quit IRC | 14:54 | |
*** chlong has joined #openstack-keystone | 14:55 | |
*** jaosorior has quit IRC | 14:57 | |
*** jaosorior has joined #openstack-keystone | 14:59 | |
*** udesale has joined #openstack-keystone | 15:00 | |
*** chris_hultin|AWA is now known as chris_hultin | 15:02 | |
stevemar__ | https://review.openstack.org/#/c/386183/ | 15:03 |
stevemar__ | !!!!!!!!!!! | 15:03 |
openstack | stevemar__: Error: "!!!!!!!!!!" is not a valid command. | 15:03 |
*** hrybacki|mtg is now known as hrybacki | 15:04 | |
*** jdennis1 has joined #openstack-keystone | 15:05 | |
*** jdennis has quit IRC | 15:05 | |
lbragstad | nice! | 15:05 |
samueldmq | dstanek: o/ | 15:08 |
samueldmq | lbragstad: stevemar__ great | 15:09 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Validate token issue input https://review.openstack.org/404806 | 15:15 |
*** stevemar__ has quit IRC | 15:18 | |
*** stevemar__ has joined #openstack-keystone | 15:19 | |
*** ayoung has quit IRC | 15:30 | |
*** darrenc has quit IRC | 15:41 | |
*** darrenc has joined #openstack-keystone | 15:42 | |
*** ravelar has joined #openstack-keystone | 15:51 | |
lbragstad | reminder that the policy meeting will be starting in 8 minutes (in #openstack-meeting-cp) | 15:53 |
*** edtubill has joined #openstack-keystone | 15:55 | |
stevemar__ | lbragstad: thanks for the reminder | 15:56 |
lbragstad | stevemar__ anytime | 15:56 |
*** jaosorior has quit IRC | 15:58 | |
*** phalmos has joined #openstack-keystone | 15:59 | |
*** phalmos has quit IRC | 15:59 | |
agrebennikov | folks, I just wanted to ask you - what is the reason of having validations in resources/schema.py (for example for the project name), if in fact it allows me to use special symbols | 16:00 |
*** spilla has joined #openstack-keystone | 16:00 | |
agrebennikov | I may create the project with names like "project+" | 16:00 |
agrebennikov | even though the validation forbids it | 16:01 |
agrebennikov | oh, sorry.... nevermind | 16:01 |
agrebennikov | stupid me | 16:01 |
*** edmondsw_ has joined #openstack-keystone | 16:02 | |
*** rcernin has quit IRC | 16:02 | |
lbragstad | ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan | 16:02 |
*** code-R has quit IRC | 16:02 | |
*** edmondsw has quit IRC | 16:02 | |
*** edmondsw_ has quit IRC | 16:02 | |
lbragstad | policy meeting starting in #openstack-meeting-cp | 16:02 |
*** chlong has quit IRC | 16:03 | |
*** edmondsw has joined #openstack-keystone | 16:03 | |
lbragstad | ayoung ^ | 16:03 |
*** chlong has joined #openstack-keystone | 16:18 | |
*** jaugustine has joined #openstack-keystone | 16:21 | |
stevemar__ | agrebennikov: used the v2 api eh? | 16:24 |
agrebennikov | no, just didn't notice the name is going to be just a string | 16:25 |
*** bigjools has joined #openstack-keystone | 16:25 | |
agrebennikov | vs all others are checked with id_string | 16:25 |
*** code-R has joined #openstack-keystone | 16:27 | |
*** thiagolib has quit IRC | 16:28 | |
*** adrian_otto has joined #openstack-keystone | 16:29 | |
*** ayoung has joined #openstack-keystone | 16:32 | |
ayoung | where is the Policy meeting lbragstad ? | 16:32 |
*** chrisplo has joined #openstack-keystone | 16:33 | |
lbragstad | ayoung in #openstack-meeting-cp http://eavesdrop.openstack.org/#Keystone_Policy_Meeting | 16:33 |
*** code-R has quit IRC | 16:35 | |
*** Zer0Byte__ has joined #openstack-keystone | 16:55 | |
*** ruan_09 has joined #openstack-keystone | 17:00 | |
lbragstad | ruan_09 for example - what the hook would look like, want information needs to be passed, how we get information from keystone to the external PDP, etc... | 17:01 |
lbragstad | ruan_09 that would be a good way to get that kind of discussion started | 17:01 |
ayoung | lbragstad: one thing to keep in mind: we have the policy/RBAC/ABAC saavy people taking part in this discussion. We need to make sure that the base mechanism we support can be used by the average user. | 17:02 |
ayoung | lbragstad: the hook would be different for each service, potentially different for each PEP call | 17:02 |
ruan_09 | the hood is the code in oslo.policy which delegates authorization to an external PDP | 17:02 |
ruan_09 | since each service invokes oslo.policy, the external PDP can than be enforced by all the services | 17:03 |
ayoung | for example, creating a network based resources would need to know about networks, subnets, ports, routers. interfaces and creating a VM would need to know about the other things. So defining the attributes for a Full ABAC system is the most intensive portion | 17:03 |
ruan_09 | intead of making a local authorization based on policy.json | 17:04 |
ayoung | whatever the attributes are that we are enforcing on need to be marshalled to the Remote PDP | 17:04 |
ruan_09 | ayoung: this is up each PDP | 17:04 |
lbragstad | ruan_09 so - part of that would be finding an external PDP/PEP system that is flexible enough to support that usecase | 17:04 |
lbragstad | ruan_09 right - but we have to get the PDP information from keystone and possibly the other service some how, so there has to be an interface around that | 17:05 |
ruan_09 | lbragstad: we should do that in 2 steps | 17:06 |
ruan_09 | 1. let external PDP fetches info from each services | 17:06 |
ayoung | ruan_09: yes, but what that means is that it is up to the Nova team to determine how nova calls it, and Neutron team for Neutron, and so on. And those attributes which are goign to be pulled out of the request, data, and response objects are now going to be "locked in" essentially becomeing a public interface. And those temas might not be comfortable doing that for every API | 17:06 |
*** code-R has joined #openstack-keystone | 17:06 | |
ruan_09 | 2. make a concensus with each service which info can be shared | 17:06 |
ruan_09 | ayoung: let the external PDP fetches info from Nova, the external PDP gets only what it needs | 17:07 |
ayoung | ruan_09: I don't think you realize just how difficult it is to get consensus on anything in OpenStack, or you might think twice about proposing that. | 17:07 |
ruan_09 | ayoung: I have an implementation which works well | 17:08 |
ayoung | ruan_09: for which services? Which operations. | 17:08 |
ruan_09 | for all the operations of nova and swift | 17:09 |
openstackgerrit | David Stanek proposed openstack/keystone-specs: Show team and repo badges on README https://review.openstack.org/402878 | 17:09 |
*** catintheroof has quit IRC | 17:11 | |
*** catintheroof has joined #openstack-keystone | 17:12 | |
ayoung | ok gotta check out for a bit | 17:12 |
ruan_09 | lbragstad: finally, I believe that all the authorization-related information should be centralized | 17:13 |
ruan_09 | but that may take long time to converge | 17:14 |
lbragstad | ruan_09 what do you mean by authorization information? | 17:14 |
ruan_09 | like role, user-role assignment | 17:15 |
lbragstad | that's already centralized in keystone | 17:15 |
ruan_09 | also information in policy.json | 17:16 |
*** ayoung has quit IRC | 17:16 | |
stevemar__ | dstanek: ha, i said the same thing: https://review.openstack.org/#/c/402878/2..3 | 17:17 |
*** topol has quit IRC | 17:17 | |
*** code-R has quit IRC | 17:17 | |
*** chlong has quit IRC | 17:21 | |
*** pcaruana has quit IRC | 17:23 | |
dstanek | stevemar__: fingers crossed | 17:23 |
dstanek | ruan_09: i agree with that. having everything in the same place would make it easier to implement more advanced things like domain specific policies | 17:24 |
*** code-R has joined #openstack-keystone | 17:25 | |
*** spzala has quit IRC | 17:25 | |
*** rodrigods is now known as rodrigods_ | 17:31 | |
*** woodster_ has joined #openstack-keystone | 17:33 | |
*** chlong has joined #openstack-keystone | 17:34 | |
*** chrisplo has quit IRC | 17:37 | |
*** udesale has quit IRC | 17:38 | |
*** mvk has quit IRC | 17:40 | |
dstanek | stevemar__: no dice | 17:42 |
*** thiagolib has joined #openstack-keystone | 17:43 | |
*** ruan_09 has quit IRC | 17:45 | |
*** gyee has joined #openstack-keystone | 17:54 | |
*** spzala has joined #openstack-keystone | 17:59 | |
stevemar__ | dstanek | 18:01 |
stevemar__ | Steve Martinelli: Patch Set 2: Code-Review+2: this should build now | 18:01 |
stevemar__ | David Stanek: Patch Set 3: Code-Review+2: This works locally for me now | 18:01 |
stevemar__ | Jenkins: NOPE! -1 | 18:01 |
*** spzala has quit IRC | 18:03 | |
stevemar__ | dstanek: for some reason a really old sphinx is installed | 18:04 |
stevemar__ | dstanek: http://logs.openstack.org/78/402878/3/check/gate-keystone-specs-docs-ubuntu-xenial/68eff27/console.html#_2016-11-30_17_11_17_458299 | 18:04 |
*** Ephur has joined #openstack-keystone | 18:05 | |
stevemar__ | oh i didn't realize we don't install > 1.4 | 18:05 |
stevemar__ | sphinx>=1.2.1,!=1.3b1,<1.4 | 18:05 |
stevemar__ | dstanek: i see you already investigated this! | 18:05 |
dstanek | stevemar__: :-) you need to catch up | 18:08 |
*** ayoung has joined #openstack-keystone | 18:16 | |
*** ChanServ sets mode: +v ayoung | 18:16 | |
*** chrisplo has joined #openstack-keystone | 18:19 | |
*** topol has joined #openstack-keystone | 18:23 | |
*** ChanServ sets mode: +v topol | 18:23 | |
*** dave-mcc_ has joined #openstack-keystone | 18:23 | |
stevemar__ | dstanek: clearly | 18:25 |
stevemar__ | dstanek: silly me, eating lunch and all that :) | 18:26 |
*** dave-mccowan has quit IRC | 18:26 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 18:26 |
*** edtubill has quit IRC | 18:26 | |
*** tqtran has joined #openstack-keystone | 18:27 | |
breton | bknudson: not enough resources :( | 18:29 |
*** adrian_otto has quit IRC | 18:30 | |
*** tqtran has quit IRC | 18:31 | |
mfisch | jamielennox: you awake yet? | 18:35 |
mfisch | nm looks early ;) | 18:36 |
mfisch | jamielennox: can you ping me about 1640891 when you get in? I think there's an oslo.context bug I found | 18:36 |
*** spzala has joined #openstack-keystone | 18:43 | |
*** spzala has quit IRC | 18:47 | |
*** amoralej is now known as amoralej|off | 18:47 | |
*** spzala has joined #openstack-keystone | 18:47 | |
*** rodrigods_ is now known as rodrigods | 18:49 | |
*** jvarlamova has quit IRC | 18:50 | |
spligak | As an admin user, is there a way to get keystone to issue a valid token for another user? To allow you to support a "pose as user" sort of workflow? | 18:56 |
ayoung | spligak, Trusts API | 18:56 |
ayoung | user has to opt in, but that is what Trusts are for | 18:57 |
*** pnavarro has quit IRC | 19:05 | |
spligak | ayoung, okay - that might be an option. is there a way for an admin user to get a token scoped to a particular project? not a full "pose as user" workflow, but at least a project-limited scenario? | 19:11 |
spligak | ayoung, perhaps I can frame that better. I want an admin user to be able to view a project the way a particular user would. I don't need to literally "pose as" a user, but I'd like to get a token that limits my project and role similar to how a user would see their own resources. | 19:12 |
*** asettle has quit IRC | 19:13 | |
ayoung | spligak, a trust is explicitly scoped to a project, and can have a subset of the users roles assigned on that project | 19:13 |
*** tqtran has joined #openstack-keystone | 19:14 | |
ayoung | people have been asking for a "READ ONLY" role and that is really hard to do, sounds like what you want, though. | 19:14 |
openstackgerrit | Steve Martinelli proposed openstack/keystone-specs: Show team and repo badges on README https://review.openstack.org/402878 | 19:17 |
stevemar__ | dstanek: ok *now* it'll work | 19:17 |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 19:20 |
openstackgerrit | Brant Knudson proposed openstack/keystone: Validate token issue input https://review.openstack.org/404806 | 19:40 |
*** lunarlamp has joined #openstack-keystone | 19:40 | |
*** adrian_otto has joined #openstack-keystone | 19:41 | |
*** adriant has joined #openstack-keystone | 19:45 | |
openstackgerrit | ayoung proposed openstack/keystone: URL pattern based RBAC Management Interface https://review.openstack.org/401808 | 19:45 |
stevemar__ | bknudson: lgtm! | 19:51 |
*** catintheroof has quit IRC | 19:54 | |
stevemar__ | bknudson & dstanek are we finally going to merge this chain: https://review.openstack.org/#/c/261188/ ? | 20:04 |
bknudson | stevemar__: I got sick of reviewing that one so do whatever. | 20:04 |
stevemar__ | bknudson: before i review it, what was wrong with it that made you sick? | 20:05 |
bknudson | I made several comments on patch set 19 | 20:06 |
breton | lets just add a bunch of other methods | 20:08 |
breton | list_as_object, get_as_object | 20:09 |
breton | and so on | 20:09 |
breton | also, dstanek had an alternative, hadn't he? | 20:09 |
breton | which was a little mind-blowing, but nice. | 20:09 |
bknudson | my complaints didn't have anything to do with wanting new methods. | 20:11 |
bknudson | it was just asking to change the base methods (.get(), .head(), .post(), etc.) to include the request ID. | 20:11 |
breton | i understand that | 20:12 |
breton | i am talking about the issue in geenral | 20:13 |
*** asettle has joined #openstack-keystone | 20:14 | |
bknudson | I'm fine with the way this is being done. This is how python is supposed to work (duck typing) | 20:14 |
morgan | morning keystone (or erm.. lunch!) | 20:16 |
*** edtubill has joined #openstack-keystone | 20:18 | |
dstanek | stevemar__: i think it's a terrible thing to do from an engineering standpoint | 20:18 |
dstanek | breton: i did, but i think it was more invasive | 20:19 |
dstanek | breton: https://review.openstack.org/#/c/329913 | 20:19 |
stevemar__ | dstanek: also please punt https://review.openstack.org/402878 through :) | 20:19 |
dstanek | stevemar__: how'd you get it to work? | 20:20 |
*** asettle has quit IRC | 20:22 | |
stevemar__ | dstanek: there's a reference to the README here: http://specs.openstack.org/openstack/keystone-specs/ | 20:22 |
stevemar__ | dstanek: we can always turn that into a doc of it's own, something like "how to contribute a new spec" | 20:23 |
openstackgerrit | Merged openstack/keystone-specs: Show team and repo badges on README https://review.openstack.org/402878 | 20:23 |
stevemar__ | dstanek: which i'm happy to do the work for, nova already has a nice starter in their readme: https://github.com/openstack/nova-specs/blob/master/README.rst | 20:25 |
stevemar__ | i guess some projects dont fail when warnings are produced | 20:25 |
morgan | stevemar__: ping - re the user-specified id patch | 20:27 |
morgan | stevemar__: for projects | 20:27 |
morgan | stevemar__: can you confirm we want this functionality or not. we had this discussion before and I want to make sure we're clearing the runway for it (aka it wont be killed again on "we don't want this" purposes) so that agrebennikov can continue working on it with the expectation that with good code, it can land | 20:28 |
stevemar__ | morgan: i like your idea about enforcing uuid4 IDs | 20:28 |
stevemar__ | with that i'm OK with it | 20:29 |
morgan | mind saying that on a comment on the patch | 20:29 |
stevemar__ | i did? | 20:29 |
morgan | i'll lift my -2 then (down to a -1) | 20:29 |
* morgan goes to look | 20:29 | |
*** basilAB has quit IRC | 20:29 | |
stevemar__ | i think i reviewed a few minutes before you pinged | 20:29 |
morgan | aha | 20:29 |
*** basilAB has joined #openstack-keystone | 20:29 | |
morgan | i saw a "put this in the schema" | 20:29 |
morgan | let me check if i missed other bits | 20:29 |
morgan | ah i see it | 20:30 |
morgan | "not crazy about..." | 20:30 |
morgan | i really would rather not add more config options | 20:30 |
morgan | but if that is the requirement, sure. | 20:30 |
stevemar__ | morgan: nah | 20:31 |
* morgan likes consistent/interoperable clouds. | 20:31 | |
morgan | with no guessing on functionality | 20:31 |
stevemar__ | morgan: andrey talked to me about it, it didn't make sense | 20:31 |
morgan | but i def. want it to conform to the standard for id values for projects | 20:31 |
stevemar__ | if the switch is off, then keystone generates a uuid, if it's on, it's another uuid (from the req) | 20:31 |
*** browne has joined #openstack-keystone | 20:31 | |
morgan | the way i see it... | 20:32 |
morgan | the uuid from the req or it's auto-generated | 20:32 |
stevemar__ | yep | 20:32 |
morgan | meaning, yes someone could create projects with deadbeefdeadbeefdeadbeefdeadbeef | 20:32 |
morgan | ids | 20:32 |
morgan | but i don't see a switch as needed. | 20:32 |
morgan | since the IDs are just that... unique and conforming to a known format | 20:32 |
morgan | the only *concern* is if things aren't cleaned up | 20:33 |
morgan | and an old role assignment lingers past deletion | 20:33 |
agrebennikov | and what we end up with - just a string of [0-9a-f]+ | 20:33 |
agrebennikov | 32 bites long | 20:33 |
morgan | but that is a legit bug. | 20:33 |
morgan | not a real security issue | 20:33 |
morgan | oooh crud | 20:34 |
morgan | stevemar__: thought of something | 20:34 |
*** Zer0Byte__ has quit IRC | 20:34 | |
morgan | this means UUID tokens could become valid for a wrong project. | 20:34 |
morgan | stevemar__: delete the project, create a new project (different owner). | 20:35 |
morgan | old tokens are valid for new (different) project | 20:35 |
agrebennikov | they cannot since the IDs are uniq? | 20:35 |
agrebennikov | and tokens tend to expire | 20:35 |
morgan | agrebennikov: right. it's a window of opportunity | 20:35 |
morgan | it's not super likely imo | 20:35 |
morgan | but it is a minor concern | 20:35 |
morgan | i'm still lifting my -2 based on this convo :) | 20:36 |
agrebennikov | so stevemar__, we go with regex, not the pure uuid, are you ok with that? | 20:36 |
*** rcernin has joined #openstack-keystone | 20:37 | |
*** Zer0Byte__ has joined #openstack-keystone | 20:39 | |
*** rodrigods is now known as rodrigods_ | 20:41 | |
lbragstad | morgan you worked with adriant on the outcomes of user managed TOTP yesterday after the meeting, didn't you? | 20:41 |
*** raildo has quit IRC | 20:41 | |
dstanek | morgan: would the data from thos IDs be value UUID values? as in i can use the UUID objects to hold them? | 20:43 |
lbragstad | that would be nice because we could convert them to byte representations | 20:43 |
morgan | it would conform to straight uuid.hex | 20:43 |
morgan | which can be converted to bytes | 20:43 |
morgan | eaisly | 20:44 |
morgan | easily* | 20:44 |
lbragstad | cool | 20:44 |
morgan | since it is HTTP1, and json... | 20:44 |
morgan | we need it human readable, and .hex is better than uuid with '-' included in that case, since we already do that everywhere in keystone | 20:44 |
morgan | (though... to be fair... i'm not sure why we chose that) | 20:44 |
morgan | (a couple extra bytes here an there wont hurt anything) | 20:45 |
morgan | mordred: silly question... since you know these things... | 20:45 |
morgan | and i can ask you :P | 20:45 |
morgan | mordred: would converting things that don't need uuids to auto-inc ints in mysql (and other DBs) be more efficient | 20:45 |
morgan | or not worth the effort(s). | 20:46 |
* morgan asks the dirty mysql questions of the dude who "knows" things. | 20:46 | |
* morgan expects a wet cat to be thrown. | 20:46 | |
mordred | morgan: yah - auto-inc ints are always more efficient - especially if they are primary keys | 20:47 |
morgan | mordred: ok i'll toss that on my backlog of things to consider when i need some time to do things. | 20:48 |
mordred | morgan: https://www.percona.com/blog/2007/03/13/to-uuid-or-not-to-uuid/ | 20:48 |
morgan | fair enough | 20:50 |
morgan | we should ocnsider moving towards a binary compression of the keys where possible if we're going to use them [long term perf considerations] if we're getting into nitty-grittys here | 20:51 |
morgan | based on that article | 20:51 |
morgan | but auto-inc as a PK is more efficient and provides proper data clustering at scale, where at small-to-mid row counts, uuid is less likely ot have as big an impact, and possibly have better distribution | 20:51 |
morgan | wow. that is a good article :) | 20:51 |
morgan | thanks! | 20:52 |
*** catintheroof has joined #openstack-keystone | 20:54 | |
*** spzala has quit IRC | 20:54 | |
adriant | lbragstad, morgan: We didn't really end up talking about the user self management side of it. Mainly just the need to have keystone be able to enforce multiple auth plugins properly. | 20:58 |
adriant | I still think user totp management in keystone would be useful, but unless we can find a good solution for it people are the least unhappy about, I not sure what good pushing it will do :( | 21:01 |
dstanek | morgan: hex bytes consistent with the UUID size would be great | 21:02 |
morgan | dstanek: aye. | 21:02 |
dstanek | i think i'm going to go get a late lunch now | 21:02 |
morgan | dstanek: i need lunch :( | 21:05 |
*** Zer0Byte__ has quit IRC | 21:05 | |
morgan | oh holy crap when did it become 1pm | 21:05 |
* morgan isn't even hungry | 21:05 | |
bknudson | we can also use tempest validate the response matches a schema: https://review.openstack.org/#/c/404962/ | 21:05 |
dstanek | morgan: i just realized it was 4pm and i'm starving | 21:06 |
*** Zer0Byte__ has joined #openstack-keystone | 21:06 | |
morgan | bknudson: ++ | 21:07 |
*** Marcellin__ has joined #openstack-keystone | 21:08 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 21:10 |
morgan | adriant: so, what if keystoneclient could generate the secret? | 21:11 |
morgan | adriant: we have to transmit the secret in either case to/from keystone (one way or another) | 21:11 |
morgan | I would rather the code not be *in* keystone itself | 21:11 |
morgan | now, there is a concern about entropy on end-user machines | 21:11 |
adriant | morgan: yeah, that's not something I considered, but in general I just thought server generation was the safest as it is then under deployer control | 21:13 |
morgan | adriant: i view this as something that shouldn't be *in* keystone | 21:14 |
morgan | i don't mind having official utilities that can do it outside of keystone | 21:14 |
morgan | so, for example, your user-management portal (i assume you have one since admin-requirement and for other reasons) | 21:14 |
adriant | I can live with that. | 21:14 |
morgan | can do these things. | 21:14 |
adriant | yes, we have a user management portal that does everything for users in keystone except auth and password changes | 21:15 |
adriant | and we can throw our MFA code into that | 21:15 |
morgan | in fact, if we didn't already have EC2 key generator apis in keystone, i'd advocate this should be in associated utils as well | 21:15 |
morgan | adriant: lets not put it in the keystone server itself. credentials are "special" cased in keystone for the most part anyway | 21:16 |
adriant | Ok, but we still probably want a way for users to upload them. We can just change the credentials api to allow "admin_or_owner" | 21:16 |
adriant | we can allow that policy provided we add... sec let me find the code | 21:17 |
adriant | morgan: I beleive throwing something close to how EC2 does this into the core credentials code is enough: https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L356 | 21:18 |
morgan | adriant: using the base credential api and setting a type should be fine | 21:18 |
morgan | as long as we provide clear documentation on how to do it | 21:19 |
adriant | because by default the policy stuff can't access the field on the model itself I believe, but this change that EC2 have done does allow that check | 21:19 |
*** franza has joined #openstack-keystone | 21:19 | |
morgan | fwiw, i think the credential API has security flaws in it... but that aside. | 21:19 |
morgan | the "ec2" controller just does some magic with creating the credential data | 21:20 |
morgan | we can do the same things with the normal api, and totp is much much much simpler credential data | 21:20 |
adriant | morgan: I don't think we need to do anything special, my main concern is the cross user problem | 21:20 |
*** gyee has quit IRC | 21:21 | |
*** amoralej|off is now known as amoralej | 21:21 | |
morgan | we can define the standard like google does | 21:21 |
morgan | for what the secret needs to be | 21:21 |
morgan | we can provide a simple validator in our utils for the secret | 21:22 |
morgan | i worry that we're going to have to add HOTP next because people want it. | 21:22 |
rcernin | do we have something like RSA tokens for Horizon auth? | 21:22 |
morgan | or <new fangled crazy MFA> | 21:22 |
adriant | not HOTP :( | 21:23 |
rcernin | :) | 21:23 |
adriant | totp is better than hotp :P | 21:23 |
morgan | adriant: right. just wait though, if we add more and more of these "things" as top-level apis... | 21:23 |
morgan | adriant: debatable | 21:23 |
morgan | adriant: totp is way easier to manage | 21:23 |
morgan | but i'd argue each has pros and cons | 21:23 |
adriant | morgan: I'm aware, I just prefer totp as it's less of a hassle most of the time. | 21:24 |
*** Zer0Byte__ has quit IRC | 21:24 | |
morgan | so do i | 21:24 |
morgan | but I also want to implement FIDO u2f for keystone | 21:25 |
morgan | ;) | 21:25 |
morgan | but that only works with chrome atm... sooooo | 21:25 |
*** mvk has joined #openstack-keystone | 21:25 | |
morgan | not useful for keystone (yet) | 21:25 |
*** Zer0Byte__ has joined #openstack-keystone | 21:25 | |
morgan | anyway let me write this spec up unless you posted one already | 21:26 |
adriant | That would be interesting, although possibly very painful to get working no? | 21:26 |
morgan | possibly, but awesome | 21:26 |
adriant | I have a user-self management one, I can rewrite it to reflect this talk. | 21:26 |
adriant | https://review.openstack.org/#/c/345705 | 21:27 |
morgan | also, if we do it without needing the keystone API to generate, it is easier to setup with a yubikey | 21:27 |
morgan | cool. let me comment on it and lets get it ready to go :) | 21:27 |
morgan | oh no not just that one | 21:27 |
rcernin | btw guys qq how does the services authenticate if you use totp or others, or you simply keep the password in methods? | 21:27 |
rcernin | ^^ | 21:27 |
morgan | rcernin: that is the idea | 21:28 |
morgan | rcernin: the plan is to make it so a given user can require specific auth plugins | 21:28 |
morgan | aka, must use totp and password | 21:28 |
morgan | or a service user can use just password | 21:28 |
adriant | morgan: I'm just curious how we'll eventually connect that to horizon :( | 21:28 |
morgan | adriant: we need the spec to update the auth plugin model with per-user requirements | 21:28 |
adriant | morgan: yes, that too. You throw up that one, I'll amend the user management one. | 21:29 |
morgan | cool. | 21:29 |
adriant | I'll change it to just be for: "fix/alter the credentials api to make this possible while adding basic validation", "add generation of totp to keystoneclient"" | 21:30 |
rcernin | btw can you block the password from horizon ui as long as you have the user/password combination you wouldn't need totp and it would loose the effect wouldn't it? | 21:30 |
rcernin | split the service use the password method while users would need to use the tokens | 21:31 |
morgan | rcernin: not sure what you're asking | 21:31 |
adriant | morgan, rcernin: my problem is Horizon doesn't know, "this user need totp and password" | 21:31 |
rcernin | if you implement tokens, and still need to have the passwords enabled for services as they can't use the tokens, isn't it useless ? | 21:31 |
adriant | and we can't really pre-fetch that info and load the UI based on it :( | 21:32 |
rcernin | yeah | 21:32 |
adriant | morgan: hence my password_totp stuff :( | 21:32 |
adriant | I didn't want to go down the rabbit hole of fixing/changing that whole process yet | 21:32 |
morgan | adriant: the thought i always had was if totp was required, you get an response back (we have an error response that works like this, look a tthe challenge-response example) and we then re-request with the data inc the totp- it's two pages, but most totp is. | 21:33 |
morgan | adriant: i.e. google. | 21:33 |
morgan | adriant: and dropbox, and amazon, and etc etc, mostly MFA is "here is pre-auth, ok now we need OTP, give me OTP" | 21:33 |
adriant | morgan: I had a similar idea, but the best way I thought it would work was by returning a semi-unscoped token that as approved with password but not totp yet. | 21:33 |
morgan | unless you use something like how FreeIPA does it, which is what you're advocating - password+OTP | 21:34 |
adriant | so the token itself knows "this is the auth I was given" and a token only gets proper roles when all the auth types are done for it. | 21:34 |
morgan | that actually would be super easy to do. | 21:34 |
morgan | it's a new token-type (in the fernet has multiple token-types) | 21:34 |
adriant | basically, we make the token itself the auth status as well as the challenge response | 21:34 |
morgan | in fernet land, you'd get a new token when you finished totping | 21:35 |
adriant | yep | 21:35 |
morgan | in uuid land... it could go either way | 21:35 |
adriant | That's the only not awful solution I saw for doing proper challenge response in keystone | 21:36 |
adriant | I'm not sure if there is a better way to do it, but I don't know keystone well enough yet anyway. | 21:36 |
morgan | or, you re-send the password and totp, horizon could maintain the password field populated (and even hidden) based upon the response | 21:36 |
morgan | so only totp is included. | 21:36 |
morgan | after. | 21:37 |
morgan | there are many ways to slice this. | 21:37 |
adriant | That's possible, we could update openstack django auth to handle that | 21:37 |
morgan | exactly | 21:37 |
morgan | but it still is predicated on having the ability to require the auth-types on a per-user basis | 21:37 |
adriant | not sure how I feel about storing the password there between responses, but it's not too awful | 21:37 |
adriant | and if the error messages and code coming from keystone are good enough to let os-django-auth programatically do all this, it would totally work. | 21:38 |
morgan | the errors for a challenge/response style should be sufficient | 21:38 |
morgan | as they sit | 21:38 |
rcernin | adriant: did you mean this on-per-user-basis MFA https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin | 21:39 |
adriant | rcernin: yes and here is the patch: https://review.openstack.org/#/c/343422 | 21:40 |
adriant | rcernin: it literally works by expected a 6digit passcode appended to the password. | 21:41 |
adriant | if totp has been setup for a user | 21:41 |
*** Zer0Byte__ has quit IRC | 21:43 | |
adriant | morgan: ok, should we just do the spec for auth plugins as discussed and then worry about challenge response later? Or include that in the spec? | 21:43 |
morgan | i'll include the details of that in the spec, but leave that bit to the implementation details | 21:44 |
morgan | if we add it or not. | 21:44 |
adriant | morgan: ok. I mention it just because how we do the auth plugins might affect what we can do with challenge response later. As trying to alter it later may break backwards compatibility :( | 21:46 |
morgan | nah. | 21:47 |
morgan | i think we can make it consistent enough so that django openstack auth can work from it | 21:48 |
*** adrian_otto has quit IRC | 21:48 | |
morgan | i lean towards not doing "temp auth" tokens | 21:48 |
morgan | but we can discuss a bit more in the spec once posted | 21:48 |
*** Zer0Byte__ has joined #openstack-keystone | 21:48 | |
adriant | morgan: so reauth based on errors? | 21:48 |
morgan | yes. since this is RESTful, it already works like that | 21:49 |
morgan | and it follows the patternof our current challenge/response concept | 21:49 |
morgan | slash example | 21:49 |
adriant | yeah fair enough | 21:49 |
adriant | morgan: sounds good. We can then work with Horizon and OS-client devs to add in support for it properly too. | 21:50 |
*** edmondsw has quit IRC | 21:50 | |
adriant | although OS-Client will not need too much work if we do a lot of it in KeystoneAuth1 | 21:50 |
morgan | in some ways i wish our specs were more like RFCs | 21:51 |
morgan | then i read RFCs and ... | 21:51 |
morgan | am glad our specs are more human readable | 21:51 |
*** adrian_otto has joined #openstack-keystone | 21:52 | |
adriant | morgan: oh, for this the auth plugins spec. I think the default if a user has no rules enforced is just "any single auth method" | 21:53 |
morgan | yep | 21:53 |
adriant | correction | 21:53 |
morgan | that is the plan | 21:53 |
adriant | "at least one" | 21:53 |
openstackgerrit | Lance Bragstad proposed openstack/keystone: Remove exception from v2 validation path https://review.openstack.org/404977 | 21:54 |
adriant | morgan: I'm looking forward to this. ;) As I can then throw in some silly auth layers like allowing users to set IP ranges they can only auth from. | 21:55 |
*** gyee has joined #openstack-keystone | 21:57 | |
*** gyee has quit IRC | 21:58 | |
ayoung | dstanek, stevemar__ cannot build docs for specs. When I try I get | 21:59 |
ayoung | File "/tmp/pip-build-nhxd68z3/feedformatter/feedformatter.py", line 77 | 21:59 |
ayoung | (("pubDate", "pubdate", "date", "published", "updated"), "pubDate", lambda(x): _format_datetime("rss2",x)), | 21:59 |
ayoung | this is a dependecny from yasfb | 22:00 |
adriant | morgan: actually, as part of the default, I think we need a default we can set in the config (at least one of: "password, totp, ..."), and if that config default isn't set, then we go by "at least one of all active methods" | 22:01 |
*** jrist has quit IRC | 22:01 | |
*** Zer0Byte__ has quit IRC | 22:01 | |
morgan | adriant: i am hesitant to add that. but we cna discuss once i post the spec | 22:01 |
adriant | morgan: just because there will be some plugins that really shouldn't be used by themselves. So a deployer can ensure totp isn't used by itself without password. | 22:01 |
adriant | morgan: otherwise they need to set it for all old and new users :( | 22:02 |
adriant | which is a huge and ugly pain | 22:02 |
*** jrist has joined #openstack-keystone | 22:02 | |
morgan | in the case of password+totp you need to configure totp for old users anyway | 22:02 |
ayoung | morgan, your argument for the security hole with the project ID is another argument in favor of soft deletes of projects | 22:02 |
morgan | you need to update users. | 22:02 |
morgan | ayoung: yes. i know. | 22:02 |
adriant | morgan: I mean more the situation. A cloud has "password, totp, external, etc" auth methods turned on. But the deployer doesn't want totp ever being used by itself. | 22:03 |
adriant | so to do that they would need to set all users "at least one of all, but not totp" | 22:04 |
adriant | a changable global default makes this easier | 22:04 |
ayoung | adriant, morgan is this really going to be on a per- user basis, or is it more likely to be on "all users in this domain" basis? | 22:04 |
adriant | ayoung: per user | 22:05 |
morgan | ayoung: to start per-user | 22:06 |
ayoung | adriant, so it should be a property of the user that is checked on the password plugin | 22:06 |
morgan | we can expand to "any user that belongs to <domain>" (not "has a role on domain") | 22:06 |
morgan | ayoung: correct. the user will have an attribute with a list of rules for authentication-types | 22:07 |
morgan | e.g.: | 22:07 |
*** jrist has quit IRC | 22:07 | |
morgan | https://www.irccloud.com/pastebin/vLAunqx9/ | 22:07 |
adriant | pretty much per user auth policy :P | 22:07 |
openstackgerrit | Samuel Pilla proposed openstack/keystone: [WIP] Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 22:08 |
ayoung | if a user has OTP set, they *MUST* pass in the OTP value. After that, the OTP value gets removed, and it is no longer valid, and their password must be reset or whatevber business logic you have | 22:08 |
ayoung | for password plugin, if OTP is set, use the OTP value, otherwise use password, and all the validation there. | 22:08 |
morgan | ayoung: correct, the auth-plugin (keystone server side) needs to know how to handle that | 22:08 |
morgan | if it's HOTP, the counter is incremented | 22:08 |
morgan | if it is true OTP, it is invalidated | 22:09 |
adriant | morgan: one thing though with the totp-self management is how can that fit into adding those rules to the user without another service doing it for them? | 22:09 |
ayoung | from a KC perspective it is still OS_PASSWORD, just set to {{ OTP VALUE }} | 22:09 |
morgan | if it is OTP + password, jus the OTP is invalidated, but still confirmed | 22:09 |
morgan | adriant: it requires a user-update, we can add an api similar to password change | 22:09 |
morgan | adriant: that is self-service | 22:09 |
ayoung | If it is used, it is discarded. Otherwise it is not a OTP. HOTP, as you described it, sounds like a bastard abomination from hell. Or at least misnamed. | 22:10 |
* morgan continues to write this spec up | 22:10 | |
morgan | ayoung: it is how HOTP works | 22:10 |
morgan | you have a counter (offset) vs a timer | 22:10 |
morgan | each token is valid once | 22:10 |
ayoung | Ah, it that what the gemalto tokens are doing? and the RSA ones? | 22:10 |
morgan | the server tries a few options | 22:10 |
morgan | your redhat token for vpn is HOTP | 22:10 |
morgan | for example | 22:10 |
ayoung | got it | 22:10 |
*** clayg has joined #openstack-keystone | 22:10 | |
morgan | it is why a re-sync is sometimes needed | 22:10 |
adriant | morgan: and do we want a difference between user set auth rules, and admin set auth rules for a user? Do we care? | 22:11 |
morgan | adriant: you can always deny users access to the self-service api | 22:11 |
morgan | via policy | 22:11 |
adriant | true | 22:11 |
ayoung | So it all comes through the password field, but the processing is done by a pipeline of Auth plugins? | 22:11 |
adriant | ok, by default a user entirely controls their rules | 22:11 |
morgan | ayoung: depends on implementation | 22:11 |
morgan | ayoung: some do it like we do at RH with a password+OTP | 22:12 |
morgan | in one field | 22:12 |
ayoung | so right now we have: [auth] password= keystone.auth.plugins.Password | 22:12 |
morgan | some work like google, which is send password, then send OTP | 22:12 |
adriant | ayoung: look at the existing totp plugin, it expects a separate passcode value in a different method | 22:12 |
ayoung | do we really want | 22:12 |
morgan | some look like "send password, and otp same request but different fields" | 22:12 |
ayoung | [auth] password= keystone.auth.plugins.HTOP, keystone.auth.plugins.OTP, keystone.auth.plugins.Password | 22:12 |
morgan | that is just telling keystone what plugins to enable | 22:12 |
adriant | ayoung: no | 22:12 |
morgan | and load | 22:12 |
ayoung | and have them processed in that order for the "password" auth method in the token request? | 22:12 |
morgan | we require the auth request to specify the type for each value | 22:13 |
morgan | and we will maintain it | 22:13 |
morgan | in a an auth-request you can have multiple plugins | 22:13 |
ayoung | morgan, that is a very poor user experience | 22:13 |
morgan | in a RESTful API, it is fine | 22:14 |
morgan | the UI/CLI can make the UX better | 22:14 |
morgan | it can do splits etc | 22:14 |
ayoung | morgan, ok...lets skip this part, and jump right to WHY you want it this way | 22:14 |
morgan | because we already have it this way and changing it would break our API and auth contract | 22:14 |
morgan | which is horrifying | 22:14 |
ayoung | So...no | 22:14 |
ayoung | that is not true and not really an answer | 22:14 |
morgan | we aren't breaking our auth contract | 22:14 |
morgan | yes it is true. it is exactly how it works now | 22:15 |
ayoung | morgan, when you send in an OTP, it *is* a password | 22:15 |
adriant | ayoung: let me show you and example of a what a request looks like: http://paste.openstack.org/show/591023/ | 22:15 |
ayoung | morgan, do you realize how much unnecssary pain that will cause? | 22:15 |
ayoung | so...let me ask again | 22:15 |
morgan | ok. we have a plugin that reads "password", traditionally or OTP, or x509 | 22:16 |
ayoung | "Why" should we not treat an OTP just like a normal password | 22:16 |
morgan | you are passing what version of password you're using. they are all passwords | 22:16 |
ayoung | is it cuz we need to be able to send it *with* a passwrod for some use cases? | 22:16 |
morgan | but the plugin must know what form of password it is | 22:16 |
adriant | because it isn't a password, it's only really useful alongside a normal password | 22:16 |
morgan | we *already* support multiple forms for auth | 22:16 |
adriant | true otp we can do, but we need to know its type | 22:17 |
morgan | and if you are authing with totp, you say this is totp: "value" in the auth requst | 22:17 |
ayoung | adriant, not the HOTP one. That replaces a password | 22:17 |
morgan | vs "password": <password value>" | 22:17 |
ayoung | if an account is locked due to expired passwrod, you require the user to send the OTP and the original password? | 22:17 |
morgan | in keystone we also support auth: ["password": <details>", "totp": <details>] | 22:17 |
morgan | and the token says "hey you used both" | 22:17 |
morgan | ayoung: right now self-service password changes cannot be done with expired passwords | 22:18 |
morgan | this doesn't change anything | 22:18 |
ayoung | morgan, I know all that. I was there when Guang wrote it. I battled with David CHadwick to have the specific mechanism in that field basedd on the requer as opposed to just having a "Federated" auth plugin...which is what we ended up with | 22:18 |
ayoung | I made all the mistakes | 22:18 |
morgan | unless you have an alternative form of auth configured | 22:18 |
ayoung | so If a user has OTP set up, their normal password will work just fine | 22:18 |
morgan | right now, OTP is just a form of password | 22:19 |
morgan | it is *not* MFA in keystone | 22:19 |
morgan | this change is simply allowing us, per-user to require multiple forms of auth. making it really MFA support | 22:19 |
morgan | aka must send the OTP *and* traditional password (if that is what is configured) | 22:19 |
ayoung | Got it | 22:20 |
adriant | ayoung: right now, this here is a valid auth request: http://paste.openstack.org/show/591024/ | 22:20 |
ayoung | so MFA is a per-user thing? | 22:20 |
adriant | yes | 22:20 |
morgan | that is the intent | 22:20 |
morgan | it can be expanded | 22:20 |
morgan | but we're starting with per-user | 22:20 |
morgan | if you configure MFA, you must use MFA. not per-domain or per-scope (this gets really ugly to support and i think a worse UX by far) | 22:21 |
morgan | i also see us *maybe* requiring a user to have MFA for a specific scope, but i like the github model | 22:21 |
ayoung | This is really going to suck | 22:21 |
ayoung | for Horizon | 22:21 |
morgan | it's either you have MFA or you don't. that may limit what you can access, but it doesn't require you to auth conditionally to get some access. it's an all or nothing | 22:21 |
morgan | we already discussed about 5 ways of approaching it for horizon | 22:22 |
adriant | ayoung: nope, we can add support in openstack-django-auth | 22:22 |
morgan | each has pros and cons | 22:22 |
ayoung | Oh, I didn't mean it couldn't be solved. I meant that it is going to fall to me to support it for Tripleo in Horizon, and that is going to suck | 22:22 |
morgan | some are better UX, some are more "standard web-style ux" | 22:22 |
*** amoralej is now known as amoralej|off | 22:22 | |
morgan | i think it's going to be pretty standard | 22:22 |
ayoung | Can't we just do all this in Keystone via Federation? | 22:23 |
morgan | you can totally support this in keystone with federation to freeipa | 22:23 |
morgan | 100% | 22:23 |
morgan | back it to freeipa with it's MFA support | 22:23 |
morgan | done | 22:23 |
morgan | this is allowing keystone to *also* support this, as it's a consistent request to have | 22:24 |
morgan | in fact, for triple-o since it is freeipa backed, i would 100% say, just do that | 22:24 |
morgan | :) | 22:24 |
ayoung | Tell them no | 22:24 |
morgan | too late | 22:24 |
ayoung | Nah, I can -2 anything | 22:24 |
morgan | we accepted the basic pemesis and added totp. | 22:24 |
morgan | with the condition this will be added | 22:24 |
ayoung | So we lied | 22:24 |
morgan | dude, we have already conceeded the IDP part of keystone | 22:25 |
morgan | we are an IDP. | 22:25 |
ayoung | Oh, I have a change to deprecate that I forgot to submit | 22:25 |
ayoung | I have conceded nothing! | 22:25 |
adriant | too many people (including my organisation) is actually using keystone without federation. | 22:26 |
adriant | s/is/are/ | 22:27 |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 22:27 |
ayoung | adriant, we give them 2 cycles to move to something real | 22:27 |
adriant | And having a basic but still useful IDP as part of openstack isn't a terrible idea. | 22:28 |
ayoung | oh yes it is | 22:28 |
ayoung | it is the worst idea I have heard. | 22:28 |
morgan | ayoung: we also are adding PCI-DSS support... we're a real (but limited) idp | 22:28 |
ayoung | morgan, I know. i was against that too. | 22:28 |
ayoung | and now my PM has heard about it and is all over it | 22:29 |
ayoung | meanwhile....https://review.openstack.org/#/c/391624/ | 22:29 |
ayoung | actually makes Keystone do something useful for a change. | 22:29 |
morgan | ayoung: ok i'm going back to writing this spec up.... | 22:30 |
morgan | ayoung: so that i can actually review the things needed to be reviewed. | 22:30 |
*** code-R_ has joined #openstack-keystone | 22:33 | |
*** code-R has quit IRC | 22:33 | |
morgan | adriant: UGH... | 22:36 |
morgan | we have to pass the user_id for *each* auth plugin | 22:36 |
morgan | *sigh* | 22:36 |
morgan | i think i need to modify (allow for a single) auth-info bit to be supplied | 22:36 |
adriant | morgan: yeah, the need to split it out per method also always bugged/confused me but I do understand why | 22:37 |
adriant | morgan: part of me wishes this was possible: http://paste.openstack.org/show/591028/ | 22:38 |
morgan | adriant: i can enhance that a bit and support both forms. | 22:38 |
morgan | yeah we can do both things | 22:38 |
morgan | would not be hard. | 22:39 |
openstackgerrit | ayoung proposed openstack/keystone: URL pattern based RBAC Management Interface https://review.openstack.org/401808 | 22:39 |
*** edtubill has quit IRC | 22:40 | |
*** mnaser has quit IRC | 22:41 | |
openstackgerrit | Samuel Pilla proposed openstack/keystone: [WIP] Add password expiration queries for PCI-DSS https://review.openstack.org/403898 | 22:41 |
*** jrist has joined #openstack-keystone | 22:42 | |
*** spilla has quit IRC | 22:44 | |
openstackgerrit | Merged openstack/keystone: Removes unused exceptions https://review.openstack.org/404416 | 22:45 |
*** mnaser has joined #openstack-keystone | 22:50 | |
*** pumaranikar has joined #openstack-keystone | 22:50 | |
*** dave-mcc_ has quit IRC | 22:53 | |
*** masuberu has quit IRC | 22:54 | |
*** masber has joined #openstack-keystone | 22:54 | |
pumaranikar | Hi jamielennox, am working on this https://review.openstack.org/#/c/387711/ spec for nova which is basically using service token for service to service communication.. | 22:55 |
jamielennox | pumaranikar: yep, i remember | 22:57 |
pumaranikar | jamielennox, Are we planning to have new release soon for keystoneauth1 so that we can make use of service token | 22:57 |
jamielennox | so we need a keystoneclient release then a keystonemiddleware release to actually enforce the expiry thing | 22:58 |
morgan | adriant: what is your launchpad id? adriant? | 22:58 |
adriant | sec, I'll check, but I think adriant-y | 22:58 |
jamielennox | however there shouldn't be any reason you can't start it now, it just won't give you the expired token advantage yet | 22:58 |
jamielennox | pumaranikar: i mean, what exactly are you waiting for on keystoneauth? | 22:58 |
adriant | morgan: "adriant-y | 22:59 |
adriant | " | 22:59 |
stevemar__ | jamielennox: want a new ksc release? | 22:59 |
pumaranikar | jamielennox, we are trying to use service token wrapper which is not part of 2.15 tag | 22:59 |
*** jperry has quit IRC | 22:59 | |
pumaranikar | I think so | 23:00 |
openstackgerrit | Brant Knudson proposed openstack/keystone: More info in schema validation error https://review.openstack.org/405006 | 23:00 |
jamielennox | pumaranikar: did that merge? | 23:01 |
jamielennox | ok, yea, but it hasn't been released yet | 23:02 |
pumaranikar | jamielennox, yes. | 23:02 |
jamielennox | stevemar__: yea, we're going to want a new release of both - can you give me a few hours to figure out what else i need in those releases | 23:02 |
jamielennox | like anything open that needs to go in | 23:02 |
openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Specification for MFA support https://review.openstack.org/405007 | 23:04 |
*** browne has quit IRC | 23:04 | |
morgan | adriant: ah doh | 23:04 |
morgan | sec | 23:04 |
stevemar__ | jamielennox: ack | 23:04 |
openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Specification for MFA support https://review.openstack.org/405007 | 23:04 |
stevemar__ | jamielennox: poke me if you need something | 23:04 |
morgan | adriant: ^ there is the first pass on the spec | 23:04 |
jamielennox | stevemar__: you happy to do it today? not too late in the week? | 23:04 |
adriant | morgan: fantastic, will look over it later today :) | 23:05 |
pumaranikar | jamielennox, thanks. I think we will have new release soon :) | 23:05 |
stevemar__ | jamielennox: i'll happen tomorrow, and there are only 8 changes, so the release team should be OK with it | 23:05 |
openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Specification for MFA support https://review.openstack.org/405007 | 23:06 |
morgan | adriant: ok there we go. fixed a couple formatting bugs | 23:06 |
morgan | hope i didn't screw up rst too badly | 23:06 |
jamielennox | stevemar__: so only https://review.openstack.org/#/c/392442/ to review for ksa - he did all the right things but i'm concerned about the noise | 23:07 |
jamielennox | basically i think everything around request id annoys me | 23:08 |
* jamielennox grumpy old man | 23:08 | |
jamielennox | ideally i think we should get rid of the curl debug statements from ksa and replace it with something useful that tells you the info you want to know | 23:08 |
jamielennox | but i think that makes it contentious and we shouldn't put it in this release - so ksa is good to go | 23:09 |
stevemar__ | jamielennox: i'm not a huge fan of the request id stuff either, but its a cross-project spec | 23:10 |
stevemar__ | initiative* | 23:10 |
bknudson | I've found the request ID in the keystone error response to be useful. | 23:11 |
stevemar__ | jamielennox: i think it's mergable | 23:12 |
pumaranikar | jamielennox, I have initiated service token change in nova. https://review.openstack.org/#/c/397399/. Please have quick look when you get time. | 23:12 |
*** catintheroof has quit IRC | 23:12 | |
stevemar__ | bknudson: jamielennox: i tossed it a +2 | 23:13 |
stevemar__ | jamielennox: oh wow, been a while since a ksa release | 23:13 |
*** ravelar has quit IRC | 23:14 | |
stevemar__ | meh, nothing major for the most part | 23:14 |
stevemar__ | "Add a service token wrapper" is the only major thing | 23:14 |
jamielennox | yea, it's been pretty stable | 23:14 |
jamielennox | stevemar__: so the problem with that review is that it will add a new, long, debug statement to every request made | 23:15 |
jamielennox | which i'm pretty sure will piss off at least the infra/devstack people | 23:15 |
jamielennox | and maybe ops in general | 23:15 |
stevemar__ | yes, i agree... | 23:15 |
jamielennox | i'm reluctant to add more output vs making the output we have better/more structured | 23:16 |
jamielennox | but who knows what ops may be doing re parsing those curl statements | 23:16 |
jamielennox | on the other hand, he's already added it to novaclient and others so maybe just suck it up and do it | 23:17 |
jamielennox | why you add it there before ksa i'm not sure | 23:17 |
jamielennox | re ksc, https://review.openstack.org/#/c/339150/10 looks easy but not urgent for part of this release | 23:18 |
jamielennox | otherwise i think that's probably fine as well | 23:18 |
*** topol has quit IRC | 23:20 | |
*** spzala has joined #openstack-keystone | 23:21 | |
stevemar__ | jamielennox: rgr | 23:21 |
stevemar__ | jamielennox: and ksm? | 23:22 |
*** chlong has quit IRC | 23:22 | |
stevemar__ | jamielennox: you've got a bunch of merge conflicts, something in WIP, and brant has something in WIP | 23:22 |
openstackgerrit | ayoung proposed openstack/keystone-specs: Role Check Check from Middleware https://review.openstack.org/391624 | 23:23 |
jamielennox | stevemar__: i need to fixup the allow_expired thing for ksm but that's going to require the new release of ksc | 23:23 |
jamielennox | there's nothing i see that really needs to be released until then | 23:24 |
jamielennox | pki deprecations, some small testing and doc fixes | 23:24 |
jamielennox | i think we can wait on that and see if i can fix the allow_expired thing quickly | 23:25 |
*** asettle has joined #openstack-keystone | 23:25 | |
*** clsacramento_ has quit IRC | 23:26 | |
*** ravelar has joined #openstack-keystone | 23:26 | |
*** spzala has quit IRC | 23:26 | |
*** rcernin has quit IRC | 23:26 | |
*** clsacramento has joined #openstack-keystone | 23:28 | |
ayoung | stevemar__, jamielennox can you do a `tox doc ` in keystone-specs? Mine breaks | 23:28 |
ayoung | actually, just tox breaks there now... | 23:28 |
ayoung | complaining about | 23:29 |
ayoung | Collecting feedformatter (from yasfb>=0.5.1->-r /opt/stack/keystone-specs/requirements.txt (line 9)) | 23:29 |
ayoung | this is post F25 upgrade, so I wonder if it is defaulting to python3 there... | 23:29 |
ayoung | nope 2.7 | 23:29 |
*** asettle has quit IRC | 23:30 | |
*** ravelar has quit IRC | 23:33 | |
jamielennox | did you rebuild the env after the upgrade | 23:36 |
*** spzala has joined #openstack-keystone | 23:36 | |
openstackgerrit | Morgan Fainberg proposed openstack/keystone-specs: Specification for MFA support https://review.openstack.org/405007 | 23:42 |
*** lamt has quit IRC | 23:44 | |
openstackgerrit | Ron De Rose proposed openstack/keystone: PCI-DSS Force users to immediately change their password upon first use https://review.openstack.org/403916 | 23:46 |
*** Zer0Byte__ has joined #openstack-keystone | 23:53 | |
stevemar__ | ayoung: tox -re docs to rebuild? | 23:56 |
stevemar__ | jamielennox: no harm in releasing it, i tossed up a release so your work can have a fresh slate | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!