Open Stack

oic, the proxy is on a different machine, and the storage node doesn't have
a proxy-server.conf - so the fact the proxy isn't starting on the storage
node is expected.  That's probably fine.

But the thing with the port is... it *has* to be coming from a ring, the
ring on the proxy actually, specifically /etc/swift/object.ring.gz

Get real paranoid about that.

It *has* to be true.

Extract object.ring.gz with gunzip and run strings on it, or use
ring-builder object.ring.gz write_builder to dump what's in the ring data
and figure out how the 6003 got in there.  If you still don't see 6003 in
the ring data then the proxy *is getting rings from somewhere else* because
rings are the only place the proxy looks for backend ports.  Check the
swift_dir setting in your proxy conf.  Delete the ring and restart the
proxy - it shouldn't start without it.

Also since `swift stat` is working you can run swift stat -v to get your
x-auth-token and try making some requests directly with curl.  Making some
object requests directly can cut out some of the noise you get when swift
client makes multiple requests in response to a single cli command.

Good Luck!

-Clay

On Thu, Oct 30, 2014 at 12:28 PM, Amit Anand <aanand at viimed.com> wrote:

> Thanks Clay. Yeah this is swift version 2.1.0. Ive done write_wring and
> copied the new .gz files to the object node still getting same error. I
> have no clue where port 6003 is coming from its driving me crazy :-)
>
>
>
> On Thu, Oct 30, 2014 at 1:11 PM, Clay Gerrard <clay.gerrard at gmail.com>
> wrote:
>
>> Well the device ports can only come from the rings. There is no default.
>> You're right the backend request is for an object - but maybe it's a
>> policy-1 ring?  You said icehouse though so maybe this isn't swift 2.0?
>> The swift-init error for proxy is troubling - you should figure out if
>> maybe the proxy process that is running is stale somehow and make sure it
>> can restart normally with no error. You should make sure all the ring.gz
>> are up to date with your builders - try to rebalance one more time - or use
>> write_ring. Also all the replication ports are 6002 - could cause problem
>> with replication. Also three replicas with only one device probably won't
>> be as successful as you might hope working around backend failures.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141030/56663f75/attachment.html>