18:00:54 <stevemar> #startmeeting keystone
18:00:55 <openstack> Meeting started Tue Feb 17 18:00:54 2015 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:59 <openstack> The meeting name has been set to 'keystone'
18:01:02 <stevemar> https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:01:19 <stevemar> #topic kilo targeted specs
18:01:34 <bknudson> hi
18:01:41 <stevemar> morganfainberg brought this up, Specs Targeted for Kilo that have not been started / have significant progress by 2/24 are subject to being punted until Liberty
18:01:48 <joesavak> o/
18:01:57 <bernardo-silva> o/
18:02:06 <stevemar> I tried to make a summary of the items here
18:02:07 <stevemar> https://etherpad.openstack.org/p/keystone-k3-blueprints
18:02:14 <marekd> stevemar: Specs or implementation ?
18:02:23 <stevemar> marekd, impl.
18:02:24 <morganfainberg> marekd, implementation
18:02:41 <stevemar> there are some that are not started (tokenless auth, domain config in sql)
18:03:09 <gyee> so who's working this weekend?
18:03:16 <stevemar> and we have a lot of bps that have not yet landed, so the amount of reviewing will be compounded
18:03:23 <atiwari> o/
18:03:27 <gyee> stevemar, tokenless review will be posted today
18:03:42 <gyee> today = before midnight PST
18:03:45 <stevemar> why does no one ever want to punt stuff :)
18:03:54 <henrynash> (oops, sorry I’m late)
18:04:13 <morganfainberg> this is just a heads up
18:04:25 <morganfainberg> if you want it to land in K, get it started
18:04:38 <gyee> morganfainberg, you just need something that complies right :)
18:04:42 <morganfainberg> we have very little time left
18:04:42 <marekd> stevemar: i think you skipped one, I will update etherpad, ok?
18:04:51 <stevemar> ++ if it's a new feature that's going into K, have something up by 2/24
18:04:52 <stevemar> sure
18:05:09 <morganfainberg> real implementation (not just POC/strawman) by 2/24
18:05:26 <morganfainberg> we're running out of time in k3
18:05:32 <morganfainberg> and k3 is Feature Freeze
18:06:00 <stevemar> morganfainberg, did you want to talk about the next topic if we're done with this one?
18:06:04 <morganfainberg> no slipping things in past k3 (without extremely good reasons, and most of these specs can wait)
18:06:07 <morganfainberg> stevemar, sure
18:06:15 <ayoung> cut abfab.  We've seen nothing from those folks
18:06:22 <stevemar> #topic liberty spec proposals
18:06:30 <ayoung> gyee, are you actively working on X509?
18:06:36 * ayoung too slow...
18:06:57 <morganfainberg> ayoung, we're not specify specs we're cutting today, just warning people to get moving
18:06:58 <stevemar> ayoung, yeah, it's just a matter of time time abfab is cut, and gyee said he'll have something up by tonight
18:07:10 <ayoung> cool
18:07:10 <morganfainberg> anyway, Liberty specs will open once K3 is cut
18:07:13 <gyee> ayoung, I am mentoring a fellow to get it implemented
18:07:27 <dims__> o/
18:07:31 <morganfainberg> the idea is I want to avoid what is happening right now next cycle (PTL or not)
18:07:32 <ayoung> OK...Liberty specs:  just submit all specs to backlog first
18:08:02 <morganfainberg> ayoung, the point i'm making is as of K3 you can start proposing them to be moved to the liberty target
18:08:04 <ayoung> we'll promote something to a "lizardbreath"  er "liberty" spec after it is approved for backlog
18:08:31 <morganfainberg> the goal is to avoid this "cram everything into milestone 3" effect we have going on now
18:09:08 <stevemar> yeah, we'll make the necessary changes to specs, should be quick
18:09:09 <morganfainberg> I'm frankly worried about the quantity and i think the road to RC is going to be rocky this cycle
18:09:16 <ayoung> morganfainberg, I think you guys are starting to see the perspecive I developed about a year and a half ago:  we really need to lead the summit come the close of M3 in order to be able to progress.
18:09:50 <stevemar> ayoung, yeah, we are slow out of the gate for some reason
18:10:09 <morganfainberg> ayoung, i think we're going to FF next cycle at milestone 2, spec freeze at milestone 1, so the summit really is almost ½ a cycle from when we start accepting specs being proposed against liberty target
18:10:21 <morganfainberg> but more on that once we hit milestone 3 this cycle.
18:10:31 <ayoung> stevemar, well, I think we are getting more deliberate. Its frustrating, but also the sign of a mature-ish project
18:10:42 <dstanek> this cycle may have been timing because of the holidays shortly after the summit
18:10:44 <ayoung> morganfainberg, exactly
18:10:56 <ayoung> dstanek, its been that way every year, though
18:11:01 <stevemar> ayoung, ++
18:11:04 <ayoung> December comes and suddenly....whooosh
18:11:09 <morganfainberg> nothing here is set in stone, just some thoughts - the only thing i'm aiming for is specs can be targeted before we hit the end of this cycle.
18:11:13 <lbragstad> we also bumped the spec dates up this release
18:11:15 <morganfainberg> ok thats it.
18:11:17 <ayoung> M2 is starting at us.
18:11:28 <lbragstad> maybe it will take a release to two to get used to it
18:11:53 <stevemar> we will probably hash this out at the summit
18:12:04 <stevemar> #topic Reminder: Review Code
18:12:07 <morganfainberg> stevemar, we will probably hash this out before we end this cycle ;)
18:12:11 <ayoung> So...I think we are acually on a really good trajectory.  We've had the specs out for a while...we can have  spec approve push at the summit, with an eye to hitting the ground running afterwards
18:12:43 <ayoung> having a really dep backlog will help.  Pre-approved specs that are ready for impl come the end of the bug fix cycle
18:12:50 <stevemar> #link https://gist.github.com/dolph/651c6a1748f69637abd0
18:12:57 <morganfainberg> It's scary looking ^^
18:13:04 <stevemar> dolphm, and morganfainberg set up this gist, and it's getting to look scary
18:13:09 <morganfainberg> that is currently the reviews for "approved" specs.
18:13:36 <stevemar> this is without stuff that hasn't been started, or (potentially) the AE (whatever it's named now) token spec
18:13:37 <morganfainberg> and osme of those haven't even been started or are missing large swaths of patches (50%+)
18:13:42 <stevemar> so please please please rview
18:13:45 <ayoung> morganfainberg, I'm wondering if we can punt on domain-as-project as a requirement for reseller
18:13:49 <dolphm> how many of those should be marked WIP that aren't?
18:14:14 <ayoung> the more I think about it, the more I am convinced that, while it would have been right from the get go,  it will be easier to just work around it
18:14:16 <morganfainberg> dolphm, any of those i marked were not abandoned, maybe 1 was WIP, and a couple were merge conflicted
18:14:25 <morganfainberg> dolphm, but doesn't diminish priority
18:14:43 <stevemar> dolphm, not as many as you would hope
18:15:04 <dolphm> stevemar: well i want them all to be polished, ready-to-merge code
18:15:25 <samueldmq> ayoung, we have a sort of backlog to organize code implementation around reseller (using domais as project ofc)
18:15:30 <samueldmq> ayoung, raildo can talk to ou later :)
18:15:33 <stevemar> dolphm, we all want that, but the only way there to get there is to review :)
18:15:48 <raildo> ayoung: sure
18:16:06 <morganfainberg> dolphm, the point is i think we need to punt things so we can get that list more sane. i made the list look awful on purpose to show how far behind we are based upon what is approved
18:16:16 <ayoung> samueldmq, raildo happy to talk after meeting on that.  Let's get that one moving, cuz it is otherwise close
18:16:37 <morganfainberg> dolphm, and not as many as you'd think were simple rebase away from being ready for review
18:16:46 <samueldmq> ayoung, ++
18:16:49 <morganfainberg> dolphm, most were/are reviewable :(
18:16:50 <raildo> ayoung: yes, we have few days, but I think that we can do that.
18:17:18 <stevemar> and the more people we have working on new things this week, the less reviews we have
18:17:18 <morganfainberg> anyway
18:17:34 <morganfainberg> we're behind is the point
18:17:52 <gyee> point taken
18:17:57 <morganfainberg> and we need to eliminate things from that list and from the approved spec list (most likely)
18:18:09 <samueldmq> morganfainberg, ++
18:18:36 <stevemar> and we're more than a little bit behind
18:18:42 <stevemar> anywho
18:18:53 <stevemar> #topic Reminder: Triage Bugs
18:19:02 <stevemar> #link http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html
18:19:13 <ayoung> shoul we set a mentor for each major feature to get the first +2 in?
18:19:41 <raildo> ayoung: ++ I like that idea.
18:19:42 <ayoung> dangit I can't keep up
18:19:45 <henrynash> stevemar: ok, so I recommend punting on the extra-disable bp idea….that can wait till L
18:19:56 <samueldmq> ayoung, ++ not bad idea
18:20:00 <lbragstad> ayoung: I don't know, that can deter other people from looking at it
18:20:13 <gyee> ayoung, ++ for review czar
18:20:16 <ayoung> lbragstad, easier to get people to look when it has a +2
18:20:31 <lbragstad> but not when other people still find issues with the code
18:20:45 <lbragstad> what looks fine to one person might not look fine to everyone,
18:20:55 <ayoung> lbragstad, also, it will help to ensure *someone* is looking at the code
18:20:59 <samueldmq> but still better than having nobody looking at that code
18:21:00 <ayoung> I'll take reseller
18:21:05 <samueldmq> ayoung, ++
18:21:26 <ayoung> I'll also take websso portal
18:21:36 <gyee> conflict of interest?
18:21:38 <jacorob> ayoung: guess means what exactly you mean by “mentor”
18:21:45 <ayoung> and mapping enhancements...all those are of interest to out group
18:21:48 <lbragstad> I think we've established we're behind and need to review anyway
18:21:59 <ayoung> jacorob, someone that stays on the review until they are comforatble giving it a +2
18:22:08 <morganfainberg> lets not say mentoring is required here. simply review.
18:22:09 <bknudson> nova actually requires cores to sign up to review the changes for the bp.
18:22:12 <ayoung> jacorob, prioritizion
18:22:20 <lbragstad> morganfainberg: ++
18:22:26 <ayoung> morganfainberg, not required.
18:22:27 <amakarov> lbragstad: what can we do motivate people to -1 +2'ed CR's?
18:22:40 <morganfainberg> bknudson, something we should probably consider once we're a bit less under water, right now limited mentoring is likely going to hurt us more imo.
18:23:08 <morganfainberg> amakarov, it depends on the reason for the -1.
18:23:19 <lbragstad> amakarov: not sure I understand the question
18:23:21 <ayoung> Anyway.. I'll commit to staying on those 3.  If you are an author on those...feel free to bug me
18:23:35 <stevemar> ayoung, ++ you hit it there, let the author decide
18:23:37 <amakarov> morganfainberg: if it is a reason of course :)
18:23:49 <stevemar> if you are authoring a patch and feel the need for a review buddy speak now
18:23:57 <morganfainberg> amakarov, if its a real concern, -1. if it's a nit pick, please don't minus 1, at worst no-score with comments.
18:23:57 <stevemar> or ping later on -keystone
18:24:15 <raildo> ayoung: I appreciate that!
18:24:21 <lbragstad> morganfainberg: amakarov or propose a follow on patch fixing that you think needs to be fixed
18:24:41 <ayoung> OK...we ready to move on to bugs?
18:24:43 <morganfainberg> yep
18:24:44 <stevemar> yup!
18:24:45 <amakarov> morganfainberg: I'm about the idea that +2'ed CR's attract attention
18:24:50 <ayoung> looking...
18:24:50 <morganfainberg> bug list is looking better.
18:24:52 <stevemar> #link http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html
18:25:01 <morganfainberg> it was really ugly last week
18:25:02 <stevemar> just a handful of new bugs
18:25:11 <morganfainberg> a few more eyes will help keep it in check
18:25:20 <morganfainberg> we got behind around the holidays and didn't pick back up
18:25:35 <ayoung> looking at 4. [Undecided:New] Bug #1421966 in Keystone: "Getting role for trust is double-protected"
18:25:36 <openstack> bug 1421966 in Keystone "Getting role for trust is double-protected" [Undecided,New] https://launchpad.net/bugs/1421966 - Assigned to Lin Hua Cheng (lin-hua-cheng)
18:25:51 <morganfainberg> so, keep eyes open, if there is a bug in "new state" [even if it's prioritized], please take a gander and get it triaged.
18:26:07 <morganfainberg> the goal is to have bugs not in "new" and with a priority
18:26:07 <gyee> double-protected? that security or what
18:26:08 <stevemar> i'll need to look at the notification one
18:26:22 <samueldmq> morganfainberg, can everyone triage bugs?
18:26:24 <ayoung> My kneejerk reaction, though, is that none of those would be stop ship-bugs, so lets focus on features until freeze
18:26:29 <bknudson> I went through the policy.json to add comments, and found a few problems so opened bugs...
18:26:33 <lbragstad> samueldmq: yes
18:26:39 <bknudson> since I didn't have time to work on all of them.
18:26:44 <morganfainberg> ayoung, triage the bugs, don't need to fix them
18:26:51 <ayoung> deal
18:26:52 <gyee> bknudson, double-protected is a special feature
18:26:58 <samueldmq> lbragstad, ok thx
18:27:04 <morganfainberg> ayoung, but triaging them early means if we need things fixed because they are major we can make sure we land that ASAP
18:27:13 <morganfainberg> e.g. the unicode issue w/ the mapping of ids
18:27:18 <morganfainberg> that was a major bug
18:27:24 <morganfainberg> and needed a backport to juno
18:27:31 <stevemar> ayoung, yeah, i agree with you there, none appear to be stop ships, and we should focus on features, but as morganfainberg says, we should triage at least
18:27:57 <morganfainberg> it also gives people things to do when they get stuck on features and want to look at something else
18:28:16 <stevemar> bored of keystone? try more keystone!
18:28:20 <morganfainberg> (after they've code reviewed)
18:28:22 <morganfainberg> >.>
18:28:24 <morganfainberg> anyway
18:28:39 <morganfainberg> on to the really important topics for the meeting
18:28:50 <stevemar> yes, the one everyone is here for
18:28:55 <stevemar> #topic SPFE for Keystone Lightweight Tokens
18:29:02 <stevemar> #link https://review.openstack.org/#/c/130050/
18:29:27 <stevemar> It's time to vote on Keystone lightweight tokens, and wether or not we allow an exception for the code to land in Kilo.
18:29:37 <lbragstad> said code https://review.openstack.org/#/c/145317/
18:29:38 <gyee> AE got renamed to lightweight now?
18:29:44 <stevemar> gyee, yep
18:29:47 <lbragstad> yes...
18:29:56 <lbragstad> we are signing or encryption
18:29:58 <morganfainberg> gyee, yes, it is a framework for tokens, and does not require encryption.
18:29:59 <lbragstad> encrypting*
18:30:07 <lbragstad> so people didn't want to have a specific name
18:30:16 <gyee> that's fine
18:30:17 <stevemar> Supermajority vote will decide the outcome, so 8 / 12 spec-cores must vote yes.
18:30:23 <lbragstad> functionality doesn't change
18:30:35 <morganfainberg> even if you're not a spec-core please feel free to vote.
18:30:36 <stevemar> i think everyone is familiar with the spec - at least on a high level
18:30:38 <bknudson> no filibustering.
18:30:40 <gyee> does keyczar scale?
18:30:45 <stevemar> yes, thanks morganfainberg
18:30:57 <dolphm> lbragstad: if we go with cryptography.fernet instead of python-keyczar, there's only a recipe for encryption afaik
18:30:57 <stevemar> bknudson, no, not for this item, maybe next time
18:31:00 <lbragstad> gyee: dolphm has a commit based on mine that doesn't rely on keyczar
18:31:00 <topol> I vote for allowing an exception.
18:31:08 <morganfainberg> your votes will not be ignored, but if no one but cores votes it's a 8/12 spec core.
18:31:13 <morganfainberg> stevemar, please use #vote
18:31:14 <dolphm> so we'd have to implement our own signing if we go that way
18:31:15 <stevemar> topol, wait for the actual vote to start!
18:31:17 <stevemar> #startvote Allow Keystone lightweight tokens a SPFE? Yes or No.
18:31:18 <openstack> Begin voting on: Allow Keystone lightweight tokens a SPFE? Valid vote options are Yes, or, No, .
18:31:19 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:31:20 <lbragstad> so that means we'd have to roll our own signing
18:31:29 <dolphm> #vote Yes
18:31:29 <bknudson> #vote Yes
18:31:33 <gyee> lbragstad, I wonder if it can scale horizontally or across regions
18:31:33 <marekd> #vote yes
18:31:33 <dstanek> #vote Yes
18:31:35 <henrynash> are teh marked experimet nal?
18:31:36 <stevemar> #vote Yes
18:31:38 <lbragstad> #vote yes
18:31:39 <morganfainberg> #vote yes
18:31:40 <amakarov> #vote Yes
18:31:41 <dolphm> someone please vote "or"
18:31:43 <gyee> with a shared HMAC secet
18:31:49 <morganfainberg> #vote or
18:31:50 <lbragstad> gyee: that depends on how you use it
18:31:51 <jamielennox> #bote yes
18:31:56 <ayoung> #vote Yes
18:32:03 <anteaya> #vote or
18:32:04 <gyee> yes
18:32:05 <jamielennox> #vote yes
18:32:06 <morganfainberg> henrynash, that can be a stipulation, i'm ok with that.
18:32:11 <gyee> #vote yes
18:32:14 <breton> #vote yes
18:32:14 <morganfainberg> anteaya, ++ *hi5*
18:32:15 <lhcheng> #vote Yes
18:32:19 <samueldmq> #vote yes
18:32:20 <anteaya> ha ha ha
18:32:25 <topol> #vote  Yes
18:32:36 <lbragstad> gyee: if you're feeling ambitious you could write an interface to something that stores your keys and replicates them
18:32:42 <breton> someone can vote .
18:32:46 <breton> #vote .
18:32:47 <openstack> breton: . is not a valid option. Valid options are Yes, or, No, .
18:32:50 <lbragstad> gyee: to sql or whatever.
18:32:53 <henrynash> (provided this fucntionality is marked as experimenatl): #vite yes
18:32:59 <breton> #vote yes
18:33:03 <henrynash> (provided this fucntionality is marked as experimenatl): #vote yes
18:33:06 <morganfainberg> breton, denied on the '.' vote
18:33:08 <gyee> lbragstad, I was think barbican or some other KMS
18:33:11 <stevemar> henrynash, nice touch
18:33:15 <morganfainberg> henrynash, (you need to start the line with #vote)
18:33:26 <stevemar> it should be started as experimental
18:33:29 <atiwari> stevemar, what is this vote for?
18:33:32 <henrynash> #vote yes
18:33:35 <atiwari> sorry I missed it
18:33:36 <lbragstad> gyee: I checked with the barbican folks and they don't have something in place yet, but they said that we should go talk to them once we have a solid use case,
18:33:43 <dolphm> lbragstad: like, secrets as a service?
18:33:48 <lbragstad> dolphm: right
18:33:49 <morganfainberg> atiwari, allowinfg the exception for the AE token spec (renamed KLWT)
18:33:51 <stevemar> atiwari, allowing keystone light weight tokens an exception to land in Kilo
18:34:01 <jamielennox> there's something a bit recursive about relying on barbican from keystone
18:34:02 <morganfainberg> atiwari, not the approval, just the allowed exception beyond the freeze
18:34:03 <ayoung> atiwari, SPFE for the AE tokens
18:34:10 <dolphm> lbragstad: import barbican as keystone_secrets
18:34:12 <dolphm> done
18:34:12 <morganfainberg> meaning i remove my -2.
18:34:32 <morganfainberg> and lbragstad works to quickly solve all outstanding issues with the spec.
18:34:41 <morganfainberg> and then code
18:34:51 <ayoung> might I also suggest that we expedite approving the spec, with a caveat that we will allow corrections of a minor sort afterwards...
18:35:05 <morganfainberg> ayoung, the goal is the spec should be approved within a couple days max
18:35:05 <stevemar> atiwari, vote with #vote Yes or #vote No
18:35:10 <atiwari> ayoung, morganfainberg IMO it is not ready for kilo
18:35:11 <lbragstad> I don't want to spend time fixing little things with the spec
18:35:15 <lbragstad> I'd rather work on the code
18:35:19 <atiwari> #vote NO
18:35:31 <morganfainberg> atiwari the whole concept or just some implementation details
18:35:35 <gyee> lbragstad, ++, its conceptually sound
18:35:42 <stevemar> i think that's everyone
18:35:49 <stevemar> #endvote
18:35:50 <openstack> Voted on "Allow Keystone lightweight tokens a SPFE?" Results are
18:35:52 <openstack> Yes (15): gyee, lbragstad, ayoung, lhcheng, bknudson, topol, marekd, dstanek, dolphm, jamielennox, henrynash, amakarov, samueldmq, breton, stevemar
18:35:53 <openstack> or (2): anteaya, morganfainberg
18:35:54 <openstack> No (1): atiwari
18:35:56 <morganfainberg> atiwari, this is a vote on concept / general direction.
18:36:11 <morganfainberg> ok so that shows a clear majority that the exception should be granted
18:36:14 <stevemar> #agreed Keystone lightweight tokens will be granted an SPFE
18:36:24 <atiwari> it is leaning toward HMAC signature
18:36:26 <morganfainberg> lbragstad, i'll remove my -2, please work to address the issues in the spec.
18:36:27 <atiwari> correct
18:36:33 <morganfainberg> atiwari, it is focused around that.
18:36:34 <lbragstad> morganfainberg: will do
18:36:39 <ayoung> atiwari, I think we can build toward your concept for HMAC tokens based on this spec.  We can discuss later.
18:36:40 <morganfainberg> atiwari, but not exclusively
18:36:44 <atiwari> and IMO it is proposing the weak signature
18:36:50 <lbragstad> atiwari: you can still HMAC sign
18:37:06 <morganfainberg> lbragstad, you *will* HMAC sign in it's current form ;)
18:37:21 <lbragstad> yeah, we discussed that
18:37:23 <morganfainberg> anyway, so please do not -1 for nit-picky stuff
18:37:26 <morganfainberg> on that spec
18:37:32 <morganfainberg> please -1 for real concerns
18:37:42 <morganfainberg> and work with lbragstad to address them, the -2 will be lifted at the end of the meeting
18:37:49 <gyee> lets do double-hmac for double-protection
18:37:55 <atiwari> morganfainberg, can we get more reviews on HMAC stuff?
18:38:03 <ayoung> atiwari, so one thing this will give us, beyond the ephemeral tokens, is that we will start deploying a very succint token format.  That alone is necessary for the HMAC proposal
18:38:29 <morganfainberg> atiwari, your spec or lbragstad's. your spec is proposed to backlog meaning earliest liberty, lbragstad's is currently prioritised for kilo.
18:39:08 <morganfainberg> atiwari, i think we can discuss how to make it work on both sides as we progress towards the next cycle. lbragstad's is a starting place and i expect to see enhancements next cycle to it / things built on top of it
18:39:10 <ayoung> once we have this one deployed, we could then make use of the internal format for distributed token validation, ie.  Your HMAC spec.    We had discussed Id-only-tokens in the past, with a fetch-and-cache  strategy for all the expanded data
18:39:14 <stevemar> lbragstad and dolphm have a PoC (probably past PoC at time point) so that helps too
18:39:36 <ayoung> so I see this as complementary, and even required, for the HMAC approach you wrote up.
18:40:03 <morganfainberg> ayoung,++ it compliments the HMAC spec, at worst is is the building blocks to get us there.
18:41:04 <atiwari> ok, ok
18:41:16 <stevemar> and now another SPFE...
18:41:21 <stevemar> #topic SPFE for Recursive Delete / Disable
18:41:32 <stevemar> #link https://review.openstack.org/#/c/148730/
18:41:43 <samueldmq> raildo, ^
18:41:50 <raildo> We are proposing this spec, In there we detail how will work recursive deletion and disabling for projects (and domains), these changes would ease a lot the way operators handle deployments using projects/domains hierarchies, the implementation changes are not big and we believe it could easily land in Kilo if the spec was approved.
18:41:53 <stevemar> i'll admit i didn't know this was up
18:42:05 <bknudson> this one depends on another spec
18:42:19 <stevemar> bknudson, yes, it seems to depend on the reseller one
18:42:37 <samueldmq> raildo, does it depends on reseller?
18:42:37 <stevemar> raildo, does this one depend on the reseller code changes?
18:42:41 <raildo> stevemar: yes
18:43:06 <ayoung> if we grant it a SPFE, it just means that it *can* go into this release, not that it *must*  right?
18:43:07 <raildo> stevemar: no, this spec just depend the the reseller spec
18:43:14 <morganfainberg> ayoung, correct
18:43:18 <raildo> but not the code
18:43:21 <ayoung> I think this one is safe
18:43:34 <ayoung> it will fall into place fairly easilky once reseller is set
18:43:34 <stevemar> ayoung, right
18:43:39 <morganfainberg> ayoung, it could be moved to liberty just like any other approved spec (or it may not get approved because it has issues)
18:43:43 <ayoung> easily
18:44:06 <ayoung> and we have significant portions of the code implemented, right raildo ?
18:44:43 <raildo> ayoung: yes, we are finishing the migration implementation and using the project API to create a is_domain project
18:45:01 <ayoung> any reasons to deny the extension?
18:45:04 <raildo> I intend to send the patches tomorrow and update the other patch
18:45:13 <stevemar> #startvote Allow recursive deletion and disabling for projects? Yes No
18:45:14 <openstack> Begin voting on: Allow recursive deletion and disabling for projects? Valid vote options are Yes, No.
18:45:15 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:45:41 <raildo> #vote yes
18:45:46 <marekd> #vote YES
18:45:54 <stevemar> #vote Yes
18:45:55 <breton> #vote yes
18:45:56 <samueldmq> #vote yes
18:46:07 <ayoung> #vote or
18:46:07 <openstack> ayoung: or is not a valid option. Valid options are Yes, No.
18:46:11 <ayoung> damn
18:46:13 <gyee> #vote yes
18:46:14 <ayoung> #vote yes
18:46:18 <jamielennox> #vote yes
18:46:19 <stevemar> ayoung, i learned this time!
18:46:22 <morganfainberg> ayoung, stevemar learned
18:46:24 <topol> #vote yes
18:46:26 <dstanek> #vote Yes
18:46:31 <morganfainberg> #vote yes
18:46:33 * ayoung should have tried last vot
18:46:34 <amakarov> #vote ,
18:46:35 <openstack> amakarov: , is not a valid option. Valid options are Yes, No.
18:46:36 <ayoung> e
18:46:38 <henrynash> #vote yes
18:46:43 <morganfainberg> amakarov, hehe
18:46:48 <amakarov> #vote yes
18:46:50 <stevemar> okay, this one looks like a done deal
18:46:54 <stevemar> #endvote
18:46:54 <openstack> Voted on "Allow recursive deletion and disabling for projects?" Results are
18:46:55 <openstack> Yes (13): gyee, dstanek, ayoung, morganfainberg, topol, marekd, samueldmq, jamielennox, amakarov, henrynash, raildo, breton, stevemar
18:47:06 <gyee> spit and shake on it
18:47:10 <stevemar> #agreed recursive delete will be granted an SPFE
18:47:18 <stevemar> morganfainberg, please lift your -2
18:47:28 <stevemar> alright cool stuff coming up!
18:47:28 <stevemar> #topic Vancouver Summit Session Breakdown
18:47:33 <stevemar> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html
18:47:38 <stevemar> There will once again be changes to the design summit, i think for the better.
18:47:42 <raildo> :D
18:47:48 <stevemar> fishbowl sessions, which are similar to the usual design session, these have projectors and plenty of room 100-300 people
18:47:56 <stevemar> working sessions, which are more board room style, meant to replace project pods, (20-40ppl sized) for hacking on stuff
18:48:04 <stevemar> morganfainberg is aiming for 4 fishbowl and ~8 working sessions, leaving us time to wander over to talk to other projects
18:48:17 <stevemar> i really like the idea of the working sessions, seems like a mini-meetup
18:48:22 <ayoung> Hotels have been posted...reserve your rooms
18:48:30 <morganfainberg> we could easily go as high as 5 fishbowl, and 10 working
18:48:34 <morganfainberg> but i'd like to keep the numbers lower
18:48:42 <ayoung> mini-me--etup
18:48:50 <morganfainberg> unless people feel like there is a real reason to ask for more spaces
18:49:10 <morganfainberg> i felt like paris summit we were a little light on topics so some stuff filled in (it worked) but this is a bit more structure
18:49:25 <morganfainberg> i'm also asking for a full-day meetup on friday (vs. the ½ day we got in paris)
18:49:33 <morganfainberg> in lieu of the more working sessions/fishbowls
18:49:36 <stevemar> we usually have a few major topics that people want to talk about, thats what fishbowl is for
18:49:49 <stevemar> ++ for full day
18:49:55 <ayoung> Schedule your flights out saturday morning so we actually get the whole day, please
18:50:03 <morganfainberg> so if we get full day on friday, 4 fishbowl / 8 working would be good.
18:50:19 <ayoung> Unless you are on the West coast, or doing a red eye, but stay through the finish line
18:50:23 <morganfainberg> and we will have plenty of "bug other projects / go to other fishbowls"
18:50:25 <atiwari> morganfainberg, ayoung is it ok to implement a solution with "HMAC token" by kilo as an exception?
18:51:07 <marekd> stevemar: what are fishbowls by summit definition?
18:51:08 <ayoung> atiwari, let's talk after this meeting...it depends on a few things
18:51:09 <morganfainberg> atiwari, i would be worried about any other SPFEs at this point. it's really late in the cycle
18:51:20 <morganfainberg> marekd, the same as our summit sessions we had in paris
18:51:28 <marekd> morganfainberg: ok :=)
18:51:39 <ayoung> the short of it is that HMAC by itself won't heal the ills of PKI tokens.
18:51:40 <morganfainberg> ok so i'm going to ask for 4/8 + full friday.
18:51:54 <gyee> they are going to pump more oxygen into the rooms this time right?
18:51:55 <morganfainberg> and move that to 5/10 if we can't get the full day on friday
18:52:22 <ayoung> gyee, that fresh Candian Air, pumped down from Bampf
18:52:24 <gyee> where were hardly room to stand at Paris
18:52:44 <ayoung> gyee, we knew that Paris was going to be crowded.  Suspect Vancouver will not have the shortcoming.
18:52:52 <morganfainberg> ok lets give time for the last topic
18:53:09 <stevemar> #topic Open Discussion
18:53:14 <gyee> ha
18:53:16 <stevemar> #topic GSoC 2015
18:53:19 <samueldmq> dims__, ^
18:53:27 <dims__> We are looking for Project ideas and mentors for Google Summer of Code - https://wiki.openstack.org/wiki/GSoC2015
18:53:27 <marekd> #yay GSOC!
18:53:33 * topol I hope I don't get stuck smuggling ketchup chip back in at the border
18:53:45 <ayoung> Dynamic Policy has many subspecs.  Would suggest starting there
18:54:01 <samueldmq> ayoung, ++
18:54:04 <stevemar> topol, you must bring back all the goodies i mentioned on twitter
18:54:09 <marekd> kicking ass auth plugins in keystoneclient
18:54:11 <dims__> thanks ayoung
18:54:15 <ayoung> also,  there are parallel efforts for a GsoC project from http://adam.younglogic.com/2014/10/who-can-sign-for-what/
18:54:21 <stevemar> marekd, ++
18:54:22 <dstanek> dims__: i've mentored before and i'd do it again if there was a need
18:54:35 <marekd> i mean, general framework for auth plugins.
18:54:36 <dims__> dstanek: mind if i add your name on a wiki?
18:54:43 <samueldmq> I am a candidate to mentor a project, I will look into those ayoung ideas and then submit a couple of ideas that fit the gsoc schedule
18:54:43 <stevemar> marekd, are you signing up for it? :)
18:54:52 <dims__> thanks samueldmq
18:54:56 <ayoung> that second one assumes PKI tokens, which is less of a viable option with AE.  Would probably recommend the dynamic policy one to start
18:55:07 <jamielennox> marekd: what's missing? :)
18:55:08 <marekd> stevemar: i would like to, but i am fearing i might not have time for that. Was just giving some ideas :(
18:55:20 <stevemar> marekd, fair enough!
18:55:27 <dstanek> dims__: not at all
18:55:30 <dims__> marekd: we need ideas too, anything you can throw in the wiki link is appreciated
18:55:42 <ayoung> dims__, I'm willing to as well, but I might have an intern this summer which would probably eat up my mentoring budget
18:56:01 <dims__> ayoung: ack, let's see how many people show up with security skills
18:56:13 <dims__> thanks everyone!
18:56:20 <stevemar> dims__, thanks for reaching out
18:56:25 <marekd> jamielennox: this very old idea where ou have complex auth plugin (say, SAML2 one), but would need to be able authN method between you and Identity PRovider (BasicAuth hardcoded today)
18:56:38 <stevemar> #topic open discussion
18:57:03 <jamielennox> marekd: yea - we're getting there, missing some discovery on the server side yet
18:57:10 <stevemar> anyone else have something they want to chat about, or we can end things a bit early?
18:57:14 <samueldmq> stevemar, I have a bp for for no-spec require status
18:57:24 <marekd> jamielennox: i think there is nothing to do with the server.
18:57:30 <samueldmq> #link https://blueprints.launchpad.net/keystone/+spec/assignment-manager-cleanup
18:57:32 <stevemar> samueldmq, liink?
18:57:32 <marekd> you, the client must know what to use.
18:57:51 <samueldmq> it's quite simple, to re-use list_role_assignemtns wherever possible inside the assingment manager
18:58:03 <samueldmq> avoiding to replicate the code for inherited roles and grouping expansion
18:58:13 <samueldmq> that leads to bugs sometimes
18:58:16 <stevemar> samueldmq, i don't think we need a spec for this
18:58:18 <samueldmq> the main goal is to reuse code
18:58:27 <jamielennox> marekd: right, you need to know what's available - anyways
18:58:33 <henrynash> I’ll make a quick pitch for some review of LDAP filtering (two patches, starting with https://review.openstack.org/#/c/147551/)…pretty easy, and we can get that in quickly
18:58:52 <samueldmq> stevemar, great! that's my goal (no spec), do we need to vote?
18:58:52 <stevemar> henrynash, i'll be glad to review it
18:58:55 <samueldmq> others?
18:58:56 <marekd> I think I will also have the student this summer
18:58:59 <ayoung> henrynash, when you write those, add nkinder and richm to the reviews.  They are the LDAP gurus
18:59:11 <stevemar> samueldmq, i think just post the code and see if you can get someone to review it
18:59:14 <ayoung> I'll look too, but I'd defer to them anyway
18:59:17 <henrynash> ayoung: ok, will do , thx
18:59:23 <stevemar> samueldmq, but priority will go to the ones associated with specs
18:59:45 <bknudson> why is priority given to bps with specs?
18:59:48 <stevemar> samueldmq, since this is a cleanup, we may allow it to go in post feature freeze, but i don't see why it can't wait til L
18:59:50 <samueldmq> stevemar, ok ack, henrynash will probably review it, it's related to the work that's going on the assignment backend
19:00:00 <jamielennox> can someone kick this off: https://review.openstack.org/#/c/150627/ - copy federation plugins over to the new repo
19:00:06 <jamielennox> actually - marekd can do it now
19:00:17 <jamielennox> marekd: this will make things quicker
19:00:23 <samueldmq> stevemar, ok let's see how fast it goes (it's simple, nothing too complex)
19:00:24 <marekd> jamielennox: looking
19:00:24 <samueldmq> thnaks
19:00:38 <stevemar> #endmeeting