16:00:24 #startmeeting Horizon 16:00:24 Meeting started Tue Oct 21 16:00:24 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:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:27 The meeting name has been set to 'horizon' 16:00:33 Hello everyone 16:00:38 hello \o 16:00:39 hello o/ 16:00:42 gm 16:00:42 Hi 16:00:43 hi 16:00:48 hello 16:00:53 hey everyone 16:00:54 hi 16:00:57 hi 16:01:00 Hi 16:01:07 hey 16:01:10 hello 16:01:20 Hello 16:01:26 hiya 16:01:35 hello 16:01:50 Hello 16:01:57 hello 16:02:19 Juno final release was on October 16 16:02:26 hi 16:02:29 hi 16:02:29 Congrats to everyone 16:02:48 Hooray! 16:02:53 Wow!!! 16:03:00 o/ 16:03:01 Thanks for all your hard work everyone 16:03:04 o/ 16:03:04 yay! 16:03:28 There were 166 contributors to Horizon in Juno 16:03:29 hi 16:03:48 This is a large jump from ~126 in Havana 16:03:50 thanks to all the contributors! you rock! 16:04:00 nice! 16:04:04 awesome 16:04:08 Great!!! 16:05:07 The agenda for today's meeting is at: #link https://wiki.openstack.org/wiki/Meetings/Horizon 16:05:24 #topic Move to DB backed sessions by default (david-lyle) 16:06:13 So we had a long discussion on IRC regarding this topic last week, but I wanted to bring it up here for greater visibility before bringing to the ML 16:06:38 We continually run into issues with overflowing the cookie size for session storage 16:06:51 david-lyle, I'm aware of the 4K-limit problem, but how do we provide HA with DB-backed sessions? 16:07:01 This is a limiting factor 16:07:30 tsufiev, for HA it requires the deployer to implement a fix as they would for other services 16:07:52 a fix? 16:08:00 either point at a common MySQL instance 16:08:10 (or db of choice) 16:08:19 doug-fish, I guess something like Galera for MySQL HA 16:08:25 fix is not the correct word, solution is better 16:08:39 got it. That makes sense. It has to be configured. 16:08:43 No patching required. 16:08:50 doug-fish, yes 16:08:51 tsufiev: Galera might be an overkill though. 16:09:01 or you can hobble along with cookies if you monkey patch saving that allowed stuff in the session 16:09:42 david-lyle, lhcheng: I know our deploy engineers have been using Memcache + cache-backed sessions 16:09:45 horizon deployments will need an HA DB setup for this, if we move to dbs 16:09:45 why are we using DB as the default over memcached? 16:09:50 making a db session store the default does not prohibit the use of signed cookies, it just changes the default 16:09:52 Not sure what was discussed previously, but can we use HTML 5 webstorage instead of cookies? 16:10:09 * jrist thinks that isn't widely supported 16:10:10 memcached is not the session backend 16:10:18 can be 16:10:24 it can be 16:10:33 asahlin_, I'd also suggest using webStorage, but it requires much more changes (IMO) 16:10:33 We can also use HTML 5 local storage and it is supported all major browsers 16:10:35 I'm not partial to a DB or memcached 16:10:42 both require some config work 16:10:44 and if you do memcached, how is that HA'd ? 16:10:52 memcached will eat more memory 16:11:00 for sure 16:11:09 I don't think memcached works for session storage, it serves another function if I recall 16:11:37 ericpeterson, you can use it for session storage, and other things 16:12:00 https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-sessions 16:12:02 Our own docs suggest that memcache isn't ideal for HA fwiw -> http://docs.openstack.org/developer/horizon/topics/deployment.html#memcached 16:12:11 tsufiev: not sure what the scope of change would be, but should be considered as an alternative.. It doesn't suffer from the same limitations as cookies. 16:12:22 https://docs.djangoproject.com/en/1.7/topics/http/sessions/#using-cached-sessions 16:12:32 I think you have up to 5 mb of space vs 4kb 16:12:51 asahlin_ I think part of the issue is that the stuff we put in the session is needed at the server 16:12:55 like tokens 16:13:15 We can offer recommendations for HA, but it's not up to the Horizon team to implement an HA solution 16:13:30 the choice of session store is pluggable today 16:13:30 doug-fish: I see. 16:13:52 operators can and do choose to move away from signed cookies already 16:14:10 david-lyle: is this a step toward deprecating the signed cookie backend? 16:14:12 well, I'm bit ashamed, but I've just questioned our deploys and it seems they use Memcached just because it's already there, while DB sessions require additional tuning :) 16:14:43 indeed, DB is more persistent and reliable than Memcache 16:14:52 what I would like to move to is not overrunning the cookie size limit 16:15:03 in the default 16:15:05 david-lyle, are we even considering file-based too? just to simplify devstack setup. 16:15:08 i think there are important and non-important cookies. can we distinguish and prioritize important ones? non-important ones are just for performance. 16:15:22 I am not sure we can though... 16:15:30 doug-fish: as we move towards more dynamic views with js (that is obligatory now), we can send the information that is needed on the server explicitly, so it's all doable, just lots of work 16:15:44 doug-fish: and lots of per-case decissions 16:15:50 there is a sqllite file based db thing I think is a leading candidate for devstack type setup 16:16:03 with that we could solve problems like being able to hold more than one token at a time which will be required for domain scoped tokens and to solve real operator problems like havign to relogin for every keystone region they want to manage 16:16:04 the default before in devstack was file-based, can't recall why we moved to cookie-based. 16:16:21 david-lyle: I guess I'm thinking that if cookie based isn't the default we'll probably break it pretty quickly 16:16:21 ericpeterson: with multiple instances we want the sessions synchornized, which rules out sqlite :( 16:16:27 i think the cookie thing is slightly more simple to setup 16:16:54 doug-fish, I think we're going to break it even if it is the default 16:16:54 rdopieralski: this is defaulting for devstack, no HA support 16:16:56 :) 16:17:01 rdopieralski: I agree, as soon as you deploy horizon for real you will need to make other choices 16:17:21 david-lyle, I remember using db-backed sessions in muranodashboard plugin, it made editing default openstack_dashboard.settings a bit more complex - had to add DATABASES settings in the beginning of settings to avoid `import policy` clause set it to DummyDatabase (or something like) 16:17:38 david-lyle: agreed. I'm wondering if we should be explicit and call it unsupported. 16:17:48 besides that everything worked fine 16:18:03 cookies could still work if you have one region and only use swift ;) 16:18:08 lol 16:18:37 until you use keystone v3 and have a domain scoped PKIZ token and a project scoped PKIZ token 16:18:58 * ericpeterson is getting a headache thinking about that 16:19:09 you're welcome 16:19:25 one thing I like about horizon, I don't need to setup a real database to get it running for development. - why I like the file-based for default. We already documented that for production user should use a DB anyway. 16:19:56 so the choices for a default are signed cookies, memcached, sqlite, mysql 16:20:00 so we move to file db type thing for the default? or we could require the cache / memcached thing? 16:20:01 lhcheng: Is that recommendation actually documented somewhere? 16:20:11 am I missing anything? 16:20:33 jpich: yeah, I was just reading the cloud admin guide for openstack last night. Let me pull it up. 16:20:39 signed cookies are a problem, I'd say it's between the cache and file db options 16:21:16 I've never used the file-based sessions, but that seems like it might be a nice default for development. 16:21:29 maybe if we only stored the 1's in the cookie that would make it smaller ;) 16:21:32 * ericpeterson ducks 16:21:34 lhcheng: I see, thank you. If only we had some kind of docs liaison to keep up with that kind of thing 16:22:00 jpich: http://docs.openstack.org/admin-guide-cloud/admin-guide-cloud.pdf page 53 16:22:07 ericpeterson: +1 16:22:31 jpich: are you nominating lhcheng ? 16:22:39 * lhcheng ducks 16:22:48 in he isn't careful, it's going to be his job 16:22:52 surely there's a goose among all these ducks 16:22:54 well apparently he can read 16:23:10 I can confirm that sqlite is awesome :) 16:23:15 david-lyle: sound overqualified 16:23:21 +1 for sqlite 16:23:31 sqlite is the django default as of 1.6 IIUC 16:23:54 +1.3456 for sqllite 16:24:13 is that an additional install requirement for devstack or does django pull it in automatically? 16:24:18 anyone know? 16:24:30 I think it just works, no additional stuff needed 16:24:39 can we potentially use sqlite for other things that horizon might need in the future? like persisting user settings? 16:24:40 david-lyle: sqlite? 16:24:49 sqlite is shipped by default with all modern pythons 16:25:01 (2.5+ iirc) 16:25:04 ok, just wanted to make sure 16:25:19 not a new dependency 16:25:21 Yes for sqlite no seprate installation is required 16:25:26 tqtran: we'll want to be sure we are using the configured db, not hardcoding to sqlite 16:25:41 doug-fish, it's all in the settings.py 16:25:41 tqtran: some companies use other DBs you know 16:25:46 ha 16:25:53 backend db is configurable 16:25:54 yep 16:25:57 tqtran: we can do that, would need to use the django orm stuff for that 16:26:15 some operators do not want to setup extra databases, so sqlite is attracitve for them. sqlite is just like a file. 16:26:17 ok, didnt know django had orm stuff 16:26:27 ok, any objections to sqlite as the new default? 16:26:44 I'd like to object in next weeks meeting 16:26:53 lol 16:27:01 tqtran, the funny part is that's one of the the best parts of django 16:27:09 which we cast aside 16:27:13 for the cfuft 16:27:18 cruft* 16:27:22 But to my knowlege sqlite doesn't uses ORM but for django we uses ORM 16:28:03 ok, I'll go ahead with a ML post about the intended switch to sqlite 16:28:12 sqlite has some limitations but if we're using it as a simple cookie store and don't intend to rely on real database features, we should be fine 16:28:34 yep, that should keep us honest from using too exotic of an ORM feature 16:28:37 in short, I'd recommend reading up on sqlite's limitations just to make sure we won't accidentally bump into them 16:28:53 what could go wrong? 16:28:55 :) 16:29:21 for a session store, I think we'll be fine 16:29:32 lol 16:29:35 for other items, we'll need to look more 16:29:39 Old browser warning message (nikunj2512) 16:29:40 yeah, I don't forsee any issues either frankly, just want everyone's consent to be informed =P 16:29:59 #topic Old browser warning message (nikunj2512) 16:30:14 nikunj2512, 16:30:17 Yes 16:30:22 Let me start 16:31:02 As we know Horizon many features break when end user uses old browsers like IE6 to IE8 and older chrome and firefox 16:31:34 As We can see from the Horizon bugs a lot of issues has been raised on browser compability 16:31:49 And they are raised because Users are using older browsers 16:32:18 I think many of these issues can be handled by just showing a friendly warning message on the login page only once 16:32:59 It can tell user that some features of Horizon will not work with current version of the browser and they should upgrade it 16:33:33 And a link to the browser support matrix where they see which browsers we support and what minimum version we support 16:33:43 It seems worthwhile to me for old browsers (e.g. IE8) that we know are broken and don't support, as long we don't block the user from login in anyway 16:33:50 nikunj2512: make sense to me, only question is, whether browser detection should happen front-end or back-end 16:34:15 makes sense to me too. I wonder how we can warn older versions of chrome and firefix because they are update automatically. 16:34:31 tqtran: We discussed about parsing the User-Agent String but people told it will be hard to do that 16:34:50 If people actually updated the support matrix too that'd be awesome :) It's not very up to date currently ( update it update it -> https://wiki.openstack.org/wiki/Horizon/BrowserSupport :-)) 16:35:09 amotoki: Chrome update automatically but not firefox, it asks for permission and user may choose to decline the upgrade 16:35:40 I think part of the challenge of implementing a check is that I don't think we've been very crisp about what browser levels we actually support. 16:35:47 What levels would you check for? 16:35:48 jpich: Yes, this covers updating the browser support matrix also :) 16:35:56 nikunj2512: yes, it is true, but most folks update it and distro like debian supports updated version of firefox. 16:36:04 doug-fish: i think we have this documented some time ago.... 16:36:21 amotoki: actually stable debian right now is on firefox 24 or so 16:36:26 doug-fish: cant remember though, but we have stated official versions we support 16:36:40 (meanwhile a "current" firefox is 33.0) 16:36:41 tqtran: Ok 16:36:46 sigmavirus24: yes. they provides two versions. 16:37:04 maybe the supported browser version should be something checked in which detection reads and also that docs can be generated from. 16:37:24 See for the firefox we can mention the minimum version against which everything works and perform the check 16:38:01 TravT: agree, that would save a lot of confusion 16:38:20 nikunj2512: do we know the minimum version of firefox against which everything works? 16:38:30 nikunj2512, yes having a base chrome and firefox version is necessary 16:38:33 i think we have to maintain a whitelist which will contain the minimum browser version we support 16:38:34 how about the latest version and some versions shipped with major distros? we can know the minimum version. 16:39:10 we can get the specific version from distros (or windows). 16:39:13 I think we just need to establish a minimum across the browsers and work from there 16:39:29 doug-fish: for firefox from 28 or greater everything works 16:39:34 david-lyle: I agree 16:39:40 I think we should only blacklist known bad versions for now (blacklist == "show message"), rather than whitelist versions and show the message to everyone else - that was the crux of the argument on IRC earlier today 16:39:47 one of the cruxes anyhow... 16:39:50 david-lyle: yes 16:40:51 jpich: Yes that can also work and You right about earlier discussion 16:40:53 jpich +1 to the blacklist 16:41:00 Taking a step back... assuming our document for what version of browsers are supported is up to date, isn't that enough? If users hit issues on previous version (unsupported), they know they have to update? 16:41:05 jpich: +1 16:41:07 it's a much simpler matrix 16:41:23 trying to think of other web applications that warn 16:41:24 asahlin_: actually, they might not know unless the message is there 16:42:04 jpich, in the message, can we also add link to the page of supported versions? 16:42:08 asahlin_: End-users hardly goes to browser support matrix. They will not go there until they will face any problem and then also they will have to struggle sometime. It will be good if we can notify in advance 16:42:24 tqtran: Correct 16:42:26 asahlin_: right, they might not even know about the page (like me) 16:42:31 So they report a bug, we point to documentation with the browser matrix 16:42:32 asahlin_: if i'm at a website and everything works but one small thing, I"m going to blame the website first. I think the point of this is to try get users to self-correct. They aren't going to go search the wiki. 16:42:33 google 16:43:00 I am not saying the message is a bad idea.. 16:43:01 gugl3: Yes, we will add the link to the browser support matrix page 16:43:03 Would we not show a message on login screen if browser is not on white list? 16:43:05 I think the message is fine, only users running antiquated browsers will run into issues and see a message, everyone else will have the same experience they do now 16:43:32 asahlin_, if everyone would be so clever, let-me-google-it-for-you site would have never appeared :) 16:43:47 Apart from versions, I think we need to define a set of support browsers: Chrome, Firefox, Safari, IE?I 16:43:48 asahlin_ are you asking if whitelist-based message is enough, so don't need blacklist? 16:43:50 asahlin_: Isn't it better if user get the info from us rather than going to google and searching for it. I think that will be much faster 16:43:54 If we're doing browser detection, should we also warn users about vulnerabilities that may affect their connection to horizon, e.g., poodle? 16:44:01 Opera? 16:44:24 amotoki: yes opera, safari 16:44:28 Insetead of browser detection, what about feature detection and alerts? 16:44:44 * TravT wishes we could just deprecate IE all together 16:44:46 sigmavirus24: i don't think so 16:44:46 mfer: that would require much more work 16:44:52 nikunj2512: and why not? 16:44:53 TravT: Same here 16:45:10 Hate to do this, but I need to move on to summit stuff because I need to hash the schedule out soon 16:45:18 do we need to specify platform? I'd guess we have issues with some screens not working on ios. 16:45:25 rbertram: was more trying toto think of what the norm is for web applications.. Do they warn if your browser is old / not supported etc.. 16:45:27 tqtran feature detection is one of the go toos now 16:45:30 #topic Summit Session Selection (david-lyle) 16:45:31 i'm happy to talk about it offline 16:45:43 I think doing it step by step is fine, let's start with a message for deprecation and move on to more goodies later on if required 16:45:50 we can continue the previous conv in another forum 16:45:52 Ok, summit so :-) 16:46:06 #link https://etherpad.openstack.org/p/horizon-kilo-summit 16:46:13 I need your votes people 16:46:26 or discussion about why there are few votes 16:46:33 mfer: yes feature detection is good but implementing feature detection for every feature in hoizon which is breaking in order browser will be a huge change and will cause a bigger mess 16:46:41 or I'll randomly pick topics that make me happy 16:46:54 david-lyle: OK 16:46:56 do you want only summit participants to vote? or should non-participants vote for things they hope will be discussed? 16:47:07 one involves a gin sampling session 16:47:28 * TravT thinks wine sampling would be more appropriate in France 16:47:35 +1 16:47:39 doug-fish, anyone can vote on a topic they would like to have a more concrete plan around 16:47:42 lol )) 16:47:48 TravT, makes ME happy 16:47:55 +1 to gin sampling 16:47:55 :) 16:48:20 +1 to sampling )) 16:48:30 and how many +1s shall we give out? 16:48:36 I am going to make sure there is a session that centers on keystone topics coming up in Kilo 16:48:37 I guess many topics are one line, rather than a description 16:48:43 there are several 16:48:48 doug-fish: as many as possible :) 16:48:49 so it's hard to know if it's a thought or what the session will attempt to resolve 16:49:07 jpich, so let's grow the topic description 16:49:09 nikunj2512: haha! Chicago style voting it is! 16:49:19 vote early and vote often. 16:49:29 chicago style... haha never heard of that term 16:49:32 some of those were placeholders I put in initially 16:49:42 doug-fish: :) 16:49:47 may be why they're sparse 16:50:33 I vote for david-lyle to speak for all sessions 16:50:49 * david-lyle starts gin sampling now 16:50:58 and he better keep it entertaining 16:50:59 doug-fish: see also New Jersey style 16:51:06 we have 6 slots for session and half day(?) contributors meetup. Allocated sessions can get attracted for other folks. I think this is the difference. 16:51:19 how do you plan to do the contributors meetup? 16:51:44 totally informal? or have some agenda planned on site (like lightning sessions) 16:52:02 I believe the only session we've scheduled goes into the "contributors meetup" aka the unscheduled session :) 16:52:21 TravT depends on demand 16:52:46 my original thought was it would be a good time for clientside discussion, but that may not be the best fit 16:52:49 sigmavirus24, do you mean 'worse is better'? 16:53:05 tsufiev: ? 16:53:28 sigmavirus24: I'm guessing a reference to New Jersey 16:53:30 sigmavirus24, http://en.wikipedia.org/wiki/Worse_is_better 16:54:32 Hah. I hadn't heard of that. I was talking about NJ style politics (aka parlor tricks) 16:54:38 In neutorn case, we are thinking to allocate scheduled sessions to community topics related to the whole neutron and planning to allocate contributors meetups to specific topics to L2/L3/LB/FW. 16:55:02 It is not decided yet and just an example. 16:58:52 ok, a lot more input now, keep it coming 16:59:02 I'll take a first pass this week sometime 16:59:16 preferences for unscheduled content? 17:00:07 We're out of time everyone. Thanks! 17:00:12 #endmeeting Horizon