While the container sync docs are comprehensive and well-written, they lack important information about the architecture & topology of sync deployments.
For example, it's not immediately apparent the fact that the container sync process runs on the container servers and connects to the remote cluster's proxy servers. This is worsened by the fact that the "allowed_sync_hosts" variable has the same name in both the container-sync section and in the authentication system section and by the fact that the documentation mentions an example of "allowed_sync_hosts = host1,host2,etc." in both cases. In other words, it's not immediately clear that in the [container-sync] section allowed_sync_hosts must be "proxy1,proxy2,etc." while in the authentication section in must list *all* of the container server backends of the remote cluster.
Additionally, the topology of how the container servers are connecting to the remote end's proxies is not very apparent, esp. since it's hard to imagine that the container servers which usually reside into one end's *internal* network are suddenly expected to connect to a comptely different site's frontends. I was told that a possible architecture would be to put an HTTP proxy server in each site, and have the container servers connect through that -- and, subsequently, have allowed_sync_hosts be that HTTP proxy server. Although this architecture was no use to me, I believe that it makes sense for others and actually helps to understand the deisgn behind this feature, and as such it belongs into the documentation.
I agree with you on the container-sync docs. What connects to what should be documented.
FYI, the allowed_sync_hosts variable is gone from the authentication system now; see https:/