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

Jaromir Coufal jcoufal at redhat.com
Thu Apr 16 15:43:41 UTC 2015

Hi Bernd,

if you are interested we also work on new installer called RDO-Manager. 
It is project based on OpenStack's official deployment tool called 
TripleO [0].

If you are interested you can have a look to the project's homepage [1] 
and follow installation guide [2]

If you have any questions, feel free to contact me, I am happy to help.

[0] TripleO: https://wiki.openstack.org/wiki/TripleO
[1] RDO-Manager Home Page: https://www.rdoproject.org/RDO-Manager
[2] RDO-Manager User Guide: 

-- Jarda

On 16/04/15 06:40, Bernd Bausch wrote:
> 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/
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> To unsubscribe: rdo-list-unsubscribe at redhat.com

More information about the dev mailing list