16:00:24 <david-lyle> #startmeeting Horizon
16:00:24 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <openstack> The meeting name has been set to 'horizon'
16:00:33 <david-lyle> Hello everyone
16:00:38 <akrivoka> hello \o
16:00:39 <tmazur> hello o/
16:00:42 <tqtran> gm
16:00:42 <doug-fish> Hi
16:00:43 <gary-smith> hi
16:00:48 <lhcheng> hello
16:00:53 <sigmavirus24> hey everyone
16:00:54 <EmilyW> hi
16:00:57 <TravT> hi
16:01:00 <bpokorny> Hi
16:01:07 <jpich> hey
16:01:10 <crobertsrh> hello
16:01:20 <jgravel_> Hello
16:01:26 <tzumainn> hiya
16:01:35 <ericpeterson> hello
16:01:50 <nikunj2512> Hello
16:01:57 <amotoki> hello
16:02:19 <david-lyle> Juno final release was on October 16
16:02:26 <rdopieralski> hi
16:02:29 <tsufiev> hi
16:02:29 <david-lyle> Congrats to everyone
16:02:48 <doug-fish> Hooray!
16:02:53 <nikunj2512> Wow!!!
16:03:00 <jrist> o/
16:03:01 <david-lyle> Thanks for all your hard work everyone
16:03:04 <amotoki> o/
16:03:04 <esp> yay!
16:03:28 <david-lyle> There were 166 contributors to Horizon in Juno
16:03:29 <gugl3> hi
16:03:48 <david-lyle> This is a large jump from ~126 in Havana
16:03:50 <akrivoka> thanks to all the contributors! you rock!
16:04:00 <lhcheng> nice!
16:04:04 <johnma> awesome
16:04:08 <nikunj2512> Great!!!
16:05:07 <david-lyle> The agenda for today's meeting is at: #link https://wiki.openstack.org/wiki/Meetings/Horizon
16:05:24 <david-lyle> #topic Move to DB backed sessions by default (david-lyle)
16:06:13 <david-lyle> 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 <david-lyle> We continually run into issues with overflowing the cookie size for session storage
16:06:51 <tsufiev> david-lyle, I'm aware of the 4K-limit problem, but how do we provide HA with DB-backed sessions?
16:07:01 <david-lyle> This is a limiting factor
16:07:30 <david-lyle> tsufiev, for HA it requires the deployer to implement a fix as they would for other services
16:07:52 <doug-fish> a fix?
16:08:00 <david-lyle> either point at a common MySQL instance
16:08:10 <ericpeterson> (or db of choice)
16:08:19 <tsufiev> doug-fish, I guess something like Galera for MySQL HA
16:08:25 <david-lyle> fix is not the correct word, solution is better
16:08:39 <doug-fish> got it.  That makes sense.  It has to be configured.
16:08:43 <doug-fish> No patching required.
16:08:50 <david-lyle> doug-fish, yes
16:08:51 <lhcheng> tsufiev: Galera might be an overkill though.
16:09:01 <ericpeterson> or you can hobble along with cookies if you monkey patch saving that allowed stuff in the session
16:09:42 <tsufiev> david-lyle, lhcheng: I know our deploy engineers have been using Memcache + cache-backed sessions
16:09:45 <ericpeterson> horizon deployments will need an HA DB setup for this, if we move to dbs
16:09:45 <doug-fish> why are we using DB as the default over memcached?
16:09:50 <david-lyle> making a db session store the default does not prohibit the use of signed cookies, it just changes the default
16:09:52 <asahlin_> 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 <ericpeterson> memcached is not the session backend
16:10:18 <doug-fish> can be
16:10:24 <david-lyle> it can be
16:10:33 <tsufiev> asahlin_, I'd also suggest using webStorage, but it requires much more changes (IMO)
16:10:33 <nikunj2512> We can also use HTML 5 local storage and it is supported all major browsers
16:10:35 <david-lyle> I'm not partial to a DB or memcached
16:10:42 <david-lyle> both require some config work
16:10:44 <ericpeterson> and if you do memcached, how is that HA'd ?
16:10:52 <david-lyle> memcached will eat more memory
16:11:00 <doug-fish> for sure
16:11:09 <ericpeterson> I don't think memcached works for session storage, it serves another function if I recall
16:11:37 <david-lyle> ericpeterson, you can use it for session storage, and other things
16:12:00 <doug-fish> https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-sessions
16:12:02 <jpich> 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 <asahlin_> 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 <david-lyle> https://docs.djangoproject.com/en/1.7/topics/http/sessions/#using-cached-sessions
16:12:32 <asahlin_> I think you have up to 5 mb of space vs 4kb
16:12:51 <doug-fish> asahlin_ I think part of the issue is that the stuff we put in the session is needed at the server
16:12:55 <doug-fish> like tokens
16:13:15 <david-lyle> We can offer recommendations for HA, but it's not up to the Horizon team to implement an HA solution
16:13:30 <david-lyle> the choice of session store is pluggable today
16:13:30 <asahlin_> doug-fish: I see.
16:13:52 <david-lyle> operators can and do choose to move away from signed cookies already
16:14:10 <doug-fish> david-lyle: is this a step toward deprecating the signed cookie backend?
16:14:12 <tsufiev> 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 <tsufiev> indeed, DB is more persistent and reliable than Memcache
16:14:52 <david-lyle> what I would like to move to is not overrunning the cookie size limit
16:15:03 <david-lyle> in the default
16:15:05 <lhcheng> david-lyle, are we even considering file-based too? just to simplify devstack setup.
16:15:08 <amotoki> 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 <amotoki> I am not sure we can though...
16:15:30 <rdopieralski> 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 <rdopieralski> doug-fish: and lots of per-case decissions
16:15:50 <ericpeterson> there is a sqllite file based db thing I think is a leading candidate for devstack type setup
16:16:03 <david-lyle> 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 <lhcheng> the default before in devstack was file-based, can't recall why we moved to cookie-based.
16:16:21 <doug-fish> 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 <rdopieralski> ericpeterson: with multiple instances we want the sessions synchornized, which rules out sqlite :(
16:16:27 <ericpeterson> i think the cookie thing is slightly more simple to setup
16:16:54 <david-lyle> doug-fish, I think we're going to break it even if it is the default
16:16:54 <lhcheng> rdopieralski: this is defaulting for devstack, no HA support
16:16:56 <david-lyle> :)
16:17:01 <ericpeterson> rdopieralski: I agree, as soon as you deploy horizon for real you will need to make other choices
16:17:21 <tsufiev> 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 <doug-fish> david-lyle:  agreed.  I'm wondering if we should be explicit and call it unsupported.
16:17:48 <tsufiev> besides that everything worked fine
16:18:03 <ericpeterson> cookies could still work if you have one region and only use swift ;)
16:18:08 <doug-fish> lol
16:18:37 <david-lyle> 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 <david-lyle> you're welcome
16:19:25 <lhcheng> 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 <david-lyle> so the choices for a default are signed cookies, memcached, sqlite, mysql
16:20:00 <ericpeterson> so we move to file db type thing for the default?  or we could require the cache / memcached thing?
16:20:01 <jpich> lhcheng: Is that recommendation actually documented somewhere?
16:20:11 <david-lyle> am I missing anything?
16:20:33 <lhcheng> jpich: yeah, I was just reading the cloud admin guide for openstack last night.  Let me pull it up.
16:20:39 <ericpeterson> signed cookies are a problem, I'd say it's between the cache and file db options
16:21:16 <doug-fish> I've never used the file-based sessions, but that seems like it might be a nice default for development.
16:21:29 <ericpeterson> maybe if we only stored the 1's in the cookie that would make it smaller ;)
16:21:32 * ericpeterson ducks
16:21:34 <jpich> 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 <lhcheng> jpich: http://docs.openstack.org/admin-guide-cloud/admin-guide-cloud.pdf page 53
16:22:07 <sigmavirus24> ericpeterson: +1
16:22:31 <sigmavirus24> jpich: are you nominating lhcheng ?
16:22:39 * lhcheng ducks
16:22:48 <ericpeterson> in he isn't careful, it's going to be his job
16:22:52 <tzumainn> surely there's a goose among all these ducks
16:22:54 <david-lyle> well apparently he can read
16:23:10 <rdopieralski> I can confirm that sqlite is awesome :)
16:23:15 <sigmavirus24> david-lyle: sound overqualified
16:23:21 <tsufiev> +1 for sqlite
16:23:31 <david-lyle> sqlite is the django default as of 1.6 IIUC
16:23:54 <ericpeterson> +1.3456 for sqllite
16:24:13 <david-lyle> is that an additional install requirement for devstack or does django pull it in automatically?
16:24:18 <david-lyle> anyone know?
16:24:30 <ericpeterson> I think it just works, no additional stuff needed
16:24:39 <tqtran> can we potentially use sqlite for other things that horizon might need in the future? like persisting user settings?
16:24:40 <sigmavirus24> david-lyle: sqlite?
16:24:49 <sigmavirus24> sqlite is shipped by default with all modern pythons
16:25:01 <sigmavirus24> (2.5+ iirc)
16:25:04 <david-lyle> ok, just wanted to make sure
16:25:19 <david-lyle> not a new dependency
16:25:21 <nikunj2512> Yes for sqlite no seprate installation is required
16:25:26 <doug-fish> tqtran:  we'll want to be sure we are using the configured db, not hardcoding to sqlite
16:25:41 <david-lyle> doug-fish, it's all in the settings.py
16:25:41 <doug-fish> tqtran:   some companies use other DBs you know
16:25:46 <jrist> ha
16:25:53 <david-lyle> backend db is configurable
16:25:54 <doug-fish> yep
16:25:57 <ericpeterson> tqtran: we can do that, would need to use the django orm stuff for that
16:26:15 <amotoki> some operators do not want to setup extra databases, so sqlite is attracitve for them. sqlite is just like a file.
16:26:17 <tqtran> ok, didnt know django had orm stuff
16:26:27 <david-lyle> ok, any objections to sqlite as the new default?
16:26:44 <ericpeterson> I'd like to object in next weeks meeting
16:26:53 <tqtran> lol
16:27:01 <david-lyle> tqtran, the funny part is that's one of the the best parts of django
16:27:09 <david-lyle> which we cast aside
16:27:13 <david-lyle> for the cfuft
16:27:18 <david-lyle> cruft*
16:27:22 <nikunj2512> But to my knowlege sqlite doesn't uses ORM but for django we uses ORM
16:28:03 <david-lyle> ok, I'll go ahead with a ML post about the intended switch to sqlite
16:28:12 <sigmavirus24> 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 <ericpeterson> yep, that should keep us honest from using too exotic of an ORM feature
16:28:37 <sigmavirus24> 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 <david-lyle> what could go wrong?
16:28:55 <david-lyle> :)
16:29:21 <david-lyle> for a session store, I think we'll be fine
16:29:32 <jrist> lol
16:29:35 <david-lyle> for other items, we'll need to look more
16:29:39 <david-lyle> Old browser warning message (nikunj2512)
16:29:40 <sigmavirus24> yeah, I don't forsee any issues either frankly, just want everyone's consent to be informed =P
16:29:59 <david-lyle> #topic  Old browser warning message (nikunj2512)
16:30:14 <david-lyle> nikunj2512,
16:30:17 <nikunj2512> Yes
16:30:22 <nikunj2512> Let me start
16:31:02 <nikunj2512> 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 <nikunj2512> As We can see from the Horizon bugs a lot of issues has been raised on browser compability
16:31:49 <nikunj2512> And they are raised because Users are using older browsers
16:32:18 <nikunj2512> 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 <nikunj2512> 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 <nikunj2512> And a link to the browser support matrix where they see which browsers we support and what minimum version we support
16:33:43 <jpich> 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 <tqtran> nikunj2512: make sense to me, only question is, whether browser detection should happen front-end or back-end
16:34:15 <amotoki> 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 <nikunj2512> tqtran: We discussed about parsing the User-Agent String but people told it will be hard to do that
16:34:50 <jpich> 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 <nikunj2512> amotoki: Chrome update automatically but not firefox, it asks for permission and user may choose to decline the upgrade
16:35:40 <doug-fish> 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 <doug-fish> What levels would you check for?
16:35:48 <nikunj2512> jpich: Yes, this covers updating the browser support matrix also :)
16:35:56 <amotoki> nikunj2512: yes, it is true, but most folks update it and distro like debian supports updated version of firefox.
16:36:04 <tqtran> doug-fish: i think we have this documented some time ago....
16:36:21 <sigmavirus24> amotoki: actually stable debian right now is on firefox 24 or so
16:36:26 <tqtran> doug-fish: cant remember though, but we have stated official versions we support
16:36:40 <sigmavirus24> (meanwhile a "current" firefox is 33.0)
16:36:41 <nikunj2512> tqtran: Ok
16:36:46 <amotoki> sigmavirus24: yes. they provides two versions.
16:37:04 <TravT> maybe the supported browser version should be something checked in which detection reads and also that docs can be generated from.
16:37:24 <nikunj2512> See for the firefox we can mention the minimum version against which everything works and perform the check
16:38:01 <tqtran> TravT: agree, that would save a lot of confusion
16:38:20 <doug-fish> nikunj2512:  do we know the minimum version of firefox against which everything works?
16:38:30 <david-lyle> nikunj2512, yes having a base chrome and firefox version is necessary
16:38:33 <nikunj2512> i think we have to maintain a whitelist which will contain the minimum browser version we support
16:38:34 <amotoki> how about the latest version and some versions shipped with major distros? we can know the minimum version.
16:39:10 <amotoki> we can get the specific version from distros (or windows).
16:39:13 <david-lyle> I think we just need to establish a minimum across the browsers and work from there
16:39:29 <nikunj2512> doug-fish: for firefox from 28 or greater everything works
16:39:34 <sigmavirus24> david-lyle: I agree
16:39:40 <jpich> 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 <jpich> one of the cruxes anyhow...
16:39:50 <nikunj2512> david-lyle: yes
16:40:51 <nikunj2512> jpich: Yes that can also work and You right about earlier discussion
16:40:53 <david-lyle> jpich +1 to the blacklist
16:41:00 <asahlin_> 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 <nikunj2512> jpich: +1
16:41:07 <david-lyle> it's a much simpler matrix
16:41:23 <asahlin_> trying to think of other web applications that warn
16:41:24 <tqtran> asahlin_: actually, they might not know unless the message is there
16:42:04 <gugl3> jpich, in the message, can we also add link to the page of supported versions?
16:42:08 <nikunj2512> 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 <nikunj2512> tqtran: Correct
16:42:26 <tqtran> asahlin_: right, they might not even know about the page (like me)
16:42:31 <asahlin_> So they report a bug, we point to documentation with the browser matrix
16:42:32 <TravT> 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 <asahlin_> google
16:43:00 <asahlin_> I am not saying the message is a bad idea..
16:43:01 <nikunj2512> gugl3: Yes, we will add the link to the browser support matrix page
16:43:03 <rbertram> Would we not show a message on login screen if browser is not on white list?
16:43:05 <david-lyle> 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 <tsufiev> asahlin_, if everyone would be so clever, let-me-google-it-for-you site would have never appeared :)
16:43:47 <amotoki> Apart from versions, I think we need to define a set of support browsers: Chrome, Firefox, Safari, IE?I
16:43:48 <rbertram> asahlin_ are you asking if whitelist-based message is enough, so don't need blacklist?
16:43:50 <nikunj2512> 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 <sigmavirus24> 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 <amotoki> Opera?
16:44:24 <nikunj2512> amotoki: yes opera, safari
16:44:28 <mfer> 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 <nikunj2512> sigmavirus24: i don't think so
16:44:46 <tqtran> mfer: that would require much more work
16:44:52 <sigmavirus24> nikunj2512: and why not?
16:44:53 <nikunj2512> TravT: Same here
16:45:10 <david-lyle> 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 <doug-fish> do we need to specify platform?  I'd guess we have issues with some screens not working on ios.
16:45:25 <asahlin_> 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 <mfer> tqtran feature detection is one of the go toos now
16:45:30 <david-lyle> #topic Summit Session Selection (david-lyle)
16:45:31 <mfer> i'm happy to talk about it offline
16:45:43 <jpich> 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 <david-lyle> we can continue the previous conv in another forum
16:45:52 <jpich> Ok, summit so :-)
16:46:06 <david-lyle> #link https://etherpad.openstack.org/p/horizon-kilo-summit
16:46:13 <david-lyle> I need your votes people
16:46:26 <david-lyle> or discussion about why there are few votes
16:46:33 <nikunj2512> 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 <david-lyle> or I'll randomly pick topics that make me happy
16:46:54 <nikunj2512> david-lyle: OK
16:46:56 <doug-fish> do you want only summit participants to vote?  or should non-participants vote for things they hope will be discussed?
16:47:07 <david-lyle> one involves a gin sampling session
16:47:28 * TravT thinks wine sampling would be more appropriate in France
16:47:35 <hurgleburgler> +1
16:47:39 <david-lyle> doug-fish, anyone can vote on a topic they would like to have a more concrete plan around
16:47:42 <tsufiev> lol ))
16:47:48 <david-lyle> TravT, makes ME happy
16:47:55 <tqtran> +1 to gin sampling
16:47:55 <david-lyle> :)
16:48:20 <tsufiev> +1 to sampling ))
16:48:30 <doug-fish> and how many +1s shall we give out?
16:48:36 <david-lyle> I am going to make sure there is a session that centers on keystone topics coming up in Kilo
16:48:37 <jpich> I guess many topics are one line, rather than a description
16:48:43 <david-lyle> there are several
16:48:48 <nikunj2512> doug-fish: as many as possible :)
16:48:49 <jpich> so it's hard to know if it's a thought or what the session will attempt to resolve
16:49:07 <david-lyle> jpich, so let's grow the topic description
16:49:09 <doug-fish> nikunj2512:  haha!  Chicago style voting it is!
16:49:19 <doug-fish> vote early and vote often.
16:49:29 <tqtran> chicago style... haha never heard of that term
16:49:32 <david-lyle> some of those were placeholders I put in initially
16:49:42 <nikunj2512> doug-fish:  :)
16:49:47 <david-lyle> may be why they're sparse
16:50:33 <ericpeterson> I vote for david-lyle to speak for all sessions
16:50:49 * david-lyle starts gin sampling now
16:50:58 <ericpeterson> and he better keep it entertaining
16:50:59 <sigmavirus24> doug-fish: see also New Jersey style
16:51:06 <amotoki> 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 <TravT> how do you plan to do the contributors meetup?
16:51:44 <TravT> totally informal?  or have some agenda planned on site (like lightning sessions)
16:52:02 <jpich> I believe the only session we've scheduled goes into the "contributors meetup" aka the unscheduled session :)
16:52:21 <david-lyle> TravT depends on demand
16:52:46 <david-lyle> my original thought was it would be a good time for clientside discussion, but that may not be the best fit
16:52:49 <tsufiev> sigmavirus24, do you mean 'worse is better'?
16:53:05 <sigmavirus24> tsufiev: ?
16:53:28 <ericpeterson> sigmavirus24: I'm guessing a reference to New Jersey
16:53:30 <tsufiev> sigmavirus24, http://en.wikipedia.org/wiki/Worse_is_better
16:54:32 <sigmavirus24> Hah. I hadn't heard of that. I was talking about NJ style politics (aka parlor tricks)
16:54:38 <amotoki> 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 <amotoki> It is not decided yet and just an example.
16:58:52 <david-lyle> ok, a lot more input now, keep it coming
16:59:02 <david-lyle> I'll take a first pass this week sometime
16:59:16 <david-lyle> preferences for unscheduled content?
17:00:07 <david-lyle> We're out of time everyone. Thanks!
17:00:12 <david-lyle> #endmeeting Horizon