QueueUrl response uses Host header instead of config address

[sthulb]

Hi,

It would be nice if elasticmq used the Host instead of what's in the config. A case for this is Docker, when using elasticmq in a container, the QueueUrl is almost certainly going to be wrong.

[adamw]

If I understand correctly, this can be achieved by setting the node-address properly (which can be different from the bind address). node-address is only used to create queue urls, in case when the address that should be used to reach the service is different from the bind one.

[waisbrot]

@sthulb the configuration I posted in #24 seems to be working for me. I do it like

$ docker run --name elasticmq elasticmq
$ docker run -it --link elasticmq:sqs.us-west-2.amazonaws.com client-container python

and then I can get Boto to talk to ElasticMQ and the queue URLs work.

[icambron]

@adamw I'd love for the queue URLs to be created from the host from the request.

I have the issue that I'm hosting ElasticMQ on Docker, and some connections to it come in from other Docker containers and some connections from outside of Docker entirely. Getting the hostname-as-seen-from-outside to be the same as hostname-as-seen-by-other-container is complicated and involves some ugly hostsfile hacking. That's why it doesn't help me much to just specify a different node-address; I really need the queue URL to be different based on how the client got to it.

I propose that if the bind-address is "0.0.0.0", that ElasticMQ just use the incoming host in the queue URLs, and ignore the host in node-address. One caveat, I guess--and this may just be that I don't understand how ElasticMQ works--is that this would mean that URLs and queues aren't one-to-one, since the same queue would need to be addressable on URLs with different hosts in them. Not sure whether that creates a problem or not.

I understand this might not be possible or just way too annoying or hard, and I'll work around it as best I can. I just wanted to point out why the node-address solution doesn't quite fit the bill.

[TomFrost]

+1. Same situation with Docker. I'm stuck building my test boxes with ugly /etc/hosts hacks just to get this running without polluting my codebase with test-specific logic.

[icambron]

I would be more than happy to write a PR for this if @adamw gives me the go-ahead.

[adamw]

Sure, I would be happy to get a PR in for this. Do I understand correctly that this would be a kind of a special setting for node-address meaning "return whatever the incoming host was"?

[icambron]

Yup, or a different setting. I originally had in mind that it could use bind-address, but that might break things for people. How does setting node-address to * sound?

[adamw]

I guess the node-address setting makes more sense here as it's the "outside visible" address. * sounds good as well :)

Btw. if you think it would make sense to do some breaking changes, now is a good moment, as I'm preparing a 0.9 release.

[wms]

I had a need for a similar feature when using ElasticMQ in a docker-compose environment, and found this workaround:

node-address {
    protocol = http
    host = ${HOSTNAME}
    port = 9324
    context-path = ""
}

[icambron]

I expected to have some time to do this by now, but haven't gotten the chance.

@warrenseymour - how does that work? Doesn't seem like that would set the queue URL on a per-request basis, but maybe I don't get it.

[wms]

@icambron I only needed the queue URL to exposed as something that was reachable from linked containers. In this case, the URL doesn't need to be set per-request; boot-time will suffice.

[icambron]

@warrenseymour does that address work for both your linked containers and from your host?

[wms]

@icambron Very good point that I had not considered; in my particular case, I have no interest in speaking to ElasticMQ from my host; only from within containers.

For that, I'll guess you'll need roll your sleeves up :)