20:01:24 #startmeeting horizondrivers 20:01:24 Meeting started Wed Jan 20 20:01:24 2016 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:29 The meeting name has been set to 'horizondrivers' 20:01:42 o/ 20:01:44 (◕‿◕✿)ノ 20:01:50 o/ 20:02:05 o/ 20:02:14 [=_=]/ 20:02:15 I'm back, and I have no agenda :) 20:02:19 \o 20:02:32 Awesome, call it there then? 20:02:51 great 20:02:59 woot 20:03:01 anyone have blueprints to air? 20:03:08 or other discussion topics? 20:03:14 or should we all save an hour? 20:03:17 Just one thing from me: Domains! 20:03:18 how about scoping down the target for M to something realistic? 20:03:23 https://review.openstack.org/#/c/148082/ 20:03:39 did we decide anything for toabctls settings.d proposal earlier? 20:03:51 esp will be holding a walkthrough of the code on Friday for the Domains patch. 20:03:53 mrunge: Looks like people want it merged 20:04:07 i might want to mention the routing thing for angular again 20:04:18 robcresswell, I still had the feeling, it was still controversial 20:04:28 I might wanna talk about a theming implementation detail for custom selects 20:04:33 mrunge: Well, it seems to be me vs all, so not really controversial. 20:04:34 bpokorny: that was accepted for liberty, no problem 20:04:48 Just one stubborn brit :) 20:05:06 Thanks, david-lyle. Just wanted to give it a plug again. 20:05:08 just needs reviews 20:05:13 sure 20:05:19 robcresswell, if I remember the last discussion about that, it felt like me versus the rest of horizoners 20:05:32 so it occurred to me while i was working on the zaqar dashboard plugin that we have quite a few different implementation and file structure for horizon plugins 20:05:48 i think it will do us good in the long run to try and standardize this 20:05:54 true tqtran_ 20:06:03 ok, we now have a list 20:06:03 tqtran_: Could use some... docs? 20:06:05 that was observed a few times already 20:06:11 let's go through these in order 20:06:15 1) Domains 20:06:27 2) scope for M 20:06:32 robcresswell: the problem is, the plugin doc im creating isn't comprehensive enough because theres quite a few different ways to do things.... 20:06:40 so it makes it a bit difficult to document 20:06:45 3) settings.d 20:06:53 4) angular routing 20:06:59 5) theming 20:07:05 \o/ 20:07:11 6) plugin file structure 20:07:15 did I miss any? 20:07:26 #topic Domains 20:07:29 7) mid cycle summit recap? 20:07:43 recap is the wrong word... 20:07:50 tqtran_: had me wondering... 20:07:58 um what i meant was, agenda 20:08:09 tqtran_: sure 20:08:14 https://review.openstack.org/#/c/148082/ 20:08:16 tqtran_, is ahead of time ;-) 20:08:21 lol 20:08:27 is the remainder of the long suffering domain support work 20:09:17 happy birthday to that patch btw 20:09:36 Just turned 100 :) 20:09:47 it's a blocker for people wanting to use domains in any real capacity in Horizon 20:10:00 consider this a plug for reviews 20:10:04 bpokorny: lol 20:10:20 esp will be giving a walk through of the code of that one on Friday. Please contact him if you're interested in the walkthrough. 20:10:23 bpokorny, and it turned a year old yesterday 20:10:26 It's a big patch. 20:10:29 what's the record? 20:10:40 mrunge: Heh. That too. 20:10:52 I've starred it 20:10:57 same 20:11:00 Need to look at lhchengs patch too 20:11:13 #topic scope for Mitaka 20:11:15 TravT: I think rajat holds the record for the # patch set 20:11:19 Should have time this week, so I hope they're idiot-proof patches 20:11:23 :) 20:11:46 we ran through the priorities this morning in the team meeting 20:11:46 we have a lot of stuff prioritized for M: https://etherpad.openstack.org/p/mitaka-horizon-priorities 20:11:58 we seem to have slowed drastically 20:12:24 lots will not make it 20:12:26 on the angular front, i actually have seen a lot of progress in the last few weeks 20:12:30 We've been writing a lot of code but not reviewing much 20:12:41 there's a *lot* to review 20:12:42 Which is why M-2 seems so small 20:12:44 m-3 is 2016-03-03 20:12:52 6 weeks. 20:12:58 0_0 wow... 20:12:59 :( 20:13:26 documentation is stalled 20:13:45 angular is moving, but the onion seems to have more layers than expected 20:13:53 theming seems to be on track 20:13:56 Image angular code seems to have a ton of content up for review. 20:13:59 the plugin doc patch kind of is annoying 20:14:01 dependencies is still in hell 20:14:19 we should probably update this: https://wiki.openstack.org/wiki/Horizon/WeeklyBugReport 20:14:20 i feel like the plugin doc patch has good content that is more useful than nothing 20:14:21 theming is on track. 20:14:45 why can't it land with followups for those so concerned? 20:14:48 david-lyle: We've started moving on manually releasing. First handful of xstatic repos were updated and r1chardj0n3s has made it so I can release them 20:15:06 TravT, agreed. everybody finds a nit in texts 20:15:10 robcresswell: that was last resort, so yes hell 20:15:19 yeah :/ 20:15:22 TravT: IMO it isn't good enough. it's convoluted and unclear to people unfamiliar with Horizon. That will just generate more questions 20:15:38 robcresswell: I agree it needs more work 20:15:58 david-lyle: True, but at least we can get something done on requirements rather than them being frozen. 20:15:58 aren't there guidelines for writing documentation on the way too? 20:16:03 piet was mentioning something about that 20:16:11 well, i've seen people multiple times come into the room and get referred to the patch 20:16:14 how is that better? 20:16:16 are there guidelines for guidlines? 20:16:23 probably, lol 20:16:32 TravT: We could address the issues with the patch? 20:16:38 It hasn't been updated in weeks. 20:16:45 which i'd be all for if it didn't seem so stagnated 20:16:46 searching for docs in gerrit is just... 20:17:03 TravT: Wait, even you have a -1 on it :p 20:17:05 robcresswell: if there are issues of inaccuracy we should update 20:17:07 We are working with the docs team around content guidelines 20:17:13 otherwise, iterate 20:17:21 Planned to be merged in mid-feb 20:17:31 no updates in about 45 days 20:17:41 yes, i'm complaining that it has a ton of comments and feedback 20:17:52 that shouldn't be too hard to address 20:17:53 partly my fault, i was on vacay, and just got back like last week 20:18:07 TravT: same 20:18:07 im working on the patch right now as we speak 20:18:27 Awesome, thanks tqtran_ 20:18:46 I'm guessing all performance work for angular is dead in the water? 20:18:56 the strict-di part is in 20:18:57 seems so 20:18:57 just going through the priority list 20:19:01 the next bit, I have no idea 20:20:33 ok, without reviews things won't make it in 20:20:54 we all have our private wars, but let's move some of these items forward 20:21:13 * david-lyle says with most guilty look 20:21:38 lhcheng: any recommendations? 20:22:00 love to see more focus on testing 20:22:13 so we can catch regression 20:22:16 yupp! 20:22:22 very true 20:22:28 Timur has a ton of integration work up 20:22:32 we've been hit twice in a week 20:22:35 with more or fixed tests, we could have avoided the angular routing mess 20:22:36 And a team of minions work on it too 20:23:06 #link https://review.openstack.org/#/q/status:open+topic:bp/integration-tests-improvements-part1 20:23:33 so yeah, lets focus reviews on that. 20:23:51 ok reviews and tests 20:24:24 if the person posting the code hasn't done their part, let them know and move on 20:24:37 #topic settings.d 20:24:51 I'm leaning toward this approach 20:25:16 * TravT refresher? 20:25:32 I think it will have limited application, but will assist packagers and allow a couple of things with plugins 20:25:42 * david-lyle must find link 20:25:58 #link https://review.openstack.org/#/c/243974/ 20:26:11 TravT, in short, it allows you to add configuration snippets in a directory 20:26:24 comparable to httpd conf.d 20:26:27 thx 20:26:30 essentially local/local/local_settings 20:26:31 :P 20:26:57 allowing for settings changes without editing the local_settings.py 20:27:13 yes, exactly. that has been a pain point for distributors 20:27:22 so installing a package (theme or plugin) can adjust settings without editing other content 20:27:56 thats a nice addition 20:27:59 I originally wanted to have the enabled files reused, but theming is an example of a non-plugin application 20:28:33 and convoluted abilities of the enabled files already makes documenting them difficult 20:28:38 :D 20:28:41 ++ on settings.d . how will this integrate with the ini config? 20:28:55 lhcheng, currently, it does not 20:28:57 do we need to move to ini config before using settings.d 20:29:10 lhcheng: do we need to move to ini config? 20:29:11 we don't need to move to .ini before 20:29:11 just trying to figure out the long term goal 20:29:40 I think that's a stretch goal 20:29:46 and we could deprecate local_settings.py in the next step then 20:29:51 It's been mentioned at both summits I've been to by different people 20:30:03 Which is why I don't like the python snippets 20:30:05 it does not need any migration code 20:30:42 The request I've heard is "external directory with .ini files" and our response has been "internal directory with .py files!" 20:30:51 robcresswell, they complained, because it's hard to edit python code from puppet 20:31:14 and one needs to edit python code, when configuring stuff 20:31:39 it's easy to copy prepared python code/snippets somewhere 20:31:46 I think it would be nice, but what we had proposed was half there 20:31:58 right 20:32:06 Thats no different to copying in .ini snippets though, except we havent solved the configuration issue 20:32:21 I mean, I'm not gonna block something that there is demand for 20:32:33 mrunge: isn't modifying python code a problem for package/installation too? 20:32:35 robcresswell, you'd get +2 from me for solving both/all three issues in one step 20:32:41 But I feel like its adding a layer that we'll need to work around when we have a proper fix. 20:32:43 lhcheng, exactly 20:33:01 mrunge: like if local_setting.py has been updated, reinstalling the package fails.. 20:33:29 lhcheng, it still succeeds. but you might have to change local_settings manually 20:33:51 Personally I'd do 1) all logic in settings.py, 2) import snippets from packagers/ deployers in external dir with .ini, 3) import deployment-specific items in local_settings. 20:34:01 not all logic. I mean all base settings. 20:34:16 Rather than the local_settings/settings division we currently have. 20:34:19 I would remove local_settings in long term 20:34:32 move it all to settings.d 20:34:35 are we going to map all django settings? 20:34:46 we still have settings.py 20:34:57 which is inherited from django 20:35:08 mrunge: ++ local_settings.py get updated always anyway 20:35:36 ok, in the interest of time, lets leave our comments on the patch 20:35:41 Sure 20:35:42 mrunge: what we did for our packaging, our local_settings.py reads data from an ini file 20:35:49 sounds like we're still not at a concensus 20:35:53 and that's fine 20:36:09 lhcheng, would you share that code in a review? 20:36:12 and lhcheng will write us an ini system 20:36:16 :D 20:36:18 it sounds like a good addition 20:36:46 #topic angular routing 20:36:54 mrunge: so local_setting.py does not get updated at all, our production engineer just need to make changes to ini files. 20:36:55 hey-o 20:36:56 move to settings.d does not require any migrations yet :D 20:37:06 mrunge: sure, will add it to my todo list 20:37:12 lhcheng, sounds great, thank you 20:37:13 other than breaking horizon a couple of times, what's up? 20:37:22 thanks lhcheng 20:37:30 well, we had a little message thread re routing 20:37:34 mrunge: I already have our message of the day up too. (shameless plug) 20:37:43 which basically stopped here 20:37:54 synopsis is that we defaulted to using ng-route 20:38:05 and that is already in 20:38:26 TravT: stupid question coming.. what does ng routing do? 20:38:39 we've learned that when client side routes are used, the perceived performance is much better 20:39:09 lhcheng: client-side routing; intercepts URL changes 20:39:14 ng route allows the transition from table to details view to occur in browser with 1 data call, instead of full backend reload 20:39:14 basically, it intercepts requests and uses the browser history api with html5mode so that you can do in place content replacement via javascript rather than a full server page refresh 20:40:23 Basically, no more loading... spinner 20:40:25 TravT wins the most detailed explanation :) 20:40:31 cool 20:40:43 anyway, r1chardj0n3s, there is a problem i raised on the patch where rajat is asking again about ui-router 20:40:46 and the argument is ng-route vs ui-router? 20:40:50 robcresswell: welll, sometimes you still want a spinner if the new page is pulling in heaps of data 20:41:01 see line 59 here: https://review.openstack.org/#/c/173885/147/openstack_dashboard/static/app/core/images/images.module.js 20:41:01 just a different spinner 20:41:17 a spinner to show another spinner, matrix style 20:41:19 I need to fix that spinner 20:41:32 so the problem I have is that there's this push for ui-router with no explanation why - there doesn't appear to be a clear need for us to pull in yet another xstatic package 20:41:34 we should use something like ladda 20:42:27 to be clear: I would be happy to move to ui-router *if there was a clear need for it* otherwise we should use the built-in router and not have an additional dependency 20:42:39 unless there is a clear benefit and given packagers hatred of Horizon already, I'd prefer not to proliferate 20:42:41 r1chardj0n3s: i don't like more dependencies either and I have provided an example asking for input on how to solve 20:42:42 Yeah, I agree with that 20:43:27 TravT: which example? 20:43:33 see above 20:43:40 see line 59 here: https://review.openstack.org/#/c/173885/147/openstack_dashboard/static/app/core/images/images.module.js 20:44:11 ah, I see 20:44:50 my .02 is that we simply have a project.images module and an admin.images module. Modules can then hard code the routes for the templates they provide 20:44:58 thanks, that does appear to be a good use of sub routing, which ui-router does (apparently - I've not used it) and ng-route does not 20:45:22 I' 20:45:30 well, rajat IM'd me this morning and said he is creating an alternate reality patch to explore the differences with ui-router 20:45:39 I'd still like to see a proposal for how sub-routing would work, yep 20:45:50 TravT: cool, thanks 20:46:01 ok, seems like we should wait for the POCs and judge from there 20:46:26 #topic theming 20:46:37 I wanted to bring up two things … 20:46:48 The first is that I have a pretty big patch train in place right now to clean up horizon.scss and I was hoping I could get some more help to push that along.  Around 6 patches have gone in so far, but its getting cumbersome to manage all the merge conflicts with the other themes patches. 20:46:59 The head of the train is here: https://review.openstack.org/#/c/260629/, but I only need more eyes starting here: https://review.openstack.org/#/c/260631/ 20:47:26 The second is an implementation detail on the custom select menus: https://review.openstack.org/#/c/263817/ 20:47:45 Right now, we are making a global replacement at the forms/__init__.py level (https://review.openstack.org/#/c/263817/21/horizon/forms/__init__.py) in order to save on the number of files we will have to change in the codebase to use the new widget. 20:47:52 I’m not sure if that is the right thing to do, as we might break people's legacy code.  I think we should call it something different and just bite the bullet and update each place its used.  Thoughts? 20:48:47 ok, I'll bite, without reading the review. Why are we replacing ChoiceField? 20:49:04 cause to use Bootstrap dropdowns, so all of our menus look the same 20:50:03 This is going to take some reading 20:50:22 yeah, 20:50:22 yeah, and should be well tested, I guess 20:50:43 We are using a hidden