Forum OpenACS Q&A: Re: naviserver cluster running inside of docker questions

Collapse
5: Re: naviserver cluster running inside of docker questions (response to 1)
Posted by Gustaf Neumann on 06/14/22 08:13 PM

Hi Marty,

I've added a small change to CVS to support the usage of HTTP locations in kernel parameter ClusterPeerIP

The change extends the values specified in ClusterPeerIP in two respects

  • one can now specify the protocol (defaults to http)
  • while ClusterPeerIP required an IP address, it is now possible to specify an DNS name

The DNS name is resolved for the time being at the start time of the OpenACS instance.

Sample supported values:

https://localhost http://[::1]:8443 127.0.0.1:8101

The last one defaults to "http", same as before. By using the "location" including the scheme we can support also UDP in the future (by using the nsudp NaviServer module) without refactoring. UDP will reduce the latency of the intra-cluster talk significantly.

Two questions:

  • is the DNS resolving at the start time of the OpenACS instance sufficient for your use case in Docker?
  • why did you specify the docker resolver (127.0.0.11) explicitly? It should be set up in the docker instance by default.

-g https://fisheye.openacs.org/changelog/OpenACS?cs=oacs-5-10%3Agustafn%3A20220614175936

Collapse
6: Re: NaviServer cluster running inside of docker questions (response to 5)
Posted by Marty Israelsen on 06/17/22 05:35 PM

When I click on the link to see the recent changes you made it says "No changeset with that ID found.".

Collapse
7: Re: NaviServer cluster running inside of docker questions (response to 5)
Posted by Gustaf Neumann on 06/18/22 09:39 AM
Sorry, markdown syntax problem, ....fixed
Collapse
8: Re: NaviServer cluster running inside of docker questions (response to 5)
Posted by Marty Israelsen on 06/20/22 11:42 PM
Thanks, Gustaf,

to answer your questions:

I think that it could be a problem to resolve the DNS on startup because of the timing issues. It is possible that they do not all startup at the exact same time, and therefore the code would be unable to resolve the DNS on startup.

Is there another place we could also try to resolve the DNS like at the time a custerwide command is issued, and we detect that one or more of the servers have not been resolved?

As for why I specified 127.0.0.11 in the nslookup? I believe you are right, it should be able to resolve without specifying the resolver.

Thanks for your help

Marty