Just noticed the changes have been backported to 1.6, that's great going.
Thanks Baptiste & Willy!
On 30 October 2015 at 14:52, Ben Tisdall wrote:
> On Fri, Oct 30, 2015 at 2:48 PM, Baptiste wrote:
>> On Fri, Oct 30, 2015 at 2:10 PM, Lukas Tribus wrote:
I sent patches to Willy, and they h
On Fri, Oct 30, 2015 at 2:48 PM, Baptiste wrote:
> On Fri, Oct 30, 2015 at 2:10 PM, Lukas Tribus wrote:
>>> I sent patches to Willy, and they have been integrated a few minutes ago.
>>> You can git pull ; make clean ; make [...]
>>
>> Unless you use haproxy-1.6, in that case you have to wait for
On Fri, Oct 30, 2015 at 2:10 PM, Lukas Tribus wrote:
>> I sent patches to Willy, and they have been integrated a few minutes ago.
>> You can git pull ; make clean ; make [...]
>
> Unless you use haproxy-1.6, in that case you have to wait for the backport
> and the git push, which has not happened
> I sent patches to Willy, and they have been integrated a few minutes ago.
> You can git pull ; make clean ; make [...]
Unless you use haproxy-1.6, in that case you have to wait for the backport
and the git push, which has not happened yet.
Lukas
On Fri, Oct 30, 2015 at 12:53 PM, Ben Tisdall wrote:
> On Thu, Oct 29, 2015 at 1:43 PM, Ben Tisdall wrote:
>
>> Sorry, I'm misinterpreting the test results, please ignore that. One
>> ELB address has remained the same today so it's likely HAProxy has
>> been using that and has not needed to updat
On Thu, Oct 29, 2015 at 1:43 PM, Ben Tisdall wrote:
> Sorry, I'm misinterpreting the test results, please ignore that. One
> ELB address has remained the same today so it's likely HAProxy has
> been using that and has not needed to update.
Ok, finally observed some more ELB address changes (2, t
On Wed, Oct 28, 2015 at 4:41 PM, Baptiste wrote:
> So, when you write
>if (cname && memcmp(ptr, cname, cnamelen))
>return DNS_UPD_NAME_ERROR;
> else if (memcmp(ptr, dn_name, dn_name_len))
> return DNS_UPD_NAME_ERROR;
>
>
On Thu, Oct 29, 2015 at 1:40 PM, Ben Tisdall wrote:
> Ok, testing with the latest
> 0001-BUG-MAJOR-dns-first-DNS-response-packet-not-matching.patch
> appears to work from the proxy POV but I'm not seeing the update
> counter incrementing on address changes.
Sorry, I'm misinterpreting the test res
Ok, testing with the latest
0001-BUG-MAJOR-dns-first-DNS-response-packet-not-matching.patch
appears to work from the proxy POV but I'm not seeing the update
counter incrementing on address changes.
On Wed, Oct 28, 2015 at 7:04 PM, Jesse Hathaway wrote:
> On Wed, Oct 28, 2015 at 12:00 PM, Baptiste wrote:
>> Good catch, forget about patch 1, It was 2AM in the morning when I
>> wrote it :'(...
>> I wanted to apply the same code as DNS_UPD_NO_IP_FOUND, and increment
>> the OTHER error.
>
>
On Wed, Oct 28, 2015 at 6:39 PM, Ben Tisdall wrote:
> On Wed, Oct 28, 2015 at 6:28 PM, Ben Tisdall wrote:
>> On Wed, Oct 28, 2015 at 6:00 PM, Baptiste wrote:
>>>
>>> Ben, could you apply the patch below instead of 0001:
>>>
>>> [snip]
>
> That patch is proving problematic to apply, to save me gu
On Wed, Oct 28, 2015 at 12:00 PM, Baptiste wrote:
> Good catch, forget about patch 1, It was 2AM in the morning when I
> wrote it :'(...
> I wanted to apply the same code as DNS_UPD_NO_IP_FOUND, and increment
> the OTHER error.
That is interesting, but I was asking about the second patch,
000
On Wed, Oct 28, 2015 at 6:28 PM, Ben Tisdall wrote:
> On Wed, Oct 28, 2015 at 6:00 PM, Baptiste wrote:
>>
>> Ben, could you apply the patch below instead of 0001:
>>
>> [snip]
That patch is proving problematic to apply, to save me guessing can
you provide it as an attachment please.
On Wed, Oct 28, 2015 at 6:00 PM, Baptiste wrote:
>
> Ben, could you apply the patch below instead of 0001:
>
> [snip]
Sure, will report back in the morning. Thanks Jesse and Baptiste :)
Ben
Jesse
On Wed, Oct 28, 2015 at 5:25 PM, Jesse Hathaway wrote:
> On Tue, Oct 27, 2015 at 8:18 PM, Baptiste wrote:
>> #2 an error in the way we parse CNAME responses, leading to return an
>> error when validating a CNAME (this triggers bug #1).
>
> How does your patch for this issue change the logi
On Tue, Oct 27, 2015 at 8:18 PM, Baptiste wrote:
> #2 an error in the way we parse CNAME responses, leading to return an
> error when validating a CNAME (this triggers bug #1).
How does your patch for this issue change the logic? It appears
functionally the same to me.
On Wed, Oct 28, 2015 at 4:29 PM, Baptiste wrote:
> Great, thanks for confirming!
>
Thanks for getting this sorted out Baptiste! Any idea of when the
fixes would be likely to be released and make it into the ppa?
--
Ben
Great, thanks for confirming!
Baptiste
On Wed, Oct 28, 2015 at 4:13 PM, Ben Tisdall wrote:
> On Wed, Oct 28, 2015 at 3:04 PM, Baptiste wrote:
>> Now, you can simply use whatever tool (ab, httperf, wrk, etc...)
>> hosted on a third party VM to inject traffic on ELB IP directly.
>> After a few mi
On Wed, Oct 28, 2015 at 3:04 PM, Baptiste wrote:
> Now, you can simply use whatever tool (ab, httperf, wrk, etc...)
> hosted on a third party VM to inject traffic on ELB IP directly.
> After a few minutes (less than 5), ELB service will be moved
> automatically to an other instance, leading IP to
Now, you can simply use whatever tool (ab, httperf, wrk, etc...)
hosted on a third party VM to inject traffic on ELB IP directly.
After a few minutes (less than 5), ELB service will be moved
automatically to an other instance, leading IP to change.
On HAProxy stat socket, you should see the 'update
On Wed, Oct 28, 2015 at 1:55 PM, Baptiste wrote:
>
> Have you forced resolution to ipv4 only?
> if not, could you give it a try?
>
Right, with "resolver-prefer ipv4":
Resolvers section aws
nameserver aws_0:
sent: 11
valid: 11
update: 0
cname: 0
cname_error: 0
any_err: 0
nx: 0
t
On Wed, Oct 28, 2015 at 11:36 AM, Ben Tisdall wrote:
> On Wed, Oct 28, 2015 at 10:15 AM, Ben Tisdall
> wrote:
>>
>> Thanks Baptiste, will get on this today.
>>
>
> Ok this in the test environment now and the "other" counter now
> increments in step with "valid", eg:
>
> Resolvers section aws
>
On Wed, Oct 28, 2015 at 10:15 AM, Ben Tisdall wrote:
>
> Thanks Baptiste, will get on this today.
>
Ok this in the test environment now and the "other" counter now
increments in step with "valid", eg:
Resolvers section aws
nameserver aws_0:
sent: 208
valid: 104
update: 0
cname: 0
cnam
On Wed, Oct 28, 2015 at 2:18 AM, Baptiste wrote:
> Ben,
>
> I found a couple of bugs:
> #1 an incomplete end of processing when the queried hostname can't be
> found in the response. This lead to the query loop you may have
> observed.
> #2 an error in the way we parse CNAME responses, leading to
Ben,
I found a couple of bugs:
#1 an incomplete end of processing when the queried hostname can't be
found in the response. This lead to the query loop you may have
observed.
#2 an error in the way we parse CNAME responses, leading to return an
error when validating a CNAME (this triggers bug #1).
On Wed, Oct 28, 2015 at 12:13 AM, Baptiste wrote:
> On Tue, Oct 27, 2015 at 11:44 AM, Ben Tisdall
> wrote:
>> Hi and thanks for a great load balancer. We're developing a much more
>> complex proxy ruleset and being able to switch back to haproxy now
>> that it supports DNS resolution was a huge
On Tue, Oct 27, 2015 at 11:44 AM, Ben Tisdall wrote:
> Hi and thanks for a great load balancer. We're developing a much more
> complex proxy ruleset and being able to switch back to haproxy now
> that it supports DNS resolution was a huge relief!
>
> Unfortunately DNS resolution is not doing what
Hi and thanks for a great load balancer. We're developing a much more
complex proxy ruleset and being able to switch back to haproxy now
that it supports DNS resolution was a huge relief!
Unfortunately DNS resolution is not doing what I expect given the
configuration. When the downstream ELB to wh
28 matches
Mail list logo
