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

[Lars Kellogg-Stedman]

> > 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-kilo-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/yum/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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150413/4b26bab6/attachment.sig>