Changes in the installation procedure

The installation mainly remains the same, except for the differences mentioned in the following sections.

Adding the repository

We will need to add the appropriate repository for the version that we need to install, so if we were to install the Kilo release, we will add the Kilo repository as shown (we added the repository in Chapter 2, Authentication and Authorization Using Keystone, before installing Keystone):

apt-get install ubuntu-cloud-keyring
echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list

For a Liberty release, the repository can be added as follows:

apt-get install software-properties-common
add-apt-repository cloud-archive:liberty

The OpenStack client

The Juno release had individual clients with the python-<projectname>client format, for example, python-keystoneclient, python-novaclient, and so on. In the Kilo and Liberty releases, this is being replaced by a single client called python-openstackclient. This replaces all of the previous clients.

We can install the client by executing the following command:

apt-get install python-openstackclient

Once this is done, we no longer need to install the individual clients.

Tip

In the Kilo release, you still use the older clients, but it will throw a deprecation notice on the screen. With the new client, we can use the same commands as with the older clients.

Installing Keystone

In both Kilo and Liberty, the Keystone service needs to be installed a little differently. The older method will still work, but it is being deprecated in favor of using the WSGI Apache methodology.

So, in order to enable that, after we have installed the Keystone service, we will execute the following steps:

  1. Disable the Keystone service from starting automatically, as this will now be proxied via the Apache server:
    echo "manual" > /etc/init/keystone.override
  2. Install the Apache and Apache WSGI modules:
    apt-get install keystone apache2 libapache2-mod-wsgi 
memcached python-memcache
  3. Edit the /etc/apache2/apache2.conf file and add the ServerName directive to the hostname of the controller node.
  4. Create a new file, /etc/apache2/sites-available/wsgi-keystone.conf, and paste the following content in it:
    Listen 5000
Listen 35357

<VirtualHost *:5000>
    WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone group=keystone display-name=%{GROUP}
    WSGIProcessGroup keystone-public
    WSGIScriptAlias / /usr/bin/keystone-wsgi-public
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
    <IfVersion >= 2.4>
      ErrorLogFormat "%{cu}t %M"
    </IfVersion>
    ErrorLog /var/log/apache2/keystone.log
    CustomLog /var/log/apache2/keystone_access.log combined

    <Directory /usr/bin>
        <IfVersion >= 2.4>
            Require all granted
        </IfVersion>
        <IfVersion < 2.4>
            Order allow,deny
            Allow from all
        </IfVersion>
    </Directory>
</VirtualHost>

<VirtualHost *:35357>
    WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone group=keystone display-name=%{GROUP}
    WSGIProcessGroup keystone-admin
    WSGIScriptAlias / /usr/bin/keystone-wsgi-admin
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
    <IfVersion >= 2.4>
      ErrorLogFormat "%{cu}t %M"
    </IfVersion>
    ErrorLog /var/log/apache2/keystone.log
    CustomLog /var/log/apache2/keystone_access.log combined

    <Directory /usr/bin>
        <IfVersion >= 2.4>
            Require all granted
        </IfVersion>
        <IfVersion < 2.4>
            Order allow,deny
            Allow from all
        </IfVersion>
    </Directory>
</VirtualHost>
  5. Create a soft link of the file, as follows:
    ln -s /etc/apache2/sites-available/wsgi-keystone.conf  
/etc/apache2/sites-enabled
  6. Restart the Apache service. This way, Apache will be the frontend for all the requests coming to Keystone. The Keystone service doesn't need to be started automatically.

This is a major installation difference when it comes to the Kilo or the Liberty release compared to Juno. The older installations of Keystone will still work in the Kilo release.

Service configurations

In the service configuration, there is only one notable difference. In all the configuration files for the different services, wherever we have the [keystone_authtoken] section, we will have to make the following modifications:

Juno

Kilo/Liberty

[keystone_authtoken]
auth_uri = http://controller: 5000/v2.0
identity_uri = http://controller:35357
admin_tenant_name = service
admin_user = <Service_UserName>
admin_password = <Service keystone pwd> 

[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = <Service Username>
password = <Service keystone pwd>

As we can see, there are three new fields to be added (auth_plugin, project_domain_id, and user_domain_id) and identity_uri is replaced with auth_url and admin_tenant_name with project_name.

This configuration is found in all the different service files and needs to be replaced to use the Apache WSGI configuration.

Tip

You can find the install guides for the Kilo and Liberty releases for the Ubuntu OpenStack distribution at the following:

http://docs.openstack.org/kilo/install-guide/install/apt/content/ch_preface.html

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset