20:00:03 <david-lyle> #startmeeting Horizon
20:00:04 <openstack> Meeting started Wed Sep  9 20:00:03 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:08 <david-lyle> who's about?
20:00:08 <openstack> The meeting name has been set to 'horizon'
20:00:13 <r1chardj0n3s> o/
20:00:18 <tsufiev> hi
20:00:25 <lhcheng_> hi
20:00:27 <rhagarty> 0/
20:00:45 <mrunge> o/
20:00:47 <tqtran> [=_=]/
20:00:59 <doug-fish> hi
20:01:09 <hurgleburgler> o/
20:01:27 <TravT> o/
20:02:17 <david-lyle> ok, was looking at curvature, sorry
20:02:29 <david-lyle> still a few blips in large environments
20:02:29 <TravT> how'd it look?
20:02:44 <david-lyle> very similar TravT to last time
20:02:59 <TravT> ok
20:03:40 <david-lyle> #link https://launchpad.net/horizon/+milestone/liberty-rc1
20:03:59 <david-lyle> this is the list of approved FFEs
20:04:15 <david-lyle> 2 are implemented, others still need review
20:05:14 <david-lyle> actually documentation merged, so that is implemented too
20:05:18 <lhcheng> david-lyle: do we have cores committed to review the approved FFEs?
20:06:36 <david-lyle> lhcheng: I know I've committed :) I think you and robcresswell volunteered for Database Clustering
20:06:38 <david-lyle> IIRC
20:07:05 <david-lyle> beyond that I don't know that we have clear commitments
20:07:09 <robcresswell> Yup, I need to go over that again
20:07:29 <robcresswell> I've got shelving on my list too, its only small
20:07:42 * lhcheng lost his memory
20:08:00 <david-lyle> yes, that one looked close
20:08:33 <david-lyle> we could always use more core eyes otherwise things will sit
20:08:52 <david-lyle> we should also look at bugs
20:08:54 <lhcheng> if we don't have core sponsoring, those patches might just sit around
20:09:19 <lhcheng> yeah, the rc1 bug list is long
20:10:15 <mrunge> ugh
20:10:27 <lhcheng> do we want to scope rc1 bugs to just critical/high?
20:10:36 <david-lyle> I'll walk through that in a bit, some may be carry overs
20:10:37 <mrunge> I'd vote for fixing bugs instead of introducing new features
20:10:46 <lhcheng> ++
20:10:47 <doug-fish> +1
20:11:44 <david-lyle> bugs should be the priority
20:12:13 <david-lyle> we have a bout 2 more weeks before we start locking down an RC
20:13:00 <mrunge> may I throw in, we can not backport patches with string changes
20:13:40 <mrunge> meaning, once mitaka is open, we most probably can't fix bugs introducing new strings in liberty
20:13:58 <doug-fish> mrunge: does that pertain to any specific bugs that you've identified? or just general advice?
20:13:59 <ducttape_> why is that?
20:14:25 <mrunge> doug-fish, general advice on priorizing on bug fixes
20:14:38 <mrunge> ducttape_, translations are only done per release
20:14:49 <ducttape_> nod, thanks
20:14:58 <mrunge> and we need to give translators time to translate
20:15:43 <mrunge> I know this is confusing sometimes and causes frustration for fixing important bugs
20:16:07 <david-lyle> another suggestion, build a fresh VM and pull down master and just exercise the views
20:16:10 <mrunge> this is why I would like to stress, we need to look at bugs changing strings
20:16:20 <lhcheng> btw, there seem a problem with translations proposed.. https://review.openstack.org/#/c/220404/
20:16:39 <david-lyle> we tend to build up collateral defects from other changes over the release
20:16:40 <doug-fish> another suggestion: extercise the views after pseudo translating them and make sure they all look translatable
20:16:46 <david-lyle> better to find them soon
20:17:07 <david-lyle> the idea here is to stabilize for release
20:17:23 <david-lyle> and find the issues before they become a firedrill
20:17:37 <david-lyle> you know, like software releases :)
20:18:09 <david-lyle> anyone have bugs not on the RC-1 list that are causing alarm?
20:18:44 <david-lyle> it's perfect then, good
20:18:52 <david-lyle> :P
20:19:15 <doug-fish> not yet
20:19:16 <david-lyle> any RC questions before we move to the agenda?
20:19:45 <david-lyle> If you find items you feel may be RC issues target them for RC-1
20:20:00 <david-lyle> we can make a judgement call later if need be
20:20:07 <r1chardj0n3s> david-lyle: https://bugs.launchpad.net/django-openstack-auth/+bug/1491117 got bumped off the rc1 list because I boo-booed
20:20:08 <openstack> Launchpad bug 1491117 in django-openstack-auth "Error when logging back in after timeout" [High,In progress] - Assigned to Richard Jones (r1chardj0n3s)
20:20:25 <mrunge> oh yes!
20:20:43 <TravT> is that the integer error?
20:20:47 <r1chardj0n3s> yes
20:20:48 <mrunge> and another thing is: unicode issues
20:20:59 <r1chardj0n3s> but the fix is against d-o-a
20:21:01 <mrunge> but r1chardj0n3s first
20:21:09 <david-lyle> r1chardj0n3s: even following you instructions I was unable to repro that
20:21:11 <TravT> yeah, i've hit that one quite a bit.
20:21:17 <robcresswell> I've hit that one a lot
20:21:19 <david-lyle> what backend?
20:21:29 <r1chardj0n3s> david-lyle: oh? huh, I can reliably do it
20:21:30 <tsufiev> and people around me complained about integer issue
20:21:52 <r1chardj0n3s> david-lyle: session backend?
20:22:00 <david-lyle> r1chardj0n3s: yes
20:22:04 <r1chardj0n3s> just the cookie one
20:22:06 <r1chardj0n3s> default
20:22:09 <TravT> yeah, same for me
20:22:16 <david-lyle> ok, I haven't used cookies in a while
20:22:19 <david-lyle> I'll try that
20:22:31 <r1chardj0n3s> it shouldn't matter though
20:22:33 <TravT> ootb devstack setup
20:22:34 <r1chardj0n3s> hm
20:22:40 <lhcheng> I'm using a db backend as well, maybe it is backend dependent
20:22:52 <david-lyle> lhcheng: have you repro'd it?
20:23:01 <lhcheng> I also can't reproduce the issue using the new instruction
20:23:07 <mrunge> I believe it's an issue with timed out keystone tokens
20:23:20 <r1chardj0n3s> no
20:23:22 <mrunge> so, set keystone tokens to be short lived,
20:23:25 <mrunge> no?
20:23:27 <r1chardj0n3s> I have actually debugged it and produced a fix
20:23:32 <r1chardj0n3s> it's all in the bug
20:23:36 <ducttape_> I think I have seen the login page getting stuck - it's when you are requesting the page /auth/login  specifically
20:23:41 <mrunge> will look at it tomorrow
20:23:53 <david-lyle> ok, will try again with cookies
20:23:55 <TravT> ducttape_: that sounds familiar
20:23:56 <david-lyle> and milk
20:24:03 <r1chardj0n3s> it's when django tries to re-use a session on login
20:24:16 <ducttape_> r1chardj0n3s : +1
20:24:28 <r1chardj0n3s> and it tries to int() the user id to compare, but d-o-a uses a string as the id which isn't int()able
20:24:37 <david-lyle> does it fail once or continuously?
20:24:49 <ducttape_> you get stuck on the login page for a while
20:24:53 * david-lyle is trying to determine if critical
20:24:58 <TravT> i have been getting around by manually typing in /auth/logout
20:25:00 <ducttape_> you eventually quit and reopen new browser, and stuff works
20:25:02 <r1chardj0n3s> if you log in as a different user from the same browser, it'll continue to fail
20:25:21 <r1chardj0n3s> ie. using the same session
20:25:27 <david-lyle> that definitely seems cookie based
20:25:30 <r1chardj0n3s> but a different user
20:25:32 <david-lyle> if it's tied to the browser
20:25:52 <ducttape_> your session is always tied to a cookie, even if the session backend is not cookie
20:25:56 <r1chardj0n3s> yes, but I'm confused as to why that'd be related to the session backend
20:26:01 <ducttape_> i.e. I think the problem is there no matter what
20:26:04 <r1chardj0n3s> what ducttape_ said
20:26:15 <TravT> r1chardj0n3s: your explanation sounds very plausible to me
20:26:24 <david-lyle> I will try harder to make horizon fail
20:26:28 <ducttape_> change your user permissions so keystone revokes your token, try that
20:26:36 <TravT> david-lyle: good luck
20:26:38 <r1chardj0n3s> david-lyle: that should be our next t-shirt motto
20:26:41 <david-lyle> rock solid
20:26:47 <TravT> "we try harder to fail"
20:26:54 <david-lyle> it's kinda my mission statement
20:26:59 <ducttape_> you really don't need to try so hard
20:27:13 <ducttape_> for some of us, it comes easily
20:27:28 <r1chardj0n3s> david-lyle: the reliable reproduction steps are in the first para of comment 5 on that bug
20:27:40 <r1chardj0n3s> https://bugs.launchpad.net/django-openstack-auth/+bug/1491117/comments/5 even
20:27:42 <openstack> Launchpad bug 1491117 in django-openstack-auth "Error when logging back in after timeout" [High,In progress] - Assigned to Richard Jones (r1chardj0n3s)
20:27:49 <david-lyle> r1chardj0n3s: I did try that
20:27:53 <lhcheng> tried that
20:27:53 <david-lyle> will try once again
20:27:54 <ducttape_> I think / recall keystone permission change will do it
20:27:55 <r1chardj0n3s> hmm
20:28:11 <r1chardj0n3s> I will look at changing my session backend (what do you both use?)
20:28:24 <david-lyle> I use LocMem or Memcache
20:28:34 <david-lyle> s/or/and
20:28:44 <r1chardj0n3s> LocMem is easier to set up, I'll try it :)
20:28:59 <ducttape_> Memcache or mysql, but I recall seeing it locally too
20:29:00 <lhcheng> Database
20:29:11 <david-lyle> anything but cookie
20:29:14 <david-lyle> :)
20:29:27 <r1chardj0n3s> oh! what *django* version are you using david-lyle, lhcheng?
20:29:36 <lhcheng> 1.8.3
20:29:42 <david-lyle> 1.8.3 I believe
20:29:45 <r1chardj0n3s> ok
20:29:55 <david-lyle> what d-o-a?
20:30:05 <r1chardj0n3s> (I'm pretty sure, though I've not verified, that it's a 1.8 thing)
20:30:14 <lhcheng> yeah, it is
20:30:20 <mrunge> +1 for 1.8 thing
20:30:23 <r1chardj0n3s> david-lyle: 1.4.0
20:30:24 <david-lyle> is your d-o-a 1.4.0 or greater?
20:30:27 <david-lyle> ok
20:30:34 <david-lyle> more numbers people
20:30:40 <mrunge> 15
20:30:47 <david-lyle> yes, that too
20:30:47 <r1chardj0n3s> 42
20:31:00 <mrunge> yikes
20:31:28 <david-lyle> mrunge: you had a different issue that was numerical?
20:31:32 <r1chardj0n3s> oh, david-lyle, make sure you don't *log out* to when testing
20:31:47 <mrunge> yes, r1chardj0n3s
20:31:50 <david-lyle> don't log out?
20:31:56 <r1chardj0n3s> so you 1) login in as admin, 2) hit the browser back button to get the login form again, 3) log in as demo
20:32:17 <mrunge> I remember having seen the same issue while testing/trying the AnonymousUser Repleacement stuff
20:32:24 <david-lyle> oh, ok, well not critical then, but I'll try that
20:32:37 <mrunge> and the issue occurred with session timeouts
20:32:58 <mrunge> i.e. browser tried to reuse the session, keystone token was invalid
20:32:58 <david-lyle> ok that's probably the different
20:33:03 <david-lyle> *difference
20:33:09 <mrunge> may be a different facet
20:33:10 <david-lyle> I always click logout
20:33:20 <mrunge> and it was a different code base
20:33:45 <robcresswell> I get the int error on timeouts I think, though I don't normally write down everything I do at all times
20:33:46 <mrunge> the issue was, user id seems to be numerical
20:34:02 <r1chardj0n3s> david-lyle: if you log out then the session is nuked, and this bug relies on attempted reuse of the session
20:34:14 <mrunge> or, in traditional django users, user ids are numerical
20:34:17 <david-lyle> mrunge: I thought you had an unicode issue
20:34:24 <david-lyle> not related
20:34:24 <mrunge> david-lyle, yes
20:34:28 <mrunge> right
20:34:34 <david-lyle> ok will reuse session for above
20:34:39 <david-lyle> mrunge unicode
20:34:42 <mrunge> I forgot the bug number
20:35:02 <mrunge> r1chardj0n3s, tsufiev and I were puzzling with unicode issues
20:35:03 <r1chardj0n3s> a great explanation of unicode, which anyone who feels even slightly mystified by it should watch/read, is  http://nedbatchelder.com/text/unipain.html
20:35:26 <tsufiev> r1chardj0n3s, nice url :)
20:35:27 <mrunge> kilo and ealier versions are broken, e.g if you're naming your instances using unicode characters
20:35:50 <r1chardj0n3s> ouch
20:36:01 <david-lyle> in horizon or underlying services?
20:36:11 <mrunge> uhm, horizon
20:36:13 <mrunge> https://launchpad.net/bugs/1488443
20:36:15 <openstack> Launchpad bug 1488443 in OpenStack Dashboard (Horizon) "Any action always cause error ( in kilo)" [High,In progress] - Assigned to Matthias Runge (mrunge)
20:36:19 <mrunge> that's just one bug
20:36:28 <mrunge> filters are defect as well
20:36:39 <mrunge> do not filter for instances with unicode names
20:36:51 <mrunge> you'll see a 500 server error
20:37:06 <mrunge> we already have a bug for this, too
20:37:11 <tsufiev> mrunge,  the funny thing about this stuff is that nobody yet complained :)
20:37:24 <mrunge> exactly tsufiev
20:38:23 <r1chardj0n3s> well, I work for a predominantly US company, so hence it's never been on my radar :(
20:38:23 <r1chardj0n3s> (see also probably most of the other people here)
20:38:23 <mrunge> wait, we had one french guy showing up on #openstack-horizon
20:38:24 <r1chardj0n3s> I'm more than happy to help sort this stuff out tho
20:38:24 <doug-fish> I thought instances names (and many other object names) were restricted to a limited character set by the services
20:38:24 <mrunge> r1chardj0n3s, help is more than welcome
20:38:48 <lhcheng> ++ there is a regex used for name validation
20:38:50 <doug-fish> yeah, I can help out as well
20:39:06 * tsufiev makes a note to add some unicode to the name generators in integration tests
20:39:21 <lhcheng> doug-fish: name validation done on the backend service, not just horizon
20:39:32 <mrunge> https://review.openstack.org/#/c/216712/ is far from perfect
20:39:52 <mrunge> but at least, it seems to fix the most urgent issues for users
20:40:01 <mrunge> I have gotten feedback, it solved their pain
20:40:25 <mrunge> tsufiev, made the comment, it's probably just the tip of the iceberg
20:40:30 <david-lyle> I targeted the bug for RC-1
20:40:41 <mrunge> nobody prevents you to create an instance from nova
20:40:52 <mrunge> and naming is free, afaik
20:41:23 * david-lyle mutters about API docs
20:41:52 <mrunge> the filter bug exploded down in nova, iirc
20:42:19 <mrunge> so, horizon failed, because nova api returned a server error
20:42:28 <mrunge> and a stack trace in database code
20:42:33 <mrunge> but I may be wrong here
20:42:45 <david-lyle> that seems like a nova bug
20:42:47 <doug-fish> I'm in favor of blaming nova
20:43:00 <mrunge> or keystone, or neutron
20:43:02 <david-lyle> one that we don't want to exercise, but an input parsing issue
20:43:03 <TravT> i'll second that
20:43:04 <r1chardj0n3s> david-lyle, lhcheng: I just confirmed reproduction of the login bug using the LocMemCache
20:43:19 <david-lyle> r1chardj0n3s: the no logout is probably the diff
20:43:24 <david-lyle> force of habit
20:43:25 <r1chardj0n3s> yup
20:43:30 <tsufiev> mrunge, filed a bug about unicode & tests https://bugs.launchpad.net/horizon/+bug/1493998
20:43:31 <openstack> Launchpad bug 1493998 in OpenStack Dashboard (Horizon) "Integration tests should use unicode characters in user-provided data" [Undecided,New]
20:43:33 <r1chardj0n3s> just wanted to double-check for my own sanity ;)
20:43:50 <mrunge> tsufiev, awesome, thank you
20:44:14 <david-lyle> ok unicode input testing added to the validation list :/
20:44:19 <david-lyle> that will be fun
20:44:31 <david-lyle> we do have an agenda
20:44:35 <r1chardj0n3s> I blame oslo_utils.encodeutils.safe_encode and all the laziness around it
20:44:41 <mrunge> ok, for reference, unicode filtering is https://bugs.launchpad.net/horizon/+bug/1472999
20:44:42 <openstack> Launchpad bug 1472999 in OpenStack Dashboard (Horizon) "filter doesn't handle unicode charaters" [High,In progress] - Assigned to Masco Kaliyamoorthy (masco)
20:45:17 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/Horizon
20:45:25 <david-lyle> mrunge: targeted for RC-1 as well
20:45:34 <mrunge> thank you david-lyle
20:45:57 <david-lyle> #topic Styling (SCSS) specific to individual Angular widgets (robcresswell)
20:46:00 <david-lyle> robcresswell: o/
20:46:46 <robcresswell> Sorry, my internet died
20:47:13 <robcresswell> Right, so this is more of a question than anything. I've seen a fair amount of styling be wrapped up in angular widgets
20:47:14 <ducttape_> using neutron, eh?
20:47:43 <robcresswell> Which seems like it would be a huge pain for people to maintain and customise, rather than using the stylesheets like we do currently.
20:48:03 <robcresswell> I was just curious what the plan was around that
20:48:06 <david-lyle> robcresswell: example?
20:48:08 <doug-fish> robcresswell: do you have an example ?
20:48:17 <david-lyle> or an example
20:48:23 <doug-fish> :-)
20:48:45 <robcresswell> https://github.com/openstack/horizon/blob/master/horizon/static/framework/widgets/transfer-table/transfer-table.scss
20:48:48 <robcresswell> Things like that
20:48:57 <tsufiev> robcresswell, could it be ruled out by linting?
20:49:09 <robcresswell> It seems like a lote of very specific tiny rules
20:49:12 <robcresswell> a lot*
20:49:25 <robcresswell> Rather than generalised styles that can be overridden for theming etc
20:49:49 <robcresswell> Just trying to not revert the bootstrap work that's going on.
20:49:50 <hurgleburgler> The rules just need to be adjusted to inherit from theme variables
20:49:53 <ducttape_> so the concern is that we have a lot of css, which cannot be themed ?
20:50:03 <hurgleburgler> I think it can be
20:50:17 <robcresswell> The concern is that rather than using the bootstrap variables and markup style, we're just using our own
20:50:21 <hurgleburgler> and the files are small enough that they'll just need a little reworking after they've stabilized
20:50:27 <david-lyle> robcresswell: the fact that most existing rules are in one file does not make the classes any less specific
20:51:13 <david-lyle> but yes, the css should be reusing the theme variables
20:51:34 <TravT> so, with the angular styling files, very early on, we wanted them to be as self contained as possible.  Maybe just theming variables need to be better enabled in them.
20:51:46 <david-lyle> TravT: yes, that's it
20:52:03 <david-lyle> the location doesn't matter in the grander theming discussion
20:52:06 <TravT> i mean each widget should really be a widget and not have random dependencies everywhere.
20:52:46 <robcresswell> It's not so much the file structure, just the very tiny specific rules for each bit, like very specific padding etc which isnt linked to a variable
20:53:00 <hurgleburgler> I think it will be pretty easy to address this in M
20:53:11 <david-lyle> I think everyone is in violent agreement then
20:53:14 <robcresswell> Cool. Well, thats that then :)
20:53:32 <david-lyle> problem kicked til M, another success story
20:53:34 <david-lyle> :(
20:53:40 <hurgleburgler> ٩(͡๏̮͡๏)۶
20:53:49 <david-lyle> #topic URL sanity for simpler navigation (nested resources are difficult) (robcresswell)
20:53:54 <david-lyle> robcresswell: o/
20:54:03 <robcresswell> Oh yeah. Man I had a lot of thoughts this week.
20:54:11 <robcresswell> Right so this pertains to a mail I sent out
20:54:18 <david-lyle> well, two weeks ago, this week was a little slower
20:54:23 <david-lyle> :P
20:54:30 <robcresswell> Specifically with nested resources
20:54:51 <tsufiev> robcresswell, does anybody look at the urls these days :)?
20:54:55 <TravT> rob, i drafted a response and didn't send it
20:55:02 <TravT> but you did have a question on urls
20:55:04 <TravT> with angular.
20:55:04 <robcresswell> haha, awesome
20:55:08 <TravT> https://review.openstack.org/#/c/173885/92/openstack_dashboard/static/app/core/images/images.module.js
20:55:16 <TravT> look at line 57
20:55:21 <robcresswell> So its not about URLs being pretty, but that it will let us have easy breadcrumb nav
20:55:31 <TravT> but we can achieve similar routing
20:55:44 <TravT> that patches provides angular routing for the ng images table.
20:56:01 <TravT> so, you don't require server round trips to go from table to details page and back
20:56:08 <TravT> as in django templating round trips
20:56:14 <TravT> just rest api calls.
20:56:28 <TravT> but the net result is you still get a similar url as django
20:57:05 <robcresswell> So one of the things thats specifically odd, is that we often append /details to details pages urls, when it should just be <object>/id etc
20:58:07 <robcresswell> The question is: is it worthwhile/ agreeable to change urls to things like network/id/port/id etc
20:58:14 <robcresswell> instead of networks/ports/id/details
20:58:30 <TravT> my question is, is it worth the effort?
20:58:31 <robcresswell> So that we can use tqtran breadcrumb patch so we have better nav across the python content we currently have
20:58:32 <ducttape_> seems like very low importance to me
20:58:41 <david-lyle> I'm highly reluctant to move existing URLs around
20:58:59 <david-lyle> cost/benefit plus side-effects
20:58:59 <robcresswell> Thats pretty much the question. I havent done much work on it, just a little investigation
20:59:12 <robcresswell> So wondered what opinions were.
20:59:29 <robcresswell> Sounds like its high risk/ low value... a real winner :p
20:59:38 <ducttape_> so the best case, would be that things work exactly the same, except the urls will be a bit more pleasant to those paying attention?
20:59:51 <robcresswell> No, the URL things not the important part
21:00:03 <tqtran> no, benefit is, it will enable breadcrumb to be more consistent
21:00:11 <robcresswell> its dropping the breadcrumbs in to give a logical structuring to "where the user is"
21:00:40 <robcresswell> if you go to the port details page for example, there's no real UI indication of where that is
21:00:47 <robcresswell> And what its meaning is
21:01:01 <ducttape_> yep, agreed.  some pages have a rough concept of breadcrumbs
21:01:02 <robcresswell> Especially if you're linked from outside, so your history doesnt go back to the networks page
21:01:22 <doug-fish> I assume we're talking about this potentially in mitaka, right?
21:01:29 <robcresswell> Absolutely
21:01:35 <doug-fish> just checking.  :-)
21:01:38 <TravT> robcresswell: any mocks up on it?
21:01:59 <robcresswell> Only the ones I was showign the other week, nothing on invision
21:02:19 <robcresswell> Will put some up.
21:02:28 <ducttape_> I'd say you can add the bread crumb stuff where it makes sense, and go at if that way - this way you are not trying to boil the ocean.  would that be more beneficial ?
21:02:30 <doug-fish> I assume the risks of changing URLs is that we'll have to change tests in parallel?
21:02:52 <robcresswell> ducttape_: I tried that, for the details pages, but it got booed
21:02:54 <david-lyle> we've run out of time. Please review critical/high bug patches and FFE code. Addressing bugs is the top priority. Also new tests and docs are allowed up to RC1 without FFE. Thanks everyone.
21:02:57 <david-lyle> #endmeeting