Open Stack

All in all this is been a long time coming. The cookie-based option was useful as a batteries-included, simplest-case scenario. Moving to SQLite is a reasonable second choice since most systems Horizon might be deployed on support sqlite out of the box.

I would make a couple notes:


1)      If you’re going to store very large amounts of data in the session, then session cleanup is going to become an important issue to prevent excessive data growth from old sessions.

2)      SQLite is far worse to go into production with than cookie-based sessions (which are far from perfect). The more we can do to ensure people don’t make that mistake, the better.

3)      There should be a clear deprecation for cookie-based sessions. Don’t just drop them in a single release, as tempting as it is.

Otherwise, seems good to me.


-          Gabriel

From: David Lyle [mailto:dklyle0 at gmail.com]
Sent: Thursday, October 23, 2014 2:44 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Horizon] [Devstack]

In order to help ease an ongoing struggle with session size limit issues, Horizon is planning on changing the default session store from signed cookie to simple server side session storage using sqlite. The size limit for cookie based sessions is 4K and when this value is overrun, the result is truncation of the session data in the cookie or a complete lack of session data updates.

Operators will have the flexibility to replace the sqlite backend with the DB of their choice, or memcached.

We gain: support for non-trivial service catalogs, support for higher number of regions, space for holding multiple tokens (domain scoped and project scoped), better support for PKI and PKIZ tokens, and frees up cookie space for user preferences.

The drawbacks are we lose HA as a default, a slightly more complicated configuration. Once the cookie size limit is removed, cookie based storage would no longer be supported.

Additionally, this will require a few config changes to devstack to configure the session store DB and clean it up periodically.

Concerns?

David


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/5b36d5e5/attachment.html>