[Rdo-list] Concerning Rabbits
by John Eckersberg
(In the spirit of "Concerning Hobbits")
Ryan O'Hara and I have been investigating RabbitMQ as it pertains to RDO
recently. There has been a lot of discussion on several disparate
threads, so I wanted to try and capture it on the list for the benefit
of everyone.
Ryan has been working on getting RabbitMQ running in a multi-node HA
configuration. I won't steal his thunder, and he can speak to it better
than I can, so I'll defer to him on the details.
As for me, I've been working on el7 support and bug squashing along the
way.
The first bug[1] causes the daemon to load incredibly slow, or outright
fail by timing out. This is due to the SELinux policy disallowing
name_bind on ports lower than 32768. RabbitMQ tries to name_bind to a
port starting at 10000, and increments if it fails. So if you have
SELinux in enforcing mode, you'll get 22768 AVC denials in the log
before it finally starts.
The second bug[2] causes the daemon to intermittently fail to start due
to a race condition in the creation of the erlang cookie file. This
happens only the first time the service starts. Really this is an
Erlang bug, but there's a workaround for the RabbitMQ case.
I've submitted patches for both issues. Until those get merged in, I've
rebuilt[3] RabbitMQ for F20 which includes the fixes.
Beyond bugs, I've also built out RabbitMQ and all the build/runtime
dependencies for el7. I have a yum repo[4] on my fedorapeople page
containing all the bits. This is all the stuff that is presently
missing from EPEL7. In time, I would hope the maintainers build all
this stuff, but for now it'll work for testing. You will also need the
EPEL 7 Beta repository[5] enabled.
As a side note, I built everything using mock with a local override repo
on my workstation. I've not used copr before but it seems relevant to
this sort of thing, so if it's any benefit I'll look to rebuilt the el7
stack there for easier consumption.
Hopefully this helps get the discussion into one place, and provide a
baseline for further investigation by everyone interested in RabbitMQ.
John.
---
[1] Is really two bugzillas, but the same bug:
[1a] https://bugzilla.redhat.com/show_bug.cgi?id=998682
[1b] https://bugzilla.redhat.com/show_bug.cgi?id=1032595
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1059913
[3] http://jeckersb.fedorapeople.org/rabbitmq-server-3.1.5-3.fc20.noarch.rpm
[4] http://jeckersb.fedorapeople.org/rabbitmq-el7/
[5] http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/
10 years, 1 month
[Rdo-list] Simplest Icehouse Implementation Architecture
by Eric Berg
I'm working toward implementation of a small RDO cloud which should be
quite minimal. We will be running < 25 VMs with very low utilization,
which will not change very often and which will basically just run to be
available.
I have two hosts with plenty of RAM and disk, and can get others as
required.
The initial expectation as communicated to me was to just use two hosts
that we already have. I'm not sure if that's a realistic architecture,
but it seems from my reading that I might want at least a separate
control box if not also have the network box be separate if not on the
same as the control host.
So, are either of the following architectures sufficient for a
development environment?
Option 1.
- Two hosts to handle the entire cloud
Option 2.
- Two compute hosts
- One control host
Thanks as always for your input.
Eric
--
Eric Berg
Sr. Software Engineer
Rubenstein Technology Group
10 years, 6 months
Re: [Rdo-list] python-*client packaging
by Jakub Ruzicka
On 26.5.2014 17:30, Pádraig Brady wrote:
> -------- Original Message --------
> Subject: python-*client packaging
> Date: Mon, 26 May 2014 11:04:25 -0400 (EDT)
> From: Steve Gordon <sgordon(a)redhat.com>
> To: rdo-list(a)redhat.com
> CC: Padraig Brady <pbrady(a)redhat.com>, Russell Bryant <rbryant(a)redhat.com>
>
> Hi all,
>
> I was answering a question on ask.o.o [1] over the weekend that caused me to ponder the way we're packaging the python-*clients in RDO. As the clients don't really follow the formal integrated release cycle no release tag was created at the point of the Icehouse release for python-novaclient and instead the most recent tag is 2.17.0 created around 3 months ago.
I wrote basic overview on RDO wiki:
http://openstack.redhat.com/Clients
Rebases to latest version are required quite often.
> This is what we package and means we're missing functionality that was merged between this tag being created and the Icehouse GA, most notably *all* of the server group commands - the API for which was a fairly important (but late - via a feature freeze exception) addition to Icehouse for some users. I am wondering whether, given tag creation is basically on the whim of the individual maintainer upstream, we should be rebasing the clients from master more regularly instead of relying on the tags?
Important patches are backported on demand. I'm not strictly against
including upstream patches in packages and in fact, it was done like
that in the past.
I stopped including upstream patches because I found it quite confusing
- version says 0.6.0 but there are SOME bugs/features from 0.7.0... So
I'm rather working with assumption that *client devs know best when to
release a new version.
> The bug I filed for this specific issue with python-novaclient is https://bugzilla.redhat.com/show_bug.cgi?id=1101014 but I imagine we experience similar issues with the other clients from time to time.
That's a perfectly valid reason for a selective backport but as you
mentioned in the bug, it would be best to release new version which
includes this and rebase to it in order to stay somehow consistent with
the rest of the world.
So, Russel, do you plan to release new novaclient anytime soon or shall
I backport?
Cheers
Jakub
10 years, 6 months
[Rdo-list] FYI - Fedora.next calls for early testing (and some details on how)
by Kashyap Chamarthy
For those of you that live on the bleeding-edge testing RDO on Fedora,
Fedora project is going through a lot of changes (dubbed as
'Fedora.next') in its upcoming release cycle. And, the project is
looking for early testers/tinkerers to make the release a success.
If you have spare cycles, please spend some time testing (heads-up:
it'll be very disruptive) Fedora Rawhide (that'll be 21) for your
regular work-flows w/ RDO, etc.
You can trivially test[1] Fedora's latest bits (Rawhide) in a virtual
machine, like that (below is a way I prefer):
Create a Fedora 20-VM with a 40GB disk image, update, install Rawhide
packages:
$ virt-builder fedora-20 -o rawhide.qcow2 --format qcow2 \
--update --selinux-relabel --size 40G\
--install "fedora-release-rawhide yum-utils"
Import the disk image into libvirt:
$ virt-install --name rawhide --ram 4096 --disk \
path=/home/kashyapc/rawhide.qcow2,format=qcow2,cache=none \
--import
Login via serial console into the guest, upgrade to Rawhide:
$ yum-config-manager --disable fedora updates updates-testing
$ yum-config-manager --enable rawhide
$ yum update yum
$ yum --releasever=rawhide distro-sync --nogpgcheck
$ reboot
Optionally, you can take a snapshot so you can revert to a known sane state:
$ virsh snapshot-create-as rawhide snap1 \
"Clean Rawhide"
[1] https://fedoraproject.org/wiki/Releases/Rawhide#Using_Rawhide
--
/kashyap
10 years, 7 months
[Rdo-list] Minimal erlang for RabbitMQ
by Matthew Mosesohn
Hi RDO people!
I remember having a conversation with a few folks at RH during OpenStack
Summit about plans to break up erlang into smaller packages to reduce the
package size and # of dependencies required to install RabbitMQ. I can't
find anything on koji.fedoraproject.org or on the RDO repositories. Does
anyone have any more information about this effort?
Best Regards,
Matthew Mosesohn
10 years, 7 months
[Rdo-list] RDO Foreman Installation error nova controller
by Benoit ML
Hello,
I'd like to install an openstack on a multinode using pre-existing work on
puppetclass. Si I decided to use RDO like documented here, for icehouse :
http://openstack.redhat.com/Deploying_RDO_using_Foreman
So i have :
1/ actived some repository : rdo, epel, Centos SCL.
2/ Installed on the foreman node openstack-foreman-node and dhcpd
3/ Follow the documentation to add the host to the group openstack nova
controlleur neutron.
4/ Launch puppet agent -tv on the designated host
And i have some errors about a puppet class for ceilometer :
Error: Could not apply complete catalog: Found 1 dependency cycle:
(Ceilometer_config[database/connection] => Class[Ceilometer::Db] =>
Class[Ceilometer::Api] => Package[ceilometer-api] =>
Ceilometer_config[database/connection])
Try the '--graph' option and opening the resulting '.dot' file in
OmniGraffle or GraphViz
I have looking in foreman smart parameters about something to configure
but without success ....
Can ou hep me please ?
Thank you in advance.
Regards,
--
--
Benoit
10 years, 7 months
[Rdo-list] OpenStack Egypt, June 21
by Rich Bowen
The Cairo OpenStack user group is planning an event on June 21, and want
an RDO presence there if possible, both as speakers and attendees. If
you are anywhere in the area and could possibly attend, reach out to
'Egyptian' on the #rdo channel on Freenode IRC, and let him know that
you're available.
--Rich
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/
10 years, 7 months
[Rdo-list] python-*client packaging
by Steve Gordon
Hi all,
I was answering a question on ask.o.o [1] over the weekend that caused me to ponder the way we're packaging the python-*clients in RDO. As the clients don't really follow the formal integrated release cycle no release tag was created at the point of the Icehouse release for python-novaclient and instead the most recent tag is 2.17.0 created around 3 months ago.
This is what we package and means we're missing functionality that was merged between this tag being created and the Icehouse GA, most notably *all* of the server group commands - the API for which was a fairly important (but late - via a feature freeze exception) addition to Icehouse for some users. I am wondering whether, given tag creation is basically on the whim of the individual maintainer upstream, we should be rebasing the clients from master more regularly instead of relying on the tags?
The bug I filed for this specific issue with python-novaclient is https://bugzilla.redhat.com/show_bug.cgi?id=1101014 but I imagine we experience similar issues with the other clients from time to time.
Thanks,
--
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform
Red Hat Canada (Toronto, Ontario)
[1] https://ask.openstack.org/en/question/30433/why-are-nova-server-group-api...
10 years, 7 months
