On Wed, Jun 17, 2015 at 11:48:46AM +0200, Michael Scherer wrote: > Le mercredi 17 juin 2015 à 08:20 +0200, Emmanuel Dreyfus a écrit : > > Venky Shankar <yknev.shan...@gmail.com> wrote: > > > > > If that's the case, then I'll vote for this even if it takes some time > > > to get things in workable state. > > > > See my other mail about this: you enter a new slave VM in the DNS and it > > does not resolve, or somethimes you get 20s delays. I am convinced this > > is the reason why Jenkins bugs. > > But cloud.gluster.org is handled by rackspace, not sure how much control > we have for it ( not sure even where to start there ).
On build.gluster.org there now is a /usr/local/bin/get-hosts.py script (needs to be executed through sude). This pulls down the DNS records from our cloud.gluster.org domain in Rackspace and proves a /etc/hosts formatted output. /etc/hosts on build.gluster.org contains all the current entries. We could automatically update it with a cron job or something, if needed. New VMs should get added to /etc/hosts too, either manually or by executing the script (sudo vim /etc/hosts, :r!/usr/local/bin/get-hosts.py). > And I think the DNS issues are just a symptom of a bigger network issue, > having local DNS might just mask the problem and which would then be non > DNS related ( like tcp connexion not working ). Maybe, but I hope those issues stay masked when resolving the hostnames is more stable. When we have the other servers up and running, we would have a better understanding and options to investigate issues like this. HTH, Niels _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
