12:00:34 #startmeeting Horizon 12:00:35 Meeting started Wed Sep 16 12:00:34 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:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:39 The meeting name has been set to 'horizon' 12:01:09 anyone around to talk horizon 12:01:11 ? 12:01:25 good morning 12:01:29 o/ 12:01:31 o/ good morning 12:02:43 Let's talk Liberty RC-1 12:02:51 #topic RC-1 12:03:21 Talking to rel-mgmt, it seems we should have the FFEs landed by the end of the week 12:03:36 and try to have an RC by the end of next week 12:04:06 so that means code for the FFEs need to land quickly and the focus should move to bugs 12:04:43 I need to start paring down the FFE list and bug list to be more tracking of what needs to be in vs what would be nice 12:05:29 if fact, I think it would be nice to look at some of the bugs here to make a more informed decision on removing from RC-1 12:05:35 I've been having a go at that. I think its closer to 25, down from 40+, bug wise. Curvature is ready, shelving is in, and I'm still going over databases bp. 12:06:00 #link https://launchpad.net/horizon/+milestone/liberty-rc1 12:06:53 robcresswell: ok, thanks 12:07:28 for FFEs I think images won't make it, the other reasonably should 12:07:53 now looking at bugs 12:07:57 o/ 12:10:13 There's a few angular related ones which could be bumped from rc1 for sure. 12:10:40 robcresswell: ok, sorry reading XSS one 12:11:02 will finish comments later 12:11:37 david-lyle, masco tried to reproduce the first one xss, but failed 12:11:49 yes 12:12:09 yeah that needs further investigation 12:12:18 i tried with the options what the reporter said 12:12:23 if it's there, is been there forever 12:13:33 he is hesitating to share the file to reproduce the issue :( 12:13:57 ok, I'll leave it in RC-1 for now, but not sure I will block on it 12:14:15 nevertheless, while looking at container code, there's much room for improvement 12:14:40 (Like throwing it away completely) 12:14:43 :) 12:14:47 mrunge: no doubt 12:14:53 hey, it's not sahara code 12:15:08 I mean sahara dashboard 12:15:09 I've suggested containers as a work area to many people, no bites 12:16:37 about: https://bugs.launchpad.net/bugs/1494171 12:16:37 Launchpad bug 1494171 in OpenStack Dashboard (Horizon) "Javascript error: Module 'horizon.auth' is not available!" [High,Confirmed] 12:16:44 I'fe had another report about this 12:16:56 kfox111 was able to reproduce it 12:16:59 Yeah, from kfox right? He was asking about it 12:17:02 since the second XSS is an indirect vector, I'm moving to next 12:17:08 It was in another package I thought mrunge 12:17:59 robcresswell, we now have 2 packages reporting the same issue with missing horizon.auth 12:18:08 one debian, one is mine 12:18:29 I have seen the issue too, this collect static stuff etc needs a test case 12:18:45 something to automatically flag it 12:18:52 ducttape_, collectstatic was executed 12:19:11 I have no doubt, but something to test we have all the js in the correct order and locations 12:19:14 and the environment was rebuilt before creating the package 12:19:27 but I agree 12:19:44 would be great to test js in order etc. 12:19:56 * robcresswell points at tsufiev 12:20:31 when I saw it, I was missing some js libraries that were supposed to be autocollected etc. this is the result of having autocollection, in my experience 12:20:36 robcresswell: huh? 12:20:45 tsufiev: They were asking for tests :p 12:20:57 tsufiev - Rob is signing you up to test all the things ;) 12:21:09 awesome, thank you robcresswell 12:21:27 robcresswell: the issue being discussed would have been caught by i9n tests for sure 12:21:37 is that due to autocollection feature? 12:21:49 if yes, can we revert that *feature*? 12:22:30 i think it's quite core to having stuff work, as you are seeing right now 12:22:31 robcresswell: I think it' s'more likely some unit-tests 12:22:54 the other option is having a static html list of js includes 12:23:22 the problem with disabling autodiscovery is then we have to specify all js files in plugin, or content loaded as a plugin, which is all 12:23:43 With angular that list would be colossal 12:23:56 its a few hundred lines, if I recall 12:24:01 yes, and it will be loaded, even if you're not using features 12:24:11 ducttape_: For a couple of panels... 12:24:51 I think one thing this does highlight is a big disconnect between developers and packagers that we need to fix. 12:24:57 I think we still need to dig into this, the bug may or may not be autodiscovery 12:25:04 ducttape_: agreed 12:25:12 right 12:25:25 yes 12:25:32 It would be good to get more info or docs etc on what packagers need us to be aware of 12:25:36 pain points etc 12:25:45 robcresswell, still on my todo list 12:25:46 I agree, this is also a side effect of xstatic.... which haunts me when I think about it 12:26:04 robcresswell: on the second thought, I don't know whether auto discovery is enabled in i9n tests 12:26:06 uhm, not sure if this is an issue of xstatic 12:26:18 Might be not 12:26:35 right, let's get it understood first 12:26:52 I'm seeing myself hacking a something together about packaging 12:26:55 it sounds like we've wandered into xstatic ;) 12:26:59 mrunge: Sure, I know you're busy, wasn't supposed to be calling you out on it :) 12:27:00 and probably shouldn't have 12:27:13 most probably to be done during the flight to tokyo 12:27:17 r1chardj0n3s - we are wandering away. don't go near there! 12:27:30 yes, autodiscovery and xstatic are not related 12:27:37 other than the word static 12:27:38 I have a cleanup for xstatic in the works, just getting distracted by doa/tempest/devstack :/ 12:28:10 r1chardj0n3s, doa could keep you busy for a longer time 12:28:22 any bugs targeting RC-1 <= medium will be removed from the list 12:28:37 the d-o-a issue is important because it blocks another release 12:28:40 nooo, I just want my simple fix to the model in and a bunch of stuff in horizon is fixed by it and I can move on with my life please pretty please? :) 12:29:09 which we have a minor FFE in around WebSSO and the login fix patch 12:29:34 r1chardj0n3s: Which patch? 12:29:56 robcresswell: https://review.openstack.org/#/c/222478/ 12:30:10 it ran smack into a devstack change that sdague checked in last week that broke a few gates :/ 12:30:25 and the webSSO is +A'd but got caught in the gate 12:30:59 I'll push to see if we can get that reverted for now 12:31:06 r1chardj0n3s: Ah, doa :p 12:31:14 robcresswell: yes, hi :) 12:31:25 * robcresswell pretends he never saw it 12:31:50 lol, nice try! 12:31:55 let's merge doa into horizon 12:31:57 this meeting is recorded, you know :) 12:32:01 and then deprecate it 12:32:05 dangit 12:32:17 mrunge: seems reasonable to me as well 12:32:30 Can we *please* merge curvature :) 12:32:41 (the first part, tsufiev) 12:33:00 robcresswell: still trying to find time to code review it 12:33:35 on curvature - I've missed many of the demos at-scale. Is it working well now? 12:33:46 it is, seems pretty ready to go 12:33:50 doug-fish: yes has been the consensus 12:33:55 cool 12:34:00 robcresswell: I'm afraid if we start reading curvature code there will be another couple of weeks to polish it 12:34:06 there was a red-herring the past couple of days, but... 12:34:25 I'm reluctant to approve it again, because I'm starting to look like I'm forcing it through. IMO its been pretty feature ready for the past 2/3 patchsets, but we keep adding little tweaks to it. 12:34:47 if we don't read the code, thats a pretty scary thing too 12:35:14 One would hope code review involves looking at the code... 12:35:20 exactly 12:35:29 you mean _all_ of the code? 12:35:33 *kidding* 12:35:37 ok 12:35:46 ducttape_: nope, I meant some tiny refactoring a that I already did while angularizing it 12:35:59 so bugs and FFEs are the priority 12:36:37 timeline again, FFEs by the end of the week, or moved to M 12:36:43 sorry - before we move on - does curvature have/need FFE? 12:36:47 and RC hopefully next week 12:36:51 doug-fish: It has FFE 12:36:51 doug-fish: has 12:36:57 ok thx 12:37:26 #topic summit planning 12:37:50 it's the time where we set up session planning, in the past we've done that on etherpad 12:37:56 that's a bit messy 12:38:07 but manageable 12:38:25 another option is google forms 12:38:36 but access is no global to that 12:38:55 any preferences? 12:38:58 I propose we lock ourselves in a room and don't come out until we have a solid plan for domain-scoped tokens and federation and get past the endless bickering... 12:39:09 -1 12:39:14 there is no hope 12:39:14 of course, we'll all starve 12:39:28 I'd go with etherpad 12:39:29 etherpad has worked, stick with that I suppose. Bit messy, but seems to function okay. 12:39:37 etherpad is fine :) 12:39:41 as long as we have beer, or shiraz r1chardj0n3s ... 12:39:54 currently sipping whiskey ;) 12:40:08 +1 for etherpad & beer 12:40:11 let's do an etherpad and try to keep total lines low 12:40:21 domain scoped token will go in early post Liberty in d-o-a 12:40:29 or a really small font :P 12:40:32 Haha I still have this amazing memory of r1chardj0n3s and sqchen having this deep technical discussion, turning me to and saying "did you get all that down?" and I just looked up from my keyboard and groaned. 12:40:42 :D 12:40:45 Less hangover on Friday for me this time. 12:40:53 ok, I will set up an etherpad and post to the mailing list 12:41:03 Sounds good 12:41:10 thank you david-lyle 12:41:13 #action david-lyle create etherpad for session planning email to dev list 12:41:20 +1 for etherpad. it is important to ensure we put your name when you put an idea to etherpad 12:41:32 +1 amotoki 12:41:38 good suggestion 12:42:00 #topic PTL elections 12:43:32 So the nomination season is open. This is the last day to submit your self-nominations. Voting if necessary will be held the next week, IIRC 12:43:45 david-lyle: do we have a choice :)? 12:43:52 tsufiev: always 12:43:59 voting will begin tomorrow 12:44:08 thanks mrunge 12:44:51 tsufiev: I encourage anyone who thinks they want or can improve on the job being done, or just wanting a change to run 12:45:20 * tsufiev steps back just in case 12:46:08 #topic Choosing a final replacement name for an 'AVAILABLE_REGIONS' setting 12:46:41 no author but I'm looking at tsufiev :) 12:47:09 So lhcheng suggested to drop AVAILABLE_ prefix because it's excessive 12:47:55 shouldn't REGIONS be renamed to something else? 12:47:56 Meaning that the new setting name is AVAILABLE_REGIONS -> KEYSTONE_ENDPOINTS 12:48:05 yes! 12:48:16 yes, I think I already +1'ed that :) 12:48:22 make sense to me, 12:48:23 +1 12:48:27 ok, are we resolved on changing, I propose and indefinite deprecation cycle to accommodate existing installations 12:48:37 do you have a review handy? 12:48:39 seems fair 12:48:39 I think that's fine for the setting -- but is that how we'd label the field in the UI? 12:48:44 yesm david-lyle 12:49:07 uhm, do we have it at all in UI? 12:49:21 mrunge: yes 12:49:23 two places 12:49:28 mrunge: https://review.openstack.org/#/c/222129/ 12:49:40 one in d-o-a and one optional header in Horizon 12:49:51 I thought we present it, yes, but without a name on it 12:50:16 ah, trying to remember user visible string 12:50:55 Region 12:51:00 :) 12:51:12 suggestions on that change? 12:51:13 doug-fish: doesn't federation bp aim to somehow hide keystone ENDPOINTS in user facing UI? 12:51:24 Cloud? 12:52:08 tsufiev: maybe ... federated keystones wouldn't have to be explicitly chosen, their regions would just be available 12:52:14 sounds cloudy, but I can not think of a better term 12:52:26 I'm good with the new setting name, for the record 12:52:45 it's the most accurate, but I'll look for further input 12:52:55 doug-fish: so I think we should have consistent UI for both federated and non-federated setups 12:53:05 we can get list of name and give it for voting 12:53:58 tsufiev: I'm not sure that will be possible: non-federated setups expose the keystone endpoints before login; federated setups discover the keystone endpoints after login 12:54:26 tsufiev: I suppose some kind of hybrid of this would be possible, but that kind of makes my head hurt. 12:54:42 I think that's a discussion for a different time :) 12:54:51 agreed. 12:55:01 doug-fish: do we mean the same thing here by keystone endpoint? 12:55:16 david-lyle: okay 12:55:29 perhaps Tokyo? 12:55:37 indeed 12:55:40 #topic Open Discussion 12:56:21 Have you seen my recent mail about cinder quotas? 12:56:51 tsufiev: I read through it, basically we have a bogus policy choice 12:57:13 did cinder implement limits instead? 12:57:35 info: this mail: http://lists.openstack.org/pipermail/openstack-dev/2015-September/074351.html 12:57:48 or are we just forcing worse UX on users? 12:57:51 amotoki: thanks! 12:58:19 david-lyle: no insight about cinder :( 12:58:48 Did nobody from Cinder reply? 12:58:56 robcresswell: not yet 12:59:01 tsufiev: I don't believe they did, just recalling the nova fun 13:00:04 at least we should use a same policy for quota-show among nova, cinder, neutron and other projects. 13:01:04 I'll work on some input/feedback from cinder 13:01:10 we are out of time 13:01:44 Thanks everyone and please focus your reviews on the remaining FFEs and bugs for RC-1 13:01:54 #endmeeting