18:02:46 <morganfainberg> #startmeeting Keystone
18:02:47 <gyee> startmeeting?
18:02:48 <openstack> Meeting started Tue Mar 17 18:02:46 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:51 <openstack> The meeting name has been set to 'keystone'
18:03:03 <morganfainberg> gyee, so i like to type extra spaces >>
18:03:07 <gyee> ha
18:03:13 <morganfainberg> Ok, lets just get to it.
18:03:25 <morganfainberg> K3 this is this week. Please review the last fernet token patches.
18:03:37 <morganfainberg> #topic DB2 CI
18:03:45 <marekd> that was fast.
18:03:54 <morganfainberg> bknudson, o/ (since yanfengxi is not in channel)
18:04:09 <bknudson> yanfenxi is in beijing and wasn't able to stay awake.
18:04:17 <morganfainberg> understandable
18:04:19 <bknudson> so he asked me to cover this...
18:04:28 <marekd> 2:04 AM
18:04:32 <marekd> in Beijing
18:04:34 <bknudson> so the DB2 CI was disabled a while ago.
18:04:45 <ayoung> why?
18:04:54 <davechen_> i am still awake, 2:04 here. :)
18:04:56 <bknudson> it was disabled because it was reporting merge failures
18:04:59 <lbragstad> o/
18:05:03 <bknudson> and nobody was around who could fix it.
18:05:07 <bknudson> I don't have access.
18:05:18 <morganfainberg> ayoung, noise, consistently broken, and was not presenting logs for 30 days, and no one was found to fix it
18:05:34 <dstanek> still in training, but i'll try to pay attention here too
18:05:41 <topol> who owns it?  We can get you access
18:06:11 <bknudson> so the request is to re-enable it, just so that it can get notifications so we can verify it works,
18:06:17 <bknudson> it won't be posting reviews
18:06:28 <gyee> was it a voting gate before?
18:06:30 <bknudson> when we think it's ready to post reviews we'll come ask fo rthat.
18:06:38 <morganfainberg> gyee, no.
18:06:51 <morganfainberg> bknudson, ok so you want to move it back to sandbox capable
18:07:30 <morganfainberg> bknudson, i'm ok with that and will ask -infra, as long as it isn't posting anything until we're sure it is working.
18:07:31 <bknudson> morganfainberg: right.
18:07:53 <gyee> how much time does db2 add to jenkins?
18:07:57 <bknudson> morganfainberg: ok, thanks.
18:08:09 <morganfainberg> bknudson, before it posts stuff again, we need to have a clear escalation when it's broken, it needs to retain logs for 30 days.
18:08:18 <marekd> bknudson: is that DB2 CI running on VM provided by Rackspace,HP and others?
18:08:26 <bknudson> gyee: obviously it runs on its own, and it's hard to compare since we've got our own system...
18:08:32 <morganfainberg> bknudson, preferably someone looking at it, vs. keystone having to ask them why it's broken.
18:08:40 <ayoung> I vote yes...any additional data points on our DB side are valuable
18:08:46 <bknudson> marekd: we've got our own systems.
18:09:01 <bknudson> one of the issues is that we didn't have enough systems and we've added more.
18:09:14 <marekd> bknudson: so, all VM's  simply configure keystone to point to that remote backend somewhere else, ok
18:09:31 <bknudson> I believe these vms have their own db2 instance.
18:09:32 <morganfainberg> ok i'll ask -infra to re-enable as long as it isn't posting anything.
18:09:40 <morganfainberg> until other issues are addressed.
18:09:42 <gyee> bknudson, that's fine so as long as it doesn't slow down jenkins considerably overall
18:09:56 <morganfainberg> gyee, it's 3rd party CI.
18:10:20 <bknudson> it actually doesn't run all of the tests, only ones marked for keystone.
18:10:44 <morganfainberg> gyee, so it should run mostly faster than the rest of the gate based on a smaller subset of tests.
18:11:00 <morganfainberg> gyee, and it wont blockup the actual gate pipeline (3rd party ci is check-only)
18:11:03 <ayoung> Can we all agree yes and move on?  I think this is a non issue
18:11:05 <gyee> morganfainberg, sure lets reenable then
18:11:17 <marekd> ayoung: yes
18:11:17 <bknudson> thanks!
18:11:24 <ayoung> coo
18:11:27 <bknudson> I'll let yanfengxi know.
18:11:42 <gyee> bknudson, he'll need to fix failures at 2am :)
18:11:56 <ayoung> he needs to give perms to bknudson to do it
18:12:02 <morganfainberg> #info DB2 CI will be requested to be re-enabled but will not post until other issues (failures and 30 day log retention) have been addressed.
18:12:08 <morganfainberg> #topic Feature Freeze Exceptions
18:12:09 <ayoung> ++
18:12:31 <morganfainberg> since kilo3 is this week.. we have a couple FFEs that will be requested.
18:12:34 <ayoung> how much work is left for Reseller?
18:12:45 <morganfainberg> I've spoken to henrynash to sponsor the two major FFEs
18:12:53 <morganfainberg> the first FFE is reseller.
18:13:00 <raildo> ayoung, we need to finish just one more patch (bye bye domain table)
18:13:15 <henrynash> yep, happy to sponsor
18:13:15 <morganfainberg> rodrigods, raildo, please send a message to the -dev mailing list requesting the FFE.
18:13:24 <ayoung> raildo, and how close is that...link?
18:13:29 <raildo> morganfainberg, ok
18:13:31 <gyee> a moment of silence for domains
18:13:33 <morganfainberg> please say henrynash will sponsor, link to the code, and show that it's mostly reviewing.
18:13:39 <marekd> morganfainberg: http://paste.openstack.org/show/192951/ this is also after couple iterations of reviews. and since we were blocked by a bug we couldn't merge earlier: https://review.openstack.org/#/c/152156/
18:13:39 <raildo> ayoung, https://review.openstack.org/#/c/161854/
18:13:48 <rodrigods> morganfainberg, great, thanks
18:13:58 <ayoung> why WIP?
18:14:18 <raildo> ayoung,because we don't finish the implementation yet
18:14:25 <ayoung> OK....how much work?
18:14:29 <morganfainberg> The second FFE, is the rest of henrynash's domainSQL, henrynash please send the FFE request to the -dev mailing list. I know it's just the final couple patches.
18:14:46 <henrynash> morganfainberg: will do
18:14:48 <raildo> adn we have a problem when we're trying drop the table
18:15:04 <morganfainberg> marekd, you or marco are welcome to send an FFE request for those.
18:15:05 <ayoung> raildo, ok,  hit me up after the meeting if you need help
18:15:13 <marekd> morganfainberg: ok
18:15:13 <morganfainberg> marekd, s/those/that
18:15:16 <ayoung> that should be relatively simple to knock out
18:15:17 <raildo> ayoung,  ok, thanks :)
18:15:34 <ayoung> or impossible...we'll see.
18:15:39 <morganfainberg> when sending to the dev mailing list be sure to use [keystone] and include FFE request in the subject
18:15:44 <morganfainberg> be descriptive
18:16:06 <morganfainberg> a few other BPs have been moved to post kilo3 since they are non-API impacting (and not really "Features")
18:16:07 <raildo> morganfainberg, ok
18:16:20 <marekd> morganfainberg: ack.
18:16:42 <morganfainberg> please respond to the ML topics (everyone) for/against/concerns once tehy are sent.
18:16:43 <ayoung> raildo, do it as two migrations.  One for the FK, one for the table drop
18:16:50 <ayoung> will make it easier to sort out/
18:16:51 <henrynash> bknduson, stevemar, lbragstad: there are two domain config ones that we can probably get in ahead of k3 since they have been extensively reviewed: https://review.openstack.org/#/c/159928/ and https://review.openstack.org/#/c/165075/
18:17:32 <raildo> ayoung, the FK part is working, but when we try drop the table, we got a error. i'll talk with you later :)
18:17:35 <morganfainberg> the ML topic will be used to either grant the exception or push to liberty. Realize it is not exclusively the keystone team involved in granting the FFE, i will be conferring with ttx and release management as well.
18:17:50 <bknudson> are all these reviews on the https://gist.github.com/dolph/651c6a1748f69637abd0 page?
18:18:06 <morganfainberg> bknudson, no. those reviews are just for k3 now [except the domain SQL one]
18:18:09 <bknudson> that's where I've been going to find reviews.
18:18:16 <morganfainberg> bknudson, since someone else has starred it
18:18:38 <lbragstad> should we put them on the review page?
18:18:42 <lbragstad> I can star them
18:18:42 <morganfainberg> bknudson, so basically the fernet tokens only
18:18:46 <marekd> morganfainberg: dolphm bknudson : https://review.openstack.org/#/c/152156/ is not
18:18:46 <morganfainberg> lbragstad, no.
18:18:49 <morganfainberg> lbragstad, wait till the FFEs are granted
18:18:54 <henrynash> morgainfainberg: remind me, keystone client library additions don’t need an FFE, right?
18:18:55 <lbragstad> morganfainberg: ok
18:19:03 <stevemar> henrynash, nope
18:19:15 <morganfainberg> henrynash, client and middleware and pycadf have no FFEs needed
18:19:17 <bknudson> at some point we're going to release a keystoneclient, so they have to be in before that.
18:19:21 <henrynash> ok
18:19:32 <morganfainberg> there will be a release of client right before RC
18:19:37 <ayoung> yeah...let's queue up the client questions for later
18:19:40 <henrynash> bknduson: indeed
18:19:45 <ayoung> I have a few...
18:19:48 <morganfainberg> that client release will coincide with the release (final tagging)
18:20:02 <morganfainberg> but for today, the Fernet token patches are the priority
18:20:02 <bknudson> scary.
18:20:21 <bknudson> btw, this means that bp https://blueprints.launchpad.net/openstack/?searchtext=auth-token-use-client isn't going to be done for K.
18:20:24 <ayoung> morganfainberg,   remove " Group role revocation invalidates all user tokens"
18:20:25 <morganfainberg> #info Fernet Token Final Reviews are priority for k3
18:20:28 <ayoung> we are not going to address that
18:20:37 <bknudson> since it requires changes to auth_token middleware that depend on client changes.
18:20:38 <morganfainberg> ayoung, i can't someone else has it starred
18:20:55 <morganfainberg> ayoung, it's not exclusively my list.
18:21:20 <ayoung> Clone it
18:21:22 <ayoung> Its git!
18:21:34 <morganfainberg> ayoung, i don't have the bot that updates it.
18:21:39 <morganfainberg> ayoung, that's dolphs code.
18:21:45 <morganfainberg> and i haven't seen it.
18:21:49 <ayoung> I know, but for the k3 list on launchpad it should be gone
18:22:07 <ayoung> https://launchpad.net/keystone/+milestone/kilo-3
18:22:25 <morganfainberg> ayoung, it was tagging 2 bugs, i missed one
18:22:31 <ayoung> cool
18:22:33 <morganfainberg> ok
18:22:50 <morganfainberg> #topic requirements.txt: Should requirements.txt be for the expected installation
18:22:57 <morganfainberg> #undo
18:22:57 <ayoung> wait
18:22:57 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x90b8750>
18:22:59 <ayoung> skipped one
18:23:04 <ayoung> https://blueprints.launchpad.net/keystone/+spec/mapping-enhancements
18:23:15 <morganfainberg> ayoung, that is a patch dstanek needed to update a comment on
18:23:16 <ayoung> that is on the k3 list, and tagged as needs code review
18:23:27 <ayoung> other than that it is good>?
18:23:28 <morganfainberg> it's done, just a test enhancement that could land now/post k3
18:23:29 <morganfainberg> yes
18:23:31 <stevemar> ayoung, i think we can close that one out now
18:23:47 <morganfainberg> wasn't going to close it till the last patch was landed but that is minimal/doesn't need massive eyes atm.
18:24:12 <ayoung> OK...
18:24:20 <morganfainberg> #topic requirements.txt: Should requirements.txt be for the expected installation?
18:24:27 <morganfainberg> bknudson, o/
18:24:32 <bknudson> ah, so I posted a review...
18:24:37 <bknudson> that got -1d
18:24:41 <ayoung> link
18:25:04 <morganfainberg> #link https://review.openstack.org/#/c/162360/
18:25:06 <stevemar> bknudson, you were finally on the receiving end
18:25:12 <bknudson> y, that was it.
18:25:24 <bknudson> essentially moving fernet requirements to test-requirements.txt
18:25:39 <bknudson> since my understanding was that we only have default config requirements in requirements.txt
18:25:55 <ayoung> Do we have mysql in requirements?
18:25:58 <morganfainberg> my view is test-requirements should only be for testing.
18:26:16 <bknudson> now, if we change that policy ... maybe we should also have ldap and ldappool in requirements.txt?
18:26:19 <morganfainberg> anything that could be used for runtime should be in main requirements.txt
18:26:25 <morganfainberg> bknudson, i would support that
18:26:28 <stevemar> bknudson, we probably should
18:26:36 <topol> bknudson +++
18:26:57 <bknudson> vote on it?
18:27:04 <morganfainberg> #vote
18:27:09 <morganfainberg> damn enter key.
18:27:09 <gyee> so why we even need test-requirements.txt then?
18:27:18 <bknudson> there will still be test-only requirements...
18:27:19 <gyee> since now everything will be enabled by default
18:27:19 <bknudson> testtools
18:27:20 * topol yay a vote. lets see who is paying attention
18:27:23 <morganfainberg> gyee, yes there are test-only things
18:27:27 <bknudson> mock
18:27:28 <haneef> How about different providers for dogpile? where does it fit?
18:27:32 <bknudson> fixtures
18:27:51 <stevemar> the documentation stuff will be there too
18:28:00 <ayoung> we don't even have mySQL in test-requirements
18:28:08 <morganfainberg> haneef, we would be adding any runtim dep - the only special case is liky mongo for licensing reasons
18:28:17 <morganfainberg> haneef, and that is a special case across openstack
18:28:19 <stevemar> using test-req for 'optional' isn't right
18:28:19 <bknudson> I don't think mysql is on pypi?
18:28:26 <bknudson> b/c oracle.
18:28:39 <morganfainberg> bknudson, mysqldb is, but i think we get that another way
18:28:55 <ayoung> So...on the client side, we are splitting things into separate repos due to dependencies.  This is where the python packaging is dumb
18:29:26 <dstanek> i always thought that test-requirements was actually for the optional stuff
18:29:37 <ayoung> if we have a plugin/extension/driver that needs a special piece of code, we should be able to package that separately without having to split the repo
18:29:39 <stevemar> dstanek, that's what we kept telling people :P
18:29:52 <ayoung> well, it is for installing things we need to run tests
18:30:05 <ayoung> so it has the optional flavor, since you can do a minimal install without it
18:30:05 <topol> whaat?  test-requirements is for test. come on man!
18:30:10 <morganfainberg> #startvote Should all runtime requirements (that don't have specific licensing concerns) move from test-requirements.txt to requirements.txt (test-requirements no longer used for "optional")? yes,no,obligatory-yes-but-i-want-to-be-a-snowflake-answer
18:30:11 <openstack> Begin voting on: Should all runtime requirements (that don't have specific licensing concerns) move from test-requirements.txt to requirements.txt (test-requirements no longer used for "optional")? Valid vote options are yes, no, obligatory-yes-but-i-want-to-be-a-snowflake-answer.
18:30:12 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:30:24 <ayoung> dstanek, is python really going to continue to be so stiffnecked about this?
18:30:29 <ayoung> #vote no
18:30:33 <gyee> #vote yes
18:30:38 <morganfainberg> #vote yes
18:30:43 <samueldmq> #vote yes
18:30:45 <topol> #vote yes
18:30:49 <ayoung> It's not licensing, it is dependencies on install
18:30:59 <marekd> #vote yes
18:30:59 <bknudson> #vote no
18:31:02 <breton> who will be the original one?
18:31:06 <breton> #vote yes
18:31:08 <jamielennox> #vote no
18:31:10 <dstanek> #vote no
18:31:11 <bknudson> voting no just because this is how we've always worked so why change it.
18:31:11 <morganfainberg> ayoung, magically knowing what to install to turn something on is a terrible experience
18:31:12 <jamielennox> but torn
18:31:20 <dolphm> #vote no
18:31:23 <morganfainberg> ayoung, it doesn't prevent redhat from bundling deps differently
18:31:29 <ayoung> morganfainberg, having to find the LDAP deps if you are not running LDAP is also a bad one
18:31:32 <ayoung> or postgresql
18:31:35 <ayoung> DB2?
18:31:36 <haneef> #vote no
18:31:41 <dstanek> has anyone talked to distributions about this?
18:31:44 <jamielennox> morganfainberg: it expects (for example redhat) package maintainer to go and find all this for themselves
18:31:46 <breton> #showvote
18:31:47 <openstack> yes (6): gyee, morganfainberg, marekd, samueldmq, topol, breton
18:31:48 <openstack> no (6): dstanek, ayoung, bknudson, haneef, dolphm, jamielennox
18:31:59 <gyee> evenly spread
18:32:03 <morganfainberg> test-requirements is the wrong place for "optional" python dependencies
18:32:03 <dstanek> ayoung: this isn't really a python thing
18:32:04 <bknudson> hmmm...
18:32:11 <topol> so ayoung brings up a valid consumability point
18:32:11 <ayoung> dstanek, distributions are going to have to update how they idenityf what to install with what...it will likely break their scripts\
18:32:16 <stevemar> #vote yes
18:32:26 <ayoung> dstanek, yes it is, cuz I can only deploy one package from one repo
18:32:29 <bknudson> stevemar: the tiebreaker.
18:32:32 <raildo> #vote yes
18:32:33 <ayoung> and that is due to python, not git, and not packaging
18:32:45 <morganfainberg> dstanek, packagers have told me both sides, the one that got me was "i can't make X a dependency in my package cause it's in test-requirements, move it to requirements or i can't support it because $policy"
18:32:48 <topol> we should not put something in requirements if its not always required and can easily break stuff
18:33:00 <dolphm> morganfainberg: that's a broken $policy
18:33:04 <stevemar> topol, how would it break stuff?
18:33:10 <bknudson> topol: changing your vote?
18:33:11 <ayoung> can we hold off on this one until we get feedback please?
18:33:13 <dstanek> ayoung: normally you would use the extras_require to say 'hey, i'm using ldap and here are the extra requirements'
18:33:15 <morganfainberg> dolphm, putting things in test-requirements because they are optional is worse imo
18:33:18 <lhcheng> #vote no
18:33:19 <breton> topol: if it's in the main tree and covered with tests, it's working
18:33:26 <lbragstad> #vote no
18:33:30 <morganfainberg> dolphm, that is very much the wrong place for these things
18:33:31 <stevemar> breton, ++
18:33:32 <lbragstad> for the reasons bknudson listed
18:33:34 <bknudson> ayoung: you know someone who can provide feedback on your side?
18:33:40 <ayoung> bknudson, yes
18:33:42 <ayoung> apevec
18:33:44 <topol> ayoung can you elaborate on your ldap concern
18:33:45 <morganfainberg> this includes cryptography, msgpack, ldap, ldappool, etc
18:33:50 <dolphm> morganfainberg: is there a broader community concern on that?
18:33:54 <ayoung> topol, LDAP pulls in a native library
18:34:06 <jamielennox> morganfainberg: isn't this a TC question anyway?
18:34:09 <dolphm> morganfainberg: (i wouldn't want to see keystone deviate from the community consensus on usage of test-requirements)
18:34:14 <morganfainberg> jamielennox, not really.
18:34:16 <topol> ayoung and if the library isnt there?
18:34:17 <ayoung> so by putting LDAP in the python tree, you pull in pythn-ldaop, which pulls in openldap libs
18:34:25 <gyee> morganfainberg have an excellent point on *user experience*
18:34:27 <morganfainberg> dolphm, i think we're flat out doing it wrong in python.
18:34:40 <ayoung> topol, I think with PIP, it is even worse
18:34:44 <breton> #showvote
18:34:44 <gyee> it would suck if I enabled a feature and then found out I need to explicitly install more packages
18:34:45 <openstack> yes (8): gyee, morganfainberg, marekd, samueldmq, topol, raildo, breton, stevemar
18:34:47 <openstack> no (8): dstanek, ayoung, lhcheng, bknudson, haneef, lbragstad, dolphm, jamielennox
18:34:56 <stevemar> how contentious
18:34:57 <breton> gyee: ++
18:34:57 <ayoung> for MySQL and LDAP you have to have the devel version of the native libs installed to do the native bindings
18:34:59 <bknudson> I vote to put it off, let's have an action to hear back from packagers.
18:35:01 <topol> gyee makes a good point
18:35:10 <morganfainberg> dolphm, this isn't openstack community this is doing it wrong in python world. if we want a separate dependency tree, we should be splitting the stuff up into separate python packages
18:35:13 <topol> I agree with bknudson
18:35:19 <stevemar> gyee, that's always been the case
18:35:20 <henrynash> #vote no
18:35:29 <gyee> stevemar, then lets make it less suck
18:35:29 <dolphm> gyee: some of those packages might require more binary deps - which sucks in python land imo
18:35:35 <dstanek> gyee: that mean you always have to install everything? what about things that have a dep on a system package?
18:35:38 <bknudson> as far as our packaging goes, I don't think it will cause a problem either way.
18:35:40 <stevemar> gyee, thats why i voted yes
18:35:46 <haneef> gyee: it would also suck if  my installation is  stuck due to a dependency which I won't be using it
18:35:50 <dolphm> morganfainberg: that'd be fantastic
18:35:52 <gyee> most of us are shipping a distro
18:36:01 <morganfainberg> dolphm, i have $ideas for liberty ;)
18:36:03 <ayoung> we split the python-keystoneclient repo for just this reason
18:36:05 <topol> henrynash, what sis your concern?
18:36:05 <dolphm> morganfainberg: test-requirements.txt was invented by the openstack community
18:36:05 <gyee> a distro, not distro and a bunch of optional deps
18:36:21 <ayoung> the client is relatively consistant, but we pushed kerberos and SAML codes to separate repos
18:36:26 <davechen_> #vote no
18:36:35 <topol> Im scared we will rush this decision and really break folks
18:36:59 <ayoung> Let's float it to the -dev list and get some wider feedback, and revisit
18:37:03 <morganfainberg> topol, it wont really break anyone shipping a distro, and anyone doing CI/CD already has addressed most of this.
18:37:10 <morganfainberg> but in short. we'll defer this till liberty
18:37:13 <breton> ++ayoung
18:37:14 * topol trying to my yes back in the bottle
18:37:14 <bknudson> there are some discussion already going on in community.
18:37:16 <gyee> as a user, I would expect a distro contains everything that I need
18:37:17 <morganfainberg> based on this. vote
18:37:22 <henrynash> topol: I’m worried about a) deviating from openstack standard, and b) loading stuff that’s not strictly needed into production systems (less you install the better for secuirty)
18:37:27 <morganfainberg> we'll do further talking at the summit and on the list
18:37:35 <morganfainberg> bknudson, i am going to -2 that patch though for now.
18:37:54 <bknudson> wait, my patch was about following the current policy...
18:37:58 <bknudson> not deviating.
18:38:04 <topol> henrynash, make sense
18:38:13 <topol> makes sense  :-)
18:38:20 <dstanek> #showvote
18:38:21 <openstack> yes (8): gyee, morganfainberg, marekd, samueldmq, topol, raildo, breton, stevemar
18:38:22 <openstack> no (10): dstanek, ayoung, lhcheng, bknudson, davechen_, haneef, lbragstad, dolphm, jamielennox, henrynash
18:38:23 <morganfainberg> bknudson, because i don't want to shuffle everything around right now.
18:38:24 <topol> (that s makes a world of difference)
18:38:30 <topol> #vote no
18:38:35 <morganfainberg> #endvote
18:38:36 <openstack> Voted on "Should all runtime requirements (that don't have specific licensing concerns) move from test-requirements.txt to requirements.txt (test-requirements no longer used for "optional")?" Results are
18:38:38 <openstack> yes (7): gyee, morganfainberg, marekd, samueldmq, raildo, breton, stevemar
18:38:39 <openstack> no (11): dstanek, ayoung, lhcheng, bknudson, davechen_, haneef, lbragstad, dolphm, jamielennox, henrynash, topol
18:38:46 <bknudson> it's 2 lines.
18:38:51 <morganfainberg> bknudson, and if we're doing massive policy adherance lots of stuff needs to shuffle.
18:38:57 <bknudson> really?
18:39:07 <morganfainberg> bknudson, yes. we have lots of non-default things in there.
18:39:11 <morganfainberg> relating to PKI tokens as well
18:39:20 <ayoung> Oy Vey!
18:39:20 <dolphm> genesis in keystone? https://github.com/openstack/keystone/commit/72e4edcc12f4741bd945adf777fe43f3ffcd62d6
18:40:03 <morganfainberg> moving optional to test-requirements was an awful thing. it has caused a lot of questions and "why can't X work" with a response of "go install thing because we don't make it a hard requirement"
18:40:06 <dolphm> morganfainberg: i might change my vote to yes after seeing my own commit :P
18:40:27 <topol> wow things were simpler in 2011
18:40:31 <ayoung> morganfainberg, lets work with dstank to have a better modular install story
18:40:45 <morganfainberg> ayoung, liberty.
18:40:48 <gyee> topol, 1969, nothing by peace and love
18:40:54 <ayoung> if we can get away from "separate git repo to avoid depednecy hell"  I'll be happy
18:40:59 <bknudson> ok, so for K we're going to stick with fernet requirements in requirements.txt ?
18:41:07 <morganfainberg> ayoung, we wont be able to with pypi
18:41:09 <ayoung> morganfainberg,  on the client first, and then Liberty for Server.
18:41:19 <morganfainberg> ayoung, and pbr.
18:41:20 <ayoung> morganfainberg, THEN WE BREAK THEM!
18:41:23 <bknudson> we can just make it a policy where we pick based on what we know.
18:41:24 <ayoung> WE BREAK THAT TOO
18:41:34 <ayoung> BREAK ALL THE THINGS!
18:41:48 <marekd> rewrite everythin from scratch
18:41:49 <morganfainberg> bknudson, ok so let me change my stance
18:41:50 <jamielennox> ayoung's ptl slogan
18:41:51 <dstanek> this is really a packager issue - 'apt-get install keystone keystone-ldap ... etc' - right?
18:41:54 <topol> please remember the user experience concerns
18:42:02 <morganfainberg> dstanek, pip install and apt-get install
18:42:17 <ayoung> jamielennox, life philosophy really.  I was, and will always in my heart be, an Infantryman
18:42:33 <gyee> there's a man who lived
18:42:35 <morganfainberg> bknudson, so my stance is: if it's pure python it can always go in requirements. if it has exceptional binary deps lets put it in test-requirements for now (ldap)
18:42:56 <topol> morganfainberg that makes sense
18:42:58 <haneef> That  is better
18:43:01 <dolphm> morganfainberg: pki & openssl?
18:43:05 <bknudson> let's write a pure-python ldap client.
18:43:09 <morganfainberg> dolphm, opensssl isn't exceptional.
18:43:14 <ayoung> morganfainberg, we shouldprobably get MySQL into test-requirements then
18:43:18 <gyee> and xmlsec1
18:43:24 <ayoung> pki and openssl is even worse
18:43:36 <bknudson> remember lxml?
18:43:39 <ayoung> those can't be done by package requirements except at the distro level
18:43:44 <morganfainberg> if it has historically been in requirements DONT MOVE IT until we decide how we're handling the splitup/new install etc
18:43:45 <gyee> yes that one too
18:43:50 <morganfainberg> this is for new requirements
18:43:57 <dstanek> morganfainberg: to me that is harder to draw the line - do i now have to know how projects are implemented?
18:43:58 <morganfainberg> so crypto and msgpack should be evaluated
18:44:08 <ayoung> we need to get the cryptography.py solution in place for PKI etc.
18:44:10 <bknudson> cryptography must rely on openssl.
18:44:12 <ayoung> But not today
18:44:19 <gyee> dstanek, I am on the user experience side
18:44:23 * dolphm finds it best to refer to the library as pypi/cryptography to avoid confusion
18:44:32 <morganfainberg> dstanek, try and install it, is it awful to pip install it?
18:44:41 <dolphm> bknudson: it does not, afaik
18:44:51 <morganfainberg> dstanek did it require a bunch of extra apt-gets (e.g. ldap libs dev)
18:44:56 <haneef> ayoung:  There was a review last week to replace  openssl system calls with a crypto lib
18:45:09 <dstanek> morganfainberg: things will go fine if i have the required system packages already so i may not think twice
18:45:25 <morganfainberg> dstanek, since we aren't adding more g-rs this cycle, this is largely deferred
18:45:31 <morganfainberg> dstanek, the only question is msgpack and crypto
18:45:33 <ayoung> haneef, link?
18:45:47 <dstanek> morganfainberg: fair enough
18:45:51 <bknudson> btw - we need a newer cryptography, we're using features that aren't in 0.4
18:45:54 <morganfainberg> dstanek, so, for this cycle address those two and in liberty we work on better stuff.
18:45:56 <browne> https://review.openstack.org/#/c/163088/
18:46:00 <morganfainberg> bknudson, yes there should be a g-r update
18:46:10 <morganfainberg> browne, yay!
18:46:18 <morganfainberg> browne, thats cool.
18:46:36 <bknudson> that must rely on openssl?
18:46:40 <ayoung> Ah...cool.  that is for the setup.  Need to -2 that one
18:46:42 <haneef> ayoung: https://review.openstack.org/#/c/163088/
18:46:46 <ayoung> Its right, but not right enopguh
18:46:49 <topol> browne, Really?  we can do that now?  Thats awesome!
18:46:51 <amakarov> wow, at long last!
18:46:53 <marekd> browne: does it also spawns new process?
18:46:59 <dolphm> morganfainberg: i believe alex gaynor implemented everything we needed to replace openssl while sitting at the keystone pod in atlanta
18:47:12 <dolphm> marekd: no
18:47:18 <morganfainberg> bknudson, https://review.openstack.org/#/c/164289/
18:47:23 <browne> marekd: no, library calls.  this patch only replace rsa key generation
18:47:25 <dolphm> pypi/cryptography implements it's own primitives
18:47:32 <bknudson> morganfainberg: y, +2 it.
18:47:45 <browne> and requires python-cryptography 0.8
18:47:48 <dolphm> browne: going to do validation next?
18:47:52 <morganfainberg> bknudson, i can only +1 requirements
18:48:04 <dolphm> browne: does global requirements require 0.8?
18:48:18 <browne> dolphm: yeah, i want to, more work for sure.
18:48:21 <dolphm> oh i see the review
18:48:29 <ayoung> doesn't matter, we want to kill that code path anyway.
18:49:00 <ayoung> selfsigning was never the right approach for SSL, and if we do it, it should not be embedded in the keystone code
18:49:02 <bknudson> #showvote
18:49:06 <dolphm> browne: add "Depends-On: I98941cce82d3c33bcc95ecc48ecff413ef81664a" to your keystone patch commit message
18:49:09 <ayoung> its not their code that is wrong, it is ours
18:49:13 <gyee> ayoung, by they are two different issues
18:49:20 <morganfainberg> bknudson, highly contentious, with people switching votes
18:49:22 <ayoung> gyee,
18:49:26 <gyee> one is about key management
18:49:29 <dolphm> browne: IF you don't want your patch to ever be tested without cryptography > 0.8
18:49:32 <ayoung> https://review.openstack.org/#/c/134099/
18:49:37 <ayoung> gyee, ^^
18:49:39 <gyee> the other to replace openssl command line call
18:50:17 <ayoung> gyee the openssl command line call can go away, and be replaced by the certmonger call
18:50:34 <gyee> ayoung, so certmonger does both?
18:50:35 <ayoung> I mean, where they *fixed* things it is arguable irrelevant.
18:50:37 <ayoung> Yep
18:50:43 <gyee> nice
18:50:43 <topol> ayoung, VERY COOL!
18:50:50 <browne> is certmonger another command line?
18:51:09 <morganfainberg> browne, yes, but it can talk to secure cert stores.
18:51:19 <morganfainberg> browne, vs needing a cert in an insecure location(ish) thing.
18:51:27 <ayoung> command line is irrelevant
18:51:36 <lbragstad> ~ 9 minutes left
18:51:39 <ayoung> we need the library for the hot path
18:51:41 <topol> ayoung, doesnt command line imply a performance hit?
18:51:44 <ayoung> signing and validating certs
18:51:48 <ayoung> topol, this is at setup
18:51:50 <morganfainberg> browne, there are further discussons to using certmonger, but that is not today
18:51:51 <ayoung> so irrelevant
18:52:04 <topol> ayoung, K
18:52:09 <morganfainberg> ok so back on topic
18:52:23 <ayoung> topol, certmonger is just for provisioning,  we need cryptography.py for keystoneclient
18:52:26 <morganfainberg> requirements: nothing is moving, please vote on bknudson's patch.
18:52:30 <morganfainberg> i wont -2
18:52:33 <ayoung> server calls in to client to sign tokens
18:52:44 <browne> ayoung: command line is not irrelevant with keystoneclient anyway.  i was seeing huge numbers of open file handles due to the exec (and chatty neutron)
18:52:44 <morganfainberg> ayoung, please defer this to later
18:52:51 <ayoung> ++
18:53:20 <morganfainberg> if you want msgpack and crypto over in test-requirements please +2/+1
18:53:25 <morganfainberg> if you don't care, no vote -1.
18:53:33 <morganfainberg> no vote/-1
18:54:00 <bknudson> alright, thanks.
18:54:06 <morganfainberg> i'll either press approve based on overall score on post k3 or -2/abandon
18:54:11 <topol> is there a good reason to move beyond the "it should be there"
18:54:16 <ayoung> vote yes
18:54:23 <ayoung> vote for pedro
18:55:07 <gyee> vote for jeb
18:55:08 <morganfainberg> this is a simple case where overall score will win, a +2/+1 is 1 point for, a -1 is a vote against. just score the patch the way you feel.
18:55:24 <topol> if folks are used to it being in requirements we just cause pain by moving to test
18:55:34 <morganfainberg> topol, this is just for fernet
18:55:41 <morganfainberg> the 2 items bknudson wanted to move
18:55:46 <morganfainberg> crypto and msgpack
18:55:48 <morganfainberg> nothing else is moving
18:55:50 <topol> K, so no larger impact. got it
18:55:52 <bknudson> those are both new
18:56:07 <morganfainberg> next quick topic
18:56:10 <topol> K. brad slow on St Patricks day (and all other days)
18:56:15 <morganfainberg> #topic Liberty Specs
18:56:32 <morganfainberg> I will be sending the announcemenrt that liberty spec proposals will be open as soon as K3 has been tagged
18:56:45 <morganfainberg> #info morganfainberg will be sending the announcemenrt that liberty spec proposals will be open as soon as K3 has been tagged
18:57:11 <morganfainberg> the goal is to make it so we can have spec discussions (like at the midcycle) but at the summit this time
18:57:21 <marekd> ++
18:57:44 <marekd> so we should start working on the specs right about almost now.
18:57:49 <morganfainberg> getitng almost a full ½ dev cycle on specs by L1 so we can avoid piling everything into the 3rd milestone
18:58:02 <morganfainberg> marekd, that is why we're going to open spec proposals now :)
18:58:08 <samueldmq> morganfainberg, ++
18:58:21 <morganfainberg> marekd, well this week :)
18:58:37 <marekd> morganfainberg: that's why i said "almost now" :-)
18:58:40 <morganfainberg> thats all i have.
18:58:48 <morganfainberg> and we should clear out of here for the nice -infra folks
18:58:56 <morganfainberg> drink an irish drink or something
18:59:05 <morganfainberg> #endmeeting