[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:
http://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/index.html
Cheers
-- Jarda
https://www.rdoproject.org/RDO-Manager
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