16:00:10 <david-lyle> #startmeeting Horizon
16:00:11 <openstack> Meeting started Tue Aug 26 16:00:10 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'horizon'
16:00:20 <david-lyle> Hello everyone
16:00:22 <ericpeterson> hello
16:00:26 <gary-smith_> hi
16:00:29 <jgravel__> hello
16:00:31 <tsufiev> hi
16:00:39 <TravT> hello
16:00:41 <absubram___> hi
16:00:48 <jpich> Hello
16:01:07 <amotoki> hello
16:01:17 <gugl2> hi
16:01:49 <david-lyle> Let's start with J-3 and the Sept 4 deadline approaching
16:01:51 <david-lyle> https://launchpad.net/horizon/+milestone/juno-3
16:02:16 <david-lyle> I did some cleanup this morning
16:02:35 <david-lyle> If there wasn't code posted yet, the bp was moved out of j03
16:02:39 <david-lyle> *j-3
16:02:44 <david-lyle> 38 Needs Code Review, 9 Implemented
16:02:53 <david-lyle> that's a lot left for review
16:03:00 <jtomasek> hey
16:03:15 <jomara> ahoy!
16:03:28 <david-lyle> many of those seem to be in very good shape and should merge soon
16:03:45 <david-lyle> others seem like long-shots
16:04:18 <jpich> At this stage I'd encourage people to not -1 blueprints for nits and small things but file follow-up bugs instead, that can be fixed after feature freeze but in time for the release
16:04:32 <david-lyle> jpich good point
16:04:47 <david-lyle> the turn around on fixing nits really drags things out
16:04:58 <david-lyle> and we can merge bug fixes after Sept 4
16:06:27 <amotoki> but please do not lower the bar on topics on itse architecture/basic directions.
16:06:44 <david-lyle> we do have some unassigned high defects as well, if people are looking for things to do :)
16:06:51 <david-lyle> amotoki: +1
16:07:44 <absubram___> david-lyle: can I add 3 low priority bug-fixes to this j-3 list? They've all got +1s and have been sitting in review for weeks (need core reviews).. I've had to just keep rebasing them.. I'd like to get them before string freeze as a couple add new strings..
16:07:48 <amotoki> For bug triage, we need some process how to triage bugs like https://wiki.openstack.org/wiki/Nova/BugTriage .
16:08:46 <amotoki> absubram___: bug fixes can be done after the feature freeze unless it is not big.
16:08:52 <david-lyle> amotoki: gary-smith_ has been doing a lot of work in triaging the existing bug list over the past few weeks
16:09:09 <gary-smith_> I been trying to follow https://wiki.openstack.org/wiki/BugTriage
16:09:11 <amotoki> yes. gary-smith_ made great jobs.
16:09:24 <david-lyle> amotoki: you have too
16:09:27 <absubram___> https://review.openstack.org/#/c/78708/   https://review.openstack.org/#/c/65793/  and https://review.openstack.org/#/c/76787/
16:09:51 <absubram___> amotoki: I know.. these are bugs that add new strings though.. we had this issue during I.. and I don't want to repeat :)
16:10:24 <absubram___> we actually didn't get these into I because of the UT issue.. but once that was fixed, these have been just sitting around waiting for reviews..
16:10:54 <amotoki> my concern is bug triage needs domain expertty, so I would like to move forward bug tagging as nova team does. we can discuss later or next week.
16:11:18 <david-lyle> amotoki: This is something I'd really like to address as well.  So far I've created the Horizon-Bugs team to increase the number of people who can triage bugs.
16:12:16 <amotoki> david-lyle: it is nice as the first step.
16:12:28 <david-lyle> yes, more is needed
16:12:49 <david-lyle> I'm happy to have the informal areas of expertise become more formal as well
16:13:11 <david-lyle> but I think there are several areas where there is not a clear domain expert
16:13:21 <david-lyle> other than perhaps Horizon core
16:13:49 <david-lyle> or are you suggesting assigning it and allowing people to make it their area of expertise?
16:14:56 <amotoki> what i am thinking is to do tagging first to categorize and then prioritize bugs of some areas.
16:16:04 <amotoki> several new dashboards were added recently and sometimes it is not easy to check bugs in such areas like heat, trove, sahara ...
16:16:56 <amotoki> if we have appropriate tagging, we can attract folks familiar with those areas. of course, we can dive into them.
16:17:09 <gary-smith_> amotoki: +1. I would also encourage all the help confirm bugs in the areas they work in. That can be the hardest part of triage
16:17:17 <gary-smith_> c/the/to
16:17:37 <david-lyle> amotoki: +1 on the tagging
16:18:01 <amotoki> this is the reason i like nova process: first tagging, then triage.
16:18:20 <david-lyle> I think if we just mark all bugs low-hanging fruit, they'll all get picked up ;)
16:18:30 <david-lyle> amotoki: ok, I understand your point now
16:18:36 * david-lyle was lost for a minute
16:18:45 <amotoki> but we don't have a list of folks responsible for areas. It is just a startline.
16:18:57 <david-lyle> amotoki: agreed
16:20:10 <amotoki> I will create a draft page like Nova/BugTriage this week and add my some thought.
16:20:15 <david-lyle> my remaining question is are people going to triage the bugs in the tags they are responsible for?
16:20:40 <david-lyle> rhetorical, no need to answer
16:21:09 <david-lyle> amotoki: thank you, I think it will be a step in the right direction
16:21:15 <amotoki> david-lyle: it is a separate topic but i cannot answer it too..... but at least tagging helps me triage neutron/network bugs.
16:21:53 <david-lyle> amotoki: works for me
16:22:47 <david-lyle> moving on the agenda for today
16:23:01 <david-lyle> I think there is only one item
16:23:06 <jpich> me me me
16:23:24 <david-lyle> #topic Documenting more precisely the browser versions we support/test with (jpich)
16:23:33 <jpich> #link https://wiki.openstack.org/wiki/Horizon/BrowserSupport
16:23:45 <jpich> I think it'd be good to track browser support a bit more precisely for each release (e.g. it's hard to remember what "latest version of each browser" means for a previous release, even for a recent one like Icehouse). I think that would be useful data to keep around, even if it starts simply with what people are using Horizon with when developing.
16:23:55 <jpich> So, please update the charts on that wiki page with whatever you've been testing with, we're particularly lacking in version numbers :)
16:24:32 <jpich> ...Thank you :-)
16:25:25 <doug-fish> Thanks jpich!
16:25:49 <david-lyle> Thank you jpich. I agree this is an important item to track and be able to point to for reference
16:26:25 <david-lyle> It does come up frequently
16:26:47 <jpich> Indeed
16:26:52 <david-lyle> #topic Open Discussion
16:28:11 <amotoki> I wonder how we can move forward on "More" button on tables.
16:28:33 <devlaps> we replaced more with a caret about 8 months ago..
16:28:39 <devlaps> no complaints from our customers..
16:28:54 <amotoki> devlaps: in your deployment version?
16:28:56 <david-lyle> More seems completely unnecessary to me
16:28:57 <devlaps> yup
16:29:07 <tqtran> agree
16:29:12 <gary-smith_> +1
16:29:18 <david-lyle> I'd like to have it stay as is
16:29:28 <jpich> I'm concerned that this was added because it was painful enough for a group of people that they decided to write up a patch about it
16:29:37 <amotoki> as I commented in the bug comment, Japanese translation for "More" is just a **space** :-)
16:30:08 <devlaps> it was actually our UX designers that suggested removing it..
16:30:09 <david-lyle> I smell a settings value compromise
16:30:13 <devlaps> :)
16:30:29 <jpich> The separator wasn't as visible with the previous skin though, so maybe that makes the separation clearer now
16:30:40 <amotoki> one suggestion from liz in bug comments is to add "hover".
16:30:50 <devlaps> that's a nice compromise..
16:30:54 <jpich> david-lyle: No, no more settings :(
16:31:03 <tqtran> lol
16:31:10 <david-lyle> just 20 or 30 more
16:31:12 <david-lyle> I promise
16:31:24 <doug-fish> Maybe a setting to enable the additonal settings?
16:31:24 <david-lyle> no, really, I think we can just use the caret
16:31:39 <tqtran> the easilest solution is to shove it off to settings and call it a win-win
16:31:45 <devlaps> with a default
16:31:46 <jpich> Ah, for people without context: https://review.openstack.org/#/c/115287/ + https://review.openstack.org/#/c/19082/
16:31:53 <jpich> A new setting is a loss
16:31:54 <david-lyle> we have enough space issues without adding superfluous wording
16:32:00 <devlaps> right
16:32:05 <devlaps> it saves a lot..
16:32:08 <amotoki> and https://bugs.launchpad.net/horizon/+bug/1357487
16:32:21 <jpich> Let's choose one way and people can override the template if they wish to
16:32:29 <david-lyle> jpich agred
16:32:33 <david-lyle> *agreed
16:33:27 <david-lyle> want to vote or just go with the caret?
16:33:31 <amotoki> +1. The majority here and bug reports like a way without "More" and some usability test result stands...
16:33:48 <jpich> The developer consensus seem to be toward not having "more" anymore. I'll just abandon the patch since it doesn't look like it's going to move forward anymore as is anyway
16:34:22 <david-lyle> jpich, I mainly wanted to hear the uproar in favor of "More"
16:34:29 <david-lyle> I haven't really witnessed that
16:34:38 <amotoki> One thing to note is a comment in the reivew: I think adding "More" was raised by a user in China, so would be great to hear the thoughts from reviewers in China.
16:35:16 <tqtran> if there isnt a "more" word in japanese, i doubt there is one in chinese?
16:35:29 <gugl2> amotoki, caret works for Chinese
16:35:42 <gugl2> there is a work for Chinese, but caret works too
16:35:51 <gugl2> s/work/word
16:36:04 <jpich> david-lyle: It's more like, there's no problems now. It's after the release we might the Big "More" Comeback Movement get started ;)
16:36:34 <jpich> I mean the initial patch doesn't seem to be coming from a company, it's someone who felt enough pain they decided to try and fix it
16:36:41 <david-lyle> I look forward to the speeches and pamphlets
16:36:50 <gary-smith_> A similar question: how to we proceed with "Server" vs. "Instance" ? ( https://bugs.launchpad.net/horizon/+bug/1319088 )
16:37:26 <jpich> I'm concerned that it's mainly the developers who are saying "yeah sure it's totally obvious and easy to understand"
16:38:27 <devlaps> jpich: from our experience, that's not the case.. we didn't have a single customer ticket after the switchover (but that is just us...)
16:38:33 <amotoki> I wonder where is a better place to ask? is it better to ask it in ops-list or general list?
16:38:49 <david-lyle> devlaps: switchover?
16:39:04 <devlaps> david-lyle: from "more" to caret..
16:39:09 <devlaps> oopss..
16:39:29 <devlaps> still on the last discussion point.. sorry about that..
16:39:32 <david-lyle> no worries, just thought maybe you switched from Instance to Server
16:39:48 <devlaps> not yet.. but we definitely need to address this..
16:39:58 <amotoki> no worries. both are similar topic.
16:40:44 <jpich_> I'm sorry, there's a power cut where I am - for the Server/Instance thing I wish it's worth a multi-project conversation on the ML
16:40:47 <jpich_> er... s/wish/think/
16:41:23 <david-lyle> I'd like to see us align with docs more than anyone else
16:42:06 <jpich_> I think it's confusing when the CLI and Horizon have different words too, especially for such an essential concept
16:42:32 <doug-fish> jpich_, agreed
16:42:35 <david-lyle> jpich_: to be fair, I think we are targeting different personas
16:42:38 <amotoki> jpich_: agree
16:42:42 <david-lyle> but it's a valid point
16:43:01 <david-lyle> there should be consistency
16:43:15 <david-lyle> and we can change much easier than the CLIs and APIs
16:43:29 <amotoki> in addition, "instance" is used in various context.
16:44:18 <david-lyle> what happens when Ironic becomes integrated? what's the term then?
16:45:55 <david-lyle> I think this requires some more input. I think a mailing list thread is probably the best bet
16:46:04 <sambetts> I prefer the use of Instance for virtual machines/lxcs etc. and Server for physical hosts
16:48:58 <david-lyle> the more topic was different than I originally believed, was thinking pagination
16:49:02 <david-lyle> on that line
16:49:43 <david-lyle> I think we have to adopt our own pagination representation and use that across all projects regardless of how they present pagination
16:50:18 <david-lyle> to do that, we need the client side pagination and table patches
16:50:27 <david-lyle> but that's a Kilo item :)
16:50:39 <david-lyle> just curious of others' thoughts on that
16:50:45 <amotoki> regaring "pagination", Filtering with pagination in horizon doesn't work practically....
16:51:05 <david-lyle> right, we need the list on the client side and filter/paginate there
16:51:07 <devlaps> right..
16:51:17 <tsufiev> david-lyle,  does client-side pagination reduce the amount of items returned on one request?
16:51:46 <david-lyle> tsufiev: well no, that's the downside
16:51:53 <david-lyle> of course
16:52:13 <clu_> :(
16:52:39 <david-lyle> the number displayed on the client is limited
16:52:48 <david-lyle> but the data is all there
16:53:06 <sambetts> wouldn't it be possible to setup a ajax based pagination system maintaining a cache of items on the webserver?
16:53:22 <rbertram> david-lyle: I assume client-side pagination (like clu_) for tables without too many rows? And something else for long tables like instances?
16:53:27 <tsufiev> sambetts, +1
16:53:29 <devlaps> david-lyle: for data sets < 1000 entries (potentially more) client-side gives a nice ux
16:53:33 <rbertram> sambetts: +1
16:53:33 <david-lyle> sambetts: yes
16:53:38 <devlaps> and yes to the caching..
16:53:43 <devlaps> only problem is cache invalidation :)
16:53:56 <devlaps> which is a problem anyway..
16:54:01 <david-lyle> but that's a problem on the client as well
16:54:05 <devlaps> yup
16:54:53 <devlaps> it would be great to solve this though.. it's a really *big* usability issue..
16:54:53 <david-lyle> but I think our strategy has to be get the exhaustive list and store it either on the server or the client and paginate/filter from that list
16:55:02 <david-lyle> devlaps: absolutel
16:55:03 <david-lyle> y
16:55:07 <david-lyle> !
16:55:09 <david-lyle> ha
16:55:18 <devlaps> especially with customers that have large numbers of HV/Server/Instances
16:55:23 <devlaps> :)
16:55:28 <david-lyle> and we have no consistency
16:55:37 <devlaps> right..
16:55:47 <tqtran> *cough cough* wouldnt moving toward angular client-side work help this goal in the long run?
16:55:47 <rbertram> david-lyle: we need async refresh through the cache up to the browser. Not easy.
16:55:56 <devlaps> tqtran: we have some work on this
16:56:03 <devlaps> would be happy to share..
16:56:08 <rbertram> tqtran: +1
16:56:19 <david-lyle> tqtran: yes
16:56:21 <sambetts> I would be easier to fix cache invalidation at the webserver level than at the clientside, is there no way for horizon to get a trigger off openstack if something changes?
16:56:29 <devlaps> yup
16:56:31 <tqtran> once everything becomes passing json, it becomes easy to do ajax request from cache
16:57:12 <david-lyle> sambetts: not now, we can try to tie in to the event queues, but that's a much bigger item, although highly desired
16:57:28 <devlaps> actually.. there is some work already done to do this..
16:57:32 <devlaps> digging up the url..
16:57:48 <david-lyle> would love event driven notifications
16:58:01 <devlaps> yup. it includes that..
16:58:01 <david-lyle> there was a proof of concept some time ago
16:58:18 <rbertram> david-lyle +1 on events
16:58:42 <devlaps> david-lyle: it was pretty nice and easy to get up and running..
16:58:57 <gary-smith_> hopefully could be leveraged for getting messages from async operations
16:59:08 <amotoki> BTW, regarding review priorities, is it better to focus on reviews related blueprints over bugs this week?
16:59:09 <david-lyle> devlaps: just a major change and those are harder to land
16:59:29 <david-lyle> amotoki: absolutely, we can land the bugs post Sept 4
16:59:35 <devlaps> david-lyle: unfortunately, yes. but a big win if we could land it!
16:59:49 <david-lyle> and if we want things to land, it's best to get them in the queue this week rather than next
16:59:50 <devlaps> Btw, if folks are interested in some of the UX work we have done recently, I gave a presentation on Horizon last week at CloudOpen: http://slidesha.re/1pkqQRn. There are some screenshots towards the end of some of our customization and statistics work. We also have quite a few additional UX modifications in the pipeline (hope to upstream soon!). Any feedback welcome…
16:59:52 <amotoki> david-lyle: the consensus on priority is important :-)
17:00:40 <david-lyle> yes BP reviews this week please
17:00:45 <david-lyle> out of time
17:00:49 <david-lyle> happy reviewing
17:00:56 <david-lyle> and keep the wheels turning for Kilo
17:01:00 <david-lyle> #endmeeting