20:00:27 #startmeeting Horizon 20:00:28 Meeting started Wed Jan 28 20:00:27 2015 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:31 The meeting name has been set to 'horizon' 20:00:37 hello everyone 20:00:41 Hello! 20:00:43 hi 20:00:48 hi 20:00:51 o/ 20:01:41 o/ 20:01:41 o/ 20:01:49 hello 20:02:32 packed house 20:02:47 Hi 20:02:50 let's get started 20:03:11 The agenda for today's meeting is available at https://wiki.openstack.org/wiki/Meetings/Horizon 20:03:26 But first let's talk milestone status 20:03:31 hi 20:03:43 k-2 ends on Feb 5 20:03:57 #link https://launchpad.net/horizon/+milestone/kilo-2 20:04:08 1 Started, 4 Good progress, 1 Beta Available, 13 Needs Code Review, 7 Implemented 20:04:14 a lot need reviews 20:04:42 I believe that a few need code review are blocked by dependencies 20:04:50 on other projects 20:05:29 I'll walk through and those blocked are going to get bumped to k-3 20:06:15 You can move https://blueprints.launchpad.net/horizon/+spec/cinder-multi-attach-volume to k-3 20:06:15 but we should prioritize those reviews 20:06:29 (it is one of those blocked) 20:06:44 done 20:07:09 any questions about k-2 or milestones in general 20:07:53 ask later if needed 20:07:57 mattfarina: around? 20:08:03 david-lyle I am 20:08:11 great 20:08:15 #topic Updating to Jasmine 2 20:08:40 #link https://blueprints.launchpad.net/horizon/+spec/update-jasmine 20:08:53 anything you want to add mattfarina on that one? 20:09:13 david-lyle we'd like to land Jasmine2. I see you +1'd the review to requiremts since i post to the agenda. 20:09:24 can we get it into kilo-2? we still have some time 20:09:35 I'd like to have it in for kilo-2 20:09:43 I think essentially we're blocked by openstack/requirements patch not 20:09:45 we need to get the people on https://review.openstack.org/#/admin/groups/131,members to weigh in. 20:09:48 s/not/now/ 20:10:09 the review to horizon is blocked by the review to requirements 20:10:26 understood 20:10:49 once requirements moves forward, we can work on merging the horizon side 20:10:53 i'm going to reach out to some of the admins and see if we can move it along 20:11:04 if anyone else wants to as well... that would be appreciated 20:11:36 point out the gate tests are disabled until updated 20:11:51 i left a ping in irc this morning, but reaching out to individuals might be better 20:12:03 thanks for raising the issue, tqtran brought it to my attention this morning 20:12:07 i tried a general ping and got no movement 20:12:27 these take time 20:12:44 for now :) 20:12:56 #topic JavaScript cleanup: reduce number of jQuery objects being created 20:13:34 this one is me too. i wanted to talk about the javascript practice 20:13:35 I think the linked patch merged 20:13:39 sure 20:13:41 have at it 20:13:41 the first of many 20:14:15 every time we do a $(document) or a $('#something') we create a new object and that takes memory and needs to be garbage collected 20:14:44 it's usually a good idea if you're going to create the same object more than once to assign it to a variable and repeatedly call the variable 20:14:52 that's what we'd do in Python or another language 20:15:31 seems like a good recommendation 20:15:45 should recommendations like this go into the JS guide? 20:15:49 I'm a big fan of this idea, if there are more patches out im happy to spend time reviewing them 20:15:53 mattfarina: yes 20:16:14 robcresswell thanks. i just updated one file. if we tried to fix everything in one go it would never land 20:16:18 i'll take you up on that 20:16:21 oh yes please 20:16:38 ok, i can update the guide 20:16:48 that's all i wanted to talk about here. thanks 20:17:00 I have noticed recently that the js behavior in horizon is flaky 20:17:11 hell yes! 20:17:23 flaky? 20:17:25 leaving the browser open for any period of time causes modal behavior to fail 20:17:25 we're using more memory than we need to and i wouldn't be surprised if we have some memory leaks 20:17:28 very strange and quite unexpected behaviour 20:17:31 tabs to stop working 20:17:33 ah.... 20:17:45 menus stop working 20:17:48 generally becomes unusable 20:17:53 we also have some problems with event handlers that can cause processing issues 20:17:54 accordion does not react 20:17:59 js is single threaded after all 20:18:03 this needs to be a critical priority 20:18:06 awesome 20:18:20 great. 20:18:32 I haven't filed a bug because I don't have concrete repeatability steps 20:18:43 just general wait a while 20:18:47 david-lyle, do you have a bug number? 20:18:48 this jquery issue here is just one of the things. if people find problems and report bugs i'm happy to help anyone figure it out or come up with a fix 20:18:51 or a link? 20:18:56 hehe, yes hard to find them. we have too many js with global reach 20:18:56 i <3 js after all 20:19:07 mattfarina: Could also take on some of the individual file rewrites... should have a bit of spare time. Let me know. 20:19:09 mrunge: I don't have a bug yet 20:19:16 ok, thanks 20:19:26 just got very frustrated recently 20:19:37 yes, I hear you! 20:19:41 some profiling would be helpful 20:20:00 I have quite a few things to fix in launch instance workflow. 20:20:09 but it doesn't make sense to start 20:20:23 since there is this whole start instance rewrite 20:20:32 mrunge: good point on that one 20:20:33 on what we're waiting 20:20:41 and waiting 20:21:03 is that targeted for kilo? 20:21:07 but we have a bunch of other places for improvement 20:21:10 mrunge: yes sir 20:21:16 really? 20:21:23 mrunge: really =) 20:21:31 glad to hear tqtran 20:21:44 maybe i can suggest a 2 headed approach. we share good practices and tools. then we use them to slowly work through the code as we fix existing code and add new features 20:21:52 i dont know if all of it will land, but thats the aim right now 20:21:59 i think a lot of it is practices or slip ups many just don't know 20:22:26 until now, we don't have any new features in kilo at all 20:22:32 like, there's a common cause of memory leaks in circular dependencies... https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript#Memory_leaks 20:22:32 at least, nothing to note 20:23:15 mattfarina, thanks for sharing the link, quite useful! 20:24:43 it seems like memory leaks happen in firefox as well... 20:24:56 not only in IE, as mentioned in the document 20:25:09 they happen in all browsers 20:25:45 this is just one example. they are common enough in FF extensions they have a guide on dealing with it there and FF has a tool to help find memory leaks 20:26:23 mattfarina: +1 to 2 headed approach comment.. get it documented, people then can reference, and we can open defects and point to best practices when issues are found. 20:26:30 thanks 20:26:45 this is already way more than i had planned on talking about. really glad there's interest 20:27:14 mattfarina: we need to get out house in order as we add more and more js 20:27:32 so it's extremely relevant, thanks for bringing it up 20:27:43 #topic Open Discussion 20:27:43 out house or our house ;-) 20:27:55 Yeah its all very valid points, just need to take it one step at a time 20:27:55 yes, the sooner we have guidelines, the better 20:27:59 asahlin: depends on the day 20:28:03 lol 20:28:15 yesterday, very much out house 20:28:19 We are looking for Domains Admins to participate in a usability study! 20:28:40 If you know someone please let me know! 20:29:08 question: has anyone started Neutron REST API for Angular front end to use? 20:29:24 Piet: that is going to be a small pool, I fear 20:29:45 I didn't see any patches out there, but didn't want to start if someone already had a jump on it. 20:29:46 Agreed, but we only need about eight people 20:29:50 asahlin: not sure 20:29:52 asahlin: I BELIEVE we have, but not entirely sure. ( 20:29:54 asahlin i think Mike Hagedorn may have 20:29:56 asahlin: bradjones was looking into it... 20:30:15 let's get coordinated 20:30:22 ok, I will ping them or send an email to the group 20:30:45 asahlin: Mike Hagedorn is doing that 20:31:01 Please take a few moments to leave comments on the UX Design for the Instance Details panel. http://invis.io/NB1L22K4Q 20:31:48 wchrisj: mattfarina: great thanks, I will reach out to Mike 20:31:52 so far all angular bps seem to be buried in one bp https://blueprints.launchpad.net/horizon/+spec/angularize-identity-tables 20:32:09 other than launch instance 20:32:39 if you are tackling other services, I expect bps, so that we can coordinate around those 20:33:01 but I also caution getting to far ahead of ourselves 20:33:17 be prepared to pivot if necessary 20:34:28 other topics? 20:34:57 does it make sense to collect extension ideas 20:35:10 separate from blueprint? 20:35:24 mrunge: for the angular work? 20:35:37 angular, anything 20:35:48 it's more general 20:36:06 mrunge: I am unclear what you're asking 20:36:12 often, you have an idea, but it's not complete to get a blueprint accepted 20:36:32 something like a feature request from someone 20:36:53 like: I'm an admin and want to see images and networks of tenant a 20:36:56 ah, I understand now 20:37:06 good question 20:37:12 is that what our wishlist is for? 20:37:21 neither someone, nor I have a concrete idea how it should look like 20:37:23 only that no one really pays attention to it 20:37:32 for example 20:37:53 it would serve as an idea pool for contributors with spare cycles 20:37:57 our bps are already over-used already, so I don't want to use that 20:38:11 maybe an etherpad or wiki page 20:38:22 don't we try to make a bp more formal? 20:38:28 mrunge: yes 20:38:39 that's why I'd like to keep suggestion out of it 20:38:51 so mis-using bp for this purpose would just be wrong 20:38:55 I'm going to clean out old bps that are out of date as it is 20:39:14 to much cruft 20:39:19 hard to manage 20:39:23 ah yes, I'll do the same. 20:39:49 we have currently 273 blueprints 20:40:01 mrunge: I am fully aware :( 20:40:07 which is insane. 20:40:14 david-lyle, I'm not blaming you 20:40:18 maybe a wishlist wiki page. if many details are needed they could go to an etherpad. the wishlist would be easy to find. using etherpads for long details would mean the wiki doesn't get cluttered (especially for search) 20:40:23 just a thought 20:40:29 good suggestion 20:40:45 works for me, mattfarina, make it so 20:40:53 thanks for stepping up 20:40:59 ha, thanks 20:41:12 just linked off the horizon page 20:41:21 I could imagine, we need to clean that wishlist up from time to time 20:41:21 https://wiki.openstack.org/wiki/Horizon 20:41:30 mrunge: indeed 20:42:15 two things moving forward I'd like people to think about 20:42:46 1. adopting a specs repo in horizon and have bps blocked to non-core additions 20:43:11 formalize the review process, come into better alignment with the rest of openstack 20:43:20 less noise 20:43:24 ideas are great 20:43:37 good suggestions 20:43:41 being randomly added to milestones is not as great 20:44:04 but with 273 bps, that's the only way to make them visible currently 20:44:29 2. moving to a wider eco-system, formalize how horizon will handle extensions 20:44:56 in a contrib folder, external to tree, how we point deployers at them 20:45:22 there will be a push for horizon to support more and more things 20:45:30 we need to be ready to handle it 20:45:59 if we formalized before the flood gates open, we will have a clear message and path for those asking 20:46:13 less painful in the long run 20:46:36 david-lyle I appreciate #2 as it came up this week 20:46:41 I'm quite reluctant to pull them in the tree 20:46:52 people are already talking about it if you didn't already know 20:46:57 I'm sure 20:47:10 As someone working in that area right now, I couldn't agree more david-lyle: 20:47:15 with #2 20:48:07 I wonder, why those extensions don't use the plugin stuff already there 20:48:23 mrunge: they will 20:48:34 and if that doesn't work out, why plugins are not extended to work 20:48:49 is it that lack of intention and documentation? 20:49:02 but if they are part of OpenStack, it is a forced dichotomy to have some in tree and some out 20:49:17 the TC is now saying OpenStack is OpenStack 20:49:25 it's not integrated 20:49:34 it's not incubated 20:49:38 it's OpenStack 20:49:42 you can basically add anything through plugins 20:49:57 just have a python module somewhere and write a config file 20:50:19 but by having cinder, nova, sahara, trove in tree, there is greater access to those services by default 20:50:31 I'm not sure fairness is our job 20:51:05 but at a bare minimum, it would be nice to have a list of compatible extensions and links to github repos or pypi packages 20:51:10 somewher 20:51:11 e 20:51:28 and also clearly define what will go in tree 20:51:40 I assume Vendor specfic extensions will be out-of-tree 20:52:01 I'm not willing to accept anything vendor specific 20:52:01 david-lyle, we could think about defining a horizon core and see the rest as add-on or plugins then? 20:52:24 how often did we had the request to have only swift and nothing else? 20:52:33 but things like Piet started with UX style guide become more important 20:52:46 since we're not reviewing the extensions directly 20:52:58 for plugins, we should bump up priority on radomir's patch https://blueprints.launchpad.net/horizon/+spec/ini-based-configuration, and eventually use stevedore to load plugins. 20:53:16 yes the current framework is flawed a bit 20:53:27 yes!, good suggestion lcheng 20:53:29 in that the extension file is a python file 20:53:35 it's pretty common to have a core set of extensions and then a long list of community extensions 20:53:39 this makes it exceptionally hard to use 20:54:24 again, my desire is to decide the plan and document it before everyone is banging on our door 20:54:40 I want to be lazy and just point them to the appropriate wiki page 20:55:06 +1 20:55:22 I'm not hearing much disagreement on the general approach 20:55:24 yes! 20:55:28 pre-planning is a good thing, because as we're seeing with neutron vendor decomp it is harder to move things out once they are in 20:55:32 +2, approved 20:55:36 sound goods to me 20:55:36 I may just need to document 20:55:37 to both :P 20:56:14 so lets describe these decisions in a series of blue prints 20:56:16 * ericpeterson ducks 20:56:54 or a specs specs repo 20:57:49 answer is always just one more level of metadata 20:58:03 * david-lyle hangs head 20:58:09 2 minutes 21:00:23 have a great week everyone. thanks for all the reviews 21:00:28 #endmeeting