12:02:47 #startmeeting Horizon 12:02:47 Meeting started Wed Mar 18 12:02:47 2015 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:02:51 The meeting name has been set to 'horizon' 12:02:56 Hello everyone 12:02:59 hi 12:03:03 Morning 12:03:06 good morning o/ 12:03:20 Morning all 12:03:24 greetings 12:03:38 hi 12:04:20 o/ 12:04:31 Hi, daisy is here for kilo translation. 12:04:43 o/ 12:04:50 Tomorrow is the deadline for k-3 and we have several blueprints in need of some reviews 12:05:17 #link https://launchpad.net/horizon/+milestone/kilo-3 12:05:55 on the plus side the bulk of the new launch instance merged and is in bug fix mode 12:06:20 it is not enabled by default yet, until the bugs are addressed. 12:06:32 but feel free to try it out and report more bugs 12:06:38 Are we still aiming to make it the default for release? 12:06:43 hooray! good job! 12:07:03 before the RC we'll se if we're comfortable making the switch 12:07:29 Awesome 12:08:10 I'd like to see several of the bugs fixed first, but trying to make a change that large perfect all at once was an impossible task 12:09:08 some blueprints of note that could use reviews: https://blueprints.launchpad.net/horizon/+spec/data-processing-rework-ui 12:09:30 that code has been up for most of kilo and suffered from a lack of reviews 12:09:55 there are two guided walkthroughs of the major workflows of Sahara 12:10:29 it's a vast improvement from figure it out for yourself which was where we were with Juno 12:11:29 it strays from the standard horizon widgets, but accomplishes its goal 12:12:34 I think django-1.7 support is a must have and will move that to RC-1 if not merged by tomorrow 12:12:51 are there others people feel need consideration for RC-1 12:13:07 assuming the list doesn't magically merge in the next 24 hours 12:13:09 ? 12:14:14 another BP of not and late comer, but highly requested is #link https://blueprints.launchpad.net/horizon/+spec/horizon-themes 12:14:27 This was demoed at the last summit 12:14:52 and at this point mainly relies on use of the variables.scss 12:15:30 and styles.scss 12:15:47 minimally invasive, I do need to test it out 12:16:02 but operators have long asked for better skinning 12:16:20 yes, sure 12:16:20 this demonstrates how to do that in bootstrap 12:16:35 we can improve upon it later 12:16:49 this will be a nice start to theming 12:17:10 Once I try it out, if it works as advertised I may move it to a High 12:17:30 anything not High isn't really eligible for a FFE 12:17:59 To revisit the timelines 12:18:13 Feature Freeze will happen tomorrow 12:18:21 we'll tag the repo with k-3 12:19:05 at that point only bug fixes and any BPs with a FFE (Feature Freeze Exception) should be merged onto master 12:20:03 RC-1 will likely be 2 weeks from there. 12:20:38 once RC-1 is cut, it will be on a branch and trunk will be open for liberty 12:20:58 at RC-1 we will also have our final string freeze 12:21:32 good to know 12:21:35 at which point Daisy_ (thanks for joining) will help drive getting our strings translated for RC-2 12:21:59 which hopefully will be only to pull in translations before release 12:22:27 if we do find other release critical bugs, we may roll them into RC-2 as well 12:22:55 Does that work for you Daisy_? I believe you have already talked to amotoki about the timeline 12:23:25 Yes, I did talk with amotoki 12:23:51 does RC-1 work for you on the string freeze 12:23:59 When is RC2, probably? 12:24:14 2-3 weeks after RC-1 12:24:19 You mean, string freeze after RC-1? 12:24:20 will look for date 12:24:35 I will ask team to work on Horizon translation tomorrow. 12:24:38 at RC-1, or a week before it 12:24:41 In our past releases, RC2 was before 1-1.5 weeks before the release. 12:24:50 I won't wait for string freeze, I think. 12:25:26 david-lyle: Are dev docs related changes subject to the same freeze timelines as code? 12:25:26 ok, we shouldn't have too much churn, but we always have a little after milestone 3 12:25:29 Daisy_: we don't need to wait for string freeze :-) After Kilo-3, not so many strings will be changed as you know. 12:25:41 amotoki: I agree. 12:26:11 amotoki: we start the translation from tomorrow, and we keep on translating, till RC2, 1-1.5 weeks before the release. 12:26:24 looks like RC-1 should april 9 -16 and RC-2 will be by April 30 12:26:41 amotoki: the translations in RC1 will auto imported. and the translations in RC2 will be imported manually, as we did before ? 12:27:12 April 30 is release day, so a few days before april 30 12:27:15 Daisy_: yes, if the process is not changed in kilo. 12:27:59 wchrisj: if it's a bug fix it can land before RC-1 12:28:05 Thanks for the date. Translators might need 1 month to translate. 12:28:47 Daisy_: thank you, please let me know if you need anything from me 12:29:06 david-lyle: Thank you. I will work closely with amotoki. 12:29:25 thank you both 12:30:01 #topic Open Discussion 12:30:15 oh, I forgot one topic 12:30:27 #topic Keystone auth plugins 12:31:14 There are several semi-related features in keystone that need to slightly change how authentication is done 12:31:56 jamielennox sent an email to the ML a couple days ago and I've been talking to him on IRC 12:32:35 david-lyle are you trying to get that in for kilo? 12:32:48 #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/059139.html 12:33:19 he's unable to attend the meeting so I said I would bring it up for him to raise awareness and solicit feedback 12:33:58 Things that people are working on, WebSSO, which is a BP approved in Horizon for Kilo 12:34:10 along similar lines, how important is the websso stuff? we're really close to getting it in 12:34:36 but does not follow any sort of proper plugin and is going to create swiss cheese in the code, especially if that format is duplicated 12:35:09 there's K2K federation work (doug-fish) that will change things a bit more 12:35:30 yeah - I'm not sure k2k benefits as much from what Jamie has proposed 12:35:42 and there's other plugins desired for say kerberos (jamielennox) 12:36:30 Our main problem is that D-O-A is built to work with keystone credential based auth and not much else 12:36:43 and makes a lot of assumptions that you are using credentials 12:37:00 david-lyle is this the kind of thing that should be external to horizon but horizon has a good plug-in mechanism to support it? 12:37:24 I would like a cleaner way to do auth plugins in d-o-a 12:37:34 david-lyle: do you mean it doa is tied to id/pw? because I think there will always be some kind of credentials 12:38:11 doug-fish: we'll still want to support credentials, but that's just one way keystone now supports to auth 12:38:35 got it 12:38:40 tqtran: I think websso is a high priority, but I'm not sure it's ready yet 12:38:58 we have 3 options as I see it 12:39:23 d-o-a has three interfaces: to hoirzon, to users (view), to keystone or other auth mechanisms. from horizon point of view, the interface to horizon is not chnaged so much (or no change). 12:40:00 1) roll in websso and take on some technical debt in Liberty to fix how it ties in 12:40:30 2) establish a proper plugin mechanism before merging any other auth types 12:41:14 3) restructure/rewrite D-O-A to make more sense 12:41:45 I'm ok with going with option #2 first 12:42:00 option 2 makes sense to me 12:42:19 2 and 3 may not be mutually exclusive ;) 12:42:27 yeah 2+3 is what I was thinking 12:42:29 I think it might be a bit rushed anyhow, websso just barely made kilo. and reviews for it came in rather late. 12:43:41 we can also discuss how much sense a separate auth package for horizon makes 12:43:56 david-lyle: can you expand on that? 12:44:02 but that's a summit discussion I think 12:44:29 doug-fish: history lesson time 12:44:31 :) 12:44:35 :-) 12:44:36 ooooo 12:45:07 D-O-A used to be part of horizon, it was rolled out to be an extensible django based auth tool for openstack 12:45:19 keystone was just one possible backend 12:45:23 * tqtran settles in. Getting the smore ready. 12:45:38 hence in backend, KeystoneBackend 12:46:26 since then we've made changes that make the library very tightly coupled to Horizon and Keystone 12:46:59 so not reusable by anyone other than someone rewriting Horizon in django and auth'ing to keystone 12:47:12 I'm thinking that's a very small set of projects 12:48:03 david-lyle: I thought at one time some groups didn't use keystone for the backend - was that ever part of the motivation for DOA? so they could plug in their own auth? 12:48:03 In the future, I think a lot of what is set up in DOA for the session will be stored on the client side and not in the session 12:48:55 doug-fish: It probably was 12:49:27 I used DOA with the keystone backend for a custom IdP 12:49:43 because so much structure from keystone is expected in Horizon 12:50:10 yeah, Horizon is really tied to keystone 12:50:38 any way, massive restructuring is a conversation for another time and gets really complicated 12:51:05 it could also be potentially disruptive to deployers 12:51:21 you think they would miss DOA? 12:51:26 but allowing for auth plugins to D-O-A makes sense 12:51:54 doug-fish: if they've built a solution that has a customized doa 12:52:16 BTW, I think the plugin we want is bigger than a keystone auth plugin, but smaller than a django auth backend 12:52:50 doug-fish: trying to imagine how far apart your hands are 12:52:55 we need to coordinate a scoped/unscoped keystone auth plugin, its method for getting projects, and messages/ui presentation at the very least 12:53:07 :-) 12:53:31 could you elaborate on what exactly in session setup by doa will be stored client side? 12:53:51 doug-fish, david-lyle I'm curently counting 37 public forks on github for doa 12:54:00 :-O 12:54:02 wow 12:54:29 tqtran: eventually I would say catalog, authorized project list, role assignments 12:54:41 for reference: https://github.com/openstack/django_openstack_auth/network 12:54:53 tqtran: maybe tokens too? 12:55:59 doug-fish: yeah 12:56:00 david-lyle: while we are thinking about changing DOA .... do you see any future for domain scoped tokens? 12:56:12 doug-fish: yes and no 12:56:14 you seemed a bit down on that earlier this week 12:56:31 only short term 12:57:04 I think a set of patches that allow using domain scoped tokens is the best path at this point 12:57:28 not necessarily merging them 12:57:39 interesting ... 12:57:45 keystone's direction is changing 12:58:10 and I see hierarchical projects actually being supported outside of keystone and horizon 12:58:15 where domains never will be 12:58:26 yeah - that seemed like a major limitation to me 12:58:30 2 years in, no support 12:58:42 * david-lyle check watch 12:58:45 though heirarchical projects don't get supported for free in the other services do they? 12:58:48 time of death 6:58 12:58:52 :-) 12:58:54 doug-fish they don't 12:58:57 doug-fish: no 12:59:25 they need quotas calculation changes at a minimum 12:59:56 * david-lyle sees to many s's not sure which one should go 13:00:07 *quota 13:00:24 *quotas calculations changes 13:00:31 +! 13:00:31 and sharing of resources cross-sub-project (like glance images) 13:00:34 +1 13:01:05 let's drop quota and make it an external service 13:01:36 yeah, that's going to be interesting code 13:01:51 just an api call away :D 13:01:54 at least the api should be easy to consume :) 13:01:55 alright times up, any parting thoughts? 13:02:03 questions 13:02:39 just to close on DOA, I think we should get a plugin model established 13:02:56 +1 david-lyle 13:03:01 yeah - would be good to have something well underway before the summit 13:03:13 doug-fish: agreed 13:03:30 tqtran: ok with that? 13:03:38 yep 13:03:58 * david-lyle easily strays off topic 13:04:15 alright, thanks everyone 13:04:22 thanks david-lyle 13:04:28 some reviews of the items in k-3 would be very helpful 13:04:38 have a great week 13:04:42 #endmeeting