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

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@redhat.com] Sent: Tuesday, April 14, 2015 3:54 AM To: Steve Gordon Cc: rdo-list; berndbausch(a)gmail.com Subject: Re: [Rdo-list] Fwd: [OpenStack-docs] [install-guide] (not that much) progress with Kilo install on RHEL/Centos 7 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: [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] 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. 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. /etc/rabbitmq/rabbitmq.config. 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. 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. 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. There is a known problem that has been corrected in the latest Kilo packages. There was no corresponding bz filed (via apevec, irc). Debugging this will probably require someone looking over your shoulder at your glance configuration. -- Lars Kellogg-Stedman <lars(a)redhat.com&gt; | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/