16:01:49 <david-lyle> #startmeeting Horizon
16:01:50 <openstack> Meeting started Tue Apr 15 16:01:49 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:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:54 <openstack> The meeting name has been set to 'horizon'
16:01:56 <lsmola> hello
16:01:58 <david-lyle> Hello everyone
16:02:03 <jpich> Hello
16:02:04 <jcoufal> o/ hello everyone
16:02:06 <jrist> o/
16:02:11 <tmazur> hello o/
16:02:15 <santibaldassin> hi everyone
16:02:23 <akrivoka> hey
16:02:58 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/Horizon
16:03:10 <david-lyle> #topic: Release Status
16:03:54 <david-lyle> RC2 appears to be holding up with no blocking issues having been raised, this looks like our final RC
16:04:04 <david-lyle> \o/
16:04:24 <akrivoka> awesome
16:04:50 <david-lyle> The last thing I need to do is post the release notes
16:05:18 <david-lyle> when I do that, hopefully today, I'll ask everyone to take a look and correct my mistakes
16:05:23 <jpich> Cool, looking forward to the patch!
16:05:58 <david-lyle> Aside, from that, I think we're focused on Juno
16:06:36 <jrist> well done, everyone
16:07:15 <david-lyle> The deadline for session proposals is five days away, so if there's something you feel needs to be discussed at the summit, get your proposal in
16:07:59 <david-lyle> #topic DocImpact tag (jpich)
16:08:05 * jcoufal will add one more session proposal focused on tuskar-ui
16:08:08 <jpich> Hey!
16:08:18 <david-lyle> jcoufal +1
16:08:21 <jcoufal> (sorry for jumping into your topic, jpich) :)
16:08:32 <jpich> I was chatting with someone on the docs team last week and realised we haven't been very good at using the DocImpact tag in Horizon (or I missed it!). It would be helpful to the docs team if we could include the tag at least for major changes and "procedure" changes - I'm guessing things around new configuration / upgrade / installation information.
16:08:37 <jpich> jcoufal: We're flexible here ;)
16:08:52 <jpich> I'm still a bit fuzzy on when it is appropriate to use it for us (so many changes impact the user experience in some way) but we can refine our approach to using the tag as we understand it better :)
16:09:09 <jpich> Somme additional reading: https://wiki.openstack.org/wiki/Documentation/DocImpact http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ and I'm sure the folks at #openstack-doc are happy to answer any question, too
16:10:02 <tzumainn> jpich, one question
16:10:23 <tzumainn> looking through the baremetal example in the second link, it strikes me that a lot of those questions are exactly the same ones a reviewer would have
16:10:40 <david-lyle> other than internal bug fixes, don't all changes in the UI potential doc impact
16:10:52 <tzumainn> are reviewers expected to just ask those questions through the gerrit comment system?
16:10:58 <david-lyle> have potential that is
16:11:18 <tzumainn> or is there an expectation that the commit message have a certain level of self-documentation?
16:11:44 <jpich> tzumainn: I'm guessing in an ideal world these should be answered in the commit message and blueprint details, yes
16:12:15 <tzumainn> jpich, is that a standard - i.e., should reviewers -1 and ask for details on how to test a change?
16:12:16 <jpich> david-lyle: These are my thoughts as well, which is when it was clarified to me to care more about "procedure" changes rather than changes in the look
16:12:54 <jpich> david-lyle: I think we should start using it for major changes, the kind we self-document at the moment. Some of this should probably also live in the generic openstack guides?
16:13:10 <jpich> like settings, or how to use policies
16:13:29 <jpich> how to set up the dashboard to work with keystone v3 - probably these would have been great commits for DocImpact
16:13:44 <david-lyle> jpich, I see
16:14:21 <jpich> tzumainn: I think it'd be great to have that information but it hasn't been customary to block on it being missing. I'd lean toward strongly encouraging people to think about it and add that sort of info to the bug reports or blueprints, but not block on it... That'd be my thoughts on that
16:14:35 <tzumainn> jpich, okay, that sounds sensible enough - thanks!
16:14:58 <tzumainn> er, sorry, I now realize that I was re-directing away from your intended topic :P
16:15:04 <jpich> david-lyle: I'm still figuring this stuff out too :)
16:15:47 <david-lyle> jpich, thanks for raising, I think this a great thing to keep in mind.  Even if it just means more complete commit messages for Horizon use.  I think we've been flagging a bit on those lately
16:15:50 <jpich> tzumainn: It's documentish! I was bringing this up as a general "FYI, more things we should probably try to pay attention to"
16:16:25 * lsmola has to disappear soon today
16:16:35 <amotoki_> hi, i totally agree the discussion above. at least changes which impact install guide and could admin guide should have DocImpact..
16:16:35 <jpich> david-lyle: More useful commit messages is good!
16:16:43 <jpich> -1 on a typo in the commit message is uncool in my world though :-)
16:17:26 <jpich> amotoki: Agreed. We probably should explore what's missing in these guides  for Horizon and help the docs team fill the gaps as well
16:17:26 <david-lyle> yeah, let's not go crazy
16:17:27 <tzumainn> jpich, lol, agreed
16:17:37 <lsmola> jpich: agree, my vi doesn't have spellcheck
16:18:25 <amotoki_> Reagrding documentation, we use django style configuration and we need to explore how to sync our configurations with the config guide.
16:18:38 <jpich> lsmola: emacs has a spellchecker if you like ;)
16:18:49 <tzumainn> and jpich starts the flame war
16:19:02 <annegentle> do feel free to file doc bugs in http://bugs.launchpad.net/openstack-manuals for those missed DocImpact opportunities - you all will know better than us what should be docc'ed
16:19:18 <annegentle> amotoki_: it'd be great to automate those
16:19:24 <jpich> amotoki: Yep, which brings to mind https://bugs.launchpad.net/horizon/+bug/1300710 and https://bugs.launchpad.net/horizon/+bug/1221115 which we probably want in the guides as well
16:20:13 <jpich> annegentle: Thanks! That's what I had in mind, hopefully we can help with writing them too rather than just overload the docs team even more
16:20:47 <annegentle> jpich: sure! we are happy to take highly detailed doc bugs and turn them into docs if tools are an issue though, that's all I mean.
16:21:03 <jpich> annegentle: That's useful information, thanks!
16:22:03 <amotoki_> jpich: thanks for filing it. in other projects configurations are extracted from code base but it is not for Horizon. we need to explore how to improve it in Juno.
16:22:49 <david-lyle> yes, the horizon settings/conf mechanism is different and we'll have to provide a mechanism to pull it automagically
16:23:04 <jpich> yep
16:23:27 <david-lyle> anything else on this topic
16:23:37 <jpich> Not from me, thanks for your attention and consideration folks!
16:23:59 <amotoki_> nothing from me too.
16:24:28 <david-lyle> thanks!
16:24:36 <david-lyle> #topic Open Discussion
16:24:43 <tzumainn> so, related to my point above - is there a way to ask for patches to have more documentation associated with them, because a lot of those patches are fairly complex and it feels like a potential blocker for reviewers?
16:25:02 <david-lyle> tzumainn, absolutely
16:25:10 <annegentle> tzumainn: educate all your reviewers
16:25:44 <david-lyle> if you don't feel like enough information is provided to do a proper review, ask for it in the review
16:25:44 <tzumainn> so, I'm going to admit that by "reviewers" I meant "me" : )
16:25:56 <jrist> so subtle
16:26:10 <jrist> what is everyone's thoughts on using polyfills or similar mechanisms for supporting older browsers with newer features (i.e. the recent 'input type number' bug)
16:26:13 <annegentle> tzumainn: I can't think of an automated way, or a test that runs each time
16:26:17 <jomara> tzumainn: your idea is going mainnstream
16:26:19 <david-lyle> you are likely not alone, and when looking back at the commit log, one sentence commit statements aren't very helpful
16:26:41 <jomara> tzumainn: ar eyou talking about commit docs, internal source comments, user guide stuff, or all of the above?
16:26:56 * david-lyle could have missed the point
16:26:57 <tzumainn> jomara, I'm talking about picking up a patch from gerrit and trying to figure out how to review it : )
16:27:18 <jomara> so, whatever it is, enough to read about it and figure it out
16:27:25 <jpich> david-lyle: Agreed with all you said either way :-)
16:27:39 <jcoufal> jrist: I think we shouldn't pay so much extra effort to support old browsers, other than those which are officially supported
16:27:56 <jrist> do we have a list of officially supported browsers
16:28:04 <jrist> jcoufal: for instance, input type number is not supported in current firefox, 28
16:28:06 <jrist> pretty bad
16:28:13 <jrist> so not necessarily older browsers
16:28:30 <jcoufal> wait, really? current firefox doesn't support number type?
16:28:34 <jrist> nope
16:28:38 <jrist> 29 maybe. 28 no
16:28:38 * jcoufal amazed
16:28:56 <jrist> there are many things like that
16:29:29 <jcoufal> From my point of view, I would say that it depends on the type of the problem and browser
16:29:30 <david-lyle> the hard limitation we have is ie 8 and greater, other than that we assume the browsers do a good job of staying reasonably up-to-date
16:29:44 <david-lyle> soon ie 8 should go away
16:30:04 <jcoufal> general rule I have is - are you using latest new versions? you get great UX, are you using old stuff? it's usable for you, but you don't get the best you can
16:30:04 <jpich> There's some serious bugs open about our ie 8 support though I seem to remember
16:30:09 <jrist> is there a list somewhere
16:30:24 <jrist> of supported browsers
16:30:29 <jcoufal> i think david-lyle just described the rule above
16:30:43 <david-lyle> actually when XP eol'd we should be able to stop support ie8, it is also eol
16:30:51 <doug-fish> https://github.com/openstack/horizon/blob/master/doc/source/contributing.rst#javascript
16:30:55 <jomara> not bad!
16:31:04 <jcoufal> david-lyle: I can't wait for this to happen :)
16:31:13 <jpich> doug-fish: Thanks! I knew it was somewhere but my grepping failed me :)
16:31:26 <david-lyle> jcoufal, the date was April 8
16:31:27 <clu_> i think for older browsers, we should at least have a warning message somewhere that says: "horizon is not fully supported"
16:31:30 <david-lyle> it is done
16:31:32 <doug-fish> jpich:  glad to help.  Took me a while as well!
16:31:45 <tzumainn> so, there's a specific case here
16:31:49 <tzumainn> https://review.openstack.org/#/c/82908/
16:31:50 <jpich> https://bugs.launchpad.net/horizon/+bug/1260281 - probably needs to be fixed and backported to icehouse
16:31:58 <tzumainn> the fix only works on these browsers: https://review.openstack.org/#/c/82908/
16:32:04 <tzumainn> so the question is - should this fix be accepted or not?
16:32:05 <jrist> clu_: supported is a loaded word
16:32:10 <jcoufal> david-lyle: so we are safe to say, that for J we are dropping IE8 support as well
16:32:15 <jrist> tzumainn: thansk for bringing that up
16:32:24 <jrist> what do we mean by supported
16:32:30 <tzumainn> jrist, np, I had similar thought processes when looking at that patch
16:32:37 <david-lyle> jcoufal, seems so
16:32:40 <jrist> how about "Horizon and OpenStack Dashboard don't work well on browsers older than ...."
16:33:16 <tzumainn> jrist, so if that's the case, would the fix in the review above be accepted as closing the bug?
16:33:43 <david-lyle> jrist, more like "... are not supported on ...
16:33:57 <jrist> david-lyle: do we offer support?
16:34:08 <jrist> support is a loaded word, like I said
16:34:10 <david-lyle> jrist good point
16:34:22 <jrist> tzumainn: no I don't think it does, thus my initial nack
16:34:32 <amotoki_> Another idea is to have a list of tested browsers with versions.
16:34:33 * david-lyle thought jrist was the support organization
16:34:37 <jrist> I agree with Maxime
16:34:38 <tzumainn> jrist, yeah, I +1'd with an understanding it was a partial fix, but I can see your point
16:34:39 <jrist> david-lyle: ha
16:34:40 <david-lyle> :)
16:34:55 <clu_> amotoki_ - this is a good idea
16:35:25 <jrist> amotoki_: yeah, that is what I'm thinking
16:35:48 <jcoufal> jrist: I am on Maxime's side as well. It is not enough to use number type as a proper validation check
16:36:07 <jrist> so my original question
16:36:16 <jrist> what is everyone's thoughts on polyfills
16:36:23 <jrist> or similar mechanisms
16:36:32 <jrist> even IE9 doesn't support dozens of HTML5 things
16:37:00 <jcoufal> I am not very sure if the polyfill will ensure the validation
16:37:07 <jcoufal> isn't it only providing the look?
16:37:12 <jrist> it will, in the input number case
16:37:21 <jrist> in this case prevent non digit
16:37:58 <jcoufal> well then I would be in favor of that (in case of number picker)
16:38:10 <jrist> yeah, it is an example of other places where polyfills might be useful
16:38:26 <jcoufal> depends on case to case, but in this one it seems reasonable to me
16:38:34 <jrist> jcoufal: thanks. anyone else? :)
16:38:41 <jrist> I wish Maxime were here
16:38:58 <jpich> Can continue the discussion on channel later when he's around
16:39:03 <jrist> yeah
16:39:04 <jrist> ok thanks
16:39:55 <jpich> If it fixes things and the licence is compatible seems ok to me!
16:40:10 <clu_> i've seen some FIXME/TODOs in the code... do we do occasional sweeps to see if the issue can be resolved now?
16:40:42 <clu_> if so, write up bugs or something, otherwise things get forgotten and the FIXME/TODO list grows
16:41:19 <jpich> Ideally people would file a bug at the same time they submit a patch with a TODO
16:41:52 <doug-fish> I guess that's something we can add to our reviewer checklist
16:41:54 <david-lyle> clu_, that would be a good idea.  Unfortunately, a lot of them are waiting on better support outside of Horizon, like server side filter criteria
16:42:25 <david-lyle> we could open a bug on something like that, but it would likely expire before we can address it
16:42:51 <clu_> david-lyle: agreed, we shouldn't write those up
16:43:01 <amotoki_> by greping the code, we have 77 TODOs but 30 TODOs comes from one person (router dashboard)..... Apart from this, we hvae ~40 TODO/FIXME.
16:43:03 <jpich> Ideally we'd add a horizon task to the bug in the related project but that's not always possible
16:43:19 <david-lyle> ideally :)
16:43:59 <jpich> It's nice to imagine the ideal world sometimes :-)
16:44:12 <david-lyle> amotoki_ 40 should be fairly easy to catagorize as actionable or not
16:44:20 <jrist> lol jpich
16:44:27 <tzumainn> I must say that it's nice that the cores in horizon are still optimists
16:44:30 <david-lyle> jpich, sometimes that's all we have
16:45:49 <amotoki_> can i discuss another topic?
16:46:02 <jpich> Please
16:46:19 <amotoki_> i would like to know opinions on backward compat of "horizon" module.
16:46:31 <amotoki_> https://review.openstack.org/#/c/86068/2/horizon/tables/actions.py
16:46:47 <amotoki_> this patch removes existing fields in BacthAction.
16:47:08 <amotoki_> I wonder we should consider backward-compat of horizon module or not.
16:47:29 <jpich> We will have to be better at it when we separate it from the dashboard for sure
16:48:29 <amotoki_> fair enough to me.
16:48:46 <jpich> This might be a topic worthy of a more meaty/thoughtful conversation on list...
16:49:39 <amotoki_> agree. i just want to know initial feedbacks.
16:50:19 <david-lyle> I think existing fields should be a high hurdle
16:50:52 <david-lyle> as an extensible framework, we potentially break existing deploys
16:51:50 <amotoki_> yes. that is in my mind. I remember Gabriel mentioned so in past reviews.
16:52:17 <david-lyle> I have to look at this particular patch in more depth to understand the intent better
16:53:08 <david-lyle> I think the story will actually be smoother after the split, because we will have packaged versions of the toolkit that doesn't have to be updated with Horizon
16:53:35 <david-lyle> makes our testing matrix more complex of course
16:54:03 <david-lyle> s/Horizon/openstack_dashboard_future_name/
16:55:10 <santibaldassin> hey folks..I'd like to have a quick talk about client side validations if there's no other topic
16:55:19 <david-lyle> sure
16:56:00 <santibaldassin> so, there are a couple of patches were we are doing an api call to get quota usages do do client side validations that are already done by nova
16:56:12 <santibaldassin> https://review.openstack.org/#/c/76107/
16:56:19 <santibaldassin> https://review.openstack.org/#/c/70158/14/openstack_dashboard/dashboards/admin/projects/workflows.py
16:58:44 <jpich> It's usually nicer to show an error on the form by the field that has the issue, rather than let the user submit it then have to start from scratch again to correct an error
16:58:52 <santibaldassin> I have two concerns, one is that we are increasing the number of request that we are doing to complete the operation and the other is that if the backend *no matter if its nova or cinder or any other module) changes the way they do the validation, we'll have to change the validation in horizon too
17:00:01 <jpich> Although for that one in particular, do the APIs actually prevent you from setting a quota less than what is currently used?
17:00:34 <david-lyle> let's continue this in the horizon room or on the review
17:00:34 <jpich> well, we're out of time, we can continue on the channel - although I have to jump in another meeting now
17:00:35 <santibaldassin> jpich: I'm ok with showing friendly user. I think we could do it without the extra api calls
17:00:50 <david-lyle> Thanks everyone have a great week.
17:00:53 <santibaldassin> thanks
17:00:56 <david-lyle> #endmeeting