[OpenStack-docs] [install-guide] (not that much) progress with Kilo install on RHEL/Centos 7

Bernd Bausch berndbausch at gmail.com
Fri Apr 17 10:23:52 UTC 2015 

My problem was wrong repositories again. After setting up the right repos, the glance client behaves as expected. I am finally making progress with my installation (currently unable to start nova-novncproxy, but that is not a showstopper).

 

From: Matt Kassawara [mailto:mkassawara at gmail.com] 
Sent: Tuesday, April 14, 2015 10:46 PM
To: Anne Gentle
Cc: Bernd Bausch; openstack-docs at lists.openstack.org
Subject: Re: [OpenStack-docs] [install-guide] (not that much) progress with Kilo install on RHEL/Centos 7

 

Bernd,

 

The glance image-create command in the Kilo version of the installation guide [1] works using an installation from the proposed/kilo branch. I can't imagine this changing for the official release.

 

[1] http://docs-draft.openstack.org/92/167692/13/gate/gate-openstack-manuals-tox-doc-publish-checkbuild/31c1ab2//publish-docs/trunk/install-guide/install/apt/content/glance-verify.html <http://docs-draft.openstack.org/92/167692/13/gate/gate-openstack-manuals-tox-doc-publish-checkbuild/31c1ab2/publish-docs/trunk/install-guide/install/apt/content/glance-verify.html> 

 

Matt

 

On Tue, Apr 14, 2015 at 8:21 AM, Anne Gentle <annegentle at justwriteclick.com <mailto:annegentle at justwriteclick.com> > wrote:

 

 

On Mon, Apr 13, 2015 at 10:30 AM, Matt Kassawara <mkassawara at gmail.com <mailto:mkassawara at gmail.com> > wrote:

Responses inline...

 

On Sun, Apr 12, 2015 at 8:49 PM, Bernd Bausch <berndbausch at gmail.com <mailto:berndbausch at gmail.com> > wrote:

In preparation for the install guide meeting on Tuesday, I would like to
share what I have been able to do so far and what problems I hit. Advice
would be welcome (I'd be happy to discuss that in the meeting):

- There are places where the install guide content should be modified
(flagged with "CONTENT" below). What's the procedure - I file a bug and
immediately provide the fix?
- Other places look like packaging bugs; I am using a Kilo repository for
the Red Hat RDO project that is still work in progress. I think I should
leave such bugs alone for now, since they are likely to go away. Correct?

This is my report. It's based on Matt's version of the install guide
http://docs-draft.openstack.org/92/167692/13/gate/gate-openstack-manuals-tox <http://docs-draft.openstack.org/92/167692/13/gate/gate-openstack-manuals-tox-doc-publish-checkbuild/31c1ab2/publish-docs/trunk/install-guide/install/yum/content/index.html> 
-doc-publish-checkbuild/31c1ab2//publish-docs/trunk/install-guide/install/yu
m/content/index.html.

---------------------------
Section 2 Basic environment
---------------------------

openstack-selinux not found in the repositories I am using. On first look,
it seems that there is no need to install it, as rules in
/etc/selinux/targeted/contexts/files/* seem to be the same as on my Juno
installation. So I am brave, plan to watch the audit log and go ahead
without modifying SELinux configs.

 

In Juno and prior releases, RHEL/CentOS required installing openstack-selinux to configure SELinux rules, but Fedora included them by default. Maybe this requirement changed for RHEL/CentOS in Kilo?

 


CONTENT: The guide lacks info about the firewall rules, except a vague
allusion in Chapter 2 Basic Environment.
Since this is Red Hat with a locked-down firewall, nothing will work without
opening ports for fundamental services (DB, RabbitMQ) and the OpenStack
services.

 

A couple of cycles ago, we decided to make first-time installations easier by recommending that people disable the the firewall and then use the security guide later to increase security before moving to production. Furthermore, no one should use the installation guide architecture for production without augmenting it with at least the security guide, HA guide, and potentially a deployment automation system.

 


My NTP server doesn't work (this has nothing to do with OpenStack).
This forum says that NTP needs to be started after DNS (???)
    https://forum.zentyal.org/index.php/topic,13045.0.html
In any case, issuing a ``systemctl restart ntpd.service`` fixes the problem,
but how can it be done automatically?

 

I haven't seen this issue and need more information here... perhaps some error messages?

 


---------------------------------
section 2, Maria DB installation:
---------------------------------

``/usr/bin/mysql_secure_installation: line 379: find_mysql_client: command
not found``

 

I haven't seen this issue. Seems like packaging, but I can't imagine RH breaking the MariaDB packages.

 

CONTENT: The install guide doesn't say how to answer the questions of this
script.

 

I think we could add some information to the guide, but in the long run think we should expect our audience to know at least the basics of MariaDB.

 

After setting the root password on the DB, I just hit enter at each
question.

------------------------------------
Section 2, Rabbit MQ installation:
------------------------------------

CONTENT: The guide asks for adding a line to /etc/rabbitmq/rabbitmq.config.
Scratching my head because I don't have that file, but then I see that it
may not always exist. Perhaps this should be made clearer to accommodate
slow thinkers.

 

I don't see where the guide asks to edit this file.

 


-------------------------------
Section 3, Identity concepts
-------------------------------

CONTENT: The diagram showing the process flow confuses me more than it
helps.

 

Most of the conceptual sections come from common content (outside of the installation guide) that needs clarification.

 


--------------------------------
Section 3, install and configure
--------------------------------

``yum install openstack-keystone python-keystoneclient``: dependency
python-cryptography can't be found

After adding this repo (found via internet search):

        [npmccallum-python-cryptography]
        name=Copr repo for python-cryptography owned by npmccallum

baseurl=https://copr-be.cloud.fedoraproject.org/results/npmccallum/python-cr <https://copr-be.cloud.fedoraproject.org/results/npmccallum/python-cryptography/epel-7-$basearch/> 
yptography/epel-7-$basearch/
        skip_if_unavailable=True
        gpgcheck=1

gpgkey=https://copr-be.cloud.fedoraproject.org/results/npmccallum/python-cry <https://copr-be.cloud.fedoraproject.org/results/npmccallum/python-cryptography/pubkey.gpg> 
ptography/pubkey.gpg
        enabled=1

it works.
This looks very much like a packaging error, and I hope it will eventually
go away.

 

I'm going with a packaging problem.

 


CONTENT (or perhaps not CONTENT): keystone.conf contains "connection =
<None>" rather than the connection string cited in the install guide. This
may be legitimately so, in which case the guide needs to be modified, or a
packaging error.

 

I don't understand the problem. The guide says to configure "connection = mysql://keystone:KEYSTONE_DBPASS@controller/keystone" in the keystone.conf file.

 


------------------------------------------------------
Section 3, create the service entity and API endpoints
------------------------------------------------------

CONTENT: ``openstack`` command missing. Found in the package
python-openstackclient.

 

We need to update the list of packages to install.

 


CONTENT: ``openstack service create --type identity`` gives me:
    WARNING: openstackclient.identity.v2_0.service.CreateService The
argument --type is deprecated, use service create --name <service-name> type
instead.

 

What version of python-openstackclient?

 


I don't like the openstack client, because its help facility is much
inferior to the one of the separate command line clients. Tough luck, I
guess.

 

Keystone requires it now, but we don't need to use it for other services.

 


CONTENT: The relevance of the sentence "Also, OpenStack supports multiple
regions for scalability" is not clear to a first time (even n-th time) user.

 

I think we're trying to explain why we keep the installation guide as simple as possible. What do you suggest?

 


CONTENT: Why are we using API v2, not v3? Why a separate adminurl port, and
same port for internal and publicurl? Some clarification would help.

 

We support Keystone API v2 and v3. Keystone kept /v2.0 for compatibility, although most clients know how to access v3. We could add some clarification between the two ports. In short, administrative operations use 35357 and user operations use 5000.

 


CONTENT: I would phrase the note at the end differently, e.g. "You will
create similar endpoints for each of the other services as you install them"

 

For whatever reason, we're not allowed to use future tense.

 

Here are our reasons. Future tense can be difficult to translate. The IBM Style Guide is our base guidance, "Use past or future tense only when you cannot use present tense or it does not make sense to..." So, try to write for global audiences with somewhat mechanical understandings of the English language.

 

 


--------------------------------------------
Section 3, Create projects, users, and roles
--------------------------------------------

CONTENT: Rather than saying "project (tenant)", be a bit more explicit e.g.
"project (also named "tenant" in earlier OpenStack releases)"

 

Seems reasonable... but we'll just mention it once.

 


CONTENT:
# openstack role add --project demo --user demo _member_
ERROR: openstack No role with a name or ID of '_member_' exists.
I fix this by adding the _member_ role first:
# openstack role create _member_

 

Keystone should create the _member_ role automatically during creation of the demo tenant/user. The guide used to explicitly create this role and later stopped after it caused problems. I think some distributions are using strange configuration options.

 


--------------------------------------------
Section 3, verify operation
--------------------------------------------

CONTENT: There is no /etc/keystone/keystone-paste.ini; it's now under
/usr/share/keystone. Not sure yet if this file is supposed to be modified.
It seems that all the Paste/Deploy files are now under /usr/share.

 

We can use a different directory for RH.

 


For now, instead of changing paste.ini I just remove the admin token from
keystone.conf.

 

This just changes the token to "ADMIN" rather than disabling the method.

 


--------------------------------------------
Section 4, Glance install and configure
--------------------------------------------

ugly message when synching DB:
/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/artifacts.py:20:
DeprecationWarning: The oslo namespace package is deprecated. Please use
oslo_config instead.
Not sure what to do about this.

 

I haven't seen this on Ubuntu yet. Maybe a packaging problem.

 


--------------------------------------------
Section 4, Verify operation
--------------------------------------------

Major problems with glance. I am stuck with problem 3 below.

Problem 1:
~~~~~~~~~~

glance image-create fails. See also Monty Taylor's comments on the docs and
dev mailing lists.

It turns out that I am using glance API v2, set in the rc files:

    export OS_IMAGE_API_VERSION=2

Glance v2 requires a quite different workflow to upload images. Setting API
version to 1 for the moment.

 

The python-glanceclient should use version 2, but nova still uses version 1. The command to upload images changes slightly for version 2. Basically, "--is-public True" becomes "--visibility public" for image creation.

 


Problem 2:
~~~~~~~~~~

It turns out glance is not running. api.log says:

        ERROR glance.common.config [-] Unable to load glance-api-keystone
from configuration file /usr/share/glance/glance-api-dist-paste.ini.
        Got: ImportError('No module named elasticsearch',)

After pip install elasticsearch, I can start glance.

 

Packaging.

 


Still getting a strange warning in api.log:
    2015-04-12 17:42:30.267 6789 WARNING oslo_config.cfg [-] Option
"username" from group "keystone_authtoken" is deprecated. Use option
"username" from group "keystone_authtoken".

 

This is a side effect of OpenStack deprecating "username" several releases ago and then bringing it back in a different form for Kilo. Upstream problem.

 


Problem 3:
~~~~~~~~~~

Trying to upload an image now fails because of wrong credentials???? Haven't
resolved this yet. Any glance request is rejected with
    # glance image-list
    Invalid OpenStack Identity credentials.

 

Could be a number of things.

 


Glance's API log:
2015-04-12 22:31:03.932 9048 DEBUG keystoneclient.session [-] REQ: curl -g
-i -X GET http://kilocontrol:35357 -H "Accept: application/json" -H
"User-Agent: python-keystoneclient" _http_log_request
/usr/lib/python2.7/site-packages/keystoneclient/session.py:195
2015-04-12 22:31:03.935 9048 WARNING
keystoneclient.auth.identity.generic.base [-] Discovering versions from the
identity service failed when creating the password plugin. Attempting to
determine version from URL.
2015-04-12 22:31:03.936 9048 WARNING keystonemiddleware.auth_token [-]
Authorization failed for token

This seems to be related with this DEBUG entry in keystone.log:
keystone.middleware.core [-] Auth token not in the request header. Will not
build auth context. process_request
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:229

I assume a misconfiguration on my side but haven't figured out what it might
be. Need to study the nature of WSGI middleware.


_______________________________________________
OpenStack-docs mailing list
OpenStack-docs at lists.openstack.org <mailto:OpenStack-docs at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

 


_______________________________________________
OpenStack-docs mailing list
OpenStack-docs at lists.openstack.org <mailto:OpenStack-docs at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs





 

-- 

Anne Gentle
annegentle at justwriteclick.com <mailto:annegentle at justwriteclick.com> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20150417/7530342d/attachment-0001.html>

More information about the OpenStack-docs mailing list