18:00:01 #startmeeting keystone 18:00:02 Meeting started Tue Jan 17 18:00:01 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:05 The meeting name has been set to 'keystone' 18:00:16 ping agrebennikov, amakarov, annakoppad, ayoung, bknudson, breton, browne, chrisplo, crinkle, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, gyee, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nisha, nkinder, notmorgan, raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, shaleh, spilla, srwilkers, StefanPaetowJisc, stevemar, topol, portdirect, SamYaple 18:00:24 o/ 18:00:24 o/ 18:00:26 o/ 18:00:26 o/ 18:00:29 o/ 18:00:30 o/ 18:00:42 Hey o/ 18:00:48 o/ 18:01:09 o/ 18:01:28 o/ 18:01:38 let's give it a minute for folks to trickle in 18:03:01 ok - cool 18:03:02 #topic announcements 18:03:06 we are in R-5 and this is the final week for non-client library releases 18:03:13 only 5 weeks left until we release 18:03:27 o/ 18:03:35 also this week is non-client library freeze 18:03:36 we will be releasing new versions of KSA and KSC this week 18:03:47 I know rodrigods has a last minute patch up to KSA to add some tests 18:03:59 and jdennis had a nice fix for ksa 18:04:00 lbragstad, ++ 18:04:00 o/ 18:04:06 mordred: ^ we wont get the KSA context manager in if we don't have an example, it will take me longer to generate it than you 18:04:08 but that's the only thing i think we are waiting on for KSA 18:04:23 if you have an example today, i'll get us to land the new context manager 18:04:27 before the release 18:04:35 morgan ++ 18:04:42 stevemar I assume we have until friday? 18:05:00 we should, but lets not delay unless there is a damn good reason to 18:05:01 lbragstad: wednesday/thursday 18:05:07 the release team doesn't like releasing on friday 18:05:13 ack 18:05:17 commit it and quit :P 18:05:20 >.> 18:05:38 ah 18:05:44 morgan cool - so we have a day or two to land the context manager 18:05:49 theres one more for KSA: https://review.openstack.org/#/c/421319/ 18:05:56 Nice! Let's get it done 18:05:58 yeah i can make that happen 18:06:04 but i need an example to work from 18:06:16 which i expect will take a day or so to shore up 18:06:22 * stevemar puts his +2 on 421319 18:06:24 morgan I can follow up with you later too on that - i just want to have tabs on it 18:06:41 lbragstad: it's more just needing a concrete example and confirming the design is sane 18:06:48 morgan ++ 18:06:51 makes sense 18:06:57 i don't want to land that in KSA (since ksa is very strict in contract) w/o the concrete test(s) 18:06:59 morgan: and docs ;) 18:07:02 (not unit/functional) 18:07:10 stevemar: the example will be for doc generation too 18:07:16 cool 18:07:24 worst case, it lands in Pike 18:07:35 morgan how much does it need to be in this next release? 18:07:36 morgan ok - that answers my question 18:07:36 morgan: yes. sorry. I will do this 18:07:56 lbragstad: ideally this release 18:07:59 we want to lean on it 18:08:01 asap 18:08:18 it cleans up our code in shade/zuul/nodeppool 18:08:21 if there is anything else that we need in those libraries, please speak up so that we can prioritize accordingly 18:08:22 and sooner is very much better 18:08:25 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:08:28 agenda ^ 18:08:32 thanks stevemar 18:08:41 but worst case we can lag on it, i just don't wnat to drag too much if we can avoid it 18:08:55 morgan makes sense - let me know when you need some reviews 18:09:03 Pike PTG in ATL is just around the corner, be sure to check out the etherpad 18:09:11 #link https://etherpad.openstack.org/p/keystone-pike-ptg 18:09:13 if mordred doesn't get it today i'll take on the example work, but it will def be in Pike timeframe instead 18:09:18 it makes it a lot easier as we go through and start planning things 18:09:31 * morgan needs to book a flight 18:09:34 morgan makes sense 18:09:37 * stevemar wonders if anyone added anything to the ptg etherpad 18:09:40 *nope* 18:09:44 Samuel has got Green status to go to Atlanta 18:09:50 final few things to review 18:09:50 nice 18:09:58 fwiw, i'll be missing day 1 of the PTG, family things to do that weekend in Los Angeles 18:09:59 i bought my ticket 18:10:00 review #link https://review.openstack.org/#/c/403898 18:10:04 but i'll be there for the rest of the time 18:10:04 review #link https://review.openstack.org/#/c/409874 18:10:09 review #link https://review.openstack.org/#/c/415895 18:10:14 lbragstad: use #topic! 18:10:16 :) 18:10:35 is the first one not WIP anymore? 18:10:36 stevemar: ++ 18:10:39 stevemar i'm still in the announcements sections :) 18:11:00 knikolla: doesn't look like it :O 18:11:01 #topic final things to review for ocata 18:11:23 o/ 18:11:30 mind if i chime in here lbragstad ? 18:11:35 stevemar sure 18:12:03 we've got maybe 1-2 weeks left for features 18:12:15 I've identified the following as critical patches 18:12:17 https://review.openstack.org/#/c/403898/ 18:12:18 https://review.openstack.org/#/c/409874/ 18:12:18 https://review.openstack.org/#/c/415895/ 18:12:33 the next few are nice to have: 18:12:36 https://review.openstack.org/#/c/387161/ 18:12:36 https://review.openstack.org/#/c/403916/ 18:12:36 https://review.openstack.org/#/c/404022/ 18:12:38 https://review.openstack.org/#/q/topic:bp/per-user-auth-plugin-reqs 18:12:53 so please... everyone knows what i'm gonna ask :) 18:12:56 reviewwwww 18:13:10 roger 18:13:24 sure 18:13:35 I have a new patch up for #link https://review.openstack.org/#/c/415895/ 18:13:36 I'm going to spend today working on docs 18:13:41 lamt: rderose samueldmq rodrigods spilla gagehugo all of you :P 18:13:44 so I'll have something up before 5 18:13:51 will do 18:13:54 I shall pickup the pace 18:14:03 pull down the patch, play with the new functionality 18:14:07 ay ay captain 18:14:12 if you have questions let me know on irc 18:14:15 * samueldmq noda 18:14:15 will do 18:14:21 Nods, not noda 18:14:29 :) 18:14:31 #topic announcement: prepare for bug mode! 18:14:38 secondly we need a few folks to look at the undecided and high bugs 18:14:38 last announcement 18:14:43 lbragstad: take it away 18:14:48 we will need to start going to bugs and getting into bug mode in order to have a productive RC period 18:14:50 stevemar: i'll triage bugs today 18:14:53 there are bunch of things that aren't triaged yet 18:15:03 is anyone able to pick up a couple? this is also something we can try and get through during office hours, too 18:15:09 thanks morgan 18:15:16 morgan: awesome, breton / lbragstad / myself have been doing a pretty good job of it this release 18:15:19 o/ 18:15:34 I don't want to ask someone to do *all* the work, but if someone even has time to do one, that's a big help 18:15:36 wont commit to code, but i'll do a sweep for the high prio ones and make sure nothing is lingering/close out dead bugs if I see them 18:15:43 morgan: ++ 18:15:51 thats all i was asking for 18:15:55 but i'll be sure to hit the highs that looks relevant for ocata 18:16:19 lbragstad: i can work on that 18:16:24 knikolla awesome 18:17:09 if in the process of triaging, you find one that makes a good candidate for office hours - write it down 18:17:13 or vocalize it 18:17:34 it's always nice to have easy ones stashed away for folks to work on 18:17:45 (I wonder if we should make an office-hours bug tag) 18:17:54 i'll put them on the office hours etherpad 18:18:44 knikolla cool - thanks! 18:18:49 moving on 18:18:55 #topic Owning the Docker image 18:19:01 SamYaple o/ 18:20:13 do we have a SamYaple ? 18:20:42 we can circle back after gagehugo's topic 18:20:49 #topic Finishing up doc build stacktraces bug 18:20:50 lbragstad: he chimed in earlier 18:20:56 o/ 18:20:58 gagehugo o/ 18:21:18 gagehugo: hmm, i remember bknudson tackled this early on, looks like we created more errors since then :) 18:21:23 so this bug is almost done 18:21:28 but he's a good resource for this stuff 18:21:43 https://bugs.launchpad.net/keystone/+bug/1602422/ 18:21:43 Launchpad bug 1602422 in OpenStack Identity (keystone) "Many tracebacks building keystone docs" [Low,In progress] - Assigned to Gage Hugo (gagehugo) 18:21:44 #lnk https://bugs.launchpad.net/keystone/+bug/1602422/ 18:21:45 i don't wnat to convert away from @hybrid_property unless really needed 18:21:50 ^ 18:21:55 it seems super useful to keep that 18:22:04 the other option is to just ignore the sql_model file 18:22:07 we used to have an option to fail docs if there were warnings but that hasn't worked for a while now 18:22:07 morgan: ++ 18:22:10 when autodoc'ing 18:22:10 we can skip the file in autodoc for now and work to make that functional down the road 18:22:12 we have other hybrid properties (domain_id), are any of those failing? 18:22:26 I think it's something to do with value that aren't in the same table 18:22:27 short term, skip with a todo 18:22:28 imo 18:22:32 hmm 18:22:37 hmm 18:22:41 because User has name/enabled/domain_id and they are fine 18:22:44 in sql_model 18:22:52 yeah 18:23:03 it's just the password stuff 18:23:20 yeah, I am okay with skipping 18:23:21 if you can't fix it w/o moving away from hybrid_property, just skip that autodoc bit and we can circle back on it 18:23:38 http://paste.openstack.org/show/595256/ 18:23:43 ok, that works 18:23:45 gagehugo: looks like zzzeek is aware of it http://stackoverflow.com/questions/6859182/sphinx-autodoc-integrate-decorated-properties :) 18:23:53 oh cool 18:24:02 sounds like future sql-a will fix 18:24:03 then 18:24:11 that'd be nice 18:24:13 5 years ago :/ 18:24:17 Heh 18:24:25 well lets bug zzzeek again 18:24:26 :) 18:24:30 it should be fixable 18:24:49 and zzzeek works on openstakc now, he didn't 5yrs ago 18:24:55 https://github.com/zzzeek/sqlalchemy/pull/238 18:24:56 so he is more reachable for us 18:24:59 also: https://review.openstack.org/#/c/420171/ for the same bug 18:25:09 oh nice 18:25:49 I'm good then if we wanna move on 18:25:53 cool 18:25:55 gagehugo: maybe check if zzzeek is available in -keystone and bug him? 18:26:01 stevemar: sure 18:26:02 hes great for anything sql related 18:26:18 #topic open discussion 18:26:25 lbragstad: apologies, kids were screaming 18:26:29 there should be some way for us to catch errors in the doc builds 18:26:31 SamYaple cool! 18:26:35 #topic Owning the Docker image 18:26:40 SamYaple o/ 18:27:16 This is based on the pattern of functional tests and devstack moving to the projects 18:27:18 bknudson: fail on warnings :D 18:27:18 * topol On irc, no one can hear your kids scream. Thank goodness. That saved me many a time 18:27:19 Heh... 18:27:36 moving from a central project to the to corresponding remote projects 18:27:40 hello all. short summary, id like to see keystone repo have a Dockerfile and maintain that for keystone 18:27:58 To that effect, we have this 18:28:00 #link https://github.com/yaodu/docker-keystone/tree/master/dockerfiles 18:28:04 it allows the Keystone team to control the defaults for containerization. 18:28:33 up until recently we havent been able to effectively build openstack images ina a manner that CI/CD likes 18:28:41 this was a major pain point in the Kolla project 18:29:00 I was thinking this could go under a separate git repo under the Identity program 18:29:05 where kolla solved this with many layers (a base layer, and openstack-base layer, a keystone-base layer, etc) 18:29:12 this is solved with a single Dockerfile 18:29:31 making it much more reasonable to get into a keystone-owned repo 18:29:40 since there are no linkages to external tooling and complicated layering system 18:29:43 SamYaple: and the identity team should manage it? 18:29:49 ayoung: i would agree a separate repo would be good. 18:29:57 dstanek: i would like to see that yes 18:30:24 morgan: ++ on separate repo - that way i don't need to see it :-) 18:30:27 for a quick look at how easy it would be to build images _with_ patches, https://github.com/yaodu/docker-keystone/blob/master/README.md 18:30:44 * morgan wants to avoid encoding special things for packaging (outside of like bindep) in the main repo 18:30:45 single command can build an image with a ref patch 18:31:27 SamYaple: as a point, is it possible to CI this with zuul? 18:31:35 morgan: yes! thats the goal! 18:31:39 && pip install --no-cache-dir --no-index --no-compile --find-links /tmp/packages --constraint /tmp/packages/upper-constraints.txt \ 18:31:40 SamYaple have other projects already started maintaining their own docker files? 18:31:42 because i don't want to be responsible for something that isn't tested 18:31:46 nothing wrong with keeping it in the repo 18:31:49 why does it install upper-constraints.txt? 18:31:52 lbragstad: no. starting with keystone 18:31:59 if it isn't tested it is broken (in proper openstack fashion) 18:32:03 we keep uwsgi and mod_wsgi stuff in the repo 18:32:14 stevemar: that is not really deployment stuff like docker is 18:32:15 breton: its not installing upper-constraints, its constraining to upper-constraints 18:32:22 stevemar: docker is more like deb or rpm spec imo 18:32:28 morgan: ++ 18:32:35 morgan: and thats the goal here 18:32:38 as long as it's tested it is OK with me 18:32:41 and i would -2 deb control files AND rpm specs 18:32:42 SamYaple: oh ok, sorry 18:32:53 so, i am inclined to say no to a dockerfile in keystone as well 18:32:58 to produce a binary-like thing that can be plugged into a deployment tool/script/devstack 18:33:19 this feels like part of the deployment tools that covers .deb and rpm building 18:33:34 SamYaple have you talked to other projects about whether or not they want a docker file in project source? 18:33:48 lbragstad: not in an official capcity, no 18:33:58 its to help kolla right? 18:33:58 * morgan doesn't wnat to block this though 18:34:10 there are people around that are interested in it, but this is the first official project meeting 18:34:14 but just voicing the opinion of where i see this fitting 18:34:17 it's no help to them if we don't use it and it just rots 18:34:32 dstanek: testing would be a requirement 18:34:47 dstanek: we've had other stuff bitrot before for less 18:34:47 stevemar: this is unrelated to Kolla. Kolla needs external tooling to build and isn't CI/CD friendly 18:34:53 SamYaple I'd be curious to see what a note the mailing list brings up 18:35:03 lbragstad: can do. 18:35:11 SamYaple I only worry about having a split conventions between the different projects 18:35:31 lbragstad: to be clear, i am hoping for a cross-openstack effort here, not something keystone specific 18:35:35 (some projects keeping in tree, some keeping it in a separate repo under the project, some projects keeping is somewhere else) 18:35:41 SamYaple ++ 18:35:45 so what you suggest is reasonable. this is jsut the first conversation on the road 18:35:53 SamYaple: apply for a new community goal? 18:36:02 * SamYaple adds to list 18:36:26 SamYaple: like this? https://review.openstack.org/#/c/419706/ 18:36:31 What I want to avboid is having people that know nothing about Keystone make decisions that are then inherited . Containers are the main way people are going to be deployiong software here on in. Seems we should take it that far 18:36:41 for those that are interested, it takes ~1 minute to build this keystone image with a ref patch 18:36:41 I just wouldn't want to have a conversation with another project as to why we keep it in tree when they have a strong reason not to, and now we have different projects doing different things 18:37:18 lets see what reasoning SamYaple brings up in the mailing list :D 18:37:34 ++ 18:37:42 just as a quick poll, is there interest in this from the keystone team? 18:37:52 And, unlike most of OpenStack, Keystone can be deployed without any other OpenStack services running. This is a reasonable tool for development, as well as comunicating live setup standards 18:38:17 SamYaple, probably too soon. people need time to consider it, I think 18:38:24 i don't use docker so i likely wouldn't look at it 18:38:30 dstanek, *yet* 18:38:36 heh 18:38:42 ayoung: hopefully ever 18:38:50 ayoung: again, i am going to refer to current state. -2 for control files and rpmspecs, i view dockerfile the same 18:38:51 ok fair enough. I will hit up the mailing list with all of this 18:38:58 dstanek, docker is like venvs for everything else 18:39:01 SamYaple awesome - thanks! 18:39:03 SamYaple: sounds like a good initiative, needs x-project talk thogh 18:39:04 i'd like us to have a clear this is how it works in openstack model 18:39:19 if that is in tree, i'll conceed, but right now i'd say no based on prior art 18:39:29 right morgan. and i don't have a good answer for that at the moment 18:39:30 for in-tree, and ask for it to be like other packaging 18:39:32 :) 18:39:34 yeah - that would probably help in figuring out if people want to use it 18:39:35 SamYaple: yep! 18:39:37 SamYaple: I'm OK as long as it's tested 18:39:42 morgan: i will say it is a _bit_ different than an RPM 18:39:47 oh for sure 18:39:49 but im with you in your concerns 18:39:54 ayoung: i tried docker, but went back to lxc 18:40:02 dstanek: you can use these images with LXC! 18:40:02 it's why i wouldn't hard -2 it on principle 18:40:09 just want to make sure we're not doing wacky things 18:40:17 dstanek, ah...so jsut the docker piece... 18:40:31 cool. well this when as well as I could have expected. thats all from me 18:40:34 ayoung: all my dev is currently in containers 18:40:47 SamYaple thanks for the info - i'll keep tabs on the mailing list 18:40:48 if you want more info on any of this, hit me up. and we have a working channel for this stuff in #yaodu 18:41:14 #topic open discussion (round 2!) 18:41:34 reminder that we have the policy meeting tomorrow for those who are interested (#link http://eavesdrop.openstack.org/#Keystone_Policy_Meeting) 18:42:46 *cough*U 18:42:48 I have something (hopefully) quick if there's nothing else 18:42:50 lbragstad: you missed my topic 18:42:55 do that ^ 18:43:09 morgan ah - im sorry 18:43:14 #topic *** VERY IMPORTANT *** VMT coverage / Threat Analysis Requirements 18:43:35 morgan fungi o/ 18:43:39 * morgan securely puts on the VMT hat 18:43:59 ok, so keystone should be leading here. We are heavily invested in security for obvious reasons 18:44:11 the issue is we are not fully covered by the VMT 18:44:20 keystone server and client are grandfathered in 18:44:35 keystone auth and middleware are not (arguably should be, but different story) 18:44:45 we really need to move on getting these covered by the VMT 18:44:49 especially middleware and auth 18:45:04 this requires a security analysis that can be publically published to be completed 18:45:18 is there a guide that we can follow? 18:45:31 should i be bugging ibm's security teams? 18:45:32 morgan is the security analysis manual? 18:45:34 in the middleterm we need to do the same for keystone and keystoneclient (as the VMT will require grandfathered in projects to do the same thing to maintain the tag) 18:45:39 there is a template 18:45:42 one sec, getting the link 18:45:53 stevemar yes - you should ;) 18:45:57 #link http://git.openstack.org/cgit/openstack/security-analysis/ 18:46:03 thanks fungi ! 18:46:16 * fungi broke radio silence 18:46:22 so i did work on this much, but i know the OSSG has been work on threat analysis of various projects 18:46:25 but in short, it needs to be a reputable external party (meaning, not the VMT members) 18:46:43 * fungi is glad not to be reputable 18:46:43 OSSG can commit to doing this, but we are not requiring them to do so 18:47:06 this almost sounds liaison related 18:47:11 morgan: yeah, best if the project cores did it 18:47:14 it might be faster to not try and ask the OSSG if we can source from one of the contributors (red hat, rackspace, etc) 18:47:25 i believe the one or two the ossg were getting hands-on with were to dry run the analysis process and templates 18:47:27 and the project cores collaborate with them on it 18:47:40 but the idea is that they wouldn't be directly involved beyond reviewing future analyses 18:47:45 but if you want templates or help in how to do it OSSG can be useful reference 18:48:00 fungi: ++ 18:48:36 i really want to get us moving on this. it is *** important *** 18:48:55 keystone should not lag behind on this. if we do, we risk a lot. 18:49:06 that said, i don't speak for the security team. the vmt asked if they wanted to help us come up with a process for this piece and they volunteered, but their involvement is their own 18:49:07 and we have a ton of new things that need to be looked at with a critical eye 18:49:12 i thought maybe bknudson had already done some work in this area 18:49:26 browne: he's been busy with a bunch of things 18:49:31 browne: i believe so, but iirc most of the work done was not directly publishable 18:49:37 ah 18:49:46 browne: as most of the threat-analysis done to this point has not been 18:49:56 the key is this version must be something we can publish publically 18:50:34 so. i am revisiting this and trying to get this done for the ocata code. 18:50:43 especially for ksa and ksm 18:50:51 morgan what's the deadline? 18:50:59 yea, i _believe_ the compromise there is that the analysis itself doesn't need to be performed in public (and in fact may turn up risks which the team doing the analysis want to bring to the project in private), but that the eventual _final_ document produced as an outcome of the analysis should be something the project can publish documenting its securit model and design 18:50:59 no real hard deadline yet 18:51:14 yes. 18:51:21 as long as the doc (final) can be published 18:51:36 ah - so it's technically doable so long as we support ocata code 18:51:37 i'm happy to work with whatever team is doing the analysis (as a member of keystone-core-sec) 18:51:51 lbragstad: i am targeting ocata because we are almost done with it 18:52:00 morgan that makes sense 18:52:04 lbragstad: barbican did their s-a for vmt tag on newton 18:52:10 morgan: maybe bug the security related folks at rh, rax and ibm ? 18:52:18 lbragstad: right, the vmt provides coverage of stable branches starting with the release following acquisition of the vulnerability:managed tag 18:52:21 but since we haven't started, no reason to target ocata 18:52:38 morgan i have some time available tomorrow and Thursday 18:52:40 erm s/to/not to/ 18:52:47 morgan if you want to work on it together? 18:52:49 so if you can get it done before ocata is released, we can cover stable/ocata onward. or if it's done before the pike release then would be stable/pike onward 18:52:51 lbragstad: if you wouldn't mind collaborating and working with me to liason 18:53:05 i just want to make sure i'm not the bottleneck as i have a ton on my plate 18:53:11 fungi got it - that makes sense 18:53:31 and... i want someone not on the VMT to be ultimately a interested party within the project 18:54:01 the only requirement i ask for whom is involved is a member of of keystone-core (and if you're not on coresec you might get added to it for this) 18:54:04 morgan cool - I'd like to help, ping me when you have time and I'll get up to speed 18:54:10 lbragstad: lets talk tomorrow 18:54:13 then 18:54:22 morgan cool - tomorrow is pretty open for me 18:54:37 #action lbragstad to help wrangle security analysis (with help from morgan) for keystone projects 18:54:59 i have a table being delivered but that is about it ;) 18:55:26 morgan cool - ping me when you're sitting at your new table 18:55:29 ok thats it for me. 18:55:31 thnx 18:55:42 fungi: thanks for the input as well 18:55:43 alright - we have 5 minutes left 18:55:53 anything else we want to cover? 18:56:06 #topic open discussion (round 3!) 18:56:08 morgan: always glad to help 18:56:20 spilla wanted to discuss something i think 18:56:51 So sorta a heat/keystone issue, if its a thing at all anymore 18:57:26 so when using the ResourceType keystone_role_assigments.py 18:57:59 if there is a user associated with a non-existing role, Heat will error out and lock the Stack in a fail state 18:58:26 Would anyone know about this/if its fixed? 18:58:50 I was planning on ping the heat irc too, wasn't sure how involved anyone in keystone was with this 18:58:55 pinging* 18:59:57 spilla: catch the roleNotFound error and make heat smarter? 19:00:20 spilla stevemar want to head over to -keystone? 19:00:28 we're about out of time 19:00:41 oh yeah 19:00:41