Fix https://github.com/jubos/fake-s3/issues/114

[Kureev]

Our fork of fake_s3 can't recognize a request host and compose a 404 response (because we have a different network in docker).

see jubos#114 thread for more details

[aseyedmehdi]

Is this tested / will it work with our current dev setup still?

[Kureev]

• it's not tested, because the only way to test it is to merge it in and use it
• this fix has been applied in the origin docker/fake_s3 image
• current behavior will keep working

[felixhageloh]

should we merge our fork with upstream if it has been fixed there, instead?

[Kureev]

I remember @suweller said that we have something specific that is not a part of the upstream. That's the only reason why we use it. If that's no longer a point, I can use a fake_s3 docker image instead

[felixhageloh]

we do which is why I said merge with upstream (not replace with upstream)

[felixhageloh]

this is why we don't use the vanilla gem btw jubos#119

[felixhageloh]

we do have merge conflicts tho :/

[Kureev]

I think for now this particular fix is the leanest iteration

[felixhageloh]

so to give more detail: fakes3 doesn't / didn't support List Parts which is why we I made a fork (and a PR).
If the latest version does support it we can switch to that again

[felixhageloh]

not sure it is the leanest:
we should probably stay up to date with upstream so adding more changes will just make the merge conflict worse.
What might be leaner maybe is to not support fakes3 in the first iteration of docker?

[Kureev]

we should probably stay up to date with upstream so adding more changes will just make the merge conflict worse.

This change mimics upstream

[felixhageloh]

#4

maybe see if this branch works for you @Kureev
If it does, maybe rebasing will be better

[suweller]

Just rebase with upstream

[Kureev]

I think we need to communicate it all together

[Kureev]

I'm fine with either of these solutions. However, I'm not sure if rebasing the whole lib is a small step. We have 2k+ diff for a one-line fix