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 []
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 

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.



OpenStack-dev mailing list

Reply via email to