20:01:24 <david-lyle> #startmeeting horizondrivers 20:01:24 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:29 <openstack> The meeting name has been set to 'horizondrivers' 20:01:42 <mrunge> o/ 20:01:44 <hurgleburgler> (◕‿◕✿)ノ 20:01:50 <bpokorny> o/ 20:02:05 <TravT> o/ 20:02:14 <tqtran> [=_=]/ 20:02:15 <david-lyle> I'm back, and I have no agenda :) 20:02:19 <robcresswell> \o 20:02:32 <robcresswell> Awesome, call it there then? 20:02:51 <mrunge> great 20:02:59 <TravT> woot 20:03:01 <david-lyle> anyone have blueprints to air? 20:03:08 <david-lyle> or other discussion topics? 20:03:14 <david-lyle> or should we all save an hour? 20:03:17 <bpokorny> Just one thing from me: Domains! 20:03:18 <lhcheng> how about scoping down the target for M to something realistic? 20:03:23 <bpokorny> https://review.openstack.org/#/c/148082/ 20:03:39 <mrunge> did we decide anything for toabctls settings.d proposal earlier? 20:03:51 <bpokorny> esp will be holding a walkthrough of the code on Friday for the Domains patch. 20:03:53 <robcresswell> mrunge: Looks like people want it merged 20:04:07 <TravT> i might want to mention the routing thing for angular again 20:04:18 <mrunge> robcresswell, I still had the feeling, it was still controversial 20:04:28 <hurgleburgler> I might wanna talk about a theming implementation detail for custom selects 20:04:33 <robcresswell> mrunge: Well, it seems to be me vs all, so not really controversial. 20:04:34 <david-lyle> bpokorny: that was accepted for liberty, no problem 20:04:48 <robcresswell> Just one stubborn brit :) 20:05:06 <bpokorny> Thanks, david-lyle. Just wanted to give it a plug again. 20:05:08 <david-lyle> just needs reviews 20:05:13 <david-lyle> sure 20:05:19 <mrunge> robcresswell, if I remember the last discussion about that, it felt like me versus the rest of horizoners 20:05:32 <tqtran_> 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 <tqtran_> i think it will do us good in the long run to try and standardize this 20:05:54 <mrunge> true tqtran_ 20:06:03 <david-lyle> ok, we now have a list 20:06:03 <robcresswell> tqtran_: Could use some... docs? 20:06:05 <mrunge> that was observed a few times already 20:06:11 <david-lyle> let's go through these in order 20:06:15 <david-lyle> 1) Domains 20:06:27 <david-lyle> 2) scope for M 20:06:32 <tqtran_> 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 <tqtran_> so it makes it a bit difficult to document 20:06:45 <david-lyle> 3) settings.d 20:06:53 <david-lyle> 4) angular routing 20:06:59 <david-lyle> 5) theming 20:07:05 <hurgleburgler> \o/ 20:07:11 <david-lyle> 6) plugin file structure 20:07:15 <david-lyle> did I miss any? 20:07:26 <david-lyle> #topic Domains 20:07:29 <tqtran_> 7) mid cycle summit recap? 20:07:43 <tqtran_> recap is the wrong word... 20:07:50 <TravT> tqtran_: had me wondering... 20:07:58 <tqtran_> um what i meant was, agenda 20:08:09 <david-lyle> tqtran_: sure 20:08:14 <david-lyle> https://review.openstack.org/#/c/148082/ 20:08:16 <mrunge> tqtran_, is ahead of time ;-) 20:08:21 <tqtran_> lol 20:08:27 <david-lyle> is the remainder of the long suffering domain support work 20:09:17 <mrunge> happy birthday to that patch btw 20:09:36 <bpokorny> Just turned 100 :) 20:09:47 <david-lyle> it's a blocker for people wanting to use domains in any real capacity in Horizon 20:10:00 <david-lyle> consider this a plug for reviews 20:10:04 <lhcheng> bpokorny: lol 20:10:20 <bpokorny> 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 <mrunge> bpokorny, and it turned a year old yesterday 20:10:26 <bpokorny> It's a big patch. 20:10:29 <TravT> what's the record? 20:10:40 <bpokorny> mrunge: Heh. That too. 20:10:52 <robcresswell> I've starred it 20:10:57 <tqtran_> same 20:11:00 <robcresswell> Need to look at lhchengs patch too 20:11:13 <david-lyle> #topic scope for Mitaka 20:11:15 <lhcheng> TravT: I think rajat holds the record for the # patch set 20:11:19 <robcresswell> Should have time this week, so I hope they're idiot-proof patches 20:11:23 <robcresswell> :) 20:11:46 <david-lyle> we ran through the priorities this morning in the team meeting 20:11:46 <lhcheng> we have a lot of stuff prioritized for M: https://etherpad.openstack.org/p/mitaka-horizon-priorities 20:11:58 <david-lyle> we seem to have slowed drastically 20:12:24 <david-lyle> lots will not make it 20:12:26 <TravT> on the angular front, i actually have seen a lot of progress in the last few weeks 20:12:30 <robcresswell> We've been writing a lot of code but not reviewing much 20:12:41 <r1chardj0n3s> there's a *lot* to review 20:12:42 <robcresswell> Which is why M-2 seems so small 20:12:44 <lhcheng> m-3 is 2016-03-03 20:12:52 <robcresswell> 6 weeks. 20:12:58 <tqtran_> 0_0 wow... 20:12:59 <lhcheng> :( 20:13:26 <david-lyle> documentation is stalled 20:13:45 <david-lyle> angular is moving, but the onion seems to have more layers than expected 20:13:53 <david-lyle> theming seems to be on track 20:13:56 <robcresswell> Image angular code seems to have a ton of content up for review. 20:13:59 <TravT> the plugin doc patch kind of is annoying 20:14:01 <david-lyle> dependencies is still in hell 20:14:19 <lhcheng> we should probably update this: https://wiki.openstack.org/wiki/Horizon/WeeklyBugReport 20:14:20 <TravT> i feel like the plugin doc patch has good content that is more useful than nothing 20:14:21 <hurgleburgler> theming is on track. 20:14:45 <TravT> why can't it land with followups for those so concerned? 20:14:48 <robcresswell> 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 <mrunge> TravT, agreed. everybody finds a nit in texts 20:15:10 <david-lyle> robcresswell: that was last resort, so yes hell 20:15:19 <r1chardj0n3s> yeah :/ 20:15:22 <robcresswell> 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 <david-lyle> robcresswell: I agree it needs more work 20:15:58 <robcresswell> david-lyle: True, but at least we can get something done on requirements rather than them being frozen. 20:15:58 <hurgleburgler> aren't there guidelines for writing documentation on the way too? 20:16:03 <hurgleburgler> piet was mentioning something about that 20:16:11 <TravT> well, i've seen people multiple times come into the room and get referred to the patch 20:16:14 <TravT> how is that better? 20:16:16 <tqtran_> are there guidelines for guidlines? 20:16:23 <hurgleburgler> probably, lol 20:16:32 <robcresswell> TravT: We could address the issues with the patch? 20:16:38 <robcresswell> It hasn't been updated in weeks. 20:16:45 <TravT> which i'd be all for if it didn't seem so stagnated 20:16:46 <mrunge> searching for docs in gerrit is just... 20:17:03 <robcresswell> TravT: Wait, even you have a -1 on it :p 20:17:05 <david-lyle> robcresswell: if there are issues of inaccuracy we should update 20:17:07 <piet> We are working with the docs team around content guidelines 20:17:13 <david-lyle> otherwise, iterate 20:17:21 <piet> Planned to be merged in mid-feb 20:17:31 <TravT> no updates in about 45 days 20:17:41 <TravT> yes, i'm complaining that it has a ton of comments and feedback 20:17:52 <TravT> that shouldn't be too hard to address 20:17:53 <tqtran_> partly my fault, i was on vacay, and just got back like last week 20:18:07 <david-lyle> TravT: same 20:18:07 <tqtran_> im working on the patch right now as we speak 20:18:27 <robcresswell> Awesome, thanks tqtran_ 20:18:46 <david-lyle> I'm guessing all performance work for angular is dead in the water? 20:18:56 <robcresswell> the strict-di part is in 20:18:57 <mrunge> seems so 20:18:57 <david-lyle> just going through the priority list 20:19:01 <robcresswell> the next bit, I have no idea 20:20:33 <david-lyle> ok, without reviews things won't make it in 20:20:54 <david-lyle> 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 <david-lyle> lhcheng: any recommendations? 20:22:00 <lhcheng> love to see more focus on testing 20:22:13 <lhcheng> so we can catch regression 20:22:16 <mrunge> yupp! 20:22:22 <david-lyle> very true 20:22:28 <robcresswell> Timur has a ton of integration work up 20:22:32 <lhcheng> we've been hit twice in a week 20:22:35 <mrunge> with more or fixed tests, we could have avoided the angular routing mess 20:22:36 <robcresswell> And a team of minions work on it too 20:23:06 <robcresswell> #link https://review.openstack.org/#/q/status:open+topic:bp/integration-tests-improvements-part1 20:23:33 <lhcheng> so yeah, lets focus reviews on that. 20:23:51 <david-lyle> ok reviews and tests 20:24:24 <david-lyle> if the person posting the code hasn't done their part, let them know and move on 20:24:37 <david-lyle> #topic settings.d 20:24:51 <david-lyle> I'm leaning toward this approach 20:25:16 * TravT refresher? 20:25:32 <david-lyle> 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 <david-lyle> #link https://review.openstack.org/#/c/243974/ 20:26:11 <mrunge> TravT, in short, it allows you to add configuration snippets in a directory 20:26:24 <mrunge> comparable to httpd conf.d 20:26:27 <TravT> thx 20:26:30 <david-lyle> essentially local/local/local_settings 20:26:31 <david-lyle> :P 20:26:57 <david-lyle> allowing for settings changes without editing the local_settings.py 20:27:13 <mrunge> yes, exactly. that has been a pain point for distributors 20:27:22 <david-lyle> so installing a package (theme or plugin) can adjust settings without editing other content 20:27:56 <tqtran_> thats a nice addition 20:27:59 <david-lyle> I originally wanted to have the enabled files reused, but theming is an example of a non-plugin application 20:28:33 <david-lyle> and convoluted abilities of the enabled files already makes documenting them difficult 20:28:38 <david-lyle> :D 20:28:41 <lhcheng> ++ on settings.d . how will this integrate with the ini config? 20:28:55 <mrunge> lhcheng, currently, it does not 20:28:57 <lhcheng> do we need to move to ini config before using settings.d 20:29:10 <david-lyle> lhcheng: do we need to move to ini config? 20:29:11 <mrunge> we don't need to move to .ini before 20:29:11 <lhcheng> just trying to figure out the long term goal 20:29:40 <david-lyle> I think that's a stretch goal 20:29:46 <mrunge> and we could deprecate local_settings.py in the next step then 20:29:51 <robcresswell> It's been mentioned at both summits I've been to by different people 20:30:03 <robcresswell> Which is why I don't like the python snippets 20:30:05 <mrunge> it does not need any migration code 20:30:42 <robcresswell> The request I've heard is "external directory with .ini files" and our response has been "internal directory with .py files!" 20:30:51 <mrunge> robcresswell, they complained, because it's hard to edit python code from puppet 20:31:14 <mrunge> and one needs to edit python code, when configuring stuff 20:31:39 <mrunge> it's easy to copy prepared python code/snippets somewhere 20:31:46 <david-lyle> I think it would be nice, but what we had proposed was half there 20:31:58 <mrunge> right 20:32:06 <robcresswell> Thats no different to copying in .ini snippets though, except we havent solved the configuration issue 20:32:21 <robcresswell> I mean, I'm not gonna block something that there is demand for 20:32:33 <lhcheng> mrunge: isn't modifying python code a problem for package/installation too? 20:32:35 <mrunge> robcresswell, you'd get +2 from me for solving both/all three issues in one step 20:32:41 <robcresswell> But I feel like its adding a layer that we'll need to work around when we have a proper fix. 20:32:43 <mrunge> lhcheng, exactly 20:33:01 <lhcheng> mrunge: like if local_setting.py has been updated, reinstalling the package fails.. 20:33:29 <mrunge> lhcheng, it still succeeds. but you might have to change local_settings manually 20:33:51 <robcresswell> 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 <robcresswell> not all logic. I mean all base settings. 20:34:16 <robcresswell> Rather than the local_settings/settings division we currently have. 20:34:19 <mrunge> I would remove local_settings in long term 20:34:32 <mrunge> move it all to settings.d 20:34:35 <david-lyle> are we going to map all django settings? 20:34:46 <mrunge> we still have settings.py 20:34:57 <mrunge> which is inherited from django 20:35:08 <lhcheng> mrunge: ++ local_settings.py get updated always anyway 20:35:36 <david-lyle> ok, in the interest of time, lets leave our comments on the patch 20:35:41 <robcresswell> Sure 20:35:42 <lhcheng> mrunge: what we did for our packaging, our local_settings.py reads data from an ini file 20:35:49 <david-lyle> sounds like we're still not at a concensus 20:35:53 <david-lyle> and that's fine 20:36:09 <mrunge> lhcheng, would you share that code in a review? 20:36:12 <david-lyle> and lhcheng will write us an ini system 20:36:16 <david-lyle> :D 20:36:18 <mrunge> it sounds like a good addition 20:36:46 <david-lyle> #topic angular routing 20:36:54 <lhcheng> 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 <TravT> hey-o 20:36:56 <mrunge> move to settings.d does not require any migrations yet :D 20:37:06 <lhcheng> mrunge: sure, will add it to my todo list 20:37:12 <mrunge> lhcheng, sounds great, thank you 20:37:13 <david-lyle> other than breaking horizon a couple of times, what's up? 20:37:22 <david-lyle> thanks lhcheng 20:37:30 <TravT> well, we had a little message thread re routing 20:37:34 <lhcheng> mrunge: I already have our message of the day up too. (shameless plug) 20:37:43 <TravT> which basically stopped here 20:37:54 <TravT> synopsis is that we defaulted to using ng-route 20:38:05 <TravT> and that is already in 20:38:26 <lhcheng> TravT: stupid question coming.. what does ng routing do? 20:38:39 <tyr_> we've learned that when client side routes are used, the perceived performance is much better 20:39:09 <r1chardj0n3s> lhcheng: client-side routing; intercepts URL changes 20:39:14 <tyr_> 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 <TravT> 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 <robcresswell> Basically, no more loading... spinner 20:40:25 <lhcheng> TravT wins the most detailed explanation :) 20:40:31 <lhcheng> cool 20:40:43 <TravT> anyway, r1chardj0n3s, there is a problem i raised on the patch where rajat is asking again about ui-router 20:40:46 <david-lyle> and the argument is ng-route vs ui-router? 20:40:50 <r1chardj0n3s> robcresswell: welll, sometimes you still want a spinner if the new page is pulling in heaps of data 20:41:01 <TravT> see line 59 here: https://review.openstack.org/#/c/173885/147/openstack_dashboard/static/app/core/images/images.module.js 20:41:01 <david-lyle> just a different spinner 20:41:17 <tqtran_> a spinner to show another spinner, matrix style 20:41:19 <hurgleburgler> I need to fix that spinner 20:41:32 <r1chardj0n3s> 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 <hurgleburgler> we should use something like ladda 20:42:27 <r1chardj0n3s> 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 <david-lyle> unless there is a clear benefit and given packagers hatred of Horizon already, I'd prefer not to proliferate 20:42:41 <TravT> r1chardj0n3s: i don't like more dependencies either and I have provided an example asking for input on how to solve 20:42:42 <robcresswell> Yeah, I agree with that 20:43:27 <r1chardj0n3s> TravT: which example? 20:43:33 <TravT> see above 20:43:40 <TravT> see line 59 here: https://review.openstack.org/#/c/173885/147/openstack_dashboard/static/app/core/images/images.module.js 20:44:11 <r1chardj0n3s> ah, I see 20:44:50 <tyr_> 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 <r1chardj0n3s> 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 <r1chardj0n3s> I' 20:45:30 <TravT> 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 <r1chardj0n3s> I'd still like to see a proposal for how sub-routing would work, yep 20:45:50 <r1chardj0n3s> TravT: cool, thanks 20:46:01 <david-lyle> ok, seems like we should wait for the POCs and judge from there 20:46:26 <david-lyle> #topic theming 20:46:37 <hurgleburgler> I wanted to bring up two things … 20:46:48 <hurgleburgler> 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 <hurgleburgler> 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 <hurgleburgler> The second is an implementation detail on the custom select menus: https://review.openstack.org/#/c/263817/ 20:47:45 <hurgleburgler> 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 <hurgleburgler> 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 <david-lyle> ok, I'll bite, without reading the review. Why are we replacing ChoiceField? 20:49:04 <hurgleburgler> cause <select> is a monstrocity and can't be themed 20:49:11 <hurgleburgler> it uses the default OS styles for hte menu 20:49:13 <david-lyle> shouldn't this be a patch to django? 20:49:17 <hurgleburgler> and every brander wants to customize that 20:49:40 <hurgleburgler> this just replaces the default <select> to use Bootstrap dropdowns, so all of our menus look the same 20:50:03 <robcresswell> This is going to take some reading 20:50:22 <david-lyle> yeah, 20:50:22 <mrunge> yeah, and should be well tested, I guess 20:50:43 <hurgleburgler> We are using a hidden <select> to make sure legacy code augmentations will still use 20:50:52 <hurgleburgler> and tying the dropdown to the change event of the select 20:51:10 <david-lyle> sounds super clean :/ 20:51:25 <hurgleburgler> heh ;) 20:51:30 <david-lyle> will require more thought than this forum affords 20:51:52 <hurgleburgler> k 20:52:19 <david-lyle> keep bugging us 20:52:40 <david-lyle> #topic plugin file structure 20:52:58 <david-lyle> tqtran_: o/ 20:53:28 <david-lyle> just that we had no consistency or guideline and now there are many differing examples? 20:53:29 <tqtran_> hello 20:53:37 <tqtran_> yes 20:53:52 <tqtran_> so not sure about how we go about fixing it either 20:53:59 <tqtran_> i think documentation is the first step 20:54:07 <david-lyle> So I wrote trove-dashboard and sahara-dashboard to be examples going forward 20:54:14 <tqtran_> so future plugins can base off of something concrete 20:54:27 <david-lyle> and my additions to the docs moved that way 20:54:30 <tqtran_> right, but the thing is, we also have panel level vs dashboard level plugins 20:54:39 <tqtran_> and those require different file structure 20:54:40 <david-lyle> true 20:54:52 <david-lyle> well, just under content 20:55:01 <david-lyle> the rest is fine 20:55:04 <david-lyle> no? 20:55:16 <robcresswell> Just more nesting for a dashboard 20:55:29 <tqtran_> with many new plugins going the angular route, there is a new problem that surfaced 20:55:58 <david-lyle> do tell 20:56:01 <tqtran_> seems like autodiscovery doesn't work well for external angular plugins, have to use the manual JS_ADD_FILES, etc... for now 20:56:17 <david-lyle> sounds like a bug 20:56:18 <robcresswell> I saw that 20:56:18 <tqtran_> lbaas is an example 20:56:23 <robcresswell> Does Magnum UI have the same issue 20:56:25 <robcresswell> ? 20:56:28 <tqtran_> but... the strange part is, its working in magnum 20:56:43 <robcresswell> So, its a configuration issue...? :) 20:57:08 <tqtran_> maybe, i have no idea whats the issue though. i plan on looking into it 20:57:27 <tyr_> perhaps just PYTHONPATH? 20:57:40 <tqtran_> lastly, we still need a standard way for external plugins to test 20:57:52 <tqtran_> localization is pretty much done, although jaeger seems to have a few ideas 20:58:11 <david-lyle> for now I think run_tests.sh in the plugin is the best bet 20:58:23 <david-lyle> but I'd like something lighter weigth 20:58:30 <david-lyle> *weight 20:58:38 <tsufiev> tqtran_: i9n tests to the rescue \o/ 20:58:50 <tqtran_> yes, we copied the run_tests in these plugins to run tests 20:58:58 <robcresswell> i18n is done? Are the bot jobs all working? 20:59:15 <robcresswell> (Also, see https://etherpad.openstack.org/p/horizon-mitaka-midcycle for midcycle topics) 20:59:25 <tqtran_> we have a standard workflow for i18n, and horizon fully supports it atm 20:59:31 <david-lyle> thanks robcresswell 20:59:36 <tqtran_> although again, its lacking documentation 20:59:49 <robcresswell> run_tests is not really an ideal solution :/ 20:59:54 <david-lyle> no kidding 21:00:05 <david-lyle> but nothing is much much worse 21:00:13 <robcresswell> copying 500+ lines of code just to make some translation jobs run is... kinda ridiculous. 21:00:30 <david-lyle> translation, unit tests, integration tests 21:00:38 <david-lyle> not just translation 21:00:46 <david-lyle> ok, we're at time 21:00:46 <robcresswell> tox-only ftw. 21:00:53 <david-lyle> good luck 21:01:12 <david-lyle> Thanks everyone! 21:01:27 <david-lyle> See the link robcresswell sent for agenda 21:01:29 <david-lyle> #endmeeting