lhcheng | ayoung: do you recall why get_trust is not raising a NotFound exception if no record is found: https://github.com/openstack/keystone/blob/master/keystone/trust/backends/sql.py#L138 | 00:08 |
---|---|---|
*** _cjones_ has quit IRC | 00:18 | |
*** henrynash has quit IRC | 00:29 | |
*** gyee has quit IRC | 00:35 | |
ayoung | lhcheng, if someone passes in a bogus trust id, what else should it do? | 00:37 |
ayoung | lhcheng, Do you mean that it looks like the code should return None, but instead throws an exception? | 00:38 |
lhcheng | ayoung: code is returning None, I wonder why it is *not raising a NotFound exception instead. | 00:39 |
ayoung | lhcheng, ah. | 00:39 |
ayoung | lhcheng, probably an oversight? I just didn't code it that way? | 00:39 |
ayoung | Maybe something later on throws the exception instead/ | 00:39 |
lhcheng | ayoung: I see is the controller is having all the checks "if not trust: raise exception" | 00:40 |
ayoung | lhcheng, I'd have to look where it was called, and see if there is any advantage to having it return None, but your logic seems correct | 00:40 |
ayoung | might have been due to some other backend? Meh | 00:40 |
ayoung | no idea, but throwing from the driver would probably be more correct | 00:41 |
lhcheng | might make sense to move all checks from controller to the backend. | 00:41 |
*** alexsyip has quit IRC | 00:42 | |
ayoung | lhcheng, Yep. DRY principle. | 00:42 |
browne | hmm, stable/juno appears broken due to pymongo | 00:42 |
browne | even though i know there was a cherry pick to fix it | 00:43 |
lhcheng | ayoung: cool, thanks. I'll propose a patch to clean that up. | 00:43 |
*** ozialien has joined #openstack-keystone | 00:44 | |
lhcheng | browne: pymongo, is already pinned in stable/juno: https://github.com/openstack/keystone/blob/stable/juno/test-requirements.txt#L15 | 00:45 |
lhcheng | browne: weird, that it is still broken.. | 00:45 |
browne | my bad, it was proposed/kilo | 00:46 |
browne | ok master has the pymongo fix, but not proposed/kilo | 00:48 |
lhcheng | browne: I believe rc2 window haven't opened up. | 00:48 |
browne | probably my misunderstanding of how proposed/ rc branches work | 00:49 |
*** browne has quit IRC | 00:56 | |
*** tqtran has quit IRC | 01:04 | |
*** ozialien has quit IRC | 01:19 | |
*** erkules_ has joined #openstack-keystone | 01:21 | |
*** erkules has quit IRC | 01:23 | |
*** browne has joined #openstack-keystone | 01:45 | |
*** diegows has quit IRC | 01:54 | |
*** davechen1 has joined #openstack-keystone | 01:54 | |
*** edmondsw has quit IRC | 02:00 | |
*** ashleighfarnham has joined #openstack-keystone | 02:05 | |
*** Raildo__ has quit IRC | 02:21 | |
*** dims_ has quit IRC | 02:28 | |
*** richm has quit IRC | 02:38 | |
*** stevemar has joined #openstack-keystone | 02:40 | |
*** ChanServ sets mode: +v stevemar | 02:40 | |
*** rm_work|away is now known as rm_work | 02:52 | |
*** rhagarty__ has joined #openstack-keystone | 02:59 | |
*** wolsen_ has joined #openstack-keystone | 03:01 | |
*** rm_work is now known as rm_work|away | 03:05 | |
*** stevemar has quit IRC | 03:06 | |
*** jdennis has quit IRC | 03:06 | |
*** rhagarty has quit IRC | 03:06 | |
*** arif-ali has quit IRC | 03:06 | |
*** wolsen has quit IRC | 03:06 | |
*** tristanC has quit IRC | 03:06 | |
*** ashleighfarnham has quit IRC | 03:09 | |
openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Checking if Trust exists should be DRY https://review.openstack.org/173158 | 03:13 |
*** tristanC has joined #openstack-keystone | 03:13 | |
*** stevemar has joined #openstack-keystone | 03:13 | |
*** jdennis has joined #openstack-keystone | 03:13 | |
*** arif-ali has joined #openstack-keystone | 03:13 | |
*** sendak.freenode.net sets mode: +v stevemar | 03:13 | |
*** lhcheng has quit IRC | 03:14 | |
*** ayoung has quit IRC | 03:14 | |
*** _cjones_ has joined #openstack-keystone | 03:19 | |
*** _cjones_ has quit IRC | 03:24 | |
stevemar | sigmavirus24_awa, i have so many questions for when you are back | 03:24 |
*** dims has joined #openstack-keystone | 03:28 | |
*** dims has quit IRC | 03:33 | |
*** lhcheng has joined #openstack-keystone | 03:36 | |
*** ChanServ sets mode: +v lhcheng | 03:36 | |
*** ajayaa has joined #openstack-keystone | 03:44 | |
*** rm_work|away is now known as rm_work | 03:52 | |
*** sdake has joined #openstack-keystone | 03:56 | |
*** harlowja is now known as harlowja_away | 03:58 | |
*** sdake_ has quit IRC | 03:58 | |
morganfainberg | lhcheng: I have not been told rc2 is open. | 03:59 |
morganfainberg | lhcheng: I have not heard rc2 windows are open. | 04:00 |
morganfainberg | browne: a bug that is a potential rc blocker just needs the appropriate kilo-rc-potential we will evaluate each bug when rc2 window opens. | 04:01 |
*** sdake_ has joined #openstack-keystone | 04:02 | |
lhcheng | morganfainberg: yup, that's what I thought. we can backport the fix bknudson made when rc2 opens. | 04:04 |
browne | morganfainberg: ok sure, but the tests on proposed/kilo are broken until bug 1441393 is cherry picked to it, no? | 04:04 |
openstack | bug 1441393 in zaqar "Keystone and Ceilometer unit tests fail with pymongo 3.0" [High,New] https://launchpad.net/bugs/1441393 - Assigned to Flavio Percoco (flaper87) | 04:04 |
*** sdake has quit IRC | 04:04 | |
morganfainberg | browne: doesn't mean we won't absolutely make that a priority ;) | 04:05 |
morganfainberg | browne: it can be proposed against the rc branch but I'll be -2 holding it until we open the window. | 04:05 |
morganfainberg | browne: I expect rc2 to open in the next couple days. | 04:05 |
morganfainberg | Hm. Is stevemar here? | 04:06 |
browne | ok so maybe i did something wrong. i cherry picked from master to proposed/kilo in https://review.openstack.org/#/c/173115/ | 04:06 |
browne | should it be -2'd | 04:06 |
openstackgerrit | Kun Huang proposed openstack/python-keystoneclient: Use "RegionOne" as default region https://review.openstack.org/173165 | 04:07 |
morganfainberg | I think the Jenkins -1 is not directly related. | 04:07 |
morganfainberg | I should -2 it. | 04:07 |
morganfainberg | You did nothing wrong. | 04:08 |
browne | oh ok. yeah probably best to -2 for now | 04:08 |
morganfainberg | And likewise brant's fix for pymongo just needs rc2 window. | 04:09 |
morganfainberg | I think we have ~4 rc blocking bugs. | 04:10 |
morganfainberg | I really need to finish this slide deck up for Thursday :P | 04:11 |
morganfainberg | lhcheng: you coming to the Sunnyvale meetup? | 04:11 |
lhcheng | morganfainberg: which meetup? I've missed the notice :P | 04:12 |
morganfainberg | lhcheng: http://www.meetup.com/openstack/events/214328842/ | 04:13 |
morganfainberg | The one I'm supposed to present something besides a slide that says "lolz identity you has it" | 04:13 |
lhcheng | morganfainberg: I haven | 04:15 |
lhcheng | I haven't attended the meetup for a while | 04:16 |
lhcheng | I attended a couple when it moved to HP campus, but it was mostly introduction track. | 04:17 |
lhcheng | morganfainberg: great to see that there'll be advanced topics! | 04:17 |
morganfainberg | This will mostly be intermediate. | 04:17 |
lhcheng | morganfainberg: I'll be there! | 04:18 |
morganfainberg | Going over the basics of keystone (act 1), multi identity setup (act 2), and federation + non-OpenStack application using Idp initiated saml to access a k2k remote resource | 04:19 |
morganfainberg | Erm s/k2k/saml protected | 04:19 |
morganfainberg | Eg something in swift | 04:19 |
morganfainberg | But I'm going to keep that last part light. | 04:20 |
stevemar | morganfainberg, yessum | 04:20 |
lhcheng | morganfainberg: I consider anything that has federation in it as advanced topic :P | 04:20 |
* jamielennox just realized how session logging is a bad idea for transferring images :( | 04:20 | |
morganfainberg | stevemar: might ask you to chair the meeting tomorrow. | 04:21 |
*** ajayaa has quit IRC | 04:21 | |
stevemar | morganfainberg, c'est bon | 04:21 |
morganfainberg | Have an errand to run around noon, but not sure if I will need to be moving earlier or not. | 04:21 |
morganfainberg | jamielennox: hmm? | 04:21 |
jamielennox | morganfainberg: i couldn't figure out why my test was running slow converting glanceclient to sessions | 04:22 |
jamielennox | because it look the whole response body, loaded it as a string and dumped it into log output | 04:22 |
morganfainberg | Lol oh god. | 04:23 |
morganfainberg | Yeah let's fix that. ;) | 04:23 |
jamielennox | yea, i can turn logging off completely but not just exclude body | 04:23 |
morganfainberg | jamielennox: I'll have time to finish the session split this week. Once I have rc2 open and this meet up out of the way. | 04:24 |
jamielennox | morganfainberg: no worries, you know i could have done it if you're swamped | 04:24 |
morganfainberg | jamielennox: eh if you want to sure. But we can't g-r it anyway yet ;) | 04:25 |
jamielennox | morganfainberg: right, i was just looking to strip out some stuff | 04:25 |
morganfainberg | jamielennox: also we need to identify anything we are back porting to the current tags for ksc/ksm. We aren't doing another release before kilo stable. | 04:25 |
jamielennox | it went from something we'll do one day to something we need in a hurry | 04:25 |
jamielennox | morganfainberg: i understand this stable policy but it's going to be annoying for ksm | 04:26 |
morganfainberg | For reasons of "God what a mess and I don't want to make people go insane". | 04:26 |
jamielennox | however i don't think there is anything more that makes much difference for this release | 04:26 |
jamielennox | i think i got the g-r bumps i wanted | 04:27 |
morganfainberg | jamielennox: think of it this way... I'm going to cap the g-r at <X where we can. Meaning if we want to break apis we do it with semver. | 04:27 |
morganfainberg | jamielennox: I'm wondering if we want to push x releases as the stables | 04:27 |
morganfainberg | We can do this | 04:27 |
morganfainberg | Make 2.x the Liberty release. | 04:28 |
morganfainberg | Think on it. No decision is needed yet. | 04:28 |
jamielennox | oooo, that's interesting | 04:28 |
jamielennox | g-r should be using ~= by default | 04:28 |
morganfainberg | We won't be able to "break" things in ksc for a few more cycles. | 04:28 |
morganfainberg | Or ever. But we can start indicating where we can do this. | 04:28 |
morganfainberg | Assume ksm is locked because the ksm requirements must play nice with the pipeline requirements. (Same interpreter) | 04:29 |
morganfainberg | Using ksm in grizzly likely would not work as much as I'd like it to be *that* compatible. | 04:29 |
morganfainberg | So maybe we really commit to semver. | 04:30 |
jamielennox | i don't think anyone will judge us on auth_token not working with grizzly | 04:30 |
morganfainberg | And if it isn't compatible (even for g-r reasons) we version it. | 04:30 |
morganfainberg | They won't. But it makes the breaking the api less bad for our users via semver | 04:30 |
morganfainberg | No one will really be able to use ksm 1.5.0 with Juno realistically. | 04:31 |
jamielennox | this progression of g-r is bad for clients | 04:31 |
morganfainberg | They will use 1.3 | 04:31 |
morganfainberg | Client cli/libs are different. | 04:31 |
jamielennox | right, if you don't need a new version of the library please don't force it on us for no reason | 04:32 |
morganfainberg | So I'm thinking we really go for it | 04:32 |
morganfainberg | If we need to break api... We increment x | 04:32 |
morganfainberg | In ksm, and for sure in keystoneauth | 04:32 |
jamielennox | so yea, keystoneauth gives us some wiggle room for sure | 04:33 |
morganfainberg | Even if it is a g-r incompat we use semver to show it. | 04:33 |
jamielennox | ksc & ksm i had given up on breaking changes | 04:33 |
morganfainberg | But I am going to be working to eliminate as many deps as we can | 04:33 |
morganfainberg | I want keystoneauth to be really lean | 04:33 |
morganfainberg | No Oslo deps if we can at all avoid it. | 04:34 |
jamielennox | morganfainberg: lol, mordred and dtroyer_zz have been onto you as well | 04:34 |
morganfainberg | For example. | 04:34 |
morganfainberg | I totally agree with them. | 04:34 |
jamielennox | me too | 04:34 |
morganfainberg | 100% | 04:34 |
morganfainberg | Didn't take much convincing fwiw ;) | 04:34 |
morganfainberg | Ksm we probably can do a breaking change with a x. Increment. Ksc we have a lot to dig ourselves out of contract wise because of the cli | 04:35 |
jamielennox | so where did you get weith keystoneauth? | 04:35 |
*** krtaylor has quit IRC | 04:35 | |
morganfainberg | jamielennox: had it all split into a repo ready to push to GitHub | 04:36 |
morganfainberg | History preserved. | 04:36 |
morganfainberg | Wanted to get it passing tests. | 04:36 |
morganfainberg | Then all the other work I wanted in gerrit. | 04:36 |
jamielennox | oh nice, i wasn't sure we'd get history | 04:36 |
morganfainberg | Oh that is why I didn't just forklift. Forklift it would already have been complete. | 04:36 |
morganfainberg | Forklift is *really* easy. | 04:36 |
morganfainberg | But I think in this case history is really important too. | 04:37 |
jamielennox | i was considering just forking keystoneclient and using gerrit to strip it | 04:37 |
*** topol has joined #openstack-keystone | 04:37 | |
*** ChanServ sets mode: +v topol | 04:37 | |
morganfainberg | That's effectively what I was going to do just with nifty it tools | 04:37 |
lhcheng | morganfainberg: you're a celebrity, haven't seen this much people signed up for the openstack meetup :P | 04:37 |
jamielennox | but if you preserved history that's better | 04:37 |
morganfainberg | jamielennox: both would preserve history but my way only holds history on the files we have in the repo. | 04:38 |
morganfainberg | lhcheng: thanks. I needed the anxiety ;) | 04:38 |
jamielennox | right, forking gives us all the CRUD history | 04:38 |
morganfainberg | jamielennox: and I really would rather rewrite that history out. | 04:38 |
*** krtaylor has joined #openstack-keystone | 04:38 | |
morganfainberg | If it becomes a rush, I don't care. | 04:38 |
morganfainberg | It's a days work to have it in a repo on github. | 04:39 |
morganfainberg | Probably another day to get tests working. | 04:39 |
lhcheng | morganfainberg: lol we got your back! | 04:39 |
jamielennox | morganfainberg: ok | 04:40 |
morganfainberg | jamielennox: I figure if ksc can replace its import with "from keystoneauth import" and pass its tests I'm happy | 04:40 |
morganfainberg | We can play "shred things out" in gerrit. | 04:40 |
morganfainberg | The retrofit stuff back in before making it the ksc dep. | 04:40 |
morganfainberg | Retrofit in ksc that is. | 04:41 |
jamielennox | can we put a branch on ksc that has keystoneauth from gerrit as a dep or something? | 04:41 |
morganfainberg | Yep. | 04:41 |
jamielennox | excellent | 04:41 |
morganfainberg | Put it in tox.ini as a dep ;) | 04:41 |
morganfainberg | Then g-r it when it's ready. | 04:42 |
jamielennox | oh g-r won't run on the branch - or we just turn it of | 04:42 |
jamielennox | f | 04:42 |
morganfainberg | Nah have a dodge for that ;) | 04:42 |
morganfainberg | We dodge g-r for that test branch | 04:42 |
jamielennox | does keystoneauth become ka - doesn't look quite right | 04:42 |
jamielennox | ksa | 04:42 |
morganfainberg | Kal? Keystoneauth lib | 04:42 |
morganfainberg | Ksa also works. | 04:43 |
morganfainberg | Btw: you get to write the readme on ksa. | 04:43 |
jamielennox | lol | 04:43 |
morganfainberg | Or I'm copy-pasta your blog post on sessions. :P | 04:43 |
jamielennox | yep, that's needed doing for a while, but at least it can start fresh rather than try to figure out how to squeeze it in amonst existing doc | 04:43 |
morganfainberg | Exactly. | 04:44 |
morganfainberg | lhcheng: tomorrow mind looking through lp bugs for keystone and making sure we have no rc-critical ones? | 04:44 |
morganfainberg | We need to do another round of triage. | 04:45 |
morganfainberg | But rc ones first. | 04:45 |
lhcheng | morganfainberg: sure, will do. | 04:45 |
stevemar | lhcheng, triage them all as non-critical | 04:45 |
jamielennox | lhcheng: btw, i've got reviews up adding doa-kerberos to governance and gerrit with horizon ownership - which means i might need to bug you about things needed doing as horizon-core | 04:47 |
jamielennox | this dual core thing is going to turn out very useful :) | 04:47 |
lhcheng | stevemar: wait, I only have to triage those "new" lp bugs right? | 04:48 |
lhcheng | jamielennox: lol I kinda expected that. :) glad to help with that. | 04:48 |
* lhcheng still have kerberos on things to-do | 04:52 | |
*** tobberydberg has joined #openstack-keystone | 05:03 | |
*** erkules_ is now known as erkules | 05:07 | |
*** erkules has joined #openstack-keystone | 05:07 | |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Make process_header private https://review.openstack.org/173171 | 05:08 |
*** tobberydberg has quit IRC | 05:08 | |
*** ajayaa has joined #openstack-keystone | 05:08 | |
morganfainberg | jamielennox: I'd like to get you core on doa if possible. Let's talk to david about making that its own team. Inherits horizon but allows specialists to jump in and help push things through. | 05:10 |
morganfainberg | jamielennox: I know we have lhcheng now too, but more the merrier. Unless you don't want it. | 05:10 |
morganfainberg | But another passing thought. | 05:11 |
jamielennox | morganfainberg: i know it fairly well now, the real challenge is going to be making horizon use what DOA sets up | 05:11 |
jamielennox | but that's up to horizon for obvious reasons | 05:11 |
morganfainberg | Right. | 05:11 |
morganfainberg | Hm. | 05:13 |
*** ishant has joined #openstack-keystone | 05:14 | |
lhcheng | morganfainberg: that makes sense.. reviews on doa are usually just between david-lyle and me, any additional reviews would definitely help. | 05:26 |
morganfainberg | Yeah. I think it makes sense. | 05:27 |
morganfainberg | Let's bug David tomorrow. Silly simple change | 05:27 |
morganfainberg | But doa is sufficiently different we might as well get interested parties in on it. | 05:28 |
* morganfainberg has no interest in being doa core. Or owning doa | 05:28 | |
morganfainberg | ;) | 05:28 |
morganfainberg | I'd rather it be over in david-lyle 's hands. And people smarter than me at django. | 05:28 |
*** rushiagr_away is now known as rushiagr | 05:33 | |
lhcheng | doa is the link between django and KSC, would definitely benefit having KSC expert on it. | 05:33 |
lhcheng | agreed, let's bug David tomorrow. | 05:34 |
morganfainberg | Oh I hope ksc dies in doa. We should be able to move it to keystoneauth this cycle since keystoneauth will be the "new hotness" :) | 05:35 |
*** kiran_ has joined #openstack-keystone | 05:37 | |
*** topol has quit IRC | 05:38 | |
*** kiran_ is now known as kiran-r | 05:39 | |
lhcheng | umm new treats.. :) | 05:39 |
lhcheng | morganfainberg: that the version-less auth endpoint? | 05:41 |
openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex https://review.openstack.org/172624 | 06:05 |
*** krtaylor has quit IRC | 06:11 | |
*** krtaylor has joined #openstack-keystone | 06:22 | |
*** jdennis1 has joined #openstack-keystone | 06:30 | |
*** jdennis has quit IRC | 06:31 | |
*** Nikkau has joined #openstack-keystone | 06:37 | |
*** tobberydberg has joined #openstack-keystone | 06:42 | |
*** henrynash has joined #openstack-keystone | 06:50 | |
*** ChanServ sets mode: +v henrynash | 06:50 | |
*** trey has quit IRC | 06:53 | |
*** trey has joined #openstack-keystone | 06:59 | |
*** jamielennox is now known as jamielennox|away | 07:02 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Remove project association before removing endpoint group https://review.openstack.org/173192 | 07:03 |
*** Nikkau has quit IRC | 07:06 | |
*** stevemar has quit IRC | 07:09 | |
*** chlong has quit IRC | 07:27 | |
*** jistr has joined #openstack-keystone | 07:29 | |
*** krykowski has joined #openstack-keystone | 07:33 | |
*** pnavarro has joined #openstack-keystone | 07:38 | |
*** lhcheng has quit IRC | 07:47 | |
*** browne has quit IRC | 07:50 | |
*** fhubik_afk has joined #openstack-keystone | 07:54 | |
*** dims has joined #openstack-keystone | 08:07 | |
*** dims has quit IRC | 08:12 | |
*** davechen1 has quit IRC | 08:16 | |
*** davechen has joined #openstack-keystone | 08:16 | |
*** davechen1 has joined #openstack-keystone | 08:19 | |
*** davechen has quit IRC | 08:22 | |
*** sdake has joined #openstack-keystone | 08:22 | |
*** davechen has joined #openstack-keystone | 08:23 | |
openstackgerrit | Kun Huang proposed openstack/python-keystoneclient: Use "RegionOne" as default region https://review.openstack.org/173165 | 08:23 |
*** davechen1 has quit IRC | 08:25 | |
*** henrynash has quit IRC | 08:26 | |
*** sdake_ has quit IRC | 08:26 | |
*** sdake has quit IRC | 08:30 | |
*** fhubik_afk has quit IRC | 08:31 | |
*** fhubik has quit IRC | 08:31 | |
*** fhubik has joined #openstack-keystone | 08:32 | |
*** lhcheng has joined #openstack-keystone | 08:47 | |
*** ChanServ sets mode: +v lhcheng | 08:47 | |
*** lhcheng has quit IRC | 08:53 | |
*** aix has quit IRC | 08:53 | |
*** jaosorior has joined #openstack-keystone | 08:53 | |
*** henrynash has joined #openstack-keystone | 09:03 | |
*** ChanServ sets mode: +v henrynash | 09:03 | |
*** henrynash has quit IRC | 09:08 | |
*** henrynash has joined #openstack-keystone | 09:10 | |
*** ChanServ sets mode: +v henrynash | 09:10 | |
*** aix has joined #openstack-keystone | 09:20 | |
*** amakarov_away is now known as amakarov | 09:22 | |
openstackgerrit | Dave Chen proposed openstack/keystone: Remove project association before removing endpoint group https://review.openstack.org/173192 | 09:43 |
openstackgerrit | Dave Chen proposed openstack/keystone: Remove project association before removing endpoint group https://review.openstack.org/173192 | 09:46 |
*** davechen has left #openstack-keystone | 09:53 | |
*** lifeless1 has joined #openstack-keystone | 09:54 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 10:00 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis token backend https://review.openstack.org/150844 | 10:02 |
*** lifeless has quit IRC | 10:02 | |
*** harlowja_away has quit IRC | 10:02 | |
*** fhubik is now known as fhubik_afk | 10:27 | |
openstackgerrit | Endre Karlson proposed openstack/python-keystoneclient: Allow for other then STABLE api version https://review.openstack.org/130159 | 10:34 |
*** lhcheng has joined #openstack-keystone | 10:37 | |
*** ChanServ sets mode: +v lhcheng | 10:37 | |
*** davidckennedy has joined #openstack-keystone | 10:39 | |
*** lhcheng has quit IRC | 10:41 | |
davidckennedy | henrynash the endpoint enforcement PS Bob Thyne was working on at https://review.openstack.org/#/c/153296/ is now in a fit state for review, I believe. | 10:42 |
henrynash | ok, will take a look thx | 10:42 |
davidckennedy | thank you. | 10:43 |
*** ishant has quit IRC | 10:50 | |
*** dims has joined #openstack-keystone | 10:54 | |
*** lsmola_ has joined #openstack-keystone | 10:58 | |
openstackgerrit | Merged openstack/keystone: Add routing for list_endpoint_groups_for_project https://review.openstack.org/167939 | 10:58 |
*** dims has quit IRC | 10:58 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 11:20 |
henrynash | davidkennedy: ping | 11:21 |
*** Nikkau has joined #openstack-keystone | 11:25 | |
*** topol has joined #openstack-keystone | 11:27 | |
*** ChanServ sets mode: +v topol | 11:27 | |
*** aix has quit IRC | 11:32 | |
*** aix has joined #openstack-keystone | 11:33 | |
openstackgerrit | Kamil Rykowski proposed openstack/oslo.policy: Fix invalid indentation in _load_policy_file method https://review.openstack.org/173275 | 11:40 |
*** fhubik_afk is now known as fhubik | 11:42 | |
*** tobberyd_ has joined #openstack-keystone | 11:42 | |
*** tobberydberg has quit IRC | 11:46 | |
*** jistr is now known as jistr|class | 11:47 | |
openstackgerrit | henry-nash proposed openstack/keystone: Use correct LOG translation indicator for warnings https://review.openstack.org/167124 | 11:54 |
*** Nikkau has quit IRC | 12:00 | |
*** henrynash has quit IRC | 12:11 | |
*** jdennis1 has quit IRC | 12:11 | |
*** fhubik is now known as fhubik_afk | 12:13 | |
*** fhubik_afk is now known as fhubik | 12:16 | |
*** davechen1 has joined #openstack-keystone | 12:16 | |
*** kiran-r has quit IRC | 12:18 | |
*** jdennis has joined #openstack-keystone | 12:21 | |
*** pnavarro is now known as pnavarro|off | 12:22 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 12:24 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis token backend https://review.openstack.org/150844 | 12:30 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 12:30 |
*** bdossant has joined #openstack-keystone | 12:32 | |
*** henrynash has joined #openstack-keystone | 12:35 | |
*** ChanServ sets mode: +v henrynash | 12:35 | |
*** gordc has joined #openstack-keystone | 12:36 | |
*** trey has quit IRC | 12:41 | |
*** lhcheng has joined #openstack-keystone | 12:43 | |
*** ChanServ sets mode: +v lhcheng | 12:43 | |
*** ajayaa has quit IRC | 12:45 | |
*** trey has joined #openstack-keystone | 12:47 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 12:50 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 12:50 |
*** dims has joined #openstack-keystone | 12:51 | |
*** markvoelker has joined #openstack-keystone | 13:00 | |
*** mitz has quit IRC | 13:01 | |
*** ozialien has joined #openstack-keystone | 13:02 | |
*** jistr|class is now known as jistr | 13:03 | |
openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Checking if Trust exists should be DRY https://review.openstack.org/173158 | 13:03 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 13:04 |
*** mitz has joined #openstack-keystone | 13:04 | |
*** markvoelker_ has joined #openstack-keystone | 13:06 | |
*** richm has joined #openstack-keystone | 13:07 | |
*** markvoelker has quit IRC | 13:09 | |
*** ozialien_ has joined #openstack-keystone | 13:12 | |
*** ozialien has quit IRC | 13:12 | |
*** ozialien_ is now known as ozialien | 13:12 | |
rodrigods | henrynash is on review mode! | 13:13 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 13:13 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 13:13 |
henrynash | rodigods: :-) | 13:14 |
*** topol has quit IRC | 13:15 | |
raildo | rodrigods, ++ hah | 13:16 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 13:20 |
*** ozialien has quit IRC | 13:23 | |
rodrigods | henrynash, replied your comments... will wait to send another patch set :) | 13:24 |
openstackgerrit | Dave Chen proposed openstack/keystone: Minor change in the docstring https://review.openstack.org/172329 | 13:26 |
ccard | which is the best channel to ask questions about quickstack and keystone? | 13:30 |
*** dims has quit IRC | 13:31 | |
*** dims has joined #openstack-keystone | 13:32 | |
*** ajayaa has joined #openstack-keystone | 13:33 | |
*** sdake has joined #openstack-keystone | 13:35 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 13:37 | |
*** lhcheng has quit IRC | 13:38 | |
*** nkinder has joined #openstack-keystone | 13:39 | |
*** sdake has quit IRC | 13:40 | |
*** rushil has joined #openstack-keystone | 13:41 | |
*** fhubik is now known as fhubik_afk | 13:42 | |
*** rushiagr is now known as rushiagr_away | 13:44 | |
*** fhubik_afk is now known as fhubik | 13:44 | |
amakarov | dstanek, hi! Addressed your comments (sorry, haven't noticed them before) https://review.openstack.org/173000 | 13:45 |
*** ajayaa has quit IRC | 13:49 | |
*** joesavak has joined #openstack-keystone | 13:50 | |
*** Ephur has joined #openstack-keystone | 13:51 | |
*** r-daneel has joined #openstack-keystone | 13:52 | |
*** fhubik is now known as fhubik_afk | 13:52 | |
*** fhubik_afk is now known as fhubik | 13:52 | |
*** Ephur_ has joined #openstack-keystone | 13:52 | |
*** ayoung_ has joined #openstack-keystone | 13:53 | |
rodrigods | henrynash, so you prefer to not delete projects that are domains unless they are leaf, right? | 13:54 |
henrynash | rodigods: well, I was more reacting to the statement taht we’d never hit a domin with recurxive delete | 13:55 |
henrynash | rodigods: and with a top level hierachy of projects with is_domain=True set….you clearly could hit a “domain” | 13:55 |
henrynash | I’m open to what we propose we support, just want us to clear | 13:55 |
*** ashleighfarnham has joined #openstack-keystone | 13:56 | |
rodrigods | henrynash, I was being specific for projects (with is_Domain false) only | 13:56 |
*** Ephur has quit IRC | 13:56 | |
rodrigods | maybe wasn't clear enough? | 13:56 |
*** sdake has joined #openstack-keystone | 13:57 | |
henrynash | rodigods: ah…but I don’t think going forward that’s a clear enough distinction…everything will be a project, just some of them will also be acting as domainds | 13:57 |
*** Ephur_ is now known as Ephur | 13:58 | |
rodrigods | henrynash, we can't have domains that are children of "pure" projects | 13:58 |
henrynash | rodigods; I think in Liberty, we’ll really be deprecating the “pure” domain concept…. | 13:58 |
henrynash | rodigods: agreed | 13:58 |
henrynash | (hey, we both used pure at the same time!_ | 13:59 |
rodrigods | (heh noticed too!) | 13:59 |
henrynash | so are you assuming you can issue the /cascade delete on a project with is_domain=True? | 13:59 |
rodrigods | henrynash, no... that if issue the /cascade on a "pure" project it will only have effect to "pure" projects | 14:00 |
*** dims has quit IRC | 14:00 | |
rodrigods | henrynash, that's the idea of that paragraph... | 14:00 |
*** dims has joined #openstack-keystone | 14:00 | |
rodrigods | because someone may be concerned about hitting a domain when using /cascade on a project | 14:00 |
henrynash | i agree with that…but is issuing it on a project acting as domain supported? | 14:01 |
rodrigods | henrynash, yes... | 14:01 |
*** rushiagr_away is now known as rushiagr | 14:01 | |
*** browne has joined #openstack-keystone | 14:02 | |
henrynash | ok, so in that case…..you *could* hit a domain, since theere could be one immediatly underneath you with is_domain=True as well | 14:02 |
*** ajayaa has joined #openstack-keystone | 14:02 | |
henrynash | that was my only point….when we say “project” now….I don’t think it implicitely means a pure project, it could be either | 14:03 |
rodrigods | henrynash, ok... so will make clear that hitting in a pure project can only affect pure projects | 14:03 |
rodrigods | and hitting on a domain can affect both | 14:04 |
*** ayoung_ has quit IRC | 14:04 | |
rodrigods | agreed? | 14:04 |
henrynash | yes….and probably need to be clear whether what happens if I have N levels of projects acting as domains beneath the point you issue teh command…so we support that and recursively delete all the sub project-domains” as well? eeek! | 14:05 |
henrynash | sounds scary to me | 14:05 |
henrynash | which was my point about a leaf project-domain | 14:05 |
rodrigods | my idea was to permit only to "cloud_admins" | 14:06 |
rodrigods | the god of the cloud heh | 14:06 |
henrynash | well, that’s a policy descsion, not an API decision | 14:06 |
rodrigods | yes... so why we'd limit the API if it is possible to properly prohibit the action in the policy | 14:06 |
rodrigods | but... as first step I'd agree to leave only for "leaf domains" | 14:07 |
henrynash | understand the principle, but in practice we never encode policy rules (or roles) into our code.... | 14:07 |
henrynash | I think that maybe that might be wise :-) | 14:08 |
rodrigods | ++ | 14:08 |
rodrigods | will update the spec | 14:08 |
*** topol has joined #openstack-keystone | 14:13 | |
*** ChanServ sets mode: +v topol | 14:13 | |
*** davechen1 has left #openstack-keystone | 14:13 | |
*** mattamizer has joined #openstack-keystone | 14:18 | |
*** markvoelker has joined #openstack-keystone | 14:19 | |
*** markvoelker_ has quit IRC | 14:19 | |
*** ayoung_ has joined #openstack-keystone | 14:19 | |
*** mattfarina has joined #openstack-keystone | 14:21 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 14:22 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 14:22 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 14:29 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 14:29 |
*** stevemar has joined #openstack-keystone | 14:30 | |
*** ChanServ sets mode: +v stevemar | 14:30 | |
*** zzzeek has joined #openstack-keystone | 14:30 | |
sigmavirus24 | stevemar: I saw you had questions | 14:30 |
stevemar | sigmavirus24, yep, regarding glanceclient and another for requests. i'll write them out in a few minutes, just doing a few things right now | 14:31 |
*** diegows has joined #openstack-keystone | 14:31 | |
sigmavirus24 | stevemar: there are fixes in play for glanceclient 0.16.1 if that's breaking nova for you | 14:31 |
*** pnavarro|off is now known as pnavarro|mtg | 14:32 | |
stevemar | sigmavirus24, nah, was around how images are listed | 14:41 |
sigmavirus24 | oooooh | 14:42 |
stevemar | sigmavirus24, looking at the v2.images.list or v1.images.list, both seem to set 'limit' by default | 14:42 |
sigmavirus24 | Also, re requests, #python-requests is a good welcoming place | 14:42 |
stevemar | but when i do a list images, glance's CLI seems to go past that limit | 14:43 |
*** bknudson has joined #openstack-keystone | 14:43 | |
*** ChanServ sets mode: +v bknudson | 14:43 | |
stevemar | rgr that, re: requests | 14:43 |
sigmavirus24 | stevemar: hm | 14:44 |
mattamizer | hello all, is there any plan to support a password reset through the API? | 14:44 |
stevemar | sigmavirus24, let me link you a bug and review | 14:44 |
stevemar | mattamizer, keystone does support password updates, but not resets | 14:45 |
stevemar | mattamizer, there are no plans to make the identity portion of keystone any better. we don't want to be an identity provider | 14:45 |
mattamizer | stevemar: update isn't really an option for us because we want Member users to be able to update their own passwords but not their domain | 14:45 |
stevemar | sigmavirus24, review: https://review.openstack.org/#/c/172763/ bug is attached | 14:46 |
*** jeffDeville has joined #openstack-keystone | 14:46 | |
mattamizer | so it is not supported, nor are there plans to eventually support it | 14:46 |
sigmavirus24 | stevemar: looking | 14:47 |
mattamizer | if that's the case, are there any plans to support custom TTL for tokens? | 14:47 |
*** stevemar has quit IRC | 14:49 | |
*** stevemar has joined #openstack-keystone | 14:49 | |
*** ChanServ sets mode: +v stevemar | 14:49 | |
morganfainberg | mattamizer: users can update their own passwords. | 14:51 |
morganfainberg | mattamizer: there is an api for that. No plans currently for a "reset" | 14:51 |
*** thedodd has joined #openstack-keystone | 14:52 | |
morganfainberg | mattamizer: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#change-user-password | 14:54 |
dstanek | reset seems more like something horizon would have to handle | 14:54 |
*** tobberydberg has joined #openstack-keystone | 14:55 | |
morganfainberg | dstanek: except horizon does not have admin rights. We would need an api and an exchange method (eg email) among other things. We said the sql backend is a toy, therefore it won't be improved. Most real idps have reset functionality (eg AD, freeipa, etc) | 14:56 |
morganfainberg | And we don't track email or other PII in keystone as first order attributes. | 14:57 |
morganfainberg | Another issue with "reset" | 14:57 |
*** nkinder has quit IRC | 14:58 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 14:58 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 14:58 |
*** jeffDeville has quit IRC | 14:58 | |
*** tobberyd_ has quit IRC | 14:59 | |
dstanek | morganfainberg: yeah, since email isn't first class you couldn't do a reset because otherwise it would be a security hole | 14:59 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 15:00 |
*** fhubik has quit IRC | 15:00 | |
*** tobberydberg has quit IRC | 15:00 | |
dstanek | reset functionality is really nothing more then a bearer token sent to a know (and hopefully secure) location for single time use | 15:00 |
rodrigods | morganfainberg, is the reseller branch idea going to be put in practice? | 15:01 |
*** ozialien has joined #openstack-keystone | 15:01 | |
openstackgerrit | Tristan Cacqueray proposed openstack/keystonemiddleware: Fix s3_token middleware parsing insecure option https://review.openstack.org/173365 | 15:01 |
morganfainberg | rodrigods: need to bug jogo. | 15:01 |
*** rushil_ has joined #openstack-keystone | 15:01 | |
morganfainberg | Not sure. Everyone is swamped with rc and gate ATM | 15:02 |
*** rushil has quit IRC | 15:02 | |
rodrigods | morganfainberg, k | 15:02 |
*** jeffDeville has joined #openstack-keystone | 15:03 | |
*** joesavak has quit IRC | 15:04 | |
mattamizer | morganfainberg: the issue is we don't have their original password in all cases | 15:05 |
morganfainberg | mattamizer: the user should be able to use that api. | 15:06 |
morganfainberg | It was designed so the admin would use a user update and the user would use he password change api | 15:06 |
morganfainberg | Because the admin shouldn't know the user's password. | 15:06 |
mattamizer | but if they don't know or have forgotten their original password we cannot use it, our hope was to provide reset for such a case | 15:06 |
morganfainberg | We don't have a secure way to do that. | 15:07 |
morganfainberg | And keystone shouldn't be emailing things out. | 15:07 |
*** _cjones_ has joined #openstack-keystone | 15:07 | |
morganfainberg | It would be really easy to have a reset service that knows the PII for the user (email etc) and their keystone user. If they pass the validate stage it can use super admin powers to update the password. | 15:08 |
mattamizer | PII? | 15:08 |
dstanek | personally identifiable information | 15:09 |
openstackgerrit | Tristan Cacqueray proposed openstack/python-keystoneclient: Fix s3_token middleware parsing insecure option https://review.openstack.org/173370 | 15:09 |
mattamizer | dstanek: thanks! | 15:09 |
morganfainberg | Unless we have some real work done on the sql backend and/or identity management crud (which involves things such as supporting encryption of personally identifiable information -[pii]) it's something I'd like to avoid keystone being responsible for. | 15:09 |
mattamizer | ok, so the path forward is some external service that does the magic | 15:10 |
mattamizer | thanks morganfainberg, that should be enough for us to go on :) | 15:10 |
morganfainberg | It really comes down to security. We don't have support to make a "reset" secure in keystone. And it may not be a good idea to put that ability inside keystone. | 15:10 |
dstanek | is this in regards to a bug/blueprint? | 15:11 |
morganfainberg | mattamizer: especially if you have a separate customer db, where you know their users/user id/ how to contact them, etc | 15:11 |
morganfainberg | mattamizer: then you can ensure it is really who they say they are :) | 15:11 |
mattamizer | yeah, I'm picking up what you're putting down :) | 15:11 |
morganfainberg | Long term I want to see keystone's identity management crud be separate - and not let any PII leak to the other services consuming authz from keystone. | 15:12 |
mattamizer | makes sense | 15:13 |
morganfainberg | It's hopes, wishes, and dreams. But I'd like to see it. | 15:13 |
*** ayoung_ has quit IRC | 15:13 | |
dolphm | +1 | 15:13 |
morganfainberg | But for the most part you need 3 things for authz in openstack: user id, scope id (domain / project), and roles | 15:14 |
*** ozialien has quit IRC | 15:14 | |
morganfainberg | Almost nothing else should be in the token** | 15:14 |
morganfainberg | ** some extra control things live there but they aren't about authz specifically but related to controls on authz | 15:14 |
mattamizer | will custom TTL on tokens be supported at some point, then? | 15:14 |
morganfainberg | Custom ttl as in? | 15:15 |
morganfainberg | User requested ttl? | 15:15 |
dstanek | if we had a good strategy for dealing with the existing APIs then i don't think it would be hard to separate | 15:15 |
mattamizer | or one we set based on role data coming from wherever | 15:15 |
mattamizer | so admin role TTL = x, Member = y, etc | 15:15 |
morganfainberg | mattamizer: ah role based ttl. Not opposed to talking about it. | 15:16 |
morganfainberg | No current plans. | 15:16 |
morganfainberg | I do not want a user to be able to change the ttl. | 15:16 |
morganfainberg | Per token that is " my first token is ttl x, next time I get ttl y" | 15:16 |
morganfainberg | Cause I want it. | 15:17 |
mattamizer | so ideally for us we want API tokens that never expire, but web tokens that do | 15:17 |
mattamizer | so for automated scripts we have a token the we can be certain will work | 15:17 |
sigmavirus24 | so stevemar, looking at https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L88 I think I see your problem | 15:17 |
mattamizer | but web based tokens will expire with certainty after X time has elapsed | 15:17 |
morganfainberg | mattamizer: what if we supported x509 client cert auth instead of endless ttl tokens? | 15:17 |
morganfainberg | Client cert is used in lieu of a token. | 15:18 |
morganfainberg | There is an initiative to do that fwiw. | 15:18 |
mattamizer | that'd be fine for sure | 15:18 |
morganfainberg | Non-expiring tokens are inherently insecure. | 15:19 |
morganfainberg | Since tokens are bearer tokens. | 15:19 |
mattamizer | really we just need support for automation that doesn't require constantly getting new tokens because ours are only good for an hour | 15:19 |
mattamizer | x509 would work just fine :) | 15:19 |
morganfainberg | X509 could solve this since it is less likely someone can steal the private key and the cert from | 15:19 |
morganfainberg | Inspecting traffic / logs / etc | 15:19 |
mattamizer | indeed so | 15:20 |
mattamizer | any idea on if that initiative will get any traction? and if so what the timeline would look like for getting that into the codebase? | 15:20 |
stevemar | sigmavirus24, oh, whats thats? | 15:20 |
morganfainberg | The other initiative is a session token (unscoped) that you can keep alive for longer than the default ttl (ask for extensions). That token can only work with keystone. You can then just ask for a scoped token anytime you need it (short ttl) | 15:21 |
sigmavirus24 | So previously we didn't send a page_size and now we always send one, (we default to a global DEFAULT) | 15:21 |
sigmavirus24 | And we do it all the time, so you can't even pass page_size=None to prevent that from happening | 15:21 |
mattamizer | morganfainberg: I think x509 would be preferable to that | 15:21 |
morganfainberg | mattamizer: the x509 stuff is planned this cycle at least for service users (how nova talks to keystone to validate a token) | 15:21 |
sigmavirus24 | We also, I think, always pass a limit in that method which can be the page_size | 15:21 |
morganfainberg | mattamizer: the options are not mutually exclusive. The session token works well for real users too. | 15:22 |
stevemar | sigmavirus24, yeah, it definitely always adds a limit now | 15:22 |
sigmavirus24 | stevemar: there's also https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L129 | 15:22 |
mattamizer | so is Liberty the target for that, then? | 15:23 |
morganfainberg | mattamizer: using an x509 cert directly with an endpoint is a bit more difficult because auth_token middleware doesn't know x509. But at the very least it is likely you can do x509 to keystone any time you need to this cycle for a new token. | 15:23 |
tristanC | Hi folks, I've submitted fix for bug 1411063 using this changeId: Id674f40532215788675c97a8fdfa91d4420347b3 | 15:23 |
openstack | bug 1411063 in keystonemiddleware "S3token incorrect condition expression for ssl_insecure (CVE-2015-1852)" [Critical,In progress] https://launchpad.net/bugs/1411063 - Assigned to Tristan Cacqueray (tristan-cacqueray) | 15:23 |
mattamizer | morganfainberg: that's great | 15:23 |
morganfainberg | tristanC: saw it. On the short list to hit - provided we can land code (had issues with stable branches) | 15:23 |
sigmavirus24 | that list method is terrible too stevemar | 15:24 |
sigmavirus24 | so I'm sorry it's so cryptic | 15:24 |
morganfainberg | tristanC: we will also need to backport to a 1.5.x minor release for stable branches. I'll make sure we look at that today. | 15:24 |
morganfainberg | And I think 1.3.x? | 15:25 |
sigmavirus24 | stevemar: if limit is None, then we make the request with the filters defined (where we set limit to page_size) and always use teh URL https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L100 | 15:25 |
morganfainberg | mattamizer: I know hp wants x509 support. So we have some engineering behind it for Liberty. :) | 15:25 |
sigmavirus24 | stevemar: so yeah, the problem is that we default the limit to the page_size | 15:26 |
sigmavirus24 | (And that's on the v2 side) | 15:26 |
mattamizer | morganfainberg: excellent :) | 15:26 |
stevemar | sigmavirus24, it's also defaulted on the v1 side :) | 15:26 |
*** ayoung_ has joined #openstack-keystone | 15:26 | |
sigmavirus24 | stevemar: yeah I hadn't looked there yet ;) | 15:26 |
tristanC | morganfainberg: as far as I know, security fix are only required on master and stable branches... It's still a bit fuzzy to me how to handle 1.3.x | 15:27 |
morganfainberg | tristanC: 1.3.x is stable/icehouse 1.5.x is Juno I think. | 15:27 |
morganfainberg | Oh wait no | 15:27 |
stevemar | sigmavirus24, was that change recently added? cause using the installed/latest version from pypi, performing a list returns >30 images | 15:27 |
morganfainberg | No icehouse stable. 1.3.x is Juno. | 15:27 |
stevemar | but using osc, it returns only 25 images | 15:28 |
bknudson | I was wondering about that... we'll have fix in 1.3.1 and 1.6 but not 1.4.1? | 15:28 |
morganfainberg | tristanC: this happened like Friday. | 15:28 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 15:28 |
morganfainberg | bknudson: I think we're going to do 2.x for Liberty. | 15:28 |
bknudson | patching every release seems like overkill | 15:28 |
tristanC | also by the way, I had trouble to submit this change for those new stable branch as they are not referenced in their .gitreview I had to specify them manually on "git review" comment | 15:28 |
*** diegows has quit IRC | 15:28 | |
sigmavirus24 | stevemar: you mean, doing "glance image-list" will return > 30 images? | 15:28 |
stevemar | sigmavirus24, yep | 15:28 |
morganfainberg | bknudson: so we semver for the major releases. | 15:28 |
sigmavirus24 | stevemar: it was added in the last ~1-2 months | 15:29 |
morganfainberg | bknudson: it's .. Not as clean as releas whenever. But at least we know the maintenance cycle. | 15:29 |
sigmavirus24 | stevemar: actually I'm wrong: https://github.com/openstack/python-glanceclient/commit/93c9bc1fe0ae3f5c95395e7a883fdffcc79d7151#diff-de2b001e2b66bb4fe4d42d7ce575567f | 15:29 |
morganfainberg | bknudson: unless you have a good reason we shouldn't do that. | 15:30 |
bknudson | morganfainberg: why 2.x? are we removing function? | 15:30 |
sigmavirus24 | stevemar: looks like that first went into 0.16.0 | 15:30 |
*** krykowski has quit IRC | 15:31 | |
morganfainberg | No, because it (due to g-r) likely won't be compat with kilo. And because we then can do backports as needed. | 15:31 |
bknudson | We're incrementing minor for dependency changes. | 15:31 |
morganfainberg | 2.x is Liberty, 1.3.x is Juno (the special case), 1.5.x++ = kilo | 15:32 |
bknudson | why not call it 2015.1? | 15:32 |
morganfainberg | Because this is where I get to be ptl and say I hate that versioning scheme ;) | 15:32 |
bknudson | I think dhellmann was going to go with a minor change for L. | 15:32 |
bknudson | you mentioned 1.3 and 1.5, what about 1.4? | 15:33 |
morganfainberg | Honestly you can't expect anything past the Juno ship to work with Juno services. | 15:33 |
morganfainberg | Ksm might as well just be shipped as the 2015.x "Juno" or whatever. | 15:33 |
ayoung_ | henrynash, you already +2ed this, but he did a minor cleanup. Wanna do the honors? https://review.openstack.org/#/c/173158/ | 15:33 |
morganfainberg | Keystone client is the weird one. | 15:34 |
bknudson | with the stable branches we can actually remove function and have a ksc 2.0 | 15:34 |
morganfainberg | bknudson: we should actually make ksm just follow the release like everyone else. | 15:34 |
bknudson | for example we could get rid of the auth_token middleware. | 15:34 |
morganfainberg | Ksc "stable" branches is for gate I think. | 15:34 |
stevemar | sigmavirus24, i'm still not seeing a way to tell glance "give me all the images" | 15:34 |
morganfainberg | bknudson: I really want to do that. | 15:34 |
*** ayoung_ is now known as ayoung | 15:34 | |
sigmavirus24 | stevemar: me too | 15:34 |
morganfainberg | bknudson: and drop the cli | 15:35 |
bknudson | oooh! | 15:35 |
henrynash | ayoung: looking | 15:35 |
sigmavirus24 | stevemar: I think I'm going to ask in #openstack-glance since I'm still half-dead from yesterday | 15:35 |
sigmavirus24 | stevemar: care to join me? | 15:35 |
morganfainberg | bknudson: and when keystoneauth becomes split out, session etc too | 15:35 |
stevemar | sigmavirus24, of course | 15:35 |
morganfainberg | bknudson: but I was told "don't do that" put breaking changes in sdk | 15:35 |
morganfainberg | So unless we make Python-keystoneclient2 I think we lose here. :( | 15:36 |
bknudson | morganfainberg: auth_token isn't going to be in sdk. | 15:36 |
henrynash | ayoung: done | 15:36 |
bknudson | keystone CLI isn't going to be in sdk. | 15:36 |
morganfainberg | bknudson: but keystone client will just die with sdk, right? | 15:36 |
morganfainberg | Actually I'm ok dropping auth_token this cycle from ksc. You can't run modern ksc auth_token in grizzly etc, | 15:37 |
bknudson | I guess so... need to start working on sdk like crazy then. | 15:37 |
morganfainberg | The requirements conflicts prevent it. | 15:37 |
stevemar | yeah, it'll be a metric ton of things | 15:37 |
morganfainberg | We're safe dropping it | 15:37 |
morganfainberg | bknudson: for ksm, we should probably move it to standard named release | 15:39 |
morganfainberg | Since it is really only compatible with the release it shipped with. | 15:39 |
morganfainberg | Meaning... Dropping semver | 15:39 |
bknudson | ... we've got some work to do to get keystoneclient stable/icehouse working. | 15:40 |
morganfainberg | Since it uses the same interpreter as the service (aka nova) | 15:40 |
bknudson | strange that python26 worked but not 27? | 15:40 |
morganfainberg | Weird. | 15:40 |
morganfainberg | I need to bring up how much this stable branch thing for clients basically makes semver useless. | 15:41 |
morganfainberg | Issue with interpreter and differing lib versions. | 15:42 |
morganfainberg | Since clients are cli, client libs, and inter-service | 15:42 |
*** gyee has joined #openstack-keystone | 15:42 | |
*** ChanServ sets mode: +v gyee | 15:42 | |
*** ajayaa has quit IRC | 15:42 | |
morganfainberg | We mixed too many things into one package. | 15:42 |
morganfainberg | Osc owns cli. Inter-service should be separate from the user-consuming client lib. | 15:43 |
morganfainberg | We did it wrong across the board. | 15:43 |
*** markvoelker has quit IRC | 15:44 | |
*** ajayaa has joined #openstack-keystone | 15:46 | |
*** stevemar has quit IRC | 15:49 | |
*** stevemar has joined #openstack-keystone | 15:49 | |
*** ChanServ sets mode: +v stevemar | 15:49 | |
*** jistr has quit IRC | 15:51 | |
openstackgerrit | Merged openstack/oslo.policy: Fix invalid indentation in _load_policy_file method https://review.openstack.org/173275 | 15:56 |
*** jeffDeville has quit IRC | 15:56 | |
*** krtaylor has quit IRC | 15:57 | |
*** tobberydberg has joined #openstack-keystone | 15:58 | |
*** edmondsw has joined #openstack-keystone | 15:58 | |
*** jeffDeville has joined #openstack-keystone | 16:00 | |
*** erkules_ has joined #openstack-keystone | 16:02 | |
*** erkules has quit IRC | 16:02 | |
*** tobberydberg has quit IRC | 16:04 | |
*** joesavak has joined #openstack-keystone | 16:04 | |
*** bdossant has quit IRC | 16:05 | |
morganfainberg | Rc2 will open tomorrow. | 16:07 |
davidckennedy | henrynash thanks for the review on https://review.openstack.org/#/c/153296/ you've higlighted something that needs addressing but maybe not for the reason that you thought. I'd welcome your thoughts on my return comments. The spec needs to be mentioned in the commit message, I will do that but for now it's at | 16:07 |
davidckennedy | http://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddleware/endpoint-enforcement-middleware | 16:07 |
*** mattamizer has quit IRC | 16:08 | |
*** joesavak has quit IRC | 16:11 | |
*** sdake_ has joined #openstack-keystone | 16:12 | |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 16:13 |
ayoung | morganfainberg, henrynash stevemar can we fast track the tests spec template: https://review.openstack.org/#/c/163882/ I'd be ok with comitting to major rewrites of it once it is in, but not having it means we can't get people to write test specs | 16:14 |
*** markvoelker has joined #openstack-keystone | 16:14 | |
ayoung | and I really want to start beating up my QE team to write test specs | 16:15 |
*** rushil_ has quit IRC | 16:15 | |
ayoung | dstanek, you too ^^ | 16:15 |
openstackgerrit | Rodrigo Duarte proposed openstack/keystone-specs: Recursive deletion and project disabling https://review.openstack.org/148730 | 16:15 |
morganfainberg | ayoung: 1 | 16:15 |
morganfainberg | Major comment | 16:15 |
ayoung | topol, actually, since it is in specs, if you could look at it, I think you will agree it is important: https://review.openstack.org/148730 | 16:15 |
*** sdake has quit IRC | 16:15 | |
rodrigods | gyee, ^ remember you had some concerns in the recursive deletion spec | 16:16 |
morganfainberg | Don't put the template in the dir. We want the templates in the repo but not rendered as part of the final docs. | 16:16 |
ayoung | morganfainberg, can we do this: | 16:16 |
ayoung | put it in the repo so it renders , get at least one test spec in, move the template out | 16:16 |
ayoung | it menas we dpn't need to mess witht the TOC on the first test review | 16:17 |
ayoung | means | 16:17 |
topol | Hi ayoung, what did you want me to look at? | 16:17 |
morganfainberg | Yeah don't mess with the toc in that case | 16:17 |
ayoung | topol, test spec. https://review.openstack.org/148730 | 16:17 |
morganfainberg | Toc should be updated when we have real content in there. | 16:17 |
ayoung | morganfainberg, I will take that as a todo once it is in | 16:17 |
morganfainberg | You also have erroneous white space in the index.rst | 16:18 |
morganfainberg | I have not reviewed the template | 16:18 |
morganfainberg | So will do before scoring the review. | 16:18 |
topol | ayoung, ok will do | 16:18 |
morganfainberg | These were the two things that came to mind at a glance. | 16:18 |
ayoung | thanks | 16:19 |
ayoung | morganfainberg, topol -1s gladly welcome, just so long as we can move it | 16:19 |
*** ajayaa has quit IRC | 16:20 | |
gyee | rodrigods, yes, I am commenting on the recursive spec | 16:21 |
gyee | give me a few more mins | 16:21 |
*** jeffDeville has quit IRC | 16:22 | |
rodrigods | gyee, k | 16:24 |
rodrigods | btw... there are two patches waiting so we can have "official" support to GET /projects?parent_id=<> | 16:26 |
rodrigods | https://review.openstack.org/#/c/166326/2 | 16:26 |
rodrigods | and https://review.openstack.org/#/c/158314/ | 16:26 |
*** markvoelker has quit IRC | 16:26 | |
rodrigods | henrynash, ^ | 16:26 |
dstanek | ayoung: so that is something to do in addition to a spec? | 16:29 |
gyee | rodrigods, see my comments, I have two concerns there | 16:31 |
*** lhcheng has joined #openstack-keystone | 16:32 | |
*** ChanServ sets mode: +v lhcheng | 16:32 | |
gyee | otherwise, mostly good | 16:32 |
dstanek | ayoung: so i wonder why we don't have tests plans part of the code repository instead of the spec repository. seems like really good developer documentation | 16:34 |
openstackgerrit | Merged openstack/keystone: Checking if Trust exists should be DRY https://review.openstack.org/173158 | 16:36 |
rodrigods | gyee, thanks! replied | 16:38 |
gyee | rodrigods, I am still not seeing the benefits of recursive disable | 16:40 |
david-lyle | gyee, it'll come around to you | 16:41 |
gyee | say I have A -> B -> C -> D, disabling B effectively disables B, C and D | 16:41 |
* david-lyle see what I did there ;) | 16:41 | |
gyee | hahaha | 16:41 |
rodrigods | gyee, we can't disable A | 16:42 |
rodrigods | gyee, allowing this kind of behavior would make us to traverse the hierarchy in every token validation, etc | 16:42 |
gyee | in that scenario, disabling B does not disable A | 16:42 |
*** joesavak has joined #openstack-keystone | 16:42 | |
gyee | rodrigods, no need, its all in a single event | 16:43 |
rodrigods | if I disable A, and I want to validate a token for B | 16:43 |
gyee | the hierarchy should be in the event | 16:43 |
rodrigods | I'd need to go through the hierarchy to check if there are disabled parents | 16:43 |
gyee | yes, or have the hierarchy in the event | 16:43 |
gyee | read is relatively in expensive compare to write | 16:44 |
rodrigods | event? | 16:44 |
gyee | inexpensive | 16:44 |
gyee | revocation event | 16:44 |
gyee | disable generates a revocation event | 16:44 |
rodrigods | uuid and fernet tokens are validated against revocation events? | 16:44 |
gyee | rodrigods, think scale, performance, multi datacenters :) | 16:45 |
gyee | you want to avoid write in favor of read if you can | 16:46 |
rodrigods | gyee, exactly... but I don't see the advantage of trading a one time write to include lots of data in the event | 16:46 |
amakarov | rodrigods, hi. Have you considered to introduce materialized path in the hierarchy? It will allow to avoid recursion | 16:47 |
gyee | its not a one-time write, its a collections of writes | 16:47 |
rodrigods | amakarov, yes... I'd be glad to help you in a spec for such redesign | 16:47 |
rodrigods | amakarov, check http://dolphm.com/hierarchical-multitenancy/ | 16:48 |
amakarov | rodrigods, ok, I'll do it. Is there any to modify or I need to create a new one? | 16:48 |
rodrigods | amakarov, the recursive deletion one does not depend on implementation, so I'd say a new one | 16:49 |
* amakarov reading... | 16:49 | |
rodrigods | gyee, a collection of one time writes heh | 16:49 |
rodrigods | you do a lot of writes once | 16:49 |
rodrigods | than everything is straightforward to check | 16:49 |
rodrigods | gyee, besides that... our current API prohibit to disable a project with enabled children... think that changing this may break the API stability? | 16:51 |
gyee | but you can easily avoid write | 16:51 |
*** jeffDeville has joined #openstack-keystone | 16:51 | |
rodrigods | gyee, in every project related call (like get_project, issuing tokens, listing projects for user...), we read up the hierarchy to check if is there a disabled parent | 16:53 |
rodrigods | we'd need* | 16:54 |
gyee | we currently don't individually disable the users when the domain is disabled | 16:54 |
gyee | otherwise, it would be rather expensive | 16:54 |
rodrigods | gyee, yeah... I think you are making me to think like you | 16:55 |
gyee | with revocation events, we really don't need to walk to tree if we store the hierarchy along with the event | 16:56 |
gyee | maybe you can even check the project status by looking at the events | 16:58 |
rodrigods | gyee, but we'd return that B is enabled in the get_project? | 16:58 |
ayoung | dstanek, they need to be in some repository. If specs get their own repos, test specs belong with them. | 16:58 |
ayoung | No reason that the codre repo can't have a reference to it | 16:58 |
*** harlowja has joined #openstack-keystone | 16:59 | |
gyee | rodrigods, sure | 17:00 |
rodrigods | gyee, ok... so my last concerns are: what is the status of revocation events, remember it had some issues... and, can we allow a call to not return an error after the API returned an error? (see https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#update-project) | 17:02 |
gyee | revocation has to work, or we don't have a non-persistent token story :) | 17:03 |
gyee | revocation events | 17:03 |
rodrigods | gyee, k... and about the API stability | 17:04 |
rodrigods | what* about | 17:04 |
gyee | have faith man :) | 17:04 |
rodrigods | heh :) | 17:04 |
*** joesavak has quit IRC | 17:05 | |
*** tqtran has joined #openstack-keystone | 17:05 | |
*** sdake has joined #openstack-keystone | 17:07 | |
*** sdake_ has quit IRC | 17:11 | |
tristanC | Please correct me if I'm wrong, for Kilo first release, keystonemiddleware will be 1.6.0 and python-keystoneclient will be 1.4.0 right ? | 17:11 |
* tristanC is trying to understand what versions will include fixes for bug 1411063 | 17:12 | |
openstack | bug 1411063 in keystonemiddleware "S3token incorrect condition expression for ssl_insecure (CVE-2015-1852)" [Critical,In progress] https://launchpad.net/bugs/1411063 - Assigned to Tristan Cacqueray (tristan-cacqueray) | 17:12 |
gyee | I thought keystonemiddleware started at 1.0.0 | 17:12 |
rodrigods | gyee, replied in the spec review, cited the concern regarding API stability | 17:13 |
*** joesavak has joined #openstack-keystone | 17:14 | |
*** sdake_ has joined #openstack-keystone | 17:14 | |
gyee | what?! we don't allow disabling a project with an enabled child? | 17:15 |
gyee | why | 17:15 |
openstackgerrit | Merged openstack/python-keystoneclient: Fix s3_token middleware parsing insecure option https://review.openstack.org/173370 | 17:16 |
rodrigods | gyee, yep... the revocation events solution wasn't cited in the time we implemented :) | 17:16 |
* gyee cries | 17:17 | |
*** sdake has quit IRC | 17:18 | |
*** aix has quit IRC | 17:18 | |
rodrigods | morganfainberg, can you give your opinion here ^? | 17:18 |
*** alexsyip has joined #openstack-keystone | 17:18 | |
morganfainberg | Let me look once I've gotten food. | 17:19 |
morganfainberg | And coffee. | 17:19 |
rodrigods | morganfainberg, k | 17:19 |
morganfainberg | Trying to eat pre-meeting for a change. | 17:19 |
openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Materialized path for project hierarchy https://review.openstack.org/173424 | 17:20 |
amakarov | rodrigods, ^^ | 17:20 |
gyee | amakarov, ++, that's what was suggested at the beginning | 17:21 |
rodrigods | amakarov, nice! | 17:21 |
morganfainberg | Gyee we have to fix revocation events as the default before we can do disable with enabled children. | 17:22 |
morganfainberg | gyee: still not in ksm | 17:22 |
gyee | morganfainberg, yes | 17:22 |
amakarov | morganfainberg, hi! btw Horizon folks already started to whine about group revocation again :) | 17:23 |
morganfainberg | amakarov: they can whine all they want. We can work on fixing it in Liberty. | 17:23 |
morganfainberg | :P | 17:23 |
gyee | what's issue with group revocation? | 17:23 |
morganfainberg | gyee: groups not in token. We can't issue an event for it. | 17:24 |
amakarov | gyee, https://review.openstack.org/#/c/141854/ | 17:24 |
morganfainberg | Therefore we revoke all tokens for the user. | 17:24 |
amakarov | and it is way too heavy | 17:24 |
lhcheng | morganfainberg: does this sounds like a rc-potential: https://bugs.launchpad.net/keystone/+bug/1440493 | 17:25 |
openstack | Launchpad bug 1440493 in Keystone "Crash with python-memcached==1.5.4" [Undecided,In progress] - Assigned to Alexander Makarov (amakarov) | 17:25 |
dolphm | didn't we agree to add the list of groups to the token validation response? | 17:25 |
gyee | I am fine with that | 17:26 |
amakarov | lhcheng, I still owe a test there | 17:26 |
openstackgerrit | Alexander Makarov proposed openstack/keystone-specs: Materialized path for project hierarchy https://review.openstack.org/173424 | 17:27 |
lhcheng | amakarov: yup, just trying to figure out if we should tag for rc-potential | 17:27 |
morganfainberg | dolphm: I think we did | 17:29 |
morganfainberg | dolphm: it's just not done yet. | 17:29 |
morganfainberg | lhcheng: that might be a requirements freeze update. | 17:30 |
gyee | amakarov, operationally, how often do you think one change the permissions of a group? | 17:30 |
*** browne has quit IRC | 17:30 | |
morganfainberg | Need to bug ttx asap. Sec | 17:30 |
openstackgerrit | ayoung proposed openstack/keystone-specs: Template for testing document https://review.openstack.org/163882 | 17:30 |
ayoung | dstanek, thanks for that review. | 17:30 |
*** sigmavirus24 is now known as sigmavirus24_awa | 17:30 | |
rodrigods | gyee, so we do not need the recursive disabling API, but we need to add ksm support, right? | 17:30 |
rodrigods | ksm support to revocation events | 17:31 |
*** sdake has joined #openstack-keystone | 17:31 | |
morganfainberg | lhcheng: so that is a crappy workaround. And will impact ksm as well I think. | 17:31 |
*** jeffDeville has quit IRC | 17:31 | |
morganfainberg | lhcheng: yes that is rc-potential. | 17:32 |
lhcheng | morganfainberg: cool, thanks for checking | 17:32 |
amakarov | gyee, as for me - not often, as for the user - he'll definitely do the worst thing you hoped he'll avoid :) | 17:33 |
lhcheng | morganfainberg: good call on adding ksm too | 17:34 |
*** sdake_ has quit IRC | 17:35 | |
gyee | yes, ksm definitely need to support revocation events | 17:35 |
gyee | rodrigods, ^^ | 17:35 |
gyee | don't think we have much of a choice here | 17:35 |
*** jeffDeville has joined #openstack-keystone | 17:36 | |
*** boris-42 has quit IRC | 17:38 | |
*** rushil has joined #openstack-keystone | 17:39 | |
dolphm | does sqlite do a decent job with indexes? | 17:39 |
*** ajayaa has joined #openstack-keystone | 17:40 | |
*** sdake_ has joined #openstack-keystone | 17:44 | |
openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 17:45 |
raildo | topol, ^ :) | 17:45 |
*** sdake has quit IRC | 17:45 | |
dstanek | dolphm: compared to what? | 17:45 |
dolphm | dstanek: i'm just curious if there are any well known caveats with sqlite indexes vs other databases. wondering how the revocation tree implementation would compare against an in-memory indexed cache of revocation events using sqlite | 17:47 |
*** sdake_ has quit IRC | 17:48 | |
*** sdake has joined #openstack-keystone | 17:48 | |
*** diegows has joined #openstack-keystone | 17:49 | |
topol | raildo, you left the last change a s a run on sentence :-) | 17:49 |
dstanek | dolphm: other than having to manually turn on foreign keys, i haven't noticed too much of a difference between it and mysql - but i'm not much of a power user of either | 17:49 |
raildo | :'( | 17:49 |
topol | raildo, the comma needs to be a period. Or I would have accepted a semi-colon. I wrote it for you. copy paste friend :-) | 17:50 |
topol | raildo, and then Im a +2 | 17:50 |
raildo | just 1 min | 17:51 |
*** jeffDeville has quit IRC | 17:51 | |
topol | raildo, I'm being picky because it is the API doc. If it was just a spec I would not have worried about it | 17:51 |
*** jaosorior has quit IRC | 17:52 | |
*** sdake has quit IRC | 17:52 | |
*** sdake has joined #openstack-keystone | 17:52 | |
raildo | topol, and you're right, this is my fault :) | 17:52 |
topol | raildo, no worries and an easy fix | 17:53 |
openstackgerrit | Raildo Mascena de Sousa Filho proposed openstack/keystone-specs: API changes for Reseller https://review.openstack.org/153007 | 17:56 |
*** davechen has joined #openstack-keystone | 17:57 | |
*** jeffDeville has joined #openstack-keystone | 18:00 | |
lhcheng | when creating a grant the already exists, the backend silently fails in: https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L130-L131 | 18:01 |
lhcheng | is that by design? | 18:01 |
lhcheng | for v2, we raise an exception when a duplicate role assignment is made. | 18:01 |
*** ptoohill has quit IRC | 18:03 | |
*** ajayaa has quit IRC | 18:04 | |
lhcheng | wondering if anyone recalls why creating duplicate grants should fail silently (there might be a good reason behind it that I overlooked) | 18:04 |
*** amaurymedeiros has quit IRC | 18:05 | |
*** jamielennox|away is now known as jamielennox | 18:05 | |
*** ptoohill has joined #openstack-keystone | 18:08 | |
*** amaurymedeiros has joined #openstack-keystone | 18:10 | |
*** amaurymedeiros has quit IRC | 18:10 | |
*** amaurymedeiros has joined #openstack-keystone | 18:10 | |
*** nkinder has joined #openstack-keystone | 18:13 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 18:16 | |
*** amolock has joined #openstack-keystone | 18:16 | |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Make memcache client reusable across threads https://review.openstack.org/170835 | 18:20 |
*** tellesnobrega has quit IRC | 18:25 | |
*** markvoelker has joined #openstack-keystone | 18:25 | |
*** sdake_ has joined #openstack-keystone | 18:25 | |
*** tellesnobrega has joined #openstack-keystone | 18:26 | |
*** tellesnobrega_ has joined #openstack-keystone | 18:27 | |
*** tellesnobrega_ has quit IRC | 18:27 | |
rodrigods | haneef, replied you in https://review.openstack.org/#/c/153007/ | 18:27 |
haneef | I will have a look at it | 18:28 |
rodrigods | thanks | 18:28 |
*** sdake has quit IRC | 18:29 | |
*** tobberydberg has joined #openstack-keystone | 18:29 | |
*** tellesnobrega has quit IRC | 18:29 | |
*** tellesnobrega has joined #openstack-keystone | 18:29 | |
haneef | rodrigods: Sorry , I added that in different patchset. Fixed it | 18:31 |
*** markvoelker has quit IRC | 18:31 | |
rodrigods | haneef, thanks | 18:31 |
openstackgerrit | Alexander Makarov proposed openstack/keystone: Redis cache backend https://review.openstack.org/173000 | 18:31 |
rodrigods | haneef, replied... basically the is_domain field is only if you want to request a project scoped token to a project with the is_Domain flag enabled | 18:33 |
*** tqtran has quit IRC | 18:34 | |
*** jeffDeville has quit IRC | 18:34 | |
*** rushil has quit IRC | 18:34 | |
*** jeffDevi_ has joined #openstack-keystone | 18:36 | |
haneef | rodrigods: May be I missed some stuff. Why do I want to do that? How are going to distinguish between project and domain roles? e.g a user has a role X on project which is a domain. Is it a domain role or project role or it doesn't matter? | 18:38 |
rodrigods | haneef, right... i think this API spec doesn't consider merging the assignments types yet | 18:39 |
*** sdake has joined #openstack-keystone | 18:39 | |
haneef | rodrigods: so the answer is , it doesn't matter | 18:40 |
rodrigods | haneef, no.. it does matter. If we have different assignments types we may have different roles | 18:41 |
rodrigods | assignments* | 18:41 |
rodrigods | s/roles/assignments | 18:41 |
haneef | So basically , with is_domain flag you are going to send project roles assignment only. Is that correct? | 18:42 |
rodrigods | haneef, correct | 18:43 |
*** sdake_ has quit IRC | 18:43 | |
amakarov | rodrigods, I've missed something: where exactly do I have to add my spec? :) | 18:45 |
rodrigods | amakarov, https://etherpad.openstack.org/p/keystone-liberty-priority-specs | 18:45 |
*** tobberydberg has quit IRC | 18:45 | |
*** browne has joined #openstack-keystone | 18:45 | |
amakarov | rodrigods, as minor under reseller? | 18:46 |
rodrigods | amakarov, I'd say in the performance topic | 18:46 |
rodrigods | not sure, though | 18:46 |
amakarov | rodrigods, I think greater minds will sort things out :) | 18:47 |
rodrigods | haneef, are you ok with the change as it is? (I mean, after addressing henrynash comments) | 18:47 |
haneef | The way openstack uses roles, basically I need to add two role assignment with "admin" role for a project which is a domain in order to use it as domain and project . Unfortunately this is very bad UX. This is very difficult to explain in documentation | 18:47 |
rodrigods | haneef, agreed, that's why we are going to submit the dual scoped spec to address this | 18:48 |
haneef | rodrigods: We are going to get a question, saying I have "admin" role for user on project, still keystone apis doesn't work. The answer is, add one more "admin" role for the project using "domain" role assignment | 18:49 |
rodrigods | haneef, but this is the current behavior, right? | 18:50 |
rodrigods | although it is also a project, by the current API domains and projects are treated separately | 18:50 |
haneef | In current domain is "different id " and project is "different id". Now we are going to have same id since project is a domain | 18:50 |
*** jeffDevi_ has quit IRC | 18:51 | |
henrynash | rodigods: one concern, if we are going to introduce dual scoped tokens later…how is it that I will know if I get one of not…is it a diferent API….although I have been skeptical of them, I think the obvious place to issue one is when specifing an is_domain=True project | 18:52 |
rodrigods | haneef, yes... but they will be different entities, unless you update a project to be a domain | 18:52 |
rodrigods | henrynash, I'd say in the domain request... | 18:52 |
rodrigods | but... have no strong preference | 18:52 |
henrynash | rodigods: interesting….I think the opposite | 18:52 |
rodrigods | btw, our fault to approve reseller without the API | 18:53 |
rodrigods | now I'm inclined to send all API changes in the dual scoped spec review | 18:53 |
henrynash | rodigods: i think the goal of dual scoped is to allow people who understand project tokens (i.e. everyone) to not have to also do domain toekns | 18:53 |
rodrigods | henrynash, good point! | 18:54 |
rodrigods | henrynash, but they'd need to update the request anyway | 18:54 |
haneef | henrynash: basically in that case, u consider domain role assignment is same as project role assignment. Is that correct? | 18:55 |
rodrigods | to add the is_domain field | 18:55 |
henrynash | rodigods: not if the specifiy project by ID | 18:55 |
rodrigods | henrynash, hmm too many types of requests to keep in mind heh | 18:55 |
rodrigods | true | 18:55 |
rodrigods | makes sense | 18:55 |
rodrigods | so I'd say we return dual scoped tokens in both domain and project requests | 18:56 |
rodrigods | to is_domain projects | 18:56 |
henrynash | rodigods: no, I’d say explict domain scoped requests should stay that way | 18:56 |
rodrigods | henrynash, why? | 18:56 |
henrynash | rodigods: i.e. they DON’T contain the project ID….. | 18:56 |
rodrigods | to keep domain API "intact" ? | 18:57 |
henrynash | rodigods: yes, I think we just freeze teh current domain idea | 18:57 |
henrynash | rodigods: and over time everyone moves to using the project API | 18:57 |
rodrigods | henrynash, ok.. agreed | 18:57 |
*** dtroyer_zz has quit IRC | 18:58 | |
*** dtroyer has joined #openstack-keystone | 18:58 | |
raildo | haneef, the main benefit to provide a dual scoped token is use the same token in other services without rescope then. | 18:58 |
rodrigods | henrynash, so what do you think about sending the API changes and dual scoped tokens spec all together? | 18:58 |
rodrigods | or at least, API changes depending in the dual scoped tokens spec | 18:59 |
*** amakarov is now known as amakarov_away | 18:59 | |
henrynash | rodigods: i’m coming round to that idea…in that the example we give in the API of gettinga token to an is_domain project is the obvious example of where you would get a dual scoped token | 19:00 |
raildo | haneef, today with the actual api, if I request a domain scoped token, and I want to use in Nova, for example, we need to get other project scoped token. | 19:00 |
jamielennox | i like that the cleanup/tech debt fixup list is longer than the new features list for this cycle | 19:00 |
morganfainberg | jamielennox, that is my goal :) | 19:00 |
jamielennox | well not good we have so many, but good they'll get attention | 19:00 |
morganfainberg | jamielennox, a lot of these are already in flight too | 19:01 |
morganfainberg | jamielennox, or things that have already been started over a few cycles. | 19:01 |
haneef | ralido: What is going to happen in dual scoped token for this? e.g a user has a role X on project which is a domain. Is it a domain role or project role or it doesn't matter? | 19:01 |
gyee | haneef, so in the case, project_id is the same as domain_id, role assignment shouldn't matter right? | 19:02 |
gyee | they are essentially the same | 19:02 |
raildo | haneef, the our first ideia is provide just one type for role, just for projects. | 19:02 |
raildo | gyee, ++ | 19:02 |
*** jeffDeville has joined #openstack-keystone | 19:04 | |
gyee | I agree the API needs to consolidate, but under the hood, the function the same | 19:04 |
*** davechen1 has joined #openstack-keystone | 19:05 | |
morganfainberg | i did notice no-downtime upgrades wasn't on the list >.> | 19:05 |
* morganfainberg doesn't know if there is a real win to no-downtime upgrades at this point | 19:05 | |
morganfainberg | e.g. supporting schema -1 in the backend. | 19:05 |
morganfainberg | s/schema/release-schema/ | 19:06 |
*** davechen has quit IRC | 19:06 | |
morganfainberg | ok i need to run an errand. | 19:06 |
*** davechen1 has left #openstack-keystone | 19:06 | |
rodrigods | morganfainberg, one of the meeting topics was to check if https://review.openstack.org/#/c/172536/ and https://review.openstack.org/#/c/172562/ needs specs | 19:07 |
rodrigods | I'm really inclined to opinion that the bugs are enough | 19:07 |
*** vilobhmm11 has joined #openstack-keystone | 19:07 | |
rodrigods | henrynash, context changing ^ | 19:08 |
morganfainberg | those are typically done out of band of the meeting | 19:08 |
morganfainberg | we just keep it in the meeting page for ease to find them | 19:08 |
morganfainberg | and so everyone sees it at least once a week | 19:08 |
rodrigods | ++ | 19:08 |
rodrigods | morganfainberg, so how can we proceed? | 19:09 |
*** rushiagr is now known as rushiagr_away | 19:10 | |
morganfainberg | rodrigods, get enough cores to agree on needing / not needing the spec | 19:11 |
morganfainberg | then update and reference the eavesdrop log | 19:11 |
morganfainberg | rodrigods, do it here :) | 19:11 |
gyee | morganfainberg, no down time is more of networking magic :) | 19:11 |
rodrigods | morganfainberg, cool... so do you think a spec is needed? I don't think so :) | 19:12 |
rodrigods | gyee, you too! ^ | 19:12 |
rodrigods | lhcheng was reviewing the first patch of the chain | 19:12 |
rodrigods | ^ | 19:12 |
gyee | rodrigods, you mean adding stuff to assertion? | 19:13 |
rodrigods | gyee, yes... because right now we can't differentiate users and projects from different domains | 19:13 |
gyee | that one needs spec as it affects external interface | 19:13 |
gyee | now I need to account for it in mapping | 19:14 |
rodrigods | gyee, why it affects? | 19:14 |
*** ptoohill has quit IRC | 19:14 | |
rodrigods | gyee, ok.. but if you had an old mapping | 19:14 |
rodrigods | it won't affect | 19:14 |
gyee | I'll have to update the mapping to remove ambiguity right? | 19:15 |
rodrigods | gyee, yes... if you want to :) | 19:15 |
*** jeffDeville has quit IRC | 19:16 | |
*** diegows has quit IRC | 19:16 | |
gyee | have to if I can't guarantee all usernames are unique | 19:16 |
morganfainberg | for the stevedore to load drivers, i don't think a spec is needed | 19:16 |
morganfainberg | bknudson, ^ | 19:16 |
morganfainberg | bknudson, confirm with the rest of the team but i'm ok with it as is. | 19:17 |
morganfainberg | now i need to run for an errand | 19:17 |
rodrigods | gyee, my point is that you were never able to do so... now we are fixing this so you can differentiate if you want... | 19:17 |
rodrigods | it won't break anything | 19:17 |
bknudson | I might write up a spec anyways after having written the code... will provide useful source for docs. | 19:18 |
gyee | rodrigods, actually it would be an OSSA/N if we can't guarantee usernames are unique from a given IdP | 19:19 |
rodrigods | gyee, OSSA/N? ;) | 19:19 |
gyee | openstack security advisory I think | 19:20 |
rodrigods | hmm | 19:20 |
*** ptoohill has joined #openstack-keystone | 19:20 | |
rodrigods | it is definitely a security issue | 19:21 |
*** jeffDeville has joined #openstack-keystone | 19:21 | |
rodrigods | gyee, how do I proceed? | 19:21 |
gyee | rodrigods, put up a spec and articulate what its for and how to utilize it | 19:22 |
rodrigods | gyee, :( was really hoping that it could land in Kilo since the code is really simple and implemented | 19:22 |
gyee | it should be there for a good reason | 19:22 |
*** aix has joined #openstack-keystone | 19:23 | |
gyee | identity attributes are part of the auth payload so we should clearly document them | 19:23 |
lhcheng | rodrigods: is this bug still valid? https://bugs.launchpad.net/keystone/+bug/1397318 | 19:25 |
openstack | Launchpad bug 1397318 in Keystone "Wrong return code for inherited project role checking" [Undecided,In progress] - Assigned to Rodrigo Duarte (rodrigodsousa) | 19:25 |
rodrigods | lhcheng, we had a discussion whether it should be 200 or 204, but I remember the APIs had conflicted returns | 19:25 |
rodrigods | API docs | 19:25 |
*** jeffDeville has quit IRC | 19:26 | |
rodrigods | gyee, document in the API spec? | 19:26 |
lhcheng | rodrigods: okay, seems like there is still some work needed to cleanup the API docs. I'll leave it open then | 19:27 |
*** markvoelker has joined #openstack-keystone | 19:29 | |
gyee | rodrigods, configure_federation.rst? | 19:31 |
*** _cjones_ has quit IRC | 19:33 | |
*** markvoelker has quit IRC | 19:34 | |
*** sdake_ has joined #openstack-keystone | 19:37 | |
*** _cjones_ has joined #openstack-keystone | 19:37 | |
dstanek | i just ran across https://review.openstack.org/#/c/173393/ - any reason it's not approved? | 19:37 |
*** carlosmarin has quit IRC | 19:38 | |
*** carlosmarin has joined #openstack-keystone | 19:39 | |
*** carlosmarin has quit IRC | 19:40 | |
*** sdake has quit IRC | 19:41 | |
bknudson | dstanek: it's on proposed/kilo... | 19:41 |
bknudson | not sure if we're supposed to be approving there. | 19:41 |
dstanek | bknudson: ah, i see - we do seem to have the power :-) | 19:42 |
bknudson | dstanek: morganfainberg -2d https://review.openstack.org/#/c/173115/ | 19:43 |
*** _cjones_ has quit IRC | 19:43 | |
*** vilobhmm11 has quit IRC | 19:47 | |
*** vilobhmm1 has joined #openstack-keystone | 19:47 | |
*** sdake has joined #openstack-keystone | 19:51 | |
*** jeffDeville has joined #openstack-keystone | 19:52 | |
*** ozialien has joined #openstack-keystone | 19:52 | |
*** carlosmarin has joined #openstack-keystone | 19:52 | |
*** sdake_ has quit IRC | 19:54 | |
rodrigods | gyee, ok... so we don't need a spec, but update our documentation, right? | 20:03 |
*** ayoung has quit IRC | 20:05 | |
*** sdake_ has joined #openstack-keystone | 20:05 | |
*** sdake has quit IRC | 20:07 | |
openstackgerrit | Lin Hua Cheng proposed openstack/keystone: Make get_trust a protected method https://review.openstack.org/172620 | 20:12 |
*** ozialien has quit IRC | 20:12 | |
*** _cjones_ has joined #openstack-keystone | 20:16 | |
*** ayoung has joined #openstack-keystone | 20:17 | |
*** ChanServ sets mode: +v ayoung | 20:17 | |
*** erkules_ is now known as erkules | 20:19 | |
*** sdake has joined #openstack-keystone | 20:23 | |
*** jeffDeville has quit IRC | 20:24 | |
*** sdake_ has quit IRC | 20:25 | |
*** topol has quit IRC | 20:31 | |
*** jeffDeville has joined #openstack-keystone | 20:32 | |
*** tqtran has joined #openstack-keystone | 20:33 | |
*** markvoelker has joined #openstack-keystone | 20:33 | |
morganfainberg | bknudson, dstanek, don't approve on proposed/kilo until we open the rc2 window please | 20:34 |
*** vilobhmm1 has quit IRC | 20:35 | |
*** lifeless1 is now known as lifeless | 20:37 | |
*** markvoelker has quit IRC | 20:37 | |
*** henrynash has quit IRC | 20:40 | |
*** samuel has joined #openstack-keystone | 20:42 | |
dstanek | morganfainberg: ack | 20:42 |
*** tqtran has quit IRC | 20:44 | |
*** jeffDeville has quit IRC | 20:44 | |
*** ozialien has joined #openstack-keystone | 20:47 | |
morganfainberg | nkinder, ping | 20:49 |
nkinder | morganfainberg: hey, what's up? | 20:49 |
morganfainberg | nkinder, if i need to get something to ayoung is it better to hand it off to you and have you ship it to him (before summit) or better to just try and catch him at the summit | 20:49 |
morganfainberg | nkinder, assuming you'll be around the meetup on thursday | 20:50 |
nkinder | morganfainberg: I'm not going to see him until the summit | 20:50 |
morganfainberg | ok | 20:50 |
nkinder | morganfainberg: I'm happy to be the mule if you want, but it won't get to him any earlier than if you bring it to the summit yourself. :) | 20:51 |
morganfainberg | i'll prob hand stuff off to you | 20:51 |
morganfainberg | will make it easier for me when heading to the summit | 20:51 |
morganfainberg | less to carry | 20:51 |
*** ayoung has quit IRC | 20:55 | |
samuel | morganfainberg:ping | 20:58 |
morganfainberg | samuel, pong | 20:58 |
*** rhagarty__ has quit IRC | 20:58 | |
*** raildo has quit IRC | 20:58 | |
samuel | morganfainberg: regarding that bug on inherited role assignments ,,, | 20:58 |
samuel | morganfainberg: https://review.openstack.org/#/c/171596/ | 20:58 |
samuel | morganfainberg: we are going to land this in rc2, right? | 20:59 |
morganfainberg | samuel, it is meant to be evaluated for rc2 | 20:59 |
samuel | morganfainberg: when is it ? | 20:59 |
morganfainberg | RC2 opens tomorrow | 20:59 |
samuel | morganfainberg: do you need something else from me to evaluate this ? | 21:00 |
morganfainberg | no we just need to land it in master | 21:00 |
morganfainberg | then make sure bug is tagged for kilo-rc-potential | 21:00 |
samuel | morganfainberg: bug #1403539 | 21:01 |
openstack | bug 1403539 in Keystone "Can't create both inherited and direct role assignment on same entities" [Medium,In progress] https://launchpad.net/bugs/1403539 - Assigned to Samuel de Medeiros Queiroz (samueldmq) | 21:01 |
morganfainberg | samuel, just tagged it | 21:01 |
*** ashleighfarnham has quit IRC | 21:01 | |
samuel | tagged Keystone liberty-1 "l1" | 21:01 |
morganfainberg | no "tags" | 21:01 |
*** ozialien has left #openstack-keystone | 21:01 | |
samuel | morganfainberg: yeah I was looking at milestone | 21:02 |
*** vilobhmm1 has joined #openstack-keystone | 21:02 | |
samuel | morganfainberg:thanks for doing so, I will promptly wait for reviews | 21:02 |
*** vilobhmm1 has quit IRC | 21:03 | |
*** vilobhmm1 has joined #openstack-keystone | 21:03 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 21:03 | |
bknudson | samueldmq: https://review.openstack.org/#/c/142472/ isn't going to work anymore since we've got a 068 migration? http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/sql/migrate_repo/versions/068_placeholder.py | 21:03 |
*** alexsyip has quit IRC | 21:06 | |
samuel | bknudson: sure, thanks .. I will update it | 21:07 |
samuel | bknudson: btw, what those placeholder migrations are for ? | 21:07 |
bknudson | samuel: in case we need to add a migration to kilo | 21:07 |
*** vilobhmm1 has quit IRC | 21:07 | |
*** vilobhmm1 has joined #openstack-keystone | 21:08 | |
openstackgerrit | Merged openstack/keystone-specs: Add parent_id to GET /projects https://review.openstack.org/166326 | 21:08 |
bknudson | I don't think we've ever actually used one of the placeholders? | 21:08 |
bknudson | so this might be a first. | 21:08 |
samuel | bknudson: to backport a migration? sorry but I dont see the advantage of already having a placeholder .. | 21:09 |
*** joesavak has quit IRC | 21:10 | |
*** pnavarro|mtg has quit IRC | 21:10 | |
bknudson | samuel: adding the placeholders gets proposed as soon as L opens... I didn't think it would get merged as quickly as it did either. | 21:10 |
dstanek | samuel: http://dolphm.com/backporting-openstack-database-migrations-to-stable-branches/ | 21:11 |
samuel | bknudson: yeah, I am going to read this ^ | 21:11 |
samuel | dstanek: thanks | 21:11 |
*** ayoung has joined #openstack-keystone | 21:11 | |
*** ChanServ sets mode: +v ayoung | 21:11 | |
*** amolock has quit IRC | 21:13 | |
*** henrynash has joined #openstack-keystone | 21:15 | |
*** ChanServ sets mode: +v henrynash | 21:15 | |
lhcheng | nkinder: ayoung: thoughts on priority of this bug report: https://bugs.launchpad.net/keystone/+bug/1409635 | 21:15 |
openstack | Launchpad bug 1409635 in Keystone "keystone fails to authenticate users when LDAP project_id_attribute is not CN" [Undecided,New] | 21:15 |
morganfainberg | LDAP assignment | 21:15 |
rodrigods | lhcheng, https://review.openstack.org/#/c/158314/ related to https://review.openstack.org/#/c/166326/ | 21:15 |
morganfainberg | i've really been holding back on wont fix for that | 21:15 |
morganfainberg | but we have exactly 1 person saying they use LDAP assignment [long term], and 2 orgs who are moving off it | 21:16 |
morganfainberg | i'm inclined to say wont fix. | 21:16 |
morganfainberg | LDAP assignment is dead. | 21:16 |
ayoung | agreed | 21:16 |
samuel | morganfainberg: btw, I thought we always had managed assignments under keystone umbrella | 21:16 |
morganfainberg | and because LDAP assignment was a bunch of hacks on hacks on hacks, we can't even provide a sane migration path | 21:17 |
morganfainberg | that is a sign somerthing is *very* wrong. | 21:17 |
lhcheng | morganfainberg: makes sense. I guess if there are critical bugs, it would only go as backport to stable? | 21:17 |
ayoung | Won't fix | 21:17 |
*** sigmavirus24_awa is now known as sigmavirus24 | 21:17 | |
samuel | we already deprecated it ? | 21:18 |
lhcheng | ayoung: thought we should still support it for stable but not for master. (only for critical bugs) | 21:19 |
morganfainberg | samuel, yes LDAP assignment is deprecated as of Kilo | 21:19 |
morganfainberg | lhcheng, this afaict is a more of a pony request | 21:20 |
ayoung | LDAP assignment must die | 21:20 |
morganfainberg | lhcheng, "hey ldap assignment doesn't do this thing, can it?" | 21:20 |
samuel | ayoung: yeah, and we're killing it, starting from deprecating ^ | 21:20 |
samuel | morganfainberg: nice thx | 21:20 |
lhcheng | morganfainberg: oh no, I don't mean this request. More of like the general process if there are critical bug that may came up | 21:20 |
morganfainberg | oh | 21:20 |
morganfainberg | if it is a security bug | 21:20 |
morganfainberg | yes we will fix it | 21:20 |
morganfainberg | yes we will backport it | 21:21 |
lhcheng | (from that 1 person :P ) | 21:21 |
morganfainberg | otherwise nope | 21:21 |
lhcheng | sounds good | 21:21 |
bknudson | when can LDAP assignment be removed? | 21:23 |
morganfainberg | bknudson, M | 21:26 |
morganfainberg | bknudson, deprecated in K, removed in M | 21:26 |
lhcheng | rodrigods: cool, thanks for the link, will look at it shortly. Going through all the un-priotized LP bugs at the moment. | 21:26 |
*** mattfarina has quit IRC | 21:27 | |
samuel | bknudson: in this case, 68-72 are placeholders | 21:31 |
samuel | bknudson: should them be the last ones on K ? in this case my patch should shifht them by 1 | 21:31 |
bknudson | samuel: the first new on in L is going to be 73 then | 21:32 |
bknudson | and the backport will be 68 | 21:32 |
bknudson | so we'll wind up having 2 of the same migration | 21:32 |
samuel | bknudson: why backport? this will possible merge into rc2 | 21:33 |
bknudson | rc2 doesn't have the placeholders. | 21:33 |
bknudson | some deployments are using trunk, so they're already at 72. | 21:33 |
bknudson | so if you put it into 68 then they won't get it. | 21:33 |
samuel | if I put on 73, they wont anyway | 21:34 |
samuel | if I put on 68 or 73, they will need an update anyway | 21:34 |
bknudson | if you put 73, then they'll get it since they're at 72. | 21:35 |
morganfainberg | bknudson, rc2 can't have the placeholders | 21:36 |
morganfainberg | oh yeah that what you were saying | 21:36 |
morganfainberg | samuel, i commented on the way to do the schema migrate + backport | 21:36 |
morganfainberg | and yes it's meant to be awful | 21:36 |
bknudson | maybe alembic makes it so much easier. | 21:36 |
morganfainberg | we should *REALLY* be needing it not "cause i like backporting" | 21:36 |
morganfainberg | bknudson, it does. | 21:36 |
morganfainberg | bknudson, but it's still a bit scary to do. | 21:37 |
samuel | bknudson: sorry but I still didnt get it, if they are on master they need to git pull anyway | 21:38 |
samuel | bknudson: which would work both ways | 21:38 |
bknudson | deployments on master are already on 72, so if you change 68 they're not going to run it. | 21:38 |
bknudson | keystone-manage db_sync will say they're already up to date | 21:39 |
*** boris-42 has joined #openstack-keystone | 21:39 | |
samuel | bknudson: even if we change the 068 filename ? | 21:39 |
bknudson | samuel: yes, sqlalchemy-migrate doesn't care about the filename. | 21:40 |
samuel | bknudson: think I got it ,,, I do pull, and then run migraitons, then db_sync says the db is updated up to version X | 21:41 |
samuel | bknudson: and then only run migrations starting at X+1 | 21:41 |
morganfainberg | samuel, yep | 21:41 |
bknudson | yes, that's how it works... there's a table that has the current version. | 21:41 |
samuel | ah :-) | 21:41 |
samuel | morganfainberg, bknudson thanks for sharing the knowledge :) | 21:42 |
bknudson | no problem. | 21:42 |
samuel | bknudson: I will update the version on that migration tomorrow morning, when I get to my pc | 21:43 |
samuel | need to go now | 21:43 |
samuel | thanks for the review | 21:43 |
*** samuel has left #openstack-keystone | 21:49 | |
*** amerine has joined #openstack-keystone | 21:54 | |
*** nkinder has quit IRC | 21:57 | |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin https://review.openstack.org/173558 | 21:59 |
*** topol has joined #openstack-keystone | 21:59 | |
*** ChanServ sets mode: +v topol | 21:59 | |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient-kerberos: Federated Kerberos plugin https://review.openstack.org/173558 | 22:06 |
*** henrynash has quit IRC | 22:09 | |
*** markvoelker has joined #openstack-keystone | 22:10 | |
*** markvoelker_ has joined #openstack-keystone | 22:10 | |
*** markvoelker has quit IRC | 22:14 | |
openstackgerrit | Merged openstack/keystone: Exposes bug on role assignments creation https://review.openstack.org/171596 | 22:18 |
*** henrynash has joined #openstack-keystone | 22:22 | |
*** ChanServ sets mode: +v henrynash | 22:22 | |
openstackgerrit | Merged openstack/keystone-specs: Adds a spec for fixing Keystone's DI https://review.openstack.org/135931 | 22:24 |
*** markvoelker has joined #openstack-keystone | 22:36 | |
*** thedodd has quit IRC | 22:36 | |
*** markvoelker_ has quit IRC | 22:37 | |
*** leonchio_ has joined #openstack-keystone | 22:37 | |
*** markvoelker_ has joined #openstack-keystone | 22:41 | |
lhcheng | morganfainberg: does this sounds like an rc potential? https://bugs.launchpad.net/keystone/+bug/1436324 | 22:43 |
openstack | Launchpad bug 1436324 in Keystone "Keystone is not HA with memcache as token persistence driver" [Medium,In progress] - Assigned to Boris Bobrov (bbobrov) | 22:43 |
lhcheng | the patch deprecates memcache as token persistence backend for Kilo | 22:43 |
*** markvoelker has quit IRC | 22:44 | |
lhcheng | not a high priority, but something we'd like to deprecate sooner | 22:44 |
jlk | leonchio_: ping, howdy! | 22:50 |
leonchio_ | @jlk hey jesse how's going? | 22:52 |
jlk | leonchio_: you know, busy as usual. only 3 or 4 simultaneous things going on this afternoon, so light load :) | 22:52 |
*** alexsyip has joined #openstack-keystone | 22:53 | |
*** edmondsw has quit IRC | 22:57 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 22:59 | |
*** nkinder has joined #openstack-keystone | 23:01 | |
*** henrynash has quit IRC | 23:06 | |
*** bknudson has quit IRC | 23:07 | |
*** zzzeek has quit IRC | 23:10 | |
*** chlong has joined #openstack-keystone | 23:10 | |
*** gordc has quit IRC | 23:11 | |
*** topol has quit IRC | 23:20 | |
morganfainberg | lhcheng, no not RC candidate | 23:25 |
morganfainberg | lhcheng, that is a fundamental problem with how memcache persistence works and a known long standing issue | 23:25 |
openstackgerrit | Merged openstack/keystonemiddleware: Fix s3_token middleware parsing insecure option https://review.openstack.org/173365 | 23:25 |
morganfainberg | lhcheng, i'd kill memcache persistence but people use it. | 23:25 |
lhcheng | morganfainberg: if people use it.. yeah, I understand not to push for RC. | 23:28 |
dstanek | are we interested in fixing https://bugs.launchpad.net/keystone/+bug/1333712 ? | 23:31 |
openstack | Launchpad bug 1333712 in Keystone "NotImplemented _for_groups functions on LDAP" [Wishlist,In progress] - Assigned to Marcos Lobo (marcos-fermin-lobo) | 23:31 |
morganfainberg | dstanek, uhm... sec | 23:31 |
morganfainberg | ok this isn't clear... this looks like another LDAP assignment bug | 23:32 |
morganfainberg | so my answer is the same as for the other one | 23:33 |
morganfainberg | dstanek, no. | 23:33 |
*** ayoung has quit IRC | 23:33 | |
morganfainberg | iirc CERN is moving off LDAP assignment | 23:33 |
dstanek | ok, i'll make it as won't fix | 23:34 |
openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Prompt for password on CLI if not provided https://review.openstack.org/173605 | 23:37 |
lhcheng | morganfainberg: this sounds like a good candidate for rc: https://bugs.launchpad.net/keystone/+bug/1401057 | 23:43 |
openstack | Launchpad bug 1401057 in Keystone "Direct mapping in mapping rules don't work with keywords" [High,In progress] - Assigned to Marek Denis (marek-denis) | 23:43 |
*** chlong has quit IRC | 23:43 | |
*** chlong has joined #openstack-keystone | 23:45 | |
dstanek | lhcheng: why do you think that? | 23:46 |
lhcheng | dstanek: lack of support for remote rules in the mapping engine.. | 23:49 |
lhcheng | dstanek: hmm reading the comments on the patch, seems like it has already been decided to move to L | 23:49 |
lhcheng | dstanek: should be fine to leave it as is then | 23:50 |
dstanek | lhcheng: ah, ok | 23:51 |
*** markvoelker_ has quit IRC | 23:54 | |
lhcheng | morganfainberg: finished going through the LP bugs, we got 8 rc potential and 3 are still being worked on in master. | 23:57 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!