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

Thu Apr 16 04:40:26 UTC 2015

Who can help installing Kilo on Centos 7? I am trying it out in view of
updating the install guide on docs.openstack.org and have showstopper
problems early in the process.

Thanks to Lars' input I corrected my repositories and got rid of what looked
like packaging errors. I am meeting new problems though and am not sure if
they are due to misconfiguration, or if Kilo still works only in a narrow
setting, or bugs (hard to believe, since I am doing nothing fancy)?

My OS is CentOS Linux release 7.1.1503 (Core), plus epel-release-7-5.

I use these instructions
http://docs-draft.openstack.org/92/167692/13/gate/gate-openstack-manuals-tox
-doc-publish-checkbuild/31c1ab2//publish-docs/trunk/install-guide/install/yu
m with a few changes:

- rdo-release-kilo-0.noarch.rpm instead of the juno rpm
- manually installing, enabling and starting memcached
- manually adding the _member_ role to keystone

----------------------------------------------------------
PROBLEM 1: I am unable to use memcached as token backend
----------------------------------------------------------

In keystone.conf:

    [token]
    driver=keystone.token.persistence.backends.memcache.Token

An attempt to request a token hangs, either ``openstack token issue`` or
``curl -i -X POST http://kilocontrol:35357/v2.0/tokens ...``. On the server
side, the hang is in the method() call inside
/lib/python2.7/site-packages/keystone/common/wsgi.py. If I use a wrong
password or malformed credentials, I get the expected error message, so that
I assume that the problem occurs after authentication. memcached is running
and accessible, but there is no traffic on its port 11211. I don't know
enough to trace any further.

My workaround is to use a different backend, sql.

----------------------------------------------
Problem 2: glance image-create doesn't work
----------------------------------------------

Using API version 2:

    # glance image-create --name "cirros-0.3.3-x86_64" --file
/tmp/images/cirros-0.3.3-x86_64-disk.img --disk-format qcow2
--container-format bare --visibility public --progress
    usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT] 
    ...
    glance: error: unrecognized arguments: --name --disk-format qcow2
--container-format bare --visibility public

Let's try the help:

    # glance help image-create
    usage: glance image-create [--property <key=value>] [--file <FILE>]
                               [--progress]
                               <unavailable>
    Create a new image.
    Positional arguments:
    <unavailable>         Please run with connection parameters set to
retrieve
                          the schema for generating help for this command
    Optional arguments:
    --property <key=value>
                          Arbitrary property to associate with image. May be
                          used multiple times.
    --file <FILE>         Local file to save downloaded image data to. If
this
                          is not specified the image data will be written to
                          stdout.
    --progress            Show upload progress bar.

This doesn't look like the image-create I am used to.

Switching to API version 1 (I also replace "--visibility public" with
"--is-public true"):

    # glance image-create --name "cirros-0.3.3-x86_64" --file
/tmp/images/cirros-0.3.3-x86_64-disk.img --disk-format qcow2
--container-format bare --is-public true --progress
    'Namespace' object has no attribute 'project_domain_name'

In fact, any glance command I try, except help, comes back with this error:

    # glance image-list
    'Namespace' object has no attribute 'project_domain_name'

The namespace messages appear to come from the message queue. There is
nothing in the glance logs - the problem is on the client side. --debug
doesn't change the output. Meanwhile, I was made aware that a new image
upload workflow exists, but how to make it work with the CLI client is
unclear to me.

Bernd

-----Original Message-----
From: Lars Kellogg-Stedman [mailto:lars at redhat.com] 
Sent: Tuesday, April 14, 2015 3:54 AM
To: Steve Gordon
Cc: rdo-list; berndbausch at gmail.com
Subject: Re: [Rdo-list] Fwd: [OpenStack-docs] [install-guide] (not that
much) progress with Kilo install on RHEL/Centos 7

> > openstack-selinux not found in the repositories I am using.

openstack-selinux is generally available for RHEL and CentOS, but not for
Fedora.  On Fedora in particular, selinux related issues are supposed to be
reported directly against selinux-policy.

When using RDO Kilo with CentOS 7, the openstack-selinux package comes from
the rdo-juno repository.  Note that installing
https://repos.fedorapeople.org/repos/openstack/openstack-kilo/rdo-release-ki
lo-0.noarch.rpm
configures two repositories on your system:

    [openstack-juno]
    name=OpenStack Juno Repository

baseurl=http://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/
    enabled=1
    skip_if_unavailable=0
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-RDO-Juno

    [openstack-kilo]
    name=Temporary OpenStack Kilo new deps

baseurl=http://repos.fedorapeople.org/repos/openstack/openstack-kilo/epel-7/
    skip_if_unavailable=0
    gpgcheck=0
    enabled=1

I notice that the draft Kilo install guide still points at the Juno
packages:

>   Install the rdo-release-juno package to enable the RDO repository:
>
>       # yum install
>       # 
> http://rdo.fedorapeople.org/openstack-juno/rdo-release-juno.rpm

[from
http://docs-draft.openstack.org/92/167692/13/gate/gate-openstack-manuals-tox
-doc-publish-checkbuild/31c1ab2//publish-docs/trunk/install-guide/install/yu
m/content/ch_basic_environment.html#basics-prerequisites]

> > 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.

As of last week, there were still selinux bugs open against RDO Juno.
I'm not sure what the state of the Kilo packages are at this opint, but it
seems likely that there may be issues there as well.

> > 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?

If you're seeing this on a RHEL or Fedora system, you should open a bug in
bugzilla so we can track this issue and maybe come up with an appropriate
solution.

> > ------------------------------------
> > 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.

There's a bug open on that for RHEL:

  https://bugzilla.redhat.com/show_bug.cgi?id=1134956

We should probably clone that to RDO as well.

> > ``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
> [...]
> > This looks very much like a packaging error, and I hope it will 
> > eventually go away.

You shouldn't require COPR repositories for anything.  If you encounter a
repeatable packaging error, make sure to open a bugzilla so that folks are
aware of the issue.

On CentOS 7 right now, I am able to install both python-keystoneclient and
openstack-keystone without any errors, using only the base, RDO, and EPEL
repositories.

> > 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.

I suspect the answer to all of the above is, "because legacy".  v3 support
has only recently been showing up in all of the services, and many folks
still aren't familiar with the newer APIs.  The admin/non-admin port
separation is another historical oddity that we have to live with.  With
Keystone v2, at least, there are some features only available through the
admin api on the admin port.

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

> > 	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',)

There is a known problem that has been corrected in the latest Kilo
packages.  There was no corresponding bz filed (via apevec, irc).

> > 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.

Debugging this will probably require someone looking over your shoulder at
your glance configuration.

--
Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/