<div dir="ltr">Thanks Clay that was exactly right!! I did the strings on the object.gz file and saw that port 6003 was in there - kinda weird since when I did swift-ring-builder object.builder I didnt show up?! In any case the containers seem now work via command line but now I when try using the Dashboard I get a 404 error when trying to list/create containers. Will dive into that now but phew, thank you very much for putting me on the right path!<div><br></div><div>Amit<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 30, 2014 at 5:30 PM, Clay Gerrard <span dir="ltr"><<a href="mailto:clay.gerrard@gmail.com" target="_blank">clay.gerrard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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</div><div><br></div><div>Get real paranoid about that.</div><div><br></div><div>It *has* to be true.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Good Luck!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Clay</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 30, 2014 at 12:28 PM, Amit Anand <span dir="ltr"><<a href="mailto:aanand@viimed.com" target="_blank">aanand@viimed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 :-)<div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 30, 2014 at 1:11 PM, Clay Gerrard <span dir="ltr"><<a href="mailto:clay.gerrard@gmail.com" target="_blank">clay.gerrard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. 
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>