Description of problem: Port 6000 causes conflicts with X11, preventing Swift from starting. Version-Release number of selected component (if applicable): 2014.1-14.2 How reproducible: Install with Packstack Steps to Reproduce: 0. set SELinux to permissive (needed for Neutron at least) 1. packstack --gen-answer-file=answer_file.txt 2. edit to suit (don't disable too much) 3. packstack, use the answer file 4. verify the port used in object-server.conf and object.builder Actual results: grep bind /etc/swift/object-server.conf ==> 6000 swift-ring-builder object.builder ==> 6000 Expected results: 6000 is actually expected, but we need to change it. Proposed is 6200. Additional info: See bug 947860, bug 995765, but 1004881, bug 1058282, bug 1072005, bug 1084310 (rwsu), bug 1095503. Notice that Swift ports are easily configurable. In fact this is the upstream's excuse why not to change the default. However, RDO users step on this again and again. Also, giving Swift its own ports makes it easier for SElinux.
Note that upstream selinux-policy allows use of 6000-6002 by swift.
Lon, regarding the comment "upstream selinux-policy allows use of 6000-6002 by swift" please see bug 1095503. It contains the AVC denials for name_bind operation.
See also: bug 1107908 (Packstack) bug 1112823 (SElinux vs upstream)
I now see the latest fedora selinux-policy allows swift access to ports 6000-6002. Do we still need to offset the ports to the 620x range? I'm wondering if we should revert the swift changes to default back to port 6000-6002. If it hasn't been consumed by folks yet since the puppet modules haven't been updated, it may be worth staying on the 600x range so we don't have to worry about having one set of users on the 600x range and another set of users on 620x. Migrating swift from one port range may require some downtime unless the process is managed correctly.
I think at this point the only argument for saying swift should be offset is so as not to conflict with an X server. IMO, that isn't a compelling enough argument to change the defaults in all of our puppet manifests (openstack-puppet-modules and astapor/openstack-foreman-installer) especially considering we would be diverging from upstream. However, we may want to make the default ports more configurable. E.g., they are hardcoded in astapor/openstack-foreman-installer right now.
Meanwhile, upstream moves to make bind_port mandatory, so that in the next phase it may be changed without blowing up the existing clusters: https://review.openstack.org/118200
Ancient bug, closing. Long since fixed.