Wednesday, 2014-03-12

openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Handle URLs via the session and auth_plugins  https://review.openstack.org/6075200:01
*** gokrokve has quit IRC00:04
openstackgerritJamie Lennox proposed a change to openstack/keystone: Change the default version discovery URLs  https://review.openstack.org/7806800:24
*** nkinder_ has joined #openstack-keystone00:24
openstackgerritJamie Lennox proposed a change to openstack/keystone: Change the default version discovery URLs  https://review.openstack.org/7806800:32
*** stevemar has quit IRC00:32
*** gokrokve has joined #openstack-keystone00:33
*** richm has quit IRC00:41
*** browne has quit IRC00:41
*** petertoft has joined #openstack-keystone00:46
*** mhu has quit IRC00:49
*** petertoft has quit IRC00:50
*** browne has joined #openstack-keystone00:52
*** zhiyan_ has quit IRC00:57
*** jraim has quit IRC00:57
*** zigo has quit IRC00:58
*** tellesnobrega has quit IRC00:58
*** huats has quit IRC00:58
*** mhu has joined #openstack-keystone00:58
openstackgerritA change was merged to openstack/keystone: Configurable temporary directory for tests  https://review.openstack.org/7921700:58
*** zhiyan` has joined #openstack-keystone00:58
*** jordant has quit IRC00:58
*** huats has joined #openstack-keystone00:58
*** huats has quit IRC00:58
*** huats has joined #openstack-keystone00:58
*** jraim has joined #openstack-keystone00:58
*** openstack has joined #openstack-keystone01:04
*** marcoemorais has quit IRC01:10
*** devlaps has quit IRC01:10
*** gokrokve has quit IRC01:17
*** mberlin1 has joined #openstack-keystone01:19
*** henrynash has quit IRC01:23
*** gokrokve has joined #openstack-keystone01:25
jamielennoxmorganfainberg, lbragstad, gyee, ayoung whoever else is here: can you have a look at https://review.openstack.org/#/c/77026/ and at least let me know if the approach is good01:25
ayoungjamielennox, I already acked that01:25
jamielennoxayoung: ah indeed01:26
jamielennoxis the gate particularly stuffed at the moment?01:26
ayoungjamielennox, what about dstanek_afk 's comment?01:26
*** zigo has quit IRC01:27
jamielennoxyea, i got that01:27
jamielennoxit does improve things01:27
*** zigo has joined #openstack-keystone01:33
*** dstanek_afk is now known as dstanek01:34
dstanekhey all01:34
dstanekjamielennox: i really like that positional decorator01:35
jamielennoxdstanek: excellent01:35
dstaneki'll go through it for a real review in a few01:35
jamielennoxme too - i really want to use it and i don't know why it's been sitting so long01:35
*** gokrokve has quit IRC01:38
dstanekjamielennox: do you have a few for some realtime questions? instead of me asking in the review?01:41
jamielennoxsure01:41
dstanekwhat do you plan on actually using it for?01:42
jamielennoxdstanek: there is a follow up patch where i start to use it01:42
jamielennoxthe point though is to seperate optional positional arguments and keyword arguments01:43
jamielennoxfor example with Session() i wanted the first parameter to be the auth plugin01:43
jamielennoxhowever in at least the first review there was no auth plugins yet01:43
jamielennoxso i gave it a bunch of kwargs, but now when i want to put in a positional auth argument it isn't backwards compatible01:44
*** gokrokve has joined #openstack-keystone01:44
dstanekjamielennox: is that protecting out code from calling it incorrectly or is it preventing 3rd party?01:44
jamielennoxdstanek: it's giving us a way to better define our public interfaces so others don't use them incorrectly01:45
jamielennoxdstanek: see also: http://legacy.python.org/dev/peps/pep-3102/01:46
jamielennoxwhich came in in python301:46
jamielennoxi'll see if i can find a beter link01:46
dstanekjamielennox: ok, that's what i thought - i just wouldn't want to see that used all over the place01:46
jamielennoxyea, it's for external interfaces just so we have some more control over them in future01:47
dstanekok, cool - the inspect line i gave you actually came from one of the pep8 checks i've been working on adding01:48
dstanekjamielennox: it doesn't look like POSITIONAL_NONE is actually used01:49
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Fixup region description uniqueness  https://review.openstack.org/7915901:50
jamielennoxit's not, it's there for completeness if you want to turn it off01:50
morganfainberglbragstad, posted updated review01:50
morganfainbergi could have done it with a temporary unique constraint on the migrate but i felt that it was too mechanical, the region.<attr> seemed fine for an insert() call instead of using a .add() call01:51
dstanekjamielennox: you would eventually add functionality to turn it off?01:55
ayoungdstanek, Its my fult.  I started nacking his patches due to him changing the order or params01:55
ayoungand I was the one that asked him to do it in the first place, too01:56
dstanek:-)01:56
morganfainbergdstanek, when you have a few, ^ the region uniqueness, any issues with that impl (this is something that is needed for I release)01:56
dstaneki'm just trying to understand it - didn't know if there was more to come or if it was something that should have been deleted with something else01:56
jamielennoxdstanek: not internally, but it's a library so you can set utils.postitional_enforcecement = utils.POSITIONAL_NONE from your app and disable the warnings01:56
morganfainbergjaypipes, ping ^ new spin on region unique description fix01:56
jamielennoxif you can flip between a warning and an error i figured you should be able to disable it as well01:57
dstanekmorganfainberg: sure i'll take a look in a sec01:57
jamielennoxand if you disable it then it's your own fault when something breaks later01:57
morganfainbergdstanek, yeah np, figured you would once the current convo was done01:57
jaypipesmorganfainberg: +1 from me.01:58
*** gokrokve has quit IRC01:58
jamielennoxi use that method because in testing i set utils.postitional_enforcecement = utils.POSITIONAL_EXCEPT so if you violate the rules in testing it fails01:58
jamielennoxbut defaults to a warning01:58
morganfainbergjaypipes, figured that since I hadn't shipped we could do an idempotent change for dropping the index and save the headache of making a table, make a temp table, migrate, drop, rename if we were just creating the region tables cleanly in the first place01:59
jaypipesyup.01:59
morganfainbergi have learned a good deal more about the ORM while I was at it01:59
*** gokrokve has joined #openstack-keystone02:01
dstanekjamielennox: that's actually an interesting feature - may be worth adding a line or two in the docstring02:01
openstackgerritA change was merged to openstack/keystone: Add missing documentation for enabling oauth1 auth plugin  https://review.openstack.org/7970802:07
*** mberlin has joined #openstack-keystone02:07
openstackgerritwanghong proposed a change to openstack/keystone: support conventional domain name with one or more dot  https://review.openstack.org/7982902:07
*** mberlin1 has quit IRC02:08
*** gokrokve has quit IRC02:14
*** gokrokve has joined #openstack-keystone02:15
*** gokrokve has quit IRC02:19
*** zigo has quit IRC02:19
gyeejamielennox, so we are using decorators to overcome the shortcomings of Python language? :)02:19
jamielennoxgyee: yes02:19
gyeenice02:19
jamielennoxi never found a good link, but in python3 you can do02:20
jamielennoxdef a(arg1, arg2, arg3='x', *, kwarg1='abc')02:20
jamielennoxwhich seperates default positional arguments from keyword only arguments02:20
jamielennoxi want that essentially02:21
jamielennoxits the runtime enforcement of bknudson's 'if it's a kwarg then use the keyword'02:21
gyeeha02:21
gyee++02:21
gyeebut then the drawback is that you'll have to specify it everywhere02:22
jamielennoxgyee: eh, only really those functions that take a lot of kwargs02:23
*** zigo has joined #openstack-keystone02:23
gyeepublic interfaces perhaps02:24
jamielennoxbut i'll do it if i can stop being concerned with backwards compatability for those interfaces02:24
jamielennox(as concerned)02:24
morganfainbergjamielennox, i like that feature02:25
gyeeI knew morganfainberg would like it :)02:25
gyeedoes it work with inheritance?02:27
jamielennoxit's a decorator, so it won't protect the child function but it will be protected when it calls super()02:28
jamielennoxit can't really do any better than that02:28
jamielennoxi don't think you can/should be able to enforce anything on deriving functions02:29
gyeejamielennox, seem like this is something we can incorporate into pep802:31
jamielennoxkwargs specified as keywords?02:31
jamielennoxhmm,02:31
gyeelike scan through all the funcs, automatically add the decorator, and print out any warnings02:31
jamielennoxnah, you'd need to do ast parsing to figure out what things allow what params02:32
jamielennoxoh02:32
jamielennoxi don't know how but it could be done02:32
gyeenot sure, was just thinking outloud02:32
lbragstadjamielennox: responed to your review02:35
jamielennoxlbragstad: thanks02:36
jamielennoxlbragstad: kind of02:36
jamielennox(in answer to question)02:36
jamielennoxif you do a @classmethod def(*args, **kwargs) the first arg is always going to be cls02:37
lbragstadjamielennox: ok cool, just curious02:37
jamielennoxso if you have def a(self, a, b='b') then you still need to account for self as one of the positional args02:37
jamielennoxso by default that's @positional(2) - self and 'a'02:38
lbragstadok, makes sense.02:38
lbragstadmorganfainberg: thanks for pushing another version of migration 043.02:39
lbragstadI appreciate it02:39
*** topol has joined #openstack-keystone02:39
ayoungWow, not having lookup by name SUCKS!02:40
ayoungbasically you have to do:   test_projects = admin_client.projects.list(name='hugeproject',02:42
ayoung                                               domain='default')02:42
ayoung    remove_users(admin_client, test_projects[0])02:42
gyeejamielennox, anyway, I don't feel strongly either way. I don't feel we necessarily need it as most of us a good at catching that stuff during code review now. But I don't object if others wants it.02:42
jamielennoxgyee: it's not about internal to the code02:42
jamielennoxgyee: it's so that we can add new positional arguments after a release has happened and not break compatability02:42
ayounggyee, it is explicitly not for our code02:42
ayoungit is for 3rd party apps that we break if we change things that were not meant to remain frozen02:43
gyeeadding keyword args won't break anything, but if we have to add positional args I would need it needs to be a different interface02:44
jamielennoxgyee: why? positional args can be optional02:44
ayoungmorganfainberg, I am running a script that creates and then destroys a slew of users, and It is slow.  ANd I am seeing a lot of kvs locks,  I suspect from the revoke backend02:44
ayoungKVS lock acquired for: os-revoke-events acquire /opt/stack/keystone/keystone/common/kvs/core.py:37502:45
morganfainbergayoung, likely02:45
ayoungit might prove to be a problem02:45
morganfainbergthat was why i was wondering if we could somehow not need to call syncronize on each call.02:45
morganfainbergerm each validate02:45
ayoungmorganfainberg, yeah...I would love to not have to do that02:45
morganfainberge.g. nothing changed, can we store something?02:46
ayoungof course we can02:47
morganfainbergi think that will speed that srtuff up a lot02:47
*** harlowja is now known as harlowja_away02:48
ayoungmorganfainberg, if last_fetch >  now - some_time_delta return02:49
morganfainbergayoung, ++02:49
morganfainbergyeah02:49
*** stevemar has joined #openstack-keystone02:50
*** gyee has quit IRC02:54
*** jordant has joined #openstack-keystone02:57
ayoungmorganfainberg, looks a lot better02:58
ayoungstill a lot of locking, running once per second02:58
*** amcrn has quit IRC03:05
*** david-lyle has joined #openstack-keystone03:09
morganfainbergayoung, i wonder if we could be even more aggressive on that03:18
ayoungmorganfainberg, probably,  5 seconds would be fine03:18
ayoungmaybe even 10 with no really window03:18
ayoungyou'll probably see some test fail, though03:19
ayoungcreate user, create token, delete user...token won't be revoked for 10 seconds03:19
*** rwsu has quit IRC03:19
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Fixup region description uniqueness  https://review.openstack.org/7915903:19
morganfainbergayoung, hmm...03:20
morganfainbergayoung, this almost feels like you should know if a new event came in, only actually sync the data if the event timer has changed.03:23
morganfainbergayoung, so you could avoid locking all together w/o a new event. obviously if you have a lot of events you'd syncronize each time.03:24
ayoungmorganfainberg, yeah.  I mean, we only need the backing store to record events03:25
ayoungwe could use the in-memory store as the cache and only go to the persisted store if the cache is invalidated, assuming a single keystone server03:25
morganfainbergaye.03:26
ayoungbut for multiple servers03:26
morganfainberghm.03:26
ayoungyou need to sync, and probably be a little sloppy about it due to time skew03:26
ayoungactually, we should record the time in the database03:26
morganfainbergor we could rip out that locking stuff and sync stuff and figure the right way to toss proper caching in front of it03:26
morganfainbergand then allow the use of memcache etc for that if you are using multiple servers (same way we allow caching on tokens)03:27
morganfainbergnot sure if that is a big win or not03:28
morganfainbergi don't think storing the last event timestamp in the db is the right answer03:29
ayoungjamielennox, is it supposed to be             admin_client.users.create(name=name, domain=test_domain)  or   admin_client.users.create(name=name, domain=test_domain.id)03:32
ayoungactually, I know from empirical that it is the former03:33
ayoungbut the later should fail, and it doesn't03:33
*** stevemar has quit IRC03:35
jamielennoxayoung: both should be fine03:36
ayoungsecond one dropped the domain...I think03:37
*** wchrisj has joined #openstack-keystone03:37
jamielennoxayoung: that's what bas.getid() does03:37
ayoungI'll see if I can reproduce03:37
ayoungI've got other problems, too03:37
ayoungoooh nasty little slipup03:38
ayoungif [Revoke]  gets commented out in the config file, but you try to set the driver, you accidentally set the token driver03:39
ayoungOk...gotta crash03:42
jamielennoxayoung: night03:43
*** petertoft has joined #openstack-keystone03:48
*** rwsu has joined #openstack-keystone03:50
*** petertoft has quit IRC03:53
*** dstanek has quit IRC03:54
*** zhiyan` is now known as zhiyan04:02
*** dstanek has joined #openstack-keystone04:02
*** gokrokve has joined #openstack-keystone04:05
*** wchrisj has quit IRC04:15
*** stevemar has joined #openstack-keystone04:20
*** petertoft has joined #openstack-keystone04:50
*** petertoft has quit IRC04:54
*** stevemar has quit IRC05:18
*** petertoft has joined #openstack-keystone05:51
*** petertoft has quit IRC05:55
openstackgerritJenkins proposed a change to openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/7852506:03
*** zoresvit1 has joined #openstack-keystone06:17
*** topol has quit IRC06:32
*** gokrokve has quit IRC06:46
*** saju_m has joined #openstack-keystone06:52
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Do not use keystone.conf.sample in tests  https://review.openstack.org/7952407:14
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Removal of test .conf files  https://review.openstack.org/7952507:14
openstackgerritMorgan Fainberg proposed a change to openstack/keystone: Move test .conf files to keystone/tests/config_files  https://review.openstack.org/7952607:14
*** jaosorior has joined #openstack-keystone07:17
*** bknudson has quit IRC07:24
*** bknudson has joined #openstack-keystone07:26
*** gokrokve has joined #openstack-keystone07:42
*** gokrokve has quit IRC07:47
*** zoresvit1 has quit IRC07:53
*** petertoft has joined #openstack-keystone07:53
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: LDAP global roles and group roles assignments  https://review.openstack.org/7656807:53
*** petertoft has quit IRC07:57
*** marekd|away is now known as marekd08:00
*** henrynash has joined #openstack-keystone08:01
*** gokrokve has joined #openstack-keystone08:13
*** henrynash has quit IRC08:14
*** morganfainberg is now known as morganfainberg_Z08:17
*** gokrokve has quit IRC08:18
*** amcrn has joined #openstack-keystone08:35
*** saju_m has quit IRC08:41
*** gokrokve has joined #openstack-keystone08:43
*** gokrokve has quit IRC08:47
*** amcrn_ has joined #openstack-keystone08:50
*** amcrn has quit IRC08:53
*** amcrn_ is now known as amcrn08:53
*** petertoft has joined #openstack-keystone09:03
*** zhiyan is now known as zhiyan_09:06
*** saju_m has joined #openstack-keystone09:09
openstackgerritMarek Denis proposed a change to openstack/keystone: Validate groups presence for federated authn  https://review.openstack.org/7928409:17
openstackgerritsagar pradhan proposed a change to openstack/keystone: Bug 1273273 :if run 'keystone-manage db_sync' without 'sudo', there should be a prompt that tables not created  https://review.openstack.org/7988909:22
*** henrynash has joined #openstack-keystone09:22
*** leseb has joined #openstack-keystone09:26
*** amcrn has quit IRC09:38
*** gokrokve has joined #openstack-keystone09:43
*** gokrokve has quit IRC09:48
*** zoresvit has quit IRC10:25
*** andreaf has joined #openstack-keystone10:26
openstackgerrithenry-nash proposed a change to openstack/keystone: Ensure v3policysample correctly limits domain_admin access  https://review.openstack.org/7989710:28
*** jamielennox is now known as jamielennox|away10:34
*** gokrokve has joined #openstack-keystone10:43
*** gokrokve has quit IRC10:48
*** henrynash has quit IRC10:48
*** saju_m has quit IRC10:49
*** henrynash has joined #openstack-keystone10:50
*** topol has joined #openstack-keystone10:50
openstackgerrithenry-nash proposed a change to openstack/keystone: Ensure v3policysample correctly limits domain_admin access  https://review.openstack.org/7989710:55
*** henrynash has quit IRC11:13
*** leseb has quit IRC11:19
*** leseb has joined #openstack-keystone11:20
*** leseb has quit IRC11:24
*** ChanServ changes topic to "test/gate jobs are queuing now in preparation for gerrit maintenance at 12:00 utc (eta to resume is 12:30 utc)"11:27
*** gokrokve has joined #openstack-keystone11:43
*** gokrokve has quit IRC11:47
openstackgerritsagar pradhan proposed a change to openstack/keystone: Bug 1230360 keystone-all --log-file logs to stdout  https://review.openstack.org/7990911:49
*** leseb has joined #openstack-keystone12:20
*** leseb has quit IRC12:23
*** leseb has joined #openstack-keystone12:23
*** david-lyle has quit IRC12:24
*** ChanServ changes topic to "gerrit on review.openstack.org is down for maintenance (revised eta to resume is 13:00 utc)"12:24
*** saju_m has joined #openstack-keystone12:38
*** gokrokve has joined #openstack-keystone12:43
*** zhiyan_ is now known as zhiyan12:47
*** gokrokve has quit IRC12:48
*** openstackgerrit has quit IRC12:54
*** openstackgerrit has joined #openstack-keystone12:54
*** henrynash has joined #openstack-keystone13:01
*** openstackgerrit has quit IRC13:08
*** openstackgerrit has joined #openstack-keystone13:08
*** browne has joined #openstack-keystone13:22
ayoungnkinder_, I just wrote this bug and assigned to you.  https://bugs.launchpad.net/keystone/+bug/129136613:23
*** haneef__ has joined #openstack-keystone13:25
*** haneef_ has quit IRC13:25
ayoungactually, I assigned to me, but lets discuss13:26
*** gokrokve has joined #openstack-keystone13:43
*** gokrokve has quit IRC13:48
*** wchrisj has joined #openstack-keystone13:51
openstackgerrithenry-nash proposed a change to openstack/keystone: Ensure v3policysample correctly limits domain_admin access  https://review.openstack.org/7989713:54
openstackgerritsagar pradhan proposed a change to openstack/keystone: Bug1273273 if run 'keystone-manage db_sync' without 'sudo', there should be a prompt that tables n ot created  https://review.openstack.org/7995013:55
ayounghenrynash, not sufficient13:56
henrynashayoung: meaning...13:57
ayounghenrynash, the domain_id field on the user object needs to be immutable13:57
henrynashayoung: Ok, so as I said I am going to put in a separate patch for that13:57
ayoungotherwise:  a domain admin can create a user in their domain,  then call update user...13:58
ayounghenrynash, how are you going to address it?13:58
henrynashayoung: but without a role on that domain they can't autneticate13:58
*** vhoward- has joined #openstack-keystone13:58
ayoungsomething like a policy on the update API that checks the target value of the domain id?13:58
henrynashayoung: so two ways we could address it...13:59
henrynashayoung: 1) as you say, policy…but I can't work out how to write a rule that says "If the domain_id is included in the update, then go check it is the same as the one in the object you are updating"14:00
ayoungthat sounds horrible and fragile.  So I assume you have a better idea14:00
henrynashayoung: as I say in the commit - I think we need to extend the policy engine to enable a check for existence of an attrinute14:00
ayounghenrynash, or we could just force domain_id to be immutable everywhere14:01
henrynashayoung: I was going to add a config option ("domain_id_immuatble") which meant we reject updates to user/group/project if the domain_id is being changed14:01
henrynashayoung: just like we do with id14:01
ayoungdo we have a config option for id, or just force it?14:01
henrynashayoung: no , we just force iyt14:02
ayoungsame with domain_id, I think, then14:02
henrynashayoung: my only concern was today you CAN change domain_id so we are changing functionality14:02
ayoungso what.  We are patching a security hole14:02
*** dims_ has quit IRC14:03
henrynashayoung: well, not if you use the standard policy file….since we don;t try and have domain admins etc.14:03
henrynashayoung: there is no "hole" in that case14:03
*** openstack has joined #openstack-keystone14:04
ayoungnah, just one big hole that we throw everything in to14:04
henrynashayoung: a pit, in fact14:04
ayoung"The PIT of DePAIR!":14:04
henrynashayoung: I'll propose it with the config variable…we can always remove that if general few is we should outlaw this (of course witt multi-backend you DEFINITELY don;t want to be able to do this)14:05
ayounghenrynash, so....the policy file makes sense to me14:05
ayoungquestion is whether we need to clean up the syntax to make this more usable in a wider setting14:05
henrynashayoung: I'll do it as a sparate patch.14:05
henrynashayoung: so I tried to do that a bit…open to suggestions14:06
ayoungyeah...need to think about it.  Might be something for the summit14:06
ayoungseems like a lot of that should be implicit14:06
henrynashayoung: maybe…ok, I'll propose a second defect/patch for the domain_id immuatbility14:07
ayounglike:  if I change something, I need perms for the pre and post states14:07
ayoungshould not be something configurable...it should be rigidly enforced14:07
ayoungpolicy should be simply:  you need this role to have the right permissions for this operation.14:08
*** fungi has joined #openstack-keystone14:08
*** ChanServ sets mode: +o fungi14:08
ayounghenrynash, this is why I like LDAP14:08
*** fungi changes topic to "[ Icehouse RC blockers https://launchpad.net/keystone/+milestone/icehouse-rc1 ][ Icehouse RC Target Date: March 27th, 2014 ]"14:08
ayoungACLs are tough to master, but they make it really hard to expose info unintentionally14:08
henrynashayoung: yeah, undestand14:08
*** ChanServ sets mode: -o fungi14:08
*** fungi has left #openstack-keystone14:08
*** stevemar has joined #openstack-keystone14:09
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleanup keystoneclient tests  https://review.openstack.org/7973014:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleanup fixture data added to test instances  https://review.openstack.org/7972914:10
dolphmlbragstad: just realized i meant nullable=False on https://bugs.launchpad.net/keystone/+bug/127245914:11
*** daneyon has joined #openstack-keystone14:12
lbragstaddolphm: ++ I was thinking that is what you meant14:12
ayoungdolphm, I think that the lock for synchronize revocation events is going to become a performance bottleneck14:13
ayoungI am running some client code and the difference between checking it each time and only synchronizing once a second is significant14:14
dolphmayoung: i would imagine that to be the case14:15
*** dims_ has joined #openstack-keystone14:16
ayoungdolphm, I'm fairly certain that adding a delay in chacking will 1.  break unit tests 2.  make no real difference in security 3.  sped things up14:16
ayoungquestion is if there is a different way to mitigate14:16
ayoungwe can't assume that there is only one keystone server14:16
ayoungor that it isn't running in multiple workers, so there needs to be some interprocess synchronization14:16
dolphmayoung: leave the delay configurable and advance the the clock in unit tests to trigger it when necessary14:17
ayoungI could make it a config value, set it to 0 for the unit tests, and have an explicit unit test for the cases where it is not 0 as well14:17
ayoungOK14:17
dolphmayoung: and i thought it was configurable?14:17
ayoungdolphm, the delay?14:18
ayoungJust hacked it in last night14:18
dolphmayoung: oh..14:18
dolphmayoung: let me look at the code, i guess i'm thinking of something else14:18
ayoungdolphm, that is the "last_fetched"14:18
ayoungso I can use that as the start of the sync delay14:19
ayoungdolphm, http://paste.openstack.org/show/73252/14:19
*** chandan_kumar has quit IRC14:22
openstackgerritsagar pradhan proposed a change to openstack/keystone: keystone-all --log-file logs to stdout  https://review.openstack.org/7990914:22
dolphmayoung: makes sense, although i feel like it should read self._last_fetch < timeutils.utcnow() - delta ?14:23
ayoungdolphm, sure.14:24
*** chandan_kumar has joined #openstack-keystone14:25
ayoungdolphm, CONF.revoke.fetch_delay ?14:25
dolphmayoung: for the delta?14:25
*** gokrokve has joined #openstack-keystone14:25
ayoungyeah14:26
dolphmayoung: from a deployer perspective, your configuring the duration of cache validity -- it only happens to be implemented as a sort of "delay"14:26
ayoungdolphm, CONF.revoke.cached_duration ?14:27
*** browne has quit IRC14:27
ayoungdolphm, CONF.revoke.cache_duration ?14:27
dolphmayoung: i'd make it look like all the other dogpile config, and then eventually replace the lock, etc, with a one liner call to dogpile14:27
ayoungah14:27
ayoungdon't want to pickle the tree each call14:28
dolphmayoung: that's why there are different backends for dogpile14:28
*** cmart has joined #openstack-keystone14:30
*** david-lyle has joined #openstack-keystone14:30
ayoungdolphm, OK, makes sense.14:31
*** browne has joined #openstack-keystone14:32
ayoungcmart, ask in here....Private messages mean that the smarter people can;t respond14:34
cmartOh I see... OK14:35
cmartI put some comments on the whiteboard related to the bp: https://blueprints.launchpad.net/keystone/+spec/tenant-14:35
dolphmhenrynash: why is https://bugs.launchpad.net/keystone/+bug/1291393 targeting RC1? i don't want to introduce breaking changes right now14:35
cmartI'm trying to dig into the code and see what things we should consider for the bp. If you can take a look at them, that would be great14:35
cmartme either, but I'm just trying to understand the working items that ayoung mentioned in that bp14:36
cmartthat's all14:36
cmart I'm new with Keystone and your feedback about this is imperative for me :)14:36
dolphmhenrynash: looks like wishlist + juno to me14:36
henrynashdolphm: so my place was to use a config variable domain_id_immutable that would be set to False by default (i.e. no change to the existing behaviour), but could be set to True to harder14:37
ayounghttps://blueprints.launchpad.net/keystone/+spec/tenant-expiration-dates14:37
henrynashharden14:37
ayoungcmart, its the wrong approach14:37
cmartayoung, I'm listening  (reading) :)14:37
henrynashdolphm: and for Juno we might state that this switched two be True by default14:37
ayoungyou want to have the whole thing managed outside of Keystone, via Heat, if the goal is to have " a limited time offer"14:38
*** topol has quit IRC14:38
ayoungyou are going to have to make a decisions "ok, times up, do we delete all of your resources, or just disable them"14:38
dolphmhenrynash: approach sounds good, but still sounds like wishlist + juno to me14:38
ayoungI mean, the specific feature, sure, sounds good14:39
stevemardolphm, question about revoking token based on idp deletion14:39
henrynashso this came out of bug #1287219 when I discovered it could not fix this by policy alone14:40
ayoungbut the general "we want to offer you a limited term freebee, and then you pay to extend" requires integration, and we should not be building keystone around that model.  Not that Keystone shouldn't support it14:40
*** chandankumar_ has joined #openstack-keystone14:40
dolphmcmart: keystone already exposes all the machinery (project enable/disabled), immediate token revocation, etc, that you need to take advantage of... i don't see much of a need to support "expiration dates" inside keystone itself14:40
*** chandankumar_ has quit IRC14:40
henrynashdolphm: I think ideally it would be with getting the change into rc1 (disabled by config) since it closes a potential nasty hole in our v3 domain admin policy protection14:42
henrynashdolphm: sorry for poor typing….multi-tasking14:42
stevemardolphm, if we used revocation extension to delete federation tokens, aren't we depending on something that is optional?14:43
bknudsonhenrynash: it would be a security vulnerability if it wasn't fixed?14:43
henrynashbknudson: a potential one…..if you are using the v3 policy to create a domain admin scope of use14:44
cmartdolphm, that idea came from a discussion that we have with ayoung in the mailing list. (http://markmail.org/message/asrlobgh3ajqju7b)14:45
cmartif that's OK for you, we can discuss it..14:46
dolphmhenrynash: if that's how you're approaching it, then definitely document that in the bug14:50
dolphmcmart: yes, i saw the conversation when it occurred14:50
*** thedodd has joined #openstack-keystone14:50
dolphmhenrynash: (specifically, how to exploit the "security hole" -- otherwise it just reads as a wishlist bug)14:52
cmartayoung, So your saying that we should support the functionality  but not build it around Keystone, Is that it? I'm not a native speaker, so there are couple of things of what you write that I don't quite understand. Sorry for that14:52
*** andreaf has quit IRC14:52
dolphmcmart: i'm a native speaker and i don't understand half of what ayoung writes ;)14:52
marekddolphm:  :D14:53
henrynashdolphm: will add14:53
ayoungcmart, I'm saying that "project start times and end times" by itself is a reasonable feature.  What I am also saying is that the "limited time offer"  functionality that someone said that they wanted it for (don't think it was you, don't remember) will require a lot more external work14:54
ayoungso I'd be hesitant to put too much effort into something that was "neither necessary nor sufficient" for the requirement14:54
*** casanch1 has joined #openstack-keystone14:54
ayoungdolphm, it is because I am a fancy-shmancy northeast intellectual and y'all are a no-nonsense, straight-talking Texan.14:57
dolphmlbragstad: morganfainberg_Z: what's with the change to migration 37? :( https://review.openstack.org/#/c/79159/14:58
dolphmayoung: +++14:58
lbragstaddolphm:  I think morganfainberg_Z added that in place of the downgrade.14:59
dolphmlbragstad: oh weird...15:00
lbragstaddolphm: the way I had it written originally, it pretty much just reverted the upgrade and if we had an sql.exc.IntegrityError because the descriptions of two regions weren't unique, I just made a new description with the uuid and the original description15:01
*** marcoemorais has joined #openstack-keystone15:01
*** marcoemorais has quit IRC15:01
lbragstaddolphm: I *think* morganfainberg_Z was coming at it from the vantage point that we didn't want to reintroduce the problem on downgrade.15:01
*** gokrokve has quit IRC15:02
*** gokrokve has joined #openstack-keystone15:03
dolphmlbragstad: i would have done it like you had it originally... but i think i understand what's going on now15:03
*** saju_m has quit IRC15:03
cmartayoung, that someone is casanch1, he just connected to the room.. and the module that will use the functionaliy will be Blazar (ex-Climate)15:03
lbragstaddolphm: ok, good deal. morganfainberg_Z will probably be able to explain his reasoning a little better than I did. :)15:04
*** saju_m has joined #openstack-keystone15:04
*** gokrokve_ has joined #openstack-keystone15:04
dolphmlbragstad: i just auto -1'd based on the change to 37, but i'm glad i asked!15:05
marekddstanek: o/ I didn't know testing data is loaded always before executing each test. Good to know that. I removed that questionable line that was reverting old mapping.15:05
cmartayoung, but I'm not getting your point.. I never talk about limited time offer.. I'm justr trying to get feedback and implementation hints related to the bp..15:05
lbragstaddolphm: ++15:06
cmartmaybe I'm confused, I don't know :S15:07
dolphmlbragstad: so old37 -> 43 -> 36 -> new37 -> 43 looks like it's handled, but not tested (not sure how we would test though)15:07
*** richm has joined #openstack-keystone15:08
*** gokrokve has quit IRC15:08
lbragstaddolphm: in the test I suppse we could mock out the behavior of the old3715:08
lbragstadand create a region table with description unique=True and nullable=False and use that as our old37 migration?15:09
bknudsonwhy is it necessary to change the migration?15:10
lbragstadbknudson: morganfainberg_Z added the change to migration 37 to work around introducing the unique=True problem on downgrade.15:11
lbragstadbknudson: he has a comment on downgrade() in migration 043,15:11
* lbragstad makes a note to add a tempest test for region description uniqueness15:12
bknudsonI don't think migrations should work that way15:12
openstackgerritMarek Denis proposed a change to openstack/keystone: Validate groups presence for federated authn  https://review.openstack.org/7928415:12
*** topol has joined #openstack-keystone15:13
lbragstadbknudson: originally, I just stuffed everything for region.description back into the region table with unique=True on the description column15:13
bknudsonlbragstad: that sounds like the right way to do it.15:15
lbragstadbknudson: if you want to leave a comment on the review, and we can try and sync up with morganfainberg_Z a little later when he's available?15:16
bknudsonlbragstad: I left a comment on the review.15:16
lbragstadbknudson: thanks15:16
bknudsonlbragstad: you're the owner of the review.15:17
lbragstadbknudson: yep15:17
*** topol has quit IRC15:18
cmartayoung, Are you there?15:18
*** henrynash has quit IRC15:20
ayoungcmart, as I said, it was notyou that asked about it.  Just that was one justification for this feature.15:21
*** leseb has quit IRC15:23
*** chandan_kumar has quit IRC15:26
*** chandan_kumar has joined #openstack-keystone15:28
*** chandan_kumar has quit IRC15:28
*** browne has quit IRC15:28
*** gyee has joined #openstack-keystone15:31
dolphmayoung: the one bug you have already have a patch for, and you don't even assign it to yourself? :P https://bugs.launchpad.net/keystone/+bug/129142315:35
ayoungdolphm, nope15:35
ayoungdolphm, I am going to let morganfainberg_Z deal with it, since you said it was a dogpile issue.  :)15:35
cmartayoung, What do you suggest about the bp? Should we continue the analysis? What could be the next steps around that?15:37
ayoungcmart, why do you want the feature?15:39
*** browne has joined #openstack-keystone15:39
*** saju_m has quit IRC15:40
dolphmayoung: for https://launchpad.net/climate15:41
cmartayoung, we have a bp on Blazar(https://blueprints.launchpad.net/climate/+spec/tenant-reservation-concept) in which the idea is manage all the leases associated to one tenant..15:42
dolphmcmart: and what about that use case can you not implement in climate? what is the critical piece that's missing from keystone?15:44
*** browne has quit IRC15:44
cmartwell,. there's no critical piece missing in Keystone15:45
cmartbut since this information was needed, we thought that it could be stored in Keystone15:45
cmartand moreover, that could be useful for keystone without having climate or any other reservation component in the picture15:45
cmartthis could be done in climate itself, but it made sense (at least for me) to store the tenant information in Keystone15:46
ayoungcmart, first off, they are projects, not tenants.  We're trying to clean up that language.15:47
cmartyes, my bad15:47
ayoungBut more important:  a feature for only one use case is risky15:47
ayoungKeystone is a general purpose service, and lots of people have proposed storing stuff in there that doesn't belong15:48
ayoungfor example, Horizon preferences for UI and such15:48
cmartso, do you think that having project start and end dates in Keystone is not a good idea?15:49
ayoungright now we have enabled/disabled.  Seems like it is a business rule to switch that to date based, and I'm not convinced15:49
ayoungI'm not saying no, just that I have not seen enough to get me to yes15:50
*** browne has joined #openstack-keystone15:50
cmartwell... this can be implemented only in climate and store those start and end dates in that db, that can be done for sure15:51
ayoungcmart, see if other projects have a need for the same feature, and build the case for it if you really want it.  There is no rush, and nothing that can't be postponed.15:52
ayoungone benefit to keeping in climate is that it would work with older versions of Keystone15:53
cmartok, I will do that15:53
cmartand will switch to work on climate for this15:53
cmartthanks for all the feedback!15:54
cmartand sorry for the bad english!!15:55
*** gyee has quit IRC15:59
*** leseb has joined #openstack-keystone16:01
*** henrynash has joined #openstack-keystone16:07
*** daneyon has quit IRC16:12
*** daneyon has joined #openstack-keystone16:12
*** gordc has joined #openstack-keystone16:19
gordcstevemar: ping16:19
*** dstanek_afk has joined #openstack-keystone16:19
*** dstanek has quit IRC16:20
*** dstanek_afk has quit IRC16:24
*** gokrokve_ has quit IRC16:25
*** devlaps has joined #openstack-keystone16:26
*** jaosorior has quit IRC16:30
stevemargordc, pong16:33
gordcstevemar: can you connect to the lab?16:34
stevemargordc, nope16:34
stevemargordc, it started before the scrum, booo16:35
gordcstevemar: cool cool. time to relax.16:35
*** dstanek_afk has joined #openstack-keystone16:35
gordcstevemar: yeah, i had to dial in with cell. my ip phone went down too.16:36
stevemargordc, yeah, just verified with another person, it's down for them too16:39
gordcstevemar: wicked.16:39
*** amcrn has joined #openstack-keystone16:42
*** gyee has joined #openstack-keystone16:49
*** gokrokve has joined #openstack-keystone16:50
*** marcoemorais has joined #openstack-keystone17:02
openstackgerritMarek Denis proposed a change to openstack/keystone: Validate groups presence for federated authn  https://review.openstack.org/7928417:03
*** harlowja_away is now known as harlowja17:04
stevemargordc, it works again17:04
gordcgordc: cool cool. perfect time to grab lunch. :)17:06
*** mpetason has joined #openstack-keystone17:09
*** gokrokve_ has joined #openstack-keystone17:09
*** andreaf has joined #openstack-keystone17:11
*** marcoemorais has quit IRC17:11
*** henrynash has quit IRC17:11
*** gokrokve has quit IRC17:12
*** henrynash has joined #openstack-keystone17:13
*** henrynash has quit IRC17:13
*** morganfainberg_Z is now known as morganfainberg17:13
*** marcoemorais has joined #openstack-keystone17:13
*** casanch1 has quit IRC17:15
*** casanch1_ has joined #openstack-keystone17:16
*** casanch1_ is now known as casanch117:16
*** saju_m has joined #openstack-keystone17:17
morganfainbergbknudson, hi17:17
bknudsonmorganfainberg: hi17:17
morganfainberglbragstad, bknudson, what is the issue with the downgrade issue?17:17
*** casanch1 has left #openstack-keystone17:18
bknudsonmorganfainberg: we can't change existing migrations17:18
morganfainbergbknudson, yes we can in this case.17:18
bknudsonmorganfainberg: otherwise we could have different versions of the database out there.17:18
bknudsonI don't want to have to deal with that.17:18
morganfainbergif you look at the code we will always end up with the same version of the db17:18
bknudsonmorganfainberg: not at level 3717:19
morganfainbergok, i take that back, if you migrate ½ way thought i and never move, yes you have a different version17:19
morganfainbergis that _really_ a case we expect?17:19
bknudsonyou could have one system is 37 is unique=True and another is 37 and unique=False17:20
lbragstaddolphm: discussing migrations17:20
lbragstad037 and 043, since we were talking about htat earlier17:20
dolphmmorganfainberg: lbragstad: o/17:20
morganfainbergthen remove the extra logic17:20
morganfainbergit is, imnsho, really dumb to migrate to a unique index'd table then respin to a non-unique indexed table within the same release. but if we can't do it17:21
morganfainbergremove that.17:21
bknudsonit's unfortunate, but we can't do it.17:22
morganfainbergif we are doing this we can't do the buffer for backport, it's the same argument17:22
morganfainbergwell we shouldn't17:22
bknudsonit would only be able to be used in the most extreme situation17:22
morganfainbergbknudson, i believe that with idempotent changes we should be able to do this within a release17:22
morganfainbergand yes, i'm willing to argue that w/ the TC if needed.17:23
morganfainbergbridging across releases, no17:23
dolphmmorganfainberg: i agree (and i don't know why anyone would want to continuously deploy keystone) but people claim to do so17:23
morganfainbergeven w/ CD this would have a net positive result17:24
dolphmmorganfainberg: the last time we rewrote any migration history was during grizzly development i believe, and we got a complaint or two about it17:24
dolphmmorganfainberg: your change is graceful compared to what we did in grizzly17:24
morganfainbergdolphm, i'll argue this one17:25
dolphmwhich was simply to fix a broken migration without writing a new one17:25
morganfainbergdolphm, but if the answer is no, just pull the code out17:25
dolphmmorganfainberg: personally i'm comfortable with your change and ready to +217:25
morganfainbergadding in a unique contraint back in is easy, though we don't want to reverse the migration, just apply a unique index17:25
morganfainbergdolphm, like i said, i'm happy to back down, but if you need arguing, i will :)17:25
dolphmmorganfainberg: ... which might crash17:26
bknudsonre-applying the unique index is probably going to crash17:26
morganfainbergbknudson, ?17:26
dolphmbknudson: ++17:26
morganfainbergoh crud didn't even realize i worked around that17:26
bknudsonmorganfainberg: expect a downgrade that adds the unique index to not work.17:27
morganfainberg:P17:27
bknudsonespecially for a field like description that I wouldn't expect to be unique.17:27
morganfainbergit just made sense to never re-add the unique index.17:27
morganfainbergderp.17:27
* dolphm +2'd but didn't approve17:27
morganfainbergbknudson, ++17:27
morganfainbergso ... how would you conflict resolve?17:27
morganfainbergcan't drop regions17:27
morganfainbergjust add some garbage into the description?17:28
bknudsonmorganfainberg: you don't. You fail and complain that we can't downgrade.17:28
morganfainbergbknudson, i vote against that.17:28
morganfainbergbknudson, personally.17:28
morganfainbergit means if you upgrade to I you can't go back to H17:28
morganfainbergit's a restore from backup17:28
bknudsonyou can go back. You have to resolve the migration problem yourself.17:28
morganfainbergprecluding running the service that is17:28
bknudsonyou can add garbage to your descriptions if that's what you want.17:29
morganfainbergeh i guess my usecase is the edge17:29
morganfainbergwell, i'm content to let it crash and raise an error if that is what is needed17:29
morganfainbergs/crash and raise/make a pretty error that says you can't do this.17:30
dolphmbknudson: why not just have a more stable migration path?17:30
lbragstadwouldn't you be able to use the existing description and hte uuid of the region to make a unique description if you do have a conflict?17:30
bknudsondolphm: I'm worried that we've got a database schema that people might have been running and testing with since migration 37 ... vs a new change that we haven't been running with17:31
bknudsondolphm: and, we'll have a bunch of situations that we've never tested with, such as the ones that are 37-41-before-this and 37-41-after this.17:32
bknudsonoops, should be 37-4317:32
dolphmbknudson: i believe morganfainberg's patch handles those situations really well17:32
*** cmart has quit IRC17:33
dolphmi'd argue that migration 37 contains a bug, which morgan's patch fixes17:33
dolphmif you were subject to the buggy version of the migration, migration 43 will fix your schema17:33
dolphmand the bug never sees a proper stable release17:33
morganfainbergdolphm, ++ that is my arguemnt17:33
morganfainbergif this was across releases i would -2 this change17:34
morganfainberge.g. H to I17:34
morganfainbergi can't make a solid argument for that.17:34
bknudsonwhy don't we just squash all the migrations down to 1?17:34
dolphmfwiw, there is an accepted precedence in the community for correcting bugged migrations, even when they're old17:35
bknudsonI guess I just don't see how bad it is to keep the migration as it was?17:36
morganfainbergdolphm, bknudson, it's a quick respin to solve the rewrite history issue, but i still think 037 is bugged17:36
dolphmbknudson: would you accept the argument that morganfainberg's version of the patch is less risky since there's less code to go wrong? (vs patchset 1)17:36
bknudsonthere's not much code in patch set 1.17:37
dolphmbknudson: patchset 4*17:38
bknudsonwell, patch set 1 is broken anyways since it has hardcoded sql.17:38
morganfainbergbknudson, and i'll fix that in J17:38
morganfainbergwe'll start at 03617:38
*** openstackstatus has quit IRC17:38
morganfainbergbut. anyway17:38
*** openstackstatus has joined #openstack-keystone17:38
* bknudson is in a meeting for a while17:39
morganfainbergdolphm, i feel like we have precedent in either case.17:39
bknudsondolphm: where's an example where we changed an existing migration?17:40
morganfainbergdolphm, so, i'm good with either solution. I am positive fixing the bug is the right way, but it's not worth massive quibbling over (we have plenty else to work on)17:40
morganfainbergjamielennox|away, did you need me to fix the kite repo stuff for you?17:41
bknudsonif we change a migration and it causes any kind of problem there are going to be a lot of questions asked.17:41
morganfainbergjamielennox|away, i'm happy to do so, just let me know17:41
bknudsonwe'll be banished or even shunned.17:41
dolphmbknudson: (i assume you mean where it's documented as an acceptable practice)17:43
dolphmi ran into this, but it's entirely written with regard to running migrations online https://wiki.openstack.org/wiki/DBMigrationBestPractices17:44
bknudsondolphm: yes, just seeing what's an acceptable reason to change a migration.17:44
morganfainbergoh live migrations would be awesome.17:44
morganfainbergbut... uhhh17:44
dolphmlol17:44
bknudsonnot something we've tried to achieve17:45
dolphmi'd be happy to do live migrations if someone wants to properly test us and gate us against them17:45
bknudsonalthough it should work in this case.17:45
dolphmuntil then, i have zero interest in pretending17:45
morganfainbergdolphm, i would love to do that. but before we do that we have some other things to deal with.17:45
morganfainbergdolphm, and i bet it would take us 2+ releases to get all the scaffolding in to properly make it happen.17:46
morganfainberglet alone tempest etc.17:46
dolphmyeah17:46
* morganfainberg sees using something like a protobuf as the core data mechanism within keystone to get there.17:47
morganfainbergthen db is just persistence, pull it all apart and put it back together.17:47
morganfainbergnot that protobuf is the tech to use.17:47
morganfainbergbut something kindof like it17:47
stevemarcan i get another review for https://review.openstack.org/#/c/73031/ it's already passed the blk-u test17:48
morganfainbergstevemar, oh i need to find a -1 reason now :P17:49
morganfainbergstevemar, sure. will look at it in a few17:49
stevemarmorganfainberg, btw - your comment "but I want to do one more pass on it vs keystone's oauth1 extension"17:49
stevemarmorganfainberg, 'splain? did you want me to write a python script to test it out or something?17:49
morganfainbergdolphm, so, lets just make a call on the migration, i think we've already spent more time than it warrants17:50
dolphmstevemar: morganfainberg: approvaled stevemar's change17:50
stevemaryahoo17:50
morganfainbergstevemar, nah, i just didn't want to +2 w/o having a sec to revisit keystone oauth1 in my head so i saw how ksc played w/ it17:50
stevemarmorganfainberg, ah okay17:50
dolphmmorganfainberg: so, the specific complaint i got last time (sorry for not being able to cite bknudson, i gave up searching)...17:51
*** Fin1te has joined #openstack-keystone17:51
dolphmmorganfainberg: was that we fixed a bug in a migration while leaving those chasing master in the dust (with a broken schema)17:51
morganfainbergstevemar, i was brain fried. nothing looked wrong but since it was late and all, didn't feel good +2/+A17:51
stevemarmorganfainberg, i might make one anyway, i saw ayoung do that in https://review.openstack.org/#/c/79096/1/examples/scripts/exercise_v3_regions.py and thought it was a good idea17:51
morganfainbergdolphm, ah, yeah17:51
dolphmmorganfainberg: this obviously isn't that scenario, so +217:51
morganfainbergdolphm, and i stand by if we were across stable releases this kind of stuff couldn't fly17:51
morganfainbergbarring a MASSIVe bug that needed a backport17:52
ayoungstevemar, oh yea17:52
*** mpetason has left #openstack-keystone17:52
ayoungstevemar, I have a better version of that coming up17:52
dolphmmorganfainberg: yeah, it'd have to be more broken than this to warrant this type of approach17:52
morganfainberga unique constrained column != massive17:52
morganfainbergdolphm, sounds good, let me know if we need to respin to downgrade and add the unique index constraint back in17:52
morganfainbergdolphm, otherwise i'll leave it (though this does need to land in I imo)17:53
dolphmmorganfainberg: going to cite IRC logs here and +A17:53
morganfainbergdolphm, ++17:53
marekddolphm: stevemar ayoung bknudson dstanek_afk lbragstad: Gents, another round of: https://review.openstack.org/#/c/79284/?17:53
*** dstanek_afk is now known as dstanek17:53
morganfainbergmarekd, i almost feel left out :P17:53
morganfainbergmarekd, >.>17:53
ayoungmarekd, -2.  Now stop bothering me.  Just kidding.  Looks good.17:54
marekdmorganfainberg: especially for ya: another round of https://review.openstack.org/#/c/79284/ ? :-)17:54
morganfainbergdolphm, for the test config stuff, lets plan for that to hit J1 during the "quiet" time.17:54
morganfainbergso the massive test restructuring doesn't get in the way, and it gets us a lot closer to parallel testing17:55
morganfainbergdstanek, ^ (for my changes)17:55
ayoungmarekd, once again, though, are you really really absotutapositicompletly sure you want this?17:55
morganfainbergdstanek, so, lets chase yours in first since i think they will provide more immidiate benefit17:55
dolphmmorganfainberg: lbragstad: bknudson: approved17:56
dolphmmorganfainberg: dstanek's patch?17:56
marekdayoung: i think we got through this yesterday and it's not only my opinoin that this could be useful...17:56
dolphmmorganfainberg: adopt oslotest j1 day 1?17:56
morganfainbergdolphm, no mine, i have a chain that rips out most test configs17:57
dolphmmorganfainberg: link?17:57
dstanekmorganfainberg: chase which one?17:57
morganfainbergdolphm, https://review.openstack.org/#/c/79524/ https://review.openstack.org/#/c/79525/ https://review.openstack.org/#/c/79526/17:57
marekdayoung: i guess there are also other cores who think this should be landed, so you can let them decide :-)17:57
dolphmdstanek: ooh, we should hold your oslotest series for j1 anyway, given it introduces a new dep post-freeze17:57
marekdayoung: just please don't -2 it :-)17:57
morganfainbergdolphm, oh his whole change is oslotest isn't it17:57
morganfainbergdstanek, doh! i was aiming for yours to land since they would conflict with my chain17:58
morganfainbergdolphm, ^17:58
morganfainbergdolphm, dstanek, then land the massive test config changes in J1.17:58
dstanekdolphm, morganfainberg: i can rebase most of my memory patches on current master instead of the oslstest change17:58
dolphmmarekd: IIRC, you satisfied ayoung's objection already in the current patchset17:58
marekddolphm: yes17:58
dolphmdstanek: that'd be handy :)17:59
morganfainbergmarekd, if everyone else is on board with this, i'm willing to give it a go.17:59
ayoungmarekd, I won't -2.  But I do think that it is a mistake17:59
morganfainbergmarekd, i am not sure i like the solution (might be more in ayoung's camp) but i am unsure if there is a better one readily available17:59
morganfainbergor that we could land before I ships18:00
morganfainbergor if we even need this.18:00
ayoungI think that somoene is going to want to use Federation as intended, and won't care that the groups aren't in identity, and will go to fix it and be tripped up by this change and reverse it18:00
morganfainbergi _think_ forcing the use of identity in this case is probably wrong.18:00
morganfainbergbut i can see why there is a desire to control the groups18:01
ayoungmorganfainberg, marekd let me ask the real question18:01
ayoungif I don;t have anything in Identity, will SAML still work today?18:01
dstanekdolphm: shouldn't take long, just a little wierd because there will be a dependency on a class that doesn't exist18:01
ayoungno users, no groups, just data from the SAML assertion18:01
ayoung?18:01
ayoungand the mapping, of course?18:02
morganfainbergdstanek, ++ I would like to land your fixes in I.18:02
marekdayoung: so if you are okay with "id don't care" approach i'd recommend check groups and only log a warning, something that may help admins debug their configs...something i proposed at the beginning and you wanted to return HTTP 500, which has a real impact on that...18:02
morganfainbergdstanek, we can do the oslotest and the config destroying in J18:02
*** marcoemorais has quit IRC18:02
*** marcoemorais has joined #openstack-keystone18:03
dstanekmorganfainberg: it would be nice to run the full test suite while i am working on bugs18:03
marekdif i was to decide i'd leave warnings instead of raising HTTP 500 errors.18:03
ayoungmarekd, I need an answer to my question before we can move on.  Will it work?18:03
dolphmayoung: no it won't work at all18:04
*** marcoemorais has quit IRC18:04
dstanekmorganfainberg: what's funny is i'm going to rebase these commits and i can't properly test the first few because i'll run out of memory18:04
*** marcoemorais has joined #openstack-keystone18:04
dolphmayoung: you'd be able to generate unscoped tokens i believe, but you'd be unable to acquire any sort of authorization as there's no authorization to map to18:04
morganfainbergdstanek, lol18:04
marekddolphm: ++18:05
ayoungdolphm, marekd ok, ignoring this change, what would it take to make it work?18:05
marekdayoung: depends what you want, map saml2 assertion directly to the rules?18:05
marekdblah18:06
marekds/rules/roles18:06
dolphmayoung: federation is currently intended to provide a authentication frontend to our existing authorization infrastructure; i'd love to see federation completely replace that entire authorization infrastructure all the way through auth_token and oslo policy, but that's an *extensive* redesign that we simply did not pursue during icehouse as it would be completely incompatible with everything about existing keystone de18:06
dolphmployments18:06
ayoungdolphm, OK.  So with that understanding, I'm ok with marekd 's change.  But it will be yet another thing to work around when the time comes to do the reworking.18:07
ayoungmarekd, the change itself looks good18:07
morganfainbergdolphm, that is a good description that clarifies these needs18:07
dolphmayoung: all this code would be out of the picture -- you wouldn't have to contact keystone at all18:07
marekdayoung: i need to run in 15 minutes, can we talk about that 'redesign' thing tomorrow?18:07
ayoungmarekd, hows about at the summit instead?18:08
marekdayoung: ah, sure!18:08
dolphmayoung: +++18:08
marekdayoung: thought you wanted to do it right about now18:08
ayoungnope18:08
morganfainbergdstanek, want me to run the tests? i can do it18:08
marekdayoung: worth proposing a design session ?18:08
ayoungjust making sure we are all on the same beat18:08
ayoungmarekd, thought I already did?18:08
marekdayoung: http://summit.openstack.org/cfp/details/6 ?18:09
ayoungmarekd, http://summit.openstack.org/cfp/details/718:09
morganfainbergmarekd, yes the code looks good to me18:09
marekdmorganfainberg: thanks.18:09
ayoung6 is for the Id thing that henrynash was working on...but we have quite a few sessions already, so maybe they will get merged18:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Very minor cleanup to default_fixtures  https://review.openstack.org/8004018:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleanup backends after each test  https://review.openstack.org/7972618:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleanup of instance attrs in core tests  https://review.openstack.org/7972718:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleanup keystoneclient tests  https://review.openstack.org/7973018:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleanup fixture data added to test instances  https://review.openstack.org/7972918:10
morganfainbergoh is summit sessions open?18:10
openstackgerritDavid Stanek proposed a change to openstack/keystone: Cleans up test data from limit tests  https://review.openstack.org/7972818:10
morganfainbergfor submission18:10
marekdmorganfainberg: yes18:10
morganfainbergoooh i need to figure out what i want to submit18:10
dolphmayoung: they'll have to be merged or rejected quite a lot based on the fact that our schedule will be more constrained than the last summit18:10
dstanekmorganfainberg: too late - new chain starts here https://review.openstack.org/#/c/79726/18:10
ayoungmarekd, I'm going to try to do something different this summit.  For each session that I am involved with, I am going to write up a blog post, including the issues and my thoughts on the solution.  Then, I'll post them long before the summit.  If anyone joins the talk and hasn';t read them, I will publically berate them.18:10
dolphmmorganfainberg: summit.openstack.org opened on friday18:11
morganfainbergdstanek, hehe ok18:11
morganfainbergdolphm, i think i have one that i want to propose18:11
dolphmmorganfainberg: and will be open until april 20th18:11
morganfainbergdolphm, for keystone18:11
ayoungmorganfainberg, get it up there18:11
dolphmmarekd: ^18:11
marekdayoung: ok ;-)18:11
morganfainbergayoung, yeah putting it up today18:11
ayoungnice18:11
ayoungmorganfainberg, I suspect that, just like last time, we'll end up with "buckets"18:11
ayoungclient, saml and ldap, token pipelien18:11
ayoungline18:11
marekdanyways,  need to run, cheers!18:12
*** marekd is now known as marekd|away18:12
ayoungmarekd, nice work18:12
ayoungI'lkl review, but plan on +218:12
marekd|awayayoung: thanks!18:12
*** leseb has quit IRC18:13
ayoungmorganfainberg, I see you are in Janitor mode.  Thanks for cleaning up the mess18:13
*** leseb has joined #openstack-keystone18:13
*** daneyon has quit IRC18:13
*** daneyon has joined #openstack-keystone18:14
morganfainbergayoung, lol18:15
morganfainbergayoung, yeah18:15
*** leseb has quit IRC18:17
morganfainbergayoung, dolphm, http://summit.openstack.org/cfp/details/4718:20
morganfainbergposted.18:20
ayoungPerf!18:20
dolphmdstanek: my only complaint with your series is that i'd prefer the addCleanup's to be as close as possible to whatever is being created that needs to be cleaned up... a couple of your changes increase that delta, but not significantly18:21
dolphmdstanek: just wanted to mention it18:21
ayoungmorganfainberg, you only mentioned Ephemeral TOkens twice.  Was that an oversight?18:21
morganfainbergayoung, lol18:21
morganfainbergayoung, i figured it warranted 2 mentioned, but didn't want to overload peopel18:21
*** Fin1te has quit IRC18:22
dstanekdolphm: there are definitely a few cases where i just grouped the cleanups together instead of adding a bunch of addCleanups18:24
dolphmayoung: addressed http://summit.openstack.org/cfp/details/4718:24
bknudsonstill not merged: https://review.openstack.org/#/c/79196/18:24
dolphmooh ^ someone review18:24
morganfainbergdolphm, looking now18:25
ayoungdolphm, looking18:25
morganfainbergreally?18:25
morganfainbergmissed that arg18:25
morganfainbergdoh!18:25
dolphmmorganfainberg: that's the second time it's been broken in like a year :P18:26
morganfainberg+2/+A18:26
dolphmmorganfainberg: i think bcwaldon fixed it last18:26
morganfainbergwell now we test!18:26
morganfainbergbknudson, _++++++18:26
bknudsonit got caught in the middle of oslo.db sync and the other migration refactoring for revoked tokens.18:27
morganfainbergbknudson, ahh18:27
bknudsonand the lack of tests didn't help18:27
ayoungthat was a nightmare to keep straight18:27
morganfainbergyeah18:27
dolphmbknudson: +++18:27
ayoungthings kept changing out from underneath me18:27
bknudsonmaybe we should put a call to keystone-manage db_version in devstack18:27
ayoungbknudson, sql livetests18:27
morganfainbergbknudson, oh that would be cool18:27
*** saju_m has quit IRC18:30
dolphmstevemar: dstanek responded to your -1 in https://review.openstack.org/#/c/79728/1/keystone/tests/test_backend.py18:30
stevemardolphm, ah so he did18:31
ayoungbknudson, https://bugs.launchpad.net/openstack-ci/+bug/11820918:32
ayoungbah18:32
ayoungwrong bug....18:32
bknudsonayoung: it's too bad about gutsy missing icons!18:32
bknudsonI'll get right on it.18:32
ayounghttps://bugs.launchpad.net/openstack-ci/+bug/118209218:33
bknudsonayoung: ah, great.18:33
ayoungbknudson, yeah...tooo bad about launchpad not keeping bugs for separate projects apart, too.18:33
dstanekthere seem to be a good amount of bugs related to data validation :-) do we have a strategy layed out or a prototype of adding a validation layer?18:33
bknudsonayoung: I never know what the infra team wants to include tests for...18:33
bknudsonit seems like lately they've been pushing back on adding new tests.18:33
bknudsoninternally here we're working on publishing CI results for keystone with db2.18:34
ayoungbknudson, I was hoping to do something along lines of mixing an LDAP and SQL backends for a single test, using henrynash's code, but since that is not going to make Icehouse18:34
dolphmdstanek: ++ only a general preference for using jsonschema18:34
stevemardstanek, thanks for the response!18:34
bknudsonayoung: we can mix ldap and sql... just not multi-ldap?18:34
ayoungI think what we can do is to add a migration test and sql based unit test with a real DB next to the mysql and postgres runs18:34
morganfainbergdstanek, +2 the whole chain. once Jenkins weighs in, +A no question18:34
bknudsonor is it not worth it to have ldap identity and sql assignment.18:35
dstanekdolphm: ok, i may POC a decorator based approach to that we have something to start looking at18:35
ayoungso long as the tests use a different DB instance (keystone_tests versus keystone)18:35
morganfainbergdstanek, once those are in i'll restructure my cleanup for the config files.18:35
morganfainbergand we can land config file stuff in J1 or in I (doesn't matter in either case)18:35
dstanekmorganfainberg: nice, i like removing the usage of sample18:36
morganfainbergheck yeah18:36
dolphmdstanek: my first question is how you're defining schemas for creates vs updates on a single resource?18:36
bknudsonayoung: ok. I'll try to get the team here to do the same for db2.18:36
ayoungbknudson, that makes sense.  We might need to split the livetest files into a DB specific file per18:36
ayoung_livetests_sql_db2.py  and so on18:37
bknudsonayoung: I hope we don't have anything different depending on the db in use.18:37
dstanekdolphm: i'll answer you with a unit test on a demo :-)  I have been thinking about this and have ideas, but i don't yet know if they'll work18:37
bknudsonayoung: I assume it's just the connection string?18:37
ayoungbknudson, we'll use a differenc config file, that should be it18:38
bknudsonayoung: that might be better to do with an env var or something.18:38
morganfainbergbknudson, so you'd do the db2 stuff like nova's minesweeper/turbo-hipster/whatever?18:38
ayoungwell, you want to be able to do18:38
dstanekwhen are we dropping XML support? there is at least on bug related to XML validation18:38
bknudsonmorganfainberg: yes... there's already some db2 ci in place, for sqlalchemy.18:38
ayoungtestr  keystone.tests._livetest_sql18:38
ayoungor some way to trigger  the test18:38
ayoungyou could do it as an external env var, but, yuck18:38
bknudsonayoung: we should look at how tempest picks which tests to run.18:39
bknudsonthey have smoke tests and other types.18:39
ayoungbknudson, also, might want to get the config file from somewhere out of the tree for a live db18:39
morganfainbergbknudson, woo!18:39
ayoungbknudson, I think we need a tox target18:39
bknudsonayoung: getting the config file from outside the tree makes sense... will probably need it for the test infrastructure to provide it to keystone anyways.18:39
ayoungbknudson, maybe18:40
ayoungnot sure what they do now, but I assume they just use devstack defaults18:40
*** petertoft has quit IRC18:41
*** andreaf has quit IRC18:45
*** bobt has joined #openstack-keystone18:53
*** bobt has quit IRC19:06
openstackgerritBrant Knudson proposed a change to openstack/keystone: Update sample config  https://review.openstack.org/7802419:13
openstackgerritBrant Knudson proposed a change to openstack/keystone: Use oslo db.sqlalchemy.session.EngineFacade.from_config  https://review.openstack.org/7845919:13
openstackgerritBrant Knudson proposed a change to openstack/keystone: Sync db, db.sqlalchemy from oslo-incubator 0a3436f  https://review.openstack.org/7842919:13
bknudsonhttps://review.openstack.org/78429 fixes the nasty WARNING message from oslo-incubator about the database mode.19:14
*** raildo has joined #openstack-keystone19:14
bknudsonthat was printed when the server starts and during db_sync.19:14
*** zhiyan is now known as zhiyan_19:20
*** daneyon has joined #openstack-keystone19:31
raildohello, I created this blueprint https://blueprints.launchpad.net/keystone/+spec/filter-user-by-project-v3 if someone wants to discuss, approve, or something like that =]19:32
*** topol has joined #openstack-keystone19:47
dolphmlast patch for an rc1 blocker needs reviews (this is just new tests) https://review.openstack.org/#/c/77375/20:07
bknudsondolphm: do you think https://bugs.launchpad.net/oslo/+bug/1271706 is rc1 blocker?20:09
morganfainbergbknudson, i would love if we could sanely smash that bug20:10
morganfainbergbknudson, if it is something easy (wont break things) it would be great to have fixed for I20:10
dolphmbknudson: just targeted it as such20:10
morganfainbergdolphm, ++20:10
bknudsonthanks... I've been getting complaints about it20:11
morganfainbergdolphm, looks like dstanek's changes are positive. should be good to go soon20:11
morganfainbergdolphm, i'll press +A on each of them once they are good if someone else doesn't beat me to it20:11
bknudsonin reviews now do we need to -1 if somebody leaves a string referenced in their test class?20:16
morganfainbergbknudson, explain?20:17
bknudsonmorganfainberg: aren't those the changes that dstanek is making?20:18
morganfainbergoh failing to cleanup?20:18
bknudsonmorganfainberg: yes20:18
morganfainbergideally yes. we should point them to how to clean it up20:18
morganfainbergesp. if we want to keep test bloat to a minimum20:18
morganfainbergi think we'll have some extra work to do to get things in-line since things merged since dstanek wrote those patches20:19
morganfainbergbut i think we can document / point people in that direction20:19
morganfainbergor do a quick "here fixed it for ya, next time do this"20:19
* dolphm p.s. i'll be afk thursday & friday this week20:20
morganfainbergdolphm, enjoy being afk (if possible)20:20
dolphmmorganfainberg: more enjoyment will be had if https://review.openstack.org/#/c/79284/ and https://review.openstack.org/#/c/77375/ are approved first ;)20:21
morganfainbergi think we can get those through today20:21
* morganfainberg has them in windows to look at as soon as i get food20:21
dolphmanxious to see subsequent patchsets on https://review.openstack.org/#/c/76476/ and https://review.openstack.org/#/c/78521/ too20:23
bknudsondolphm: cjellick said he'd have a new revision of https://review.openstack.org/#/c/78521/ up yesterday...20:23
morganfainbergick, we allow referral chasing... well don't disable it20:23
morganfainbergick20:23
bknudsonmorganfainberg: I think referral chasing in python is mostly broken, since it doesn't pass on the credentials20:24
morganfainbergbknudson, yep20:24
morganfainbergbknudson, ran across that when i worked at the former large social media company that facebook superseded.20:24
morganfainbergreferral chasing was just... broken20:25
bknudsonmorganfainberg: it'll probably make a comeback once too many adults get on facebook.20:25
morganfainbergno thanks i'll pass on seeing the resurgence if myspace.20:26
bknudsonmorganfainberg: too many unicorns?20:26
morganfainberghere let me bling that up for you20:26
morganfainbergbknudson, in short, ues20:26
morganfainbergyes*20:26
* dolphm relevant https://www.youtube.com/watch?v=7mFJdOsjJ0k20:28
morganfainbergoh no.. risky click of the day? :P20:28
morganfainbergLOLLLL20:29
morganfainbergs/LLL/20:29
morganfainbergi kinda like jamielennox|away's positional decorator20:29
morganfainbergit makes python feel less "oops i tossed arguments in and got something out" syntax wise20:30
bknudsonmorganfainberg: I wanted to look at that... I'd seen an interesting stackoverflow on this.20:31
dolphmmorganfainberg: link?20:31
bknudsonhttp://legacy.python.org/dev/peps/pep-3102/20:33
bknudsonso you could do "def compare(a, b, *ignore, key=None):" and then "if ignore: raise TypeError" already20:34
bknudsonI don't know if "def compare(a, b, *, key=None):" works in python3 already?20:34
dolphmnice20:35
ayoungFunny thing is that one of the features that Java is finally getting in Java 8 is that it will no longer throw out the parameter names in the reflection data about a function call.20:35
dstanekbknudson: yes it does in 3320:35
ayoungSo you would finally be able to convert from a dictionary to the arguments of a method20:35
ayoungits only taken 20 years20:35
dstanekbknudson: jamielennox|away has a decorator under review for similar functionality; to be used on methods that make up our external API20:36
dstanekayoung: what do you mean?20:37
bknudsonunfortunately you have to supply the number of positionals...20:37
bknudsoncould indicate that with a *ignore or something in the arguments instead.20:37
dstanekbknudson: not anymore, i gave him a snippet that takes care of that20:37
dolphmdstanek: it seems like you'd end up using , *, in every single method signature where you have both args and kwargs ... is that true?20:37
morganfainbergdolphm, here is the review jamie proposed https://review.openstack.org/#/c/77026/20:37
ayoungdstanek, so before you could get an object and enumerate its methods.  and take a method and enumerate the types it took in a parameter list.  But you could not actually get the parameter names20:37
morganfainbergbknudson, ^20:38
ayoungthey were tossed out at compile time20:38
ayoungso if you had a function that takes 3 strings, you don;t know which is which unless you do it positionally20:38
dstanekdolphm: only the ones where you wanted to control how it's being called and you don't have control of the calling code20:38
ayoungand considering that creating a db connection is usually String url, String userid, String password....20:38
dolphmdstanek: "don't have control of the calling code" == "all public methods" ?20:39
dstanekayoung: you've been able to get parameter names of a method using inspect for a long time20:39
ayoungits funny, dstanek because I consider this the killer feature, but they've been holding up the release due to Lamdas20:39
ayoungdstanek, in Java20:39
dstanekdolphm: yes, whatever is advertised as a public method (and you want control)20:40
dstanekdolphm: i think that in some ways the need for this is driven from a fragmented model20:40
*** nkinder_ has quit IRC20:41
bknudsonlet's just drop python2 support20:42
morganfainbergbknudson, i'd love to see py2 go away :)20:42
morganfainbergbknudson, i think we're getting closer to py3 being the default install around... but still probably a few OS releases away20:44
ayoungmorganfainberg, we need to drive a fix for eventlet20:46
morganfainbergayoung, can we ditch eventlet instead :P20:46
ayoungHA!20:46
ayoungsince we're dreaming, I'd like....hmmmm.....20:46
morganfainbergayoung, actually i think it's a different bug now *goes and looks*20:46
ayoungwasn';t last week20:46
morganfainbergayoung, can't have a pony, i already requisitioned one20:46
bknudsonI'm not sure what all eventlet does for keystone... isn't it blocked on the db all the time anyways?20:47
morganfainbergbknudson, it makes a WSGI stand-alone framework?20:47
morganfainbergor a wrapper to call that wsgi framework20:47
bknudsonmorganfainberg: there must be other ways to do that... plus ayoung wants to run in apache anyways.20:48
ayoungeventlet does nothing for us AFAICT20:48
morganfainbergbknudson, i keep trying to work on making devstack play nice w/ keystone on port 80 shared w/ horizon20:48
morganfainbergwow. it's kindof a pain the way the config files are built20:49
morganfainbergi kinda wish it used a CMS instead of hacky bash-isms20:49
ayoungI wish it was in Python20:50
openstackgerritBrant Knudson proposed a change to openstack/keystone: Remove unnecessary oauth1.Manager constructions  https://review.openstack.org/7921320:51
morganfainbergayoung, python, puppet, chef, cfengine, whatever20:51
ayoungIts has outgrown what you should do in Bash20:51
ayoungno, Python20:51
ayoungone language is easier to understand than twpo20:51
ayoungtwo20:51
morganfainbergayoung, devstack likely should be puppet based tbh. it's what infra uses..20:51
morganfainbergcombine efforts20:51
morganfainbergcould use saltstack20:51
morganfainbergthat's python20:51
bknudsonI expect that sometime devstack will go away for chef or puppet or something.20:52
morganfainbergbknudson, likely20:52
morganfainbergor devstack will just be a pretty wrapper for puppet/chef20:52
morganfainbergrun this script and it does the extra magic20:52
morganfainbergactually i wonder how hard that would be to convert to.20:52
dolphmmorganfainberg: that script: https://github.com/dolph/keystone-deploy20:52
morganfainbergdolphm, ooh20:53
haneef__ayoung:  is the following bug or something unqiue to ldaps.?  In the code we don't set cacertfile option if the protocol is ldaps. We do only for start_tls.  Won't ldaps protocol require cert?20:53
dstanekthese are still a handful of requirements in requirements.txt that don't play nice on py320:53
dstaneks/these/their/20:54
ayounghaneef__, I have no idea.  In order to remember I would have to forget all of the python-keystoneclient stuff in my brain right now20:54
morganfainbergdstanek, yeah20:54
ayoungI'll let you tell me20:54
dstaneki wish there was a way to list requirements by Python version20:54
dolphmmorganfainberg: my goal there is to have the recommended production configuration for 50% of deployments in the master branch, and then illustrate a few popular alternatives (backing to LDAP, federated, etc) in branches20:54
morganfainbergdolphm, hmm. should i submit a session for devstack saying "maybe we should move away from bash" for Juno summit?20:55
morganfainbergdolphm, awesome, let me look at it, and if i can toss some pull requests you way i will20:55
dolphmmorganfainberg: it's been brought up before, and hasn't made any traction20:55
morganfainbergdolphm, /me thinks it'll just be ignored as a summit session20:55
morganfainbergperhaps the only way to do it is propose a devstack 2.0 that is using different tech.20:56
morganfainbergdo all the work at once.20:56
dolphmthere was a project at some point called pystack or stack.py or something that was basically a port of early devstack to python20:56
morganfainbergicky20:56
dstanekbknudson: are your tests here https://review.openstack.org/#/c/77375/13/keystone/tests/test_backend_kvs.py just to make sure the parent's impl is not implemented?20:56
morganfainbergdolphm, the hard part is getting enough adoption to make it the gate target20:57
bknudsondstanek: yes, just shows how the test works today... if somebody implements it in future it will be easy to find.20:57
morganfainbergwithout that it'll just wither and die20:57
*** raildo has quit IRC20:57
dolphmmorganfainberg: ++ i'd start as 3rd party CI and work from there20:57
*** leseb has joined #openstack-keystone20:58
morganfainbergdolphm, interesting idea20:58
morganfainbergdolphm, if i had cash to spare i'd donate some resources for that20:58
morganfainbergalas, i'm not paid that much :P20:58
dstanekmorganfainberg: i started a port to saltstack a while back as a way to learn more about devstack :-)20:58
morganfainbergdstanek, yeah20:58
morganfainbergdstanek, i worked on something similar not too long ago20:59
morganfainbergdidn't get too far20:59
dolphmmorganfainberg: if we have code to run, i can probably wrangle some VMs20:59
morganfainbergdolphm, hm, maybe i'll make it a weekend project.20:59
morganfainbergdolphm, we can start by having keystone use it as external CI :)20:59
dolphmmorganfainberg: ++21:00
morganfainbergi think mirroring the devstack-full gate box would be the initial target21:00
*** marcoemorais has quit IRC21:01
dstaneki just added the second +2 to https://review.openstack.org/#/c/77375/ - any reason not to approve it at this time?21:01
*** nkinder has joined #openstack-keystone21:01
morganfainbergdstanek, i say +A it21:01
*** marcoemorais has joined #openstack-keystone21:02
dolphmdstanek: go for it!21:02
morganfainbergdstanek, i approved the patches in your chain that passed check21:02
morganfainbergwaiting for a recheck or two21:02
morganfainberg2nd and last ones failed for known bug reasons21:02
morganfainbergas soon as they pass everything should hit gate21:02
dstanekmorganfainberg: great, thanks21:03
*** marcoemorais has quit IRC21:03
*** marcoemorais has joined #openstack-keystone21:03
dstanekok, off to look at https://review.openstack.org/#/c/79284 again!21:03
*** gyee has quit IRC21:05
*** marcoemorais has quit IRC21:08
*** marcoemorais has joined #openstack-keystone21:09
*** daneyon has quit IRC21:10
*** daneyon has joined #openstack-keystone21:11
dstanekdolphm, stevemar: the commit message on https://review.openstack.org/#/c/79284 is incorrect now, right? We're not discarding groups anymore, we're raising a server error21:11
stevemardstanek, yeshhh21:12
dstanekstevemar: k, that's what i thought. i can submit an update to it.21:14
stevemardstanek, cool21:21
*** stevemar has quit IRC21:22
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Add request/access token and consumer support for keystoneclient  https://review.openstack.org/6082021:23
*** stevemar has joined #openstack-keystone21:23
stevemarmorganfainberg, i addressed your concerns here: https://review.openstack.org/#/c/60820/1821:23
stevemardolphm, ayoung ^21:23
openstackgerritSteve Martinelli proposed a change to openstack/python-keystoneclient: Authenticate via oauth  https://review.openstack.org/7797721:24
openstackgerritDavid Stanek proposed a change to openstack/keystone: Enforce groups presence for federated authn  https://review.openstack.org/7928421:26
dstanekdolphm, stevemar: i just updated the commit message ^21:27
stevemardstanek, thanks boss21:27
*** marcoemorais has quit IRC21:30
*** marcoemorais has joined #openstack-keystone21:30
*** stevemar has quit IRC21:43
*** thedodd has quit IRC21:44
*** leseb has quit IRC21:46
*** leseb has joined #openstack-keystone21:47
*** leseb has quit IRC21:51
*** topol has quit IRC21:52
*** devlaps1 has joined #openstack-keystone22:02
*** devlaps has quit IRC22:02
*** daneyon has quit IRC22:29
*** harlowja has quit IRC22:30
*** harlowja has joined #openstack-keystone22:31
*** nkinder has quit IRC22:40
*** jamielennox|away is now known as jamielennox22:40
*** Daviey has quit IRC22:46
*** nkinder has joined #openstack-keystone22:47
*** Daviey has joined #openstack-keystone22:47
*** leseb has joined #openstack-keystone22:57
*** leseb has quit IRC23:01
*** dims_ has quit IRC23:02
*** gordc has quit IRC23:05
*** nkinder has quit IRC23:13
*** dims_ has joined #openstack-keystone23:16
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Add a positional decorator  https://review.openstack.org/7702623:17
openstackgerritJamie Lennox proposed a change to openstack/python-keystoneclient: Start using positional decorator  https://review.openstack.org/7705523:18
*** henrynash has joined #openstack-keystone23:23
*** gyee has joined #openstack-keystone23:24
*** wchrisj has quit IRC23:26
*** nkinder has joined #openstack-keystone23:28
*** david_lyle_ has joined #openstack-keystone23:39
jamielennoxhow's zuul doing at the moment? i've reverified this review now 6 times and it fails: https://review.openstack.org/#/c/79474/23:39
jamielennox(no, it's not my fault)23:39
*** david-lyle has quit IRC23:41
*** wchrisj has joined #openstack-keystone23:48
*** gokrokve_ has quit IRC23:54
*** gokrokve has joined #openstack-keystone23:55
bknudsonjamielennox: what do you think about having the positional decorator use something more like py3 / pep 3102 -- http://legacy.python.org/dev/peps/pep-3102/23:56
jamielennoxbknudson: let me check23:57
bknudsonjamielennox: here they say you can simulate it in py27 using "def compare(a, b, *ignore, key=None):"23:57
bknudsonwe'd still need a decorator... it could check if the *ignore argument is empty23:58
bknudsondoes the decorator know the names of the arguments?23:58
*** gokrokve has quit IRC23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!