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