Open Stack

On 08/06/16 10:50, Mark Kirkwood wrote:
> On 08/06/16 07:06, Pete Zaitcev wrote:
>
>>> The proxies are load balanced behind Haproxy (which I'm guessing is
>>> causing the 404 - see below)
>> HAproxy is often troublesome, but I don't expect it is at fault in
>> this instance. The logs that you quoted show that the proxy-server
>> returned the 404. Do proxies happen to talk to separate memcached
>> instances by any chance?
>
> Yeah - good point, each proxy has its own memcache.
>

Following up this point,

I can reproduce this issue by putting haproxy in front of some 
development proxies I have running as VMs on my workstation (easier to 
amend config in this case):

So I have 2 Swift proxies, each using itself as a memcache server (e.g 
proxy 192.168.122.21), other one (192.168.122.24) defined similarly:

$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211

changing this servers line to include the other proxy's memcache too 
(e.g proxy 192.168.122.21 again):

$ cat /etc/swift/proxy-server.conf
...
[filter:cache]
use = egg:swift#memcache
memcache_servers = 192.168.122.21:11211,192.168.122.24:11211

I no longer see any 404s with my test. Reading the install docs (a bit 
more carefully this time it seems), I see that they are leaning us 
towards doing that - am I understanding that correctly?

regards

Mark