[Gluster-infra] [Gluster-devel] NetBSD regressions not being triggered for patches
amukherj at redhat.com
Wed Jun 17 04:31:50 UTC 2015
On 06/17/2015 09:57 AM, Venky Shankar wrote:
> On Wed, Jun 17, 2015 at 9:50 AM, Atin Mukherjee <amukherj at redhat.com> wrote:
>> On 06/11/2015 08:04 PM, Emmanuel Dreyfus wrote:
>>> On Thu, Jun 11, 2015 at 04:04:44PM +0200, Niels de Vos wrote:
>>>> Michael installed and configured dnsmasq on build.gluster.org yesterday.
>>>> If that does not help today, we need other ideas...
>>> Just to confirm the problem:
>>> [manu at build ~]$ time nslookup nbslave7i.cloud.gluster.org
>>> ;; connection timed out; trying next origin
>>> ;; connection timed out; no servers could be reached
>>> real 0m20.013s
>>> user 0m0.002s
>>> sys 0m0.012s
>>> Having a local cache does not help because upstream DNS service is
>>> weak. Without the local cache, individual processes crave for a reply,
>>> and with the local server, the local server crave itself crave for
>>> a reply.
>>> And here upstream DNS is really at fault: at mine I get a reply in
>>> We need to configure a local authoritative secondary DNS for the zone,
>>> so that the answer is always available locally wihtout having to rely
>>> on outside's infrastructure.
>> I am not sure whether we have any improvements on this front. I still
>> see patches are waiting for ages to get their turn for the regression
>> run and hence delaying merges and effecting the release process.
>> I still feel we don't need to wait for NetBSD's vote for merging patches
>> on a temporary basis till we fix the infrastructure problem. This is the
>> only quick solution which I can think of now.
> That *might* result in lots of NetBSD regression failures later on and
> we may end up with another round of fixups.
Agreed, that's the known risk but we don't have any other alternatives atm.
> I can't think of a quick solution either.
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
More information about the Gluster-infra