18:00:21 <stevemar> #startmeeting keystone
18:00:22 <openstack> Meeting started Tue Apr 12 18:00:21 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:22 <roxanaghe> o/
18:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:25 <stevemar> hello!
18:00:26 <openstack> The meeting name has been set to 'keystone'
18:00:36 <stevemar> #link agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:00:36 <crinkle> o/
18:00:36 <bknudson> hi
18:00:41 <knikolla> o/ hello
18:00:42 * ayoung-mobile in lunch mode still
18:00:43 <dstanek> o/
18:00:43 <gsilvis> hello
18:00:45 <breton> hi
18:00:46 <shaleh> \o
18:00:51 <gyee> \o
18:00:56 <raildo> \o/
18:01:03 <stevemar> they are testing the fire alarm right now in my building, fun times
18:01:06 <morgan> oh
18:01:12 <morgan> o/
18:01:17 <morgan> \o
18:01:28 <stevemar> amakarov: hope you're around, you're on the agenda!
18:01:39 <amakarov> Hi all
18:01:45 <samueldmq> oh I am here
18:01:52 <stevemar> #topic mitaka is out
18:01:52 <samueldmq> and I was waiting for a courtesy ping :B
18:01:57 <samueldmq> bye mitaka
18:01:59 <samueldmq> hello newton
18:02:02 <morgan> amakarov: i have things to talk to you about that caching btw...
18:02:04 <stevemar> i am off my game...
18:02:04 <morgan> oooooh
18:02:08 <stevemar> ping ajayaa, amakarov, ayoung, breton, browne, crinkle, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, jorge_munoz, knikolla, lbragstad, lhcheng, marekd, MaxPC, morganfainberg, nkinder, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tjcocozz, tsymanczyk, topol, vivekd, wanghong, xek
18:02:11 <morgan> yay Mitaka
18:02:16 <rodrigods> o/
18:02:19 <bknudson> we support mitaka for at least 12 months
18:02:20 <amakarov> Why don't we cache new tokens in kmw cache right after they were issued?
18:02:25 <lbragstad> o/
18:02:26 <ayoung-mobile> Sam you are supposed tobsay "here I am!". It goes with the name
18:02:29 <shaleh> queue horrible bug discovery in 3,2,....
18:02:32 <stevemar> MITAKA is out!
18:02:32 <jamielennox> o/
18:02:40 <stevemar> release notes! http://docs.openstack.org/releasenotes/keystone/mitaka.html
18:02:54 <samueldmq> here I am! <<< ayoung-mobile
18:02:55 <lhcheng> o/
18:03:04 <stevemar> just wanted to say thanks to everyone that contributed
18:03:05 <rderose> o/
18:03:14 <morgan> amakarov: hold up but yes.
18:03:15 <stevemar> and i hope we have an awesome newton
18:03:27 <stevemar> thats alL!
18:03:33 * morgan hides the microphone before ayoung-mobile gets it ;)
18:03:35 <samueldmq> we will ahve !! for sure
18:04:00 <stevemar> alright, lets give the microphone over
18:04:10 <raildo> stevemar, great job as  PTL on mitaka! congrats :)
18:04:15 <stevemar> #topic Pre-cache new tokens for 5 minutes in KMW cache
18:04:26 <morgan> raildo: ++ so glad it wasn't me :)
18:04:39 <raildo> morgan, haha
18:04:44 <bknudson> I assume this this auth_token middleware?
18:04:48 <breton> kmw == ksm?
18:04:52 <morgan> yeah
18:04:58 <morgan> keystonemiddleware
18:05:01 <samueldmq> nice, I was confused too
18:05:16 <amakarov> Well, I've ran into one stupid thing we do for every token: validate it right after it was issued
18:05:17 <morgan> can i make a recommendation - do not abbreviate "ks, ksm, ksa,..."
18:05:17 <gyee> damn acronyms
18:05:33 <ayoung-mobile> Doesn't a shared memcache work now
18:05:35 <amakarov> is it necessary?
18:05:44 <morgan> so there is a reason for this
18:05:46 <bknudson> how does auth_token know about the new token?
18:05:52 <samueldmq> bknudson: ++
18:05:55 <bknudson> send it over a message bus?
18:06:06 <amakarov> ayoung-mobile, yes, and we can cache new tokens there
18:06:09 <morgan> bknudson: he's saying puysh the validated totken to memcache
18:06:13 <morgan> directly from keystone
18:06:15 <morgan> on issuance
18:06:23 <amakarov> without validating them first
18:06:24 <ayoung-mobile> Amakarov so this is on issue?
18:06:32 <jamielennox> i don't think you could message bus it, keystone would have to go straight to memcache
18:06:33 <samueldmq> jsut a config thing not ?
18:06:35 <samueldmq> no*
18:06:46 <morgan> so hold up before we discuss how we get tokens out there
18:06:53 <ayoung-mobile> Nah right into memcache from keystone
18:06:56 <morgan> often endpoints are grouped logically
18:07:05 <morgan> and have some shared memcache but not all shared
18:07:12 <amakarov> I'd suggest do that on client side
18:07:15 <morgan> keystone would need to know what memcaches to push the token to.
18:07:32 <amakarov> morgan, that's not essential
18:07:33 <morgan> amakarov: wait is this a client thing or a middleware thing?
18:07:51 <amakarov> morgan, that's the client thing I think
18:08:07 <morgan> because lets draw the line in the sand, client is NOT trusted to put things in memcache that keystonemiddleware or keystone consumes
18:08:09 <amakarov> the client should cache new tokens for middleware to get it
18:08:17 <breton> so how is this different from our current flow in terms of performance?
18:08:19 <samueldmq> morgan: amakarov: client think -> keystone auth thing ?
18:08:20 <dstanek> morgan: +1000
18:08:29 <morgan> and client will never be trusted.
18:08:32 <morgan> to do so
18:08:53 <morgan> in fact, most deployments should lock down memcache more than they do... that is a different convo though
18:08:57 <samueldmq> oh wait, that's just for new issued tokens
18:09:00 <amakarov> samueldmq, by client I mean keystoneclient lib and everything it uses
18:09:00 <samueldmq> is it that important?
18:09:11 <bknudson> if the client can put tokens in the auth_token cache then there's no need for keystone at all
18:09:22 <samueldmq> I think the effort doesn't pay the improvement (1 request) ?
18:09:26 <amakarov> bknudson, hmm, right
18:09:29 <morgan> bknudson: and no security in openstack
18:09:37 <ayoung-mobile> Amakarov this is client as called from within middleware right?
18:09:37 <amakarov> let's move it to server side then
18:09:39 <bknudson> morgan: y, that too.
18:09:46 <morgan> ok, so server side
18:09:59 <morgan> you have keystone needing to know all the memcaches to push to
18:10:01 <amakarov> ayoung-mobile, I want to avoid this first-time validation
18:10:10 <morgan> i support shared memcache for endpoints
18:10:11 <jamielennox> so as of a review i have open keystone can/will be consuming keystonemiddleware
18:10:14 <bknudson> all the memcache clusters
18:10:17 <amakarov> so I assume we can trust keystone server then
18:10:22 <jamielennox> so where this code lives is not a big deal
18:10:22 <morgan> bknudson: correct
18:10:23 <amakarov> that token is valid
18:10:26 <dstanek> are we talking about keystone pushing to another service's memcache cluster?
18:10:33 <morgan> dstanek: possibly
18:10:33 <ayoung-mobile> Amakarov allinone deploys?
18:10:42 <dstanek> seems like bad architecture
18:10:51 <morgan> allinone deployes are not really something we enginerr for
18:10:59 <morgan> we get it for free most of the time :)
18:11:06 <samueldmq> dstanek: I don't like that too
18:11:06 <amakarov> ayoung-mobile, not exactly
18:11:21 <samueldmq> dstanek:  too much change for saving 1 validation request
18:11:29 <morgan> amakarov: i made this argument before
18:11:43 <morgan> and we explored it ( ayoung-mobile and i )
18:11:52 <bknudson> if keystone had a memcache where it could look up tokens quickly then the call from auth_token would be faster
18:11:54 <morgan> sharing a memcache cluster for endpoints is good
18:12:16 <morgan> however, keystone pushing to probably a separate cluster in big deploys
18:12:18 <morgan> is bad
18:12:29 <morgan> keystone as it is could pre-cache for itself making the validate faster
18:12:37 <dolphm> morgan: ++
18:12:39 <morgan> and i'd be happy to add that to the caching layer for tokens
18:12:42 <amakarov> anyway, if kmw uses another cache it will stil validate the token as usual
18:12:50 <dstanek> morgan: i think that's a good idea
18:12:53 <morgan> but i wouldn't want keystone to push to the cache in the keystonemiddleware way
18:13:00 <dolphm> morgan: ++
18:13:07 <morgan> keep keystonemiddleware in charge of keystonemiddleware semantics
18:13:23 <morgan> if the cluster happens to be shared and the semantics are the same
18:13:25 <morgan> sure
18:13:28 <dstanek> from an architecture POV a cache is within a service and not a part of the API.
18:13:33 <dolphm> keystonemiddleware can share the cache of other service's keystoenmiddlewares though, if that's convenient
18:13:36 <morgan> but i'd focus on keystone pre-caching for itself.
18:13:38 <samueldmq> dstanek: ++
18:13:51 <morgan> and i REALLY like recommending the various services sharing keystonemiddleware caches
18:13:59 <amakarov> morgan, do you suggest to cache tokens in keystone server very own jaust to validate it faster?
18:14:00 <morgan> regardless if keystone shares that or not.
18:14:14 <morgan> amakarov: it would be easy to on issuance to a pre-cache in keystone
18:14:14 <amakarov> s/jaust/just/
18:14:22 <morgan> and it would make validations faster
18:14:28 <morgan> for the window of cache
18:14:31 <amakarov> morgan, sounds like a compromise
18:14:33 <morgan> so ~300s by default
18:14:55 <morgan> once keystone uses keystonemiddleware
18:15:05 <morgan> and keystonemiddleware is on oslo.cache these pre-caches may look the same
18:15:07 <gyee> morgan, I presume we still invalid the cache of the token changes?
18:15:10 <amakarov> morgan, under our loads the majority of tokens are short living
18:15:11 <morgan> so it accelerates everything
18:15:13 <gyee> i.e. role changes in fernet
18:15:32 <morgan> gyee: we would need to be smart about where we cache the data.
18:15:43 <amakarov> gyee, there may be a trade-off
18:15:51 <morgan> gyee: but we cache for 300s by default
18:16:03 <morgan> gyee: which we've always said is within our acceptible clock skew
18:16:03 <amakarov> 5 min cache is ok to wait for
18:16:05 <jamielennox> morgan: so at least under current design we don't inherit the caching part of keystonemiddleware in keystone
18:16:13 <morgan> jamielennox: and we shouldn't
18:16:19 <stevemar> amakarov: are you satisfied with this discussion, is there still a need for the blueprint? https://blueprints.launchpad.net/keystone/+spec/pre-cache-tokens
18:16:21 <jamielennox> right
18:16:21 <gyee> behavior is a bit different though, middleware versus keystone
18:16:28 <gyee> middleware cache validation results only
18:16:29 <morgan> jamielennox: i'd like to see keystonemiddleware move to oslo.cache and we can see if they align
18:16:36 <morgan> jamielennox: but i don't expect it to in the near term
18:16:50 <amakarov> stevemar, I'm ok with current agreement
18:17:04 <morgan> gyee: again, known window of validation we accept as tokens being valid for
18:17:12 <jamielennox> morgan: gah, i got it so close, but the edge cases are hard
18:17:20 <shaleh> stevemar: might make sense to document the agreement in a bp
18:17:22 <morgan> gyee: known risk and within what we consider clock-skew
18:17:28 <gyee> morgan, sure, options and tradeoffs as always
18:17:34 <shaleh> stevemar: people might want to know what we were thinking 6 months from now
18:17:47 <gyee> just saying we need to doc the difference
18:17:52 <stevemar> shaleh: that's what i'm doing :)
18:17:53 <morgan> this is a relatively low bar (yay!) to hit for newton
18:18:17 <morgan> i'm happy to sign up for helping on this front as long as someone else is willing to take a first stab at docs
18:18:25 <amakarov> shaleh, modified the bp
18:18:28 <morgan> and/or someone is willing to at least co-author so we have more cache knowledge :)
18:18:53 <morgan> or take a stab and i'll review
18:18:54 <morgan> ;)
18:19:04 <stevemar> amakarov: i may have overridden your changes, launchpad :(
18:19:12 <morgan> lets continue the impl details offline btw
18:19:12 <amakarov> morgan, :)
18:19:29 <bknudson> I'd like to know more about token validation performance since I'm sure our cloud folks will ask about it.
18:19:36 <morgan> bknudson: sounds good! :)
18:19:47 <morgan> bknudson: actually i think we have a lot of ways to improve that this cycle
18:19:53 <lbragstad> ++
18:19:59 <bknudson> how about we split token validation to another service?
18:20:04 <bknudson> ;)
18:20:08 <gyee> say what?!
18:20:13 * stevemar throws a rotten tomato at bknudson
18:20:28 * morgan borrows a wet emu from mordred to throw at bknudson
18:20:34 <ayoung> Lets go tokenless everywhere
18:20:40 <morgan> ayoung: good plan!
18:20:42 <stevemar> next topic :)
18:20:46 <stevemar> #topic OSProfiler integration
18:21:03 <stevemar> amakarov: morgan ^
18:21:13 <amakarov> ok, what's holding us from accepting that thing? )
18:21:30 <amakarov> https://review.openstack.org/#/c/294535
18:21:30 <morgan> amakarov: was working through the last bits (such as https://review.openstack.org/#/q/I4857cfe1e62d54c3c89a0206ffc895c4cf681ce5,n,z ) with DinaBelova
18:21:44 <stevemar> amakarov: i don't want config options for it (not sure if this is still an issue_
18:21:59 <morgan> making sure we weren't doing something weird with either side
18:22:05 <amakarov> morgan, yes, and I was fixing that job failures ))
18:22:17 <morgan> stevemar: all options are [iirc] in osprofiler now
18:22:24 <morgan> we have an external default set
18:22:28 <morgan> to default it to off
18:22:31 <stevemar> ++
18:22:32 <morgan> and a couple other things
18:22:46 <morgan> i'll confirm, but the code is almost there and looks pretty good
18:23:14 <morgan> we should aim to land it early this cycle and i plan on opening a convo with DinaBelova at the summit about better ways to desgin for profiling going forward across openstack
18:23:17 <amakarov> morgan, it has just passed jenkins tests
18:23:28 <morgan> but we shouldn't wait since that'll be a few cycles out
18:23:34 <morgan> this is a good starting place
18:23:46 <morgan> so in short, review it.
18:23:50 <shaleh> morgan: ++
18:23:53 <morgan> please don't bikeshed it
18:24:15 <morgan> and if there are minor concerns lets stack the changes on top where possible
18:24:34 <morgan> i am happy where this has moved to and think it can land soon as long as it's reviewed.
18:25:06 <dstanek> morgan: we should take some hints from how things like newrelic are implemented
18:25:13 <morgan> dstanek: that is the plan.
18:25:39 <morgan> dstanek: and setting clear hook points in the projects so anything (not just osprofiler) can hool in
18:25:39 <dstanek> morgan: i have some ideas, but no time :-(
18:25:41 <morgan> hook*
18:25:45 <jamielennox> question though, why doesn't that live in oslo.db?
18:26:05 <morgan> jamielennox: it isn't db only
18:26:25 <jamielennox> no, but i know i put a review on the oslo.cache one the other day that it should be in oslo.cache
18:26:29 <dstanek> jamielennox: there should be support in oslo.db, but also in other things
18:26:42 <jamielennox> as is you are going to be _wrap_session-ing in every project, why not just control it from oslo.db?
18:26:50 <morgan> jamielennox: that is part of the larger conversation / x-project spec i want to work with DinaBelova on
18:26:53 <shaleh> so start with it here in Keystone and move it down to oslo.db?
18:26:59 <bknudson> maybe we can move it to oslo.db once we prove it out
18:27:04 <amakarov> shaleh, ++
18:27:14 <stevemar> its in all the pipelines too
18:27:17 <amakarov> let's have something up and running first
18:27:20 <dstanek> isn't this already in other projects?
18:27:24 <morgan> dstanek: it is
18:27:27 <morgan> we're one of the last
18:27:28 <jamielennox> that's ok - we can do it that way i'm just wondering why we'd do this particular case this way
18:27:29 <morgan> iirc
18:27:44 <morgan> jamielennox: version 1, i think is the answer
18:27:47 <dstanek> it that's the case why prove it again? just put it where it belongs
18:27:50 <jamielennox> k
18:28:15 <morgan> dstanek: i think the architecture isn't there.
18:28:26 <morgan> and having profiling hooks in keystone is a good thing (tm)
18:28:34 <morgan> even if they are suboptimal for the moment
18:28:51 <morgan> once it is in oslo.db we move the stuff out of keystone, it's a pattern we've done before
18:29:00 <stevemar> true
18:29:19 <morgan> and should be pretty lightweight to do so as it improves.
18:29:44 <morgan> but if we;re adding changes to oslo, and othe rthings i think we should look at the design to be not just osprofiler specific
18:29:47 <morgan> let anyone hook in
18:29:49 <stevemar> alright, lets review it then
18:29:57 <morgan> but in short,lets review it.
18:30:01 <stevemar> any new issues we can leave as comments
18:30:12 <morgan> critical concerns please highlight right away
18:30:18 <morgan> minor concerns can be addon patches
18:30:26 <morgan> bikeshedding... leave at the door ;)
18:30:45 <ayoung> I'd rather not think of it as generic hooks, but rather profiling that can be 0 cost disabled
18:30:47 * morgan steps off the soapbox
18:30:58 <stevemar> next topic
18:31:02 <shaleh> ayoung: you mean 0 cost enabled right?
18:31:11 <morgan> ayoung: join us at the summit and we will work on that :)
18:31:14 <ayoung> shaleh, nah, meaning you don't pay for it if it is disabled
18:31:16 <morgan> ayoung: please join us for that convo.
18:31:24 <morgan> ayoung: that is the goal btw.
18:31:27 <ayoung> morgan, speaking of summit....
18:31:32 <ayoung> is that next?
18:31:48 <stevemar> ayoung: next is federation functional tests
18:31:50 <dstanek> shaleh: unfortunately profiling always has a cost. that's why i was advocating for defaulting to of
18:31:52 <dstanek> off
18:31:56 <stevemar> ayoung: what did you have in mind?
18:32:09 <morgan> dstanek: and why i -2d it up and down until it was default off
18:32:34 <ayoung> stevemar, on Profiling?  Nothing, just avoiding a general "hooks" approach.
18:32:37 <shaleh> dstanek: fair anough
18:32:39 <ayoung> Lets do Federation
18:32:52 <stevemar> #topic Keystone federation integration/functional tests
18:33:12 <rodrigods> knikolla around?
18:33:18 <knikolla> rodrigods, yeah
18:33:21 <shaleh> ayoung: we talking k2k here?
18:33:23 <ayoung> So...dumb Idea....
18:33:30 <gsilvis> shaleh: yup
18:33:35 <knikolla> so, current CI gates do not do functional/integration testing for federation
18:33:37 <ayoung> what if we made Keystone act as its own Federated IdP?
18:33:39 <bknudson> devstack should be able to spin up 2 keystone instances so you can do k2k on 1 system.
18:33:54 <ayoung> Like...you get an url under OS-FEDERATION
18:33:59 <ayoung> and it is protected with basic auth
18:33:59 <rodrigods> ayoung, interesting
18:34:01 <gsilvis> ayoung: I feel like testing something closer to a real setup would be a more reassuring test
18:34:12 <shaleh> bkero: yeah, plausible.
18:34:12 <breton> bknudson: why not use the same keystone as IdP and SP?
18:34:16 <ayoung> gsilvis, this is testing the Federation code itself.
18:34:17 <shaleh> bknudson: plausible
18:34:23 <shaleh> stupid auto nick
18:34:32 <ayoung> THis is not K2K
18:34:33 <breton> ayoung: ++
18:34:36 <knikolla> ayoung, a real gate with 2 devstack would allow to test features that are enabled by k2k.
18:34:43 <bknudson> http://lists.openstack.org/pipermail/openstack-dev/2016-March/091055.html says k2k
18:34:46 <shaleh> knikolla: agreed
18:34:56 <gsilvis> ayoung: we had intended it to be a test of K2K
18:35:06 <ayoung> this is just for getting rid of Password in the token request, and doing basic auth like the  web Spec
18:35:07 <rodrigods> i'd also like to see "regular" federation besides k2k
18:35:20 <gsilvis> rodrigods: sure
18:35:24 <ayoung> gsilvis, I care far more about regular federation
18:35:30 <breton> rodrigods: i am actually working on this
18:35:31 <ayoung> but, if this is K2K, go on.
18:35:36 <rodrigods> breton, wow
18:35:38 <gyee> what is "regular"?
18:35:44 <breton> rodrigods: there are patches by dstanek that i'm reviving
18:35:48 <rodrigods> so... let's focus our efforts
18:35:52 <ayoung> gyee, SAML, OpenIDC,  Federation with "2K"
18:35:55 <rodrigods> breton, our idea is to use tempest instead
18:35:57 <ayoung> without 2K
18:35:57 <gsilvis> ayoung: yup, I can understand that
18:35:58 <knikolla> ayoung, K2K includes the regular federation bits.
18:36:00 <rodrigods> and run the tests using dvms
18:36:03 <dstanek> is there different code paths between the SP in k2k vs "regular" federation?
18:36:14 <rodrigods> dstanek, just for the idp
18:36:23 <rodrigods> actually...
18:36:30 <rodrigods> no?
18:36:45 <rodrigods> it should be the same
18:36:53 <breton> rodrigods: you still need to set up federation bits like mod_shib. Does tempest do that?
18:37:03 <rodrigods> breton, we setup it up in devstack
18:37:05 <gyee> dstanek, no difference as far as I know
18:37:09 <rodrigods> since it is FOSS software
18:37:12 <dstanek> breton: not yet. that what my patches do, setup tempest
18:37:15 <dstanek> rodrigods: ^
18:37:21 <breton> dstanek: https://review.openstack.org/#/c/151310/9 these ones?
18:37:32 <jamielennox> have we asked devstack about this? it would be a huge change to make two devstacks parallelably installable
18:37:46 <morgan> jamielennox: infra supports multi-node
18:37:47 <shaleh> when i was testing this I used some ansible to manipulate the N devstacks once they were up into being federated
18:37:49 <ayoung> So....theoretically, could an application running in a VM inside of Nova accpet the SAML assertion from Keystone?
18:37:52 <dstanek> breton: yep
18:37:52 <morgan> we could hook into the muiltinode thing
18:37:57 <morgan> if we wanted
18:37:59 <shaleh> bknudson's suggestion lets it all live in devstack
18:38:03 <breton> dstanek: cool. Hope you don't mind me tackling them.
18:38:10 <rodrigods> ayoung, yes
18:38:11 <ayoung> Damnit we built an IdP.
18:38:12 <dstanek> breton: nope, not at all
18:38:24 <gsilvis> ayoung: yup.
18:38:24 <jamielennox> i think for functional testing it would be easy to have a 2 keystone only env, but i like the idea of being able to test beyond just the keystone effects and proper resource federation
18:38:25 <ayoung> I knew this was a mistake
18:38:29 <morgan> jamielennox: ++
18:38:32 <bknudson> shaleh: it makes more sense to do 2 devstack vms if you want to expand this beyond keystone (e.g. image federation)
18:38:42 <dstanek> i would rather, but get it all setup in devstack as it would be much easier and i think hits all the code paths
18:38:44 <breton> i still don't understand why we want 2 keystones
18:38:46 <shaleh> bknudson: tree
18:38:48 <shaleh> true
18:38:49 <breton> why not use the same keystone?
18:38:49 <shaleh> bah
18:39:15 <shaleh> breton: better insurance we are not lying to ourselves, right?
18:39:15 <dstanek> the only reason not to do that would be to test against a specific IdP.
18:39:16 <gsilvis> bknudson: exactly---we want to build resource federation tests on top of this
18:39:18 <ayoung> breton, the second Keystone consumes the SAML generated by the first.  We need to test that code path
18:39:21 <shaleh> Functional should be a pretty real test
18:39:27 <rodrigods> breton, like bknudson just said
18:39:34 <jamielennox> you could loop it, but it's not a realistic functional test
18:39:36 <rodrigods> the idp can be keytone... or not
18:39:58 <breton> Keystones don't consume SAML. Apache does.
18:40:04 * topol o/ better late than never
18:40:09 <dstanek> breton: .... for  now ...
18:40:19 <breton> dstanek: oh gawd
18:40:28 <dstanek> ;-)
18:40:28 <lbragstad> lol
18:40:32 <rodrigods> i think we need to sync the efforts
18:40:36 <amakarov> dstanek, are there plans to implement own shibboleth or something?
18:40:42 <knikolla> as gsilvis said, this would allow as to test resource federation using k2k between two different devstack.
18:40:44 <rodrigods> https://etherpad.openstack.org/p/Keystone-Federation-Testing
18:40:53 <knikolla> us*
18:41:06 <dstanek> amakarov: i am working on a POC to have keystone deal with the SAML bits
18:41:12 <gyee> can we call "k2k" irregular federation?
18:41:18 <gyee> :-)
18:41:20 <breton> dstanek: but why?
18:41:21 <stevemar> gyee: not so much :)
18:41:25 <dstanek> amakarov: to support dynamic configuration among other things
18:41:59 <lbragstad> it would make federation easier for ops
18:42:05 <jamielennox> i would agree - the point here was to not build a full SAML parser into keystone
18:42:15 <gyee> dstanek, yeah, PKI tokens :-)
18:42:16 <amakarov> dstanek, cool. why have you chosen saml then? Just a preference or you compared it with oidc for ex. ?
18:42:25 <gsilvis> dstanek: hm, the dynamic configuration is an interesting point
18:42:46 <amakarov> jamielennox, ++
18:42:49 <ayoung> we should actually test both
18:42:55 <dstanek> amakarov: i believe that it fits the Rackspace usecase
18:42:57 <gsilvis> dstanek: though I definitely agree with jamielennox here too
18:43:01 <ayoung> But K2K can't produce OpenIDC
18:43:05 <ayoung> only SAML now
18:43:12 <morgan> correct
18:43:13 <amakarov> jamielennox, we need an army to implement all of its bells and whistles!
18:43:21 <bknudson> so was the plan to have a job in keystone for the multinode k2k test run?
18:43:26 <jamielennox> also mod_shib is crazy in what it will do without an apache reboot
18:43:28 <ayoung> gyee, PKI tokens were written with this in mind, but let's let that go.
18:43:29 <gsilvis> bknudson: yes
18:43:31 <dstanek> gsilvis: jamielennox: fair point, but i'm actually not building the SAML parsing myself - it already exists
18:43:40 <bknudson> gsilvis: no complaints from me.
18:43:50 <ayoung> jamielennox, craazy in a good or bad wy?
18:43:52 <gyee> ayoung, oh I agree, PKI token is a "signed document" like SAML2
18:44:00 <ayoung> gyee, "was"
18:44:07 <ayoung> lets put itin the past tense.
18:44:12 <gsilvis> gyee: has anyone ever suggested saml2 tokens
18:44:13 <stevemar> dstanek: why not just use the plugins?
18:44:14 <jamielennox> ayoung: i'm undecided - but crazy
18:44:16 <morgan> ayoung: it can do interesting things if configured right w/o a restart
18:44:24 <amakarov> ayoung, gyee necromancy, hm? ;)
18:44:25 <dstanek> stevemar: like mod_shib?
18:44:29 <stevemar> dstanek: y
18:44:39 <dstanek> stevemar: you have to restart apache for most changes
18:44:40 <gyee> amakarov, I am being fair here
18:44:50 <lbragstad> every time you add an idp you have to kick apache
18:44:55 <dstanek> stevemar: and you have to manage config files instead or using an API
18:45:00 <morgan> dstanek: restart... graceful...
18:45:01 <ayoung> I think that Apache can do a kill -1 type thing, and reread its config, no need to dump sessions
18:45:08 <morgan> dstanek: potato potato
18:45:36 <jamielennox> so are we still talking k2k here? how many times are we adding this?
18:45:38 <breton> how often does one add idps?
18:45:43 <morgan> ayoung: graceful - process current requests, new requests go to new workers with new things
18:45:45 <stevemar> dstanek: you're not wrong
18:45:48 <dstanek> my vision is to build it as something that can sit outside of keystone's core code - so even if nobody else liked it we could still doit
18:45:51 <gsilvis> jamielennox: well I'd like to...
18:45:52 <lbragstad> breton depends on who you are
18:46:26 <ayoung> Have a related conversation on hold with #puppet-openstack about setting up Federation
18:46:30 <jamielennox> dstanek: and it's crypto so you want it to be fast - so an apache plugin?
18:46:46 <morgan> jamielennox: or something not pure cpython
18:46:47 <amakarov> morgan, restarting apache... as for me is like buing a new car once it out of fuel
18:46:56 <breton> lbragstad: i don't know. The guy who usually adds idp.
18:47:00 <amakarov> s/buing/buying/
18:47:06 <morgan> amakarov: graceful reload, it's what it's there for
18:47:19 <lbragstad> breton well - public clouds might add idps a lot more than a private deployment
18:47:22 <dstanek> jamielennox: if your using separate processes in apache then crypto is find in Python since it's in C anyway. it's when you use threading that it's a problem.
18:47:39 <gsilvis> lbragstad: I could definitely imagine adding idps all the time in our usecase
18:47:47 <amakarov> morgan, not long ago wa had an issue with mod_wsgi desagree with graceful reloads
18:47:47 <shaleh> lbragstad: resource federation also opens up the possibility of a much more dynamic setup
18:48:14 <morgan> amakarov: use uwsgi and mod_proxy_uwsgi ;) [actually a better setup for that reason]
18:48:19 <dstanek> i think i side tracked us too much.
18:48:23 <morgan> amakarov: separate convo though
18:48:25 <bknudson> tornado drill... I should work from home.
18:48:34 <morgan> amakarov: stay on federatio
18:48:43 <amakarov> ack
18:48:50 <morgan> amakarov: :)
18:49:07 <rodrigods> so... who is interested in having a CI for federation
18:49:13 <rodrigods> join the etherpad
18:49:20 <morgan> rodrigods: i think everyone is interested ;)
18:49:32 <rodrigods> morgan, awesome
18:49:40 <stevemar> rodrigods: link?
18:49:43 <ayoung> rodrigods, would K2K be sufficient for SAML?
18:49:47 * morgan waits for open discussion has something.
18:49:48 <ayoung> testing, that is?
18:49:49 <rodrigods> https://etherpad.openstack.org/p/Keystone-Federation-Testing
18:49:51 <morgan> ayoung: it should be.
18:50:00 <rodrigods> ayoung, it would
18:50:00 <stevemar> ty
18:50:08 <amakarov> rodrigods, I'd start with testing on a single keystone and split it afterwards when you have tests to run in the new environment
18:50:24 <stevemar> morgan: how many minutes you need?
18:50:27 <gsilvis> can someone link the etherpad in the meeting summary?  (I don't know how that sort of thing works)
18:50:32 <morgan> stevemar: 5 ish
18:50:40 <stevemar> #link https://etherpad.openstack.org/p/Keystone-Federation-Testing
18:50:40 <morgan> stevemar: will be quick.
18:50:42 <rodrigods> amakarov, put that idea there
18:50:59 <gsilvis> stevemar: thanks
18:51:00 <rodrigods> so we can discuss and vote, also i'm not complete aware of all the needed steps
18:51:09 <stevemar> next topic for now, edit the etherpad for federation functional tests
18:51:10 <rodrigods> where to send changes to have this kind of deployment and so on
18:51:18 <rodrigods> stevemar, ++
18:51:23 <gyee> vote for who?
18:51:28 <ayoung> Pedro
18:51:31 <stevemar> #topic morgan wanted 5 minutes
18:51:33 <ayoung> Vote for PEDRO!
18:51:36 <stevemar> lol nice one ayoung
18:51:38 <rodrigods> lol
18:51:42 <morgan> Keystone Midcyle
18:51:53 <ayoung> PLease say Boston
18:51:57 <morgan> i'm volunteering to help chase down venue in the bay area
18:52:00 <morgan> sorry ayoung
18:52:06 <ayoung> Dagnabit
18:52:19 <shaleh> we already did Boston :-)
18:52:24 <gyee> bay area sounds great
18:52:32 <morgan> this is to change up the venue to a location we haven't been and switch coasts
18:52:41 <gsilvis> shaleh: is once really enough, when it's boston?
18:52:41 <morgan> also summer in the bay is kindof awesome
18:52:42 <shaleh> gyee: he means Vancouver Bay right?
18:52:55 <morgan> shaleh: lol
18:52:56 <ayoung> I vote for the Hotel Formerly named the Ahawannee
18:53:03 <lbragstad> those lobster rolls were top notch btw...
18:53:07 <gyee> shaleh, love that one too
18:53:11 <shaleh> ayoung: not exactly Bay Area but close
18:53:17 <morgan> anyway, i'll start working on some details for it this week so we can roll into the summit with planning
18:53:25 <ayoung> shaleh, If I'm flying to California....
18:53:38 <shaleh> ayoung: 2 hour drive when there is no traffic
18:53:41 <morgan> i figure it's not a hard sell to get people to fly to California / SF [everyone has offices in that area]
18:53:47 <ayoung> shaleh, thre 3.5
18:53:50 <ayoung> ttry
18:53:51 <ayoung> try
18:53:57 <shaleh> ayoung: maybe how you drive :-)
18:54:05 <amakarov> morgan, if you change coasts it can be Vladivostok :)
18:54:06 <dstanek> lbragstad: ++
18:54:07 <ayoung> shaleh, I did it most weekends for a decade
18:54:09 <morgan> ayoung: i would have voted for yosemite
18:54:16 <morgan> ayoung: but.. i think nothing would get done
18:54:23 <jamielennox> amakarov: i offer sydney each time, nothign...
18:54:24 <ayoung> morgan, lots would get done
18:54:29 <morgan> ayoung: just not code.
18:54:35 <ayoung> Priorities
18:54:37 <anteaya> jamielennox: sydney!
18:54:41 <stevemar> jamielennox: hehe
18:54:42 <lbragstad> ayoung ++
18:54:45 <shaleh> samueldmq: wanted it down his way. But you know, Olympics.....
18:54:50 <anteaya> Toronto
18:54:54 <ayoung> Push for Summit in Sydney afte Barthelona
18:54:55 <samueldmq> shaleh: :-(
18:54:57 <stevemar> anteaya ++
18:54:59 <amakarov> btw, why not Sidney?
18:54:59 <samueldmq> shaleh: maybe next year
18:55:06 <topol> what dates were we looking at for the midcycle?
18:55:08 <morgan> as a fallback would be Tronto if the bay area can't happen this time around
18:55:13 <ayoung> Boston
18:55:14 <morgan> topol: haven't looked at the scheudle
18:55:24 <shaleh> late June right?
18:55:29 <morgan> topol: will know more later this week, but it'll prob be june
18:55:34 <samueldmq> FYI 5 mins left
18:55:35 <ayoung> Late July I think
18:55:36 <stevemar> topol: releases.openstack.org/newton/schedule.html late june or early july
18:55:36 <jamielennox> amakarov: because enough people couldn't justify the flight to come
18:55:37 <morgan> shaleh: typically.
18:55:40 <topol> morgan so its gonna be city by the bay? Awesome
18:55:48 <morgan> topol: that is what i want :)
18:55:49 <gsilvis> ayoung: if only the midcycle were in a month with good weather in boston
18:56:05 <ayoung> gsilvis, is there such a month?
18:56:16 <lbragstad> 4 minutes
18:56:24 <morgan> i'll send ML emails and such later this week
18:56:25 <knikolla> ayoung, we can lie and say they all are.
18:56:27 * morgan is done.
18:56:28 <gsilvis> ayoung: ... well there's a week, sometimes, does that count?
18:56:29 <topol> legal seafood in boston or fishermans warf in SF. Its a win win
18:56:31 <stevemar> gsilvis: thats why i'm gunning for rochestor and toronto :P
18:56:41 <ayoung> topol, not.even.close.
18:56:52 <jamielennox> topol: where is this illegal seafood you eat?
18:56:58 <ayoung> But there is much good food in SF
18:57:01 <morgan> topol: sourdough is better in SF though.
18:57:03 <stevemar> jamielennox: his fish tank
18:57:07 <morgan> ayoung: ++ tons of fantastic food
18:57:10 <jamielennox> stevemar: that... ugh..
18:57:22 <ayoung> morgan, are you looking for in SF proper?
18:57:23 <topol> ayoung. well maybe if you took me to the good seafood restaurant in boston I could agree
18:57:23 <jamielennox> not so much illegal as unhygenic
18:57:28 <gyee> topol ate nemo?
18:57:32 <ayoung> Cuz South Bay is not worth the trip.
18:57:40 <shaleh> ayoung: nah, let's do something horrible like milptas
18:57:42 <stevemar> gyee: and dory
18:57:45 <ayoung> Vacaville
18:57:48 <breton> lets do in Europe
18:57:50 * gyee cries
18:57:54 <breton> UK?
18:57:55 <shaleh> ayoung: eeewww in June :-)
18:58:03 <ayoung> Fremont!
18:58:15 <shaleh> ayoung: Fremont is just Milpitas north
18:58:16 <morgan> brazil!
18:58:22 <amakarov> breton, spb? :)
18:58:24 <jamielennox> we are getting to the point where we have a decent contingent of non-US people who would attend\
18:58:27 <morgan> we can all visit samueldmq
18:58:32 <ayoung> Dublin.  Lunch at Gyee's
18:58:47 <stevemar> i imagine we'll hash this all out at the summit
18:58:48 <shaleh> ayoung: sounds good. His Dad rocks the kitchen.
18:58:57 <gyee> ayoung, sounds good
18:59:02 <morgan> jamielennox: i think midcycles are going to be a different thing post austin.
18:59:06 <ayoung> shaleh, and we would be ahead of the City traffic headed out 120 to Yose
18:59:08 <stevemar> whoever is willing to organize it has my vote
18:59:08 <amakarov> ayoung, good idea!
18:59:10 <morgan> jamielennox: and it'll make it easier [i hope]
18:59:13 <anteaya> post barcelona
18:59:15 <jamielennox> morgan: waiting to see how that one plays out
18:59:18 <shaleh> ayoung: ++++++++....
18:59:19 <morgan> anteaya: ++
18:59:19 <ayoung> I mean Dublin, CA
18:59:31 <lbragstad> oh... I was totally fore ireland
18:59:32 <morgan> anyway, i'll start organizing this for this cycle.
18:59:33 <stevemar> lets give infra time to assemble
18:59:35 <amakarov> ayoung, LOL
18:59:36 <morgan> cheers.
18:59:37 <stevemar> #endmeeting