tutorial-cloud/docs/old-instance/tutorial-8.md

---
sidebar_label: 'Set up session storage for the Dashboard'
sidebar_position: 1
---

<!-- truncate -->
import CodeBlock from '@site/src/components/CodeBloack';

# Set up session storage for the Dashboard

<div className="text">The Dashboard uses <span style={{textDecoration:'underline', color: '#0000b3'}}>Django sessions framework</span> to handle user session data. However, you can use any available session back end. You customize the session back end through the **SESSION_ENGINE** setting in your ***local_settings.py***  file.</div>

<div className="text">After architecting and implementing the core OpenStack services and other required services, combined with the Dashboard service steps below, users and administrators can use the OpenStack dashboard. Refer to the <span style={{textDecoration:'underline', color: '#0000b3'}}>OpenStack User Documentation</span> chapter of the OpenStack End User Guide for further instructions on logging in to the Dashboard.</div>

<div className="text">The following sections describe the pros and cons of each option as it pertains to deploying the Dashboard.</div>

<div className="head">Local memory cache</div>
<div className="text">Local memory storage is the quickest and easiest session back end to set up, as it has no external dependencies whatsoever. It has the following significant drawbacks: <ul><li>No shared storage across processes or workers.</li><li>No persistence after a process terminates.</li></ul></div>

<div className="text">The local memory back end is enabled as the default for Horizon solely because it has no dependencies. It is not recommended for production use, or even for serious development work.</div>

<CodeBlock code={`SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
  'default' : {
    'BACKEND': 'django.core.cache.backends.locmem.LocMemCache'
  }
}
`} /> <br/>


<div className="text">You can use applications such as ***Memcached*** or ***Redis*** for external caching. These applications offer persistence and shared storage and are useful for small-scale deployments and development.</div>

<div className="text" style={{ fontSize:'28px' }}>Memcached</div>

<div className="text">Memcached is a high-performance and distributed memory object caching system providing in-memory key-value store for small chunks of arbitrary data.<br/><br/>Requirements:</div>

<div className="text"><ul><li>Memcached service running and accessible.
</li><li>Python module ***python-memcached*** installed.</li></ul></div>

<CodeBlock code={`SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
  'default': {
    'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
    'LOCATION': 'my_memcached_host:11211',
  }
}
`} /> <br/>

<div className="text" style={{ fontSize:'28px' }}>Redis</div>

<div className="text">Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server.<br/><br/>Requirements:</div>

<div className="text"><ul><li>Redis service running and accessible.
</li><li>Python modules ***redis*** and ***django-redis*** installed.</li></ul></div>

<CodeBlock code={`SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
CACHES = {
    "default": {
        "BACKEND": "redis_cache.cache.RedisCache",
        "LOCATION": "127.0.0.1:6379:1",
        "OPTIONS": {
            "CLIENT_CLASS": "redis_cache.client.DefaultClient",
        }
    }
}
`} /> <br/>

<div className="text" style={{ fontSize:'28px' }}>Initialize and configure the database</div>

<div className="text">Database-backed sessions are scalable, persistent, and can be made high-concurrency and highly available.<br/><br/>However, database-backed sessions are one of the slower session storages and incur a high overhead under heavy usage. Proper configuration of your database deployment can also be a substantial undertaking and is far beyond the scope of this documentation.</div>

<div className="text">1. Start the MySQL command-line client.</div>

<CodeBlock code={`# mysql
`} /> <br/>

<div className="text">2. Enter the MySQL root user’s password when prompted.</div>

<div className="text">3. To configure the MySQL database, create the dash database.</div>

<CodeBlock code={`mysql> CREATE DATABASE dash;
`} /> <br/>

<div className="text">4. Create a MySQL user for the newly created dash database that has full control of the database. Replace DASH_DBPASS with a password for the new user.</div>

<CodeBlock code={`mysql> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'%' IDENTIFIED BY 'DASH_DBPASS';
mysql> GRANT ALL PRIVILEGES ON dash.* TO 'dash'@'localhost' IDENTIFIED BY 'DASH_DBPASS';
`} /> <br/>

<div className="text">5. Enter quit at the mysql> prompt to exit MySQL.</div>
<div className="text">6. In the ***local_settings.py*** file, change these options:</div>

<CodeBlock code={`SESSION_ENGINE = 'django.contrib.sessions.backends.db'
DATABASES = {
    'default': {
        # Database configuration here
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'dash',
        'USER': 'dash',
        'PASSWORD': 'DASH_DBPASS',
        'HOST': 'localhost',
        'default-character-set': 'utf8'
    }
}
`} /> <br/>

<div className="text">7. After configuring the ***local_settings.py*** file as shown, you can run the ***manage.py migrate*** command to populate this newly created database.</div>

<CodeBlock code={`# /usr/share/openstack-dashboard/manage.py migrate
`} /> <br/>

<div className="text">8. To avoid a warning when you restart Apache on Ubuntu, create a ***blackhole*** directory in the Dashboard directory, as follows.</div>

<CodeBlock code={`# mkdir -p /var/lib/dash/.blackhole
`} /> <br/>

<div className="text">9. Restart the Apache service.</div>
<div className="text">10. On Ubuntu, restart the nova-api service to ensure that the API server can connect to the Dashboard without error.</div>

<CodeBlock code={`# service nova-api restart
`} /> <br/>

<div className="head">Cached database</div>

<div className="text">To mitigate the performance issues of database queries, you can use the Django cached_db session back end, which utilizes both your database and caching infrastructure to perform write-through caching and efficient retrieval.<br/> <br/>Enable this hybrid setting by configuring both your database and cache, as discussed previously. Then, set the following value:</div>

<CodeBlock code={`SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"
`} /> <br/>

<div className="head">Cookies</div>

<div className="text">If you use Django 1.4 or later, the signed_cookies back end avoids server load and scaling problems.</div>

<div className="text">This back end stores session data in a cookie, which is stored by the user’s browser. The back end uses a cryptographic signing technique to ensure session data is not tampered with during transport. This is not the same as encryption; session data is still readable by an attacker.</div>

<div className="text">The pros of this engine are that it requires no additional dependencies or infrastructure overhead, and it scales indefinitely as long as the quantity of session data being stored fits into a normal cookie.</div>

<div className="text">The biggest downside is that it places session data into storage on the user’s machine and transports it over the wire. It also limits the quantity of session data that can be stored.<br/>See the Django <span style={{textDecoration:'underline', color: '#0000b3'}}>cookie-based sessions</span> documentation.</div>