[ANNOUNCE] HAProxy issue tracker is now open

[Lukas Tribus]

Hi,


as mentioned previously on the list, Tim Düsterhus, Willy and myself
have been discussing and working on the github issue tracker, setting
up issue templates and labels with the purpose to fully open it for
everyone. We have now reached that goal and consider the issue tracker
ready for everyone to use:

https://github.com/haproxy/haproxy/issues


The primary and most important benefit we expect from the issue
tracker is for bugs and feature-requests to not get lost/forgotten in
the stream of other discussion (as Tim put it). It will also make it
easier for everyone to understand the status of a bug, both in terms
of actual development as well as its backport (labels indicated which
branch is still affected).


Reporting issues to the mailing list is still absolutely encouraged,
the issue tracker doesn't change that. Some bugs can be fixed
immediately, not requiring an actual issue to be filed (especially
regarding recent code); other bugs require some discussion (which can
then be referenced in the issue on Github later). Some people may not
want to create a GitHub account for the purpose of reporting a bug -
that is also perfectly fine (we can file it). Reporting issues on the
mailing list is therefor here to stay, but by filing issue on Github
we are finally able to track them.

Issue labels are subject to change as the issue tracker gets more
exposure. I will be implementing (TODO) some basic automation that
reopens issues that - based on the assigned labels - are not supposed
to be closed and a weekly digest send to the mailing list summarizing
how the issue situation on github looks like, based on the assigned
labels.


regards,
- lukas

Re: haproxy issue tracker discussion

[Aleksandar Lazic]

Cool, thanks :-)


 Ursprüngliche Nachricht 
Von: Lukas Tribus 
Gesendet: 18. Jänner 2019 14:14:06 MEZ
An: Aleksandar Lazic 
CC: haproxy , Willy Tarreau , "Tim 
Düsterhus" 
Betreff: Re: haproxy issue tracker discussion

Hello Aleksandar,


On Fri, 18 Jan 2019 at 12:54, Aleksandar Lazic  wrote:
>
> Hi.
>
> As there are now the github templates in the repo can / should we start to 
> create issues &  features on github?

Yes, you can go ahead and start filing bugs and features.

There's some minor tweaking yet to be done regarding the subsystem
labels, but that's not really a blocking issue. Once that is done, I
will send out a proper announcement on the list (tomorrow, probably).


Lukas

Re: haproxy issue tracker discussion

[Lukas Tribus]

Hello Aleksandar,


On Fri, 18 Jan 2019 at 12:54, Aleksandar Lazic  wrote:
>
> Hi.
>
> As there are now the github templates in the repo can / should we start to 
> create issues &  features on github?

Yes, you can go ahead and start filing bugs and features.

There's some minor tweaking yet to be done regarding the subsystem
labels, but that's not really a blocking issue. Once that is done, I
will send out a proper announcement on the list (tomorrow, probably).


Lukas

Re: haproxy issue tracker discussion

[Aleksandar Lazic]

Hi.

As there are now the github templates in the repo can / should we start to 
create issues &  features on github?

Regards
Aleks


 Ursprüngliche Nachricht 
Von: Willy Tarreau 
Gesendet: 14. Jänner 2019 04:11:17 MEZ
An: "Tim Düsterhus" 
CC: Lukas Tribus , haproxy 
Betreff: Re: haproxy issue tracker discussion

On Mon, Jan 14, 2019 at 03:06:54AM +0100, Tim Düsterhus wrote:
> May I suggest the following to move forward?
(...)
> That way we can test the process with a small, unimportant, test issue.
> The automated closing based on the labels can than be added a few days
> later. I don't expect huge numbers of issues right away, so they can be
> closed by hand.

Sounds good to me.

Thanks guys!
Willy

Re: haproxy issue tracker discussion

[Willy Tarreau]

On Mon, Jan 14, 2019 at 03:06:54AM +0100, Tim Düsterhus wrote:
> May I suggest the following to move forward?
(...)
> That way we can test the process with a small, unimportant, test issue.
> The automated closing based on the labels can than be added a few days
> later. I don't expect huge numbers of issues right away, so they can be
> closed by hand.

Sounds good to me.

Thanks guys!
Willy

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,
Lukas,

Am 14.01.19 um 02:08 schrieb Lukas Tribus:
> My simple github script which relays the PR to the mailing list uses
> the GH Rest API through the agithub client [1]. I will have a look at
> how extensible it is, but extracting labels of closed issues and
> reopening it if it contains one of the "affected" labels should be
> quite simple.

I suggest to not fully rely on the webhooks (they might not be delivered
under high load).

Also: The automated closing / opening should only happen for type: bug
labels.

> I added labels based on the previous discussion (and removing and
> skipping some of them, as we are already at 30 labels anyway):
> 
> https://github.com/lukastribus/hap-issue-trial/labels?sort=name-asc

I suggest to make it less colorful. e.g. use a single color for all the
subsystems (they are probably the least interesting label).

---

May I suggest the following to move forward?

1. Enable the issue tracker on GitHub.
2. Set up the labels based in the list in Lukas' repository.
3. Prepare a patch that adds the issue templates, with a `see #1` in the
commit message body.

Ideally Lukas would do this, he did the bulk work of testing with the
templates (you can add me as a Co-authored-by: Tim Düsterhus
 at the bottom).

Lukas: You probably need to update the "bug" label to "type: bug" in the
Bug.md template.
4. Someone creates a first issue titled "Add issue templates".
5. The patch is merged by Willy.
6. The issue is being closed by Willy.

That way we can test the process with a small, unimportant, test issue.
The automated closing based on the labels can than be added a few days
later. I don't expect huge numbers of issues right away, so they can be
closed by hand.

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Lukas Tribus]

Hello,

On Sat, 12 Jan 2019 at 13:38, Willy Tarreau  wrote:
> > The situation on GitHub does not need to mirror the situation on
> > haproxy.org. You could still use separated repositories on haproxy.org
> > to separate permissions and push the "validated" commits to GitHub. This
> > is what the PHP project does. The canonical repositories lives on their
> > infrastructure and GitHub is a mirror only. They have a pre-receive hook
> > that prevents pushes if files / branches outside one's permission set
> > are touched: https://github.com/php/karma/blob/master/hooks/pre-receive

Cool, did not know that.


> > Just mentioning the issue does not close it! You have to prefix the
> > number with a "(Fix(es)?|Closes?)".
> > Mentioning the issue comes with the nice property that the commit
> > appears in the timeline of the issue, which I consider useful.
>
> Got it, I didn't think about this, makes sense indeed. I agree that
> given that we'll have unique ID numbers across all branches, it would
> be sad not to be able to easily reference them.

Yes, I agree that ideally we should be able to reference the issue #ID
from the commits, and if we can mirror stable branches into the same
repository on github, it should just work for all of them.



> > > Mind you that I don't have any idea what language this code block uses nor
> > > where it has to be stuffed, so I'll trust you :-)
> >
> > It's the Graph Query Language the v4 API of GitHub uses:
> > https://developer.github.com/v4/. You send it as the body of the HTTP
> > API request and get back a JSON formatted reply with the data you asked
> > for. And if it's non-empty you send a new API request that opens /
> > closes the issue in question.
> > Where it needs to be stuffed: On some server that runs a cronjob /
> > ingests the webhooks. :-)
>
> Thanks for the explanation.
>
> > In the long run it can probably be stuffed as a GitHub Action and be
> > part of the repository (in the .github folder). They are still a Beta,
> > though: https://developer.github.com/actions/
>
> Thanks for the link, I wasn't aware of this.

Yeah I think there are a lot of possibilities.

My simple github script which relays the PR to the mailing list uses
the GH Rest API through the agithub client [1]. I will have a look at
how extensible it is, but extracting labels of closed issues and
reopening it if it contains one of the "affected" labels should be
quite simple.

I added labels based on the previous discussion (and removing and
skipping some of them, as we are already at 30 labels anyway):

https://github.com/lukastribus/hap-issue-trial/labels?sort=name-asc


Also Tim improved the issue templates.


Regards,
Lukas

[1] https://github.com/mozilla/agithub

Re: haproxy issue tracker discussion

[Willy Tarreau]

On Sat, Jan 12, 2019 at 01:09:08PM +0100, Tim Düsterhus wrote:
> Willy,
> 
> Am 12.01.19 um 12:45 schrieb Willy Tarreau:
> >> This example makes me wonder, though: Should the various branches be
> >> separate repositories on GitHub like on haproxy.org or should they be
> >> actual branches (e.g. 1.8.x in haproxy/haproxy instead of
> >> haproxy/haproxy-1.8) for the mirror?
> > 
> > I've been thinking about this for a while in the past, which is the
> > reason why we purposely didn't upload the other branches yet. On the
> > one hand having all branches at once in a single repository is
> > convenient to retrieve everything at once. On the other hand, most
> > people cloning the repo are not interested in retrieving maintenance
> > versions for old branches. In addition, while at the moment and for
> > simplicity reasons, all stable maintainers do have write access to
> > the master repository, in the future we could imagine delegating some
> > outdated branches to certain contributors who still need to maintain
> > them for whatever reason, and in this case we might not feel much at
> > ease with granting them a write access to all other repos and have to
> > face their occasional mistakes.
> 
> The situation on GitHub does not need to mirror the situation on
> haproxy.org. You could still use separated repositories on haproxy.org
> to separate permissions and push the "validated" commits to GitHub. This
> is what the PHP project does. The canonical repositories lives on their
> infrastructure and GitHub is a mirror only. They have a pre-receive hook
> that prevents pushes if files / branches outside one's permission set
> are touched: https://github.com/php/karma/blob/master/hooks/pre-receive
> 
> The post-receive hook would then do the following for dev:
> 
> git push github master:master
> git push github --tags
> 
> And this for 1.8:
> 
> git push github master:1.8.x
> git push github --tags

Well, maybe indeed. However if a new maintainer comes and wants to follow
a different process he will need the permissions to push to GH. But you're
making a point that anyway GH is only a mirror so he'll have to have access
to haproxy.org and publish the reference there, so that might work anyway.
As you see, I'm mentioning use cases, though I'll probably not be the one
having the last word on the implementation given that I'll rely on others'
help.

> Just mentioning the issue does not close it! You have to prefix the
> number with a "(Fix(es)?|Closes?)".
> Mentioning the issue comes with the nice property that the commit
> appears in the timeline of the issue, which I consider useful.

Got it, I didn't think about this, makes sense indeed. I agree that
given that we'll have unique ID numbers across all branches, it would
be sad not to be able to easily reference them.

> > Mind you that I don't have any idea what language this code block uses nor
> > where it has to be stuffed, so I'll trust you :-)
> 
> It's the Graph Query Language the v4 API of GitHub uses:
> https://developer.github.com/v4/. You send it as the body of the HTTP
> API request and get back a JSON formatted reply with the data you asked
> for. And if it's non-empty you send a new API request that opens /
> closes the issue in question.
> Where it needs to be stuffed: On some server that runs a cronjob /
> ingests the webhooks. :-)

Thanks for the explanation.

> In the long run it can probably be stuffed as a GitHub Action and be
> part of the repository (in the .github folder). They are still a Beta,
> though: https://developer.github.com/actions/

Thanks for the link, I wasn't aware of this.

> > OK, that's manageable I guess, thanks. I find it a bit annoying that it uses
> > the code repository to store the github interface configuration but aside
> > this it's probably OK.
> 
> At least you can use the .github/ hidden folder now. In former times
> they had to be placed at the root of the repository.

Ah so we're seeing the improved version :-)

>  status: pending-backport
> >>>
> >>> I think this one is implied by the presence of "affects:"
> >>
> >> Not necessarily. "affects" without "pending-backport" probably needs
> >> more work finding the issue first, while "pending-backport" can be as
> >> easy as a cherry-pick.
> > 
> > OK I see your point but in this case the dev branch is fixed,
> > "affects: dev" is not there anymore then pending-backport is implied
> > by ("affects: 1.x" and not "affects: dev"). This even works for bugs
> > that only affect older branches. 
> 
> Does it? What if a bug is found that only affects the current stable
> branch, but not dev, because some refactoring "accidentally" fixed it?

In practice we *always* first try to diagnose the issue in -dev. The
only case where dev is not affected but an older branch is affected is
when we have diagnosed it enough to know that dev is really not affected.

However I'm seeing the problem with -dev : we need to know that a fix
is known. It's the "status: resolved" that 

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,

Am 12.01.19 um 12:45 schrieb Willy Tarreau:
>> This example makes me wonder, though: Should the various branches be
>> separate repositories on GitHub like on haproxy.org or should they be
>> actual branches (e.g. 1.8.x in haproxy/haproxy instead of
>> haproxy/haproxy-1.8) for the mirror?
> 
> I've been thinking about this for a while in the past, which is the
> reason why we purposely didn't upload the other branches yet. On the
> one hand having all branches at once in a single repository is
> convenient to retrieve everything at once. On the other hand, most
> people cloning the repo are not interested in retrieving maintenance
> versions for old branches. In addition, while at the moment and for
> simplicity reasons, all stable maintainers do have write access to
> the master repository, in the future we could imagine delegating some
> outdated branches to certain contributors who still need to maintain
> them for whatever reason, and in this case we might not feel much at
> ease with granting them a write access to all other repos and have to
> face their occasional mistakes.

The situation on GitHub does not need to mirror the situation on
haproxy.org. You could still use separated repositories on haproxy.org
to separate permissions and push the "validated" commits to GitHub. This
is what the PHP project does. The canonical repositories lives on their
infrastructure and GitHub is a mirror only. They have a pre-receive hook
that prevents pushes if files / branches outside one's permission set
are touched: https://github.com/php/karma/blob/master/hooks/pre-receive

The post-receive hook would then do the following for dev:

git push github master:master
git push github --tags

And this for 1.8:

git push github master:1.8.x
git push github --tags

> This matches perfectly the situation I've been into with the kernel:
> I inherited old ones and other developers didn't have to be scared by
> my mistakes because I could only affect the part I was responsible for.
> As such it makes me think that it's probably better to only have the
> master branch in the main repo, and create separate repos for the
> maintenance branches.
> 
>> The former would require referencing issues as haproxy/haproxy#123. The
>> latter allows for a more simple #123.
> 
> Given that we'd prefer *not* to see them automatically closed, I don't
> see this as a limitation, on the opposite!

Just mentioning the issue does not close it! You have to prefix the
number with a "(Fix(es)?|Closes?)".
Mentioning the issue comes with the nice property that the commit
appears in the timeline of the issue, which I consider useful.

>> The following GitHub v4 API query pulls issues with
>> state == OPEN && (label == "1.6-affected" || label == "enhancement")
>> for Lukas' test repository from the API. "enhancement" is to be replaced
>> by the other "*-affected" labels.
>>
>> {
>>   repository(owner: "lukastribus", name: "hap-issue-trial") {
>> issues(states: [OPEN], labels: ["1.6-affected", "enhancement"],
>> last: 100) {
>>   nodes {
>> title
>>   }
>> }
>>   }
>> }
> 
> Mind you that I don't have any idea what language this code block uses nor
> where it has to be stuffed, so I'll trust you :-)

It's the Graph Query Language the v4 API of GitHub uses:
https://developer.github.com/v4/. You send it as the body of the HTTP
API request and get back a JSON formatted reply with the data you asked
for. And if it's non-empty you send a new API request that opens /
closes the issue in question.
Where it needs to be stuffed: On some server that runs a cronjob /
ingests the webhooks. :-)

In the long run it can probably be stuffed as a GitHub Action and be
part of the repository (in the .github folder). They are still a Beta,
though: https://developer.github.com/actions/

 - and issue and feature request template
>>>
>>> For this one I have no idea since I don't know much how it works.
>>
>> You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the
>> repository:
>>
>> https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md
>>
>> see:
>> https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/
> 
> OK, that's manageable I guess, thanks. I find it a bit annoying that it uses
> the code repository to store the github interface configuration but aside
> this it's probably OK.

At least you can use the .github/ hidden folder now. In former times
they had to be placed at the root of the repository.

 status: pending-backport
>>>
>>> I think this one is implied by the presence of "affects:"
>>
>> Not necessarily. "affects" without "pending-backport" probably needs
>> more work finding the issue first, while "pending-backport" can be as
>> easy as a cherry-pick.
> 
> OK I see your point but in this case the dev branch is fixed,
> "affects: dev" is not there anymore then pending-backport is implied
> by ("affects: 1.x" and not "affects: 

Re: haproxy issue tracker discussion

[Willy Tarreau]

Hi Tim,

On Sat, Jan 12, 2019 at 12:24:23PM +0100, Tim Düsterhus wrote:
> > This one is less of a problem because the likelihood that someone writes
> > "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless
> > they do it on purpose to annoy us of course.
> 
> It would only close on us, if the person creating the other commit had
> the necessary permissions in our issue tracker.

OK.

> This example makes me wonder, though: Should the various branches be
> separate repositories on GitHub like on haproxy.org or should they be
> actual branches (e.g. 1.8.x in haproxy/haproxy instead of
> haproxy/haproxy-1.8) for the mirror?

I've been thinking about this for a while in the past, which is the
reason why we purposely didn't upload the other branches yet. On the
one hand having all branches at once in a single repository is
convenient to retrieve everything at once. On the other hand, most
people cloning the repo are not interested in retrieving maintenance
versions for old branches. In addition, while at the moment and for
simplicity reasons, all stable maintainers do have write access to
the master repository, in the future we could imagine delegating some
outdated branches to certain contributors who still need to maintain
them for whatever reason, and in this case we might not feel much at
ease with granting them a write access to all other repos and have to
face their occasional mistakes.

This matches perfectly the situation I've been into with the kernel:
I inherited old ones and other developers didn't have to be scared by
my mistakes because I could only affect the part I was responsible for.
As such it makes me think that it's probably better to only have the
master branch in the main repo, and create separate repos for the
maintenance branches.

> The former would require referencing issues as haproxy/haproxy#123. The
> latter allows for a more simple #123.

Given that we'd prefer *not* to see them automatically closed, I don't
see this as a limitation, on the opposite!

> > I'm wondering if based on the previous work you did on the
> > pull requests using the API it would be possible to :
> >   - reopen closed issues that still have a "*-affected" or "needs triage" 
> > label
> >   - close issues that don't have "*-affected" nor "needs triage"
> > 
> > In this case it would mean we just need to use the labels and not care
> > about the state at all.
> 
> Yes. You can pull issues with a specific state and a specific label from
> the API and you can receive webhooks when an issue is being opened or
> closed.

Fine!

> The following GitHub v4 API query pulls issues with
> state == OPEN && (label == "1.6-affected" || label == "enhancement")
> for Lukas' test repository from the API. "enhancement" is to be replaced
> by the other "*-affected" labels.
> 
> {
>   repository(owner: "lukastribus", name: "hap-issue-trial") {
> issues(states: [OPEN], labels: ["1.6-affected", "enhancement"],
> last: 100) {
>   nodes {
> title
>   }
> }
>   }
> }

Mind you that I don't have any idea what language this code block uses nor
where it has to be stuffed, so I'll trust you :-)

> >> - and issue and feature request template
> > 
> > For this one I have no idea since I don't know much how it works.
> 
> You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the
> repository:
> 
> https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md
> 
> see:
> https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/

OK, that's manageable I guess, thanks. I find it a bit annoying that it uses
the code repository to store the github interface configuration but aside
this it's probably OK.

> >> status: pending-backport
> > 
> > I think this one is implied by the presence of "affects:"
> 
> Not necessarily. "affects" without "pending-backport" probably needs
> more work finding the issue first, while "pending-backport" can be as
> easy as a cherry-pick.

OK I see your point but in this case the dev branch is fixed,
"affects: dev" is not there anymore then pending-backport is implied
by ("affects: 1.x" and not "affects: dev"). This even works for bugs
that only affect older branches. It's even better as we have always
implied that a backport to a branch is not welcome until the next
branch is fixed. Thus the "backport-pending" for a branch is always
deduced from "affects: branch" and not "affects:next branch".

Willy

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,

Am 12.01.19 um 08:47 schrieb Willy Tarreau:
>> The following issue was closed ... :
>> https://github.com/lukastribus/hap-issue-trial/issues/3
>>
>> from another repository, just because I referenced the issue
>> prepending the word "Fix":
>> https://github.com/lukastribus/hap-issue-trial-1.8/commit/91a0776fec856766c64b8f3a34a796718c2368c1
> 
> This one is less of a problem because the likelihood that someone writes
> "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless
> they do it on purpose to annoy us of course.

It would only close on us, if the person creating the other commit had
the necessary permissions in our issue tracker.

This example makes me wonder, though: Should the various branches be
separate repositories on GitHub like on haproxy.org or should they be
actual branches (e.g. 1.8.x in haproxy/haproxy instead of
haproxy/haproxy-1.8) for the mirror?

The former would require referencing issues as haproxy/haproxy#123. The
latter allows for a more simple #123.

>> As our intention I believe is to keep the issue open until all
>> affected branches are fixed, this github feature is a little
>> inconvenient. But I guess we can just refer to the issue by prepending
>> it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like
>> we are working against the system.
> 
> As often yes. I'm wondering if based on the previous work you did on the
> pull requests using the API it would be possible to :
>   - reopen closed issues that still have a "*-affected" or "needs triage" 
> label
>   - close issues that don't have "*-affected" nor "needs triage"
> 
> In this case it would mean we just need to use the labels and not care
> about the state at all.

Yes. You can pull issues with a specific state and a specific label from
the API and you can receive webhooks when an issue is being opened or
closed.

The following GitHub v4 API query pulls issues with
state == OPEN && (label == "1.6-affected" || label == "enhancement")
for Lukas' test repository from the API. "enhancement" is to be replaced
by the other "*-affected" labels.

{
  repository(owner: "lukastribus", name: "hap-issue-trial") {
issues(states: [OPEN], labels: ["1.6-affected", "enhancement"],
last: 100) {
  nodes {
title
  }
}
  }
}

>> - and issue and feature request template
> 
> For this one I have no idea since I don't know much how it works.

You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the
repository:

https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md

see:
https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/

>> status: pending-backport
> 
> I think this one is implied by the presence of "affects:"

Not necessarily. "affects" without "pending-backport" probably needs
more work finding the issue first, while "pending-backport" can be as
easy as a cherry-pick.

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Lukas,

Am 12.01.19 um 02:53 schrieb Lukas Tribus:
> As our intention I believe is to keep the issue open until all
> affected branches are fixed, this github feature is a little
> inconvenient. But I guess we can just refer to the issue by prepending
> it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like
> we are working against the system.

Simply doing "see #123" / "ref #123" instead of "Fixes #123" probably
would work as well. The rest of the message probably makes it clear that
it's a fix.

> - a rough consensus of the process (like the sequence above)

It's looking good. I believe the initial "needs-triage" label can be
added using the template:
https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/
(step 5).

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Willy Tarreau]

Hi Lukas,

On Sat, Jan 12, 2019 at 02:53:45AM +0100, Lukas Tribus wrote:
> Hi Tim, Willy,
> 
> apologies for not responding sooner, I always have to force myself to
> policy/organizational discussions, when I can also read stack or
> straces :)

You really don't need to apologize :-)

> > So in the end we can live with simply "affects-1.8" etc and remove these
> > flags once the fix(es) is/are backported.
> 
> I like that. If it has that branch specific affected label, we know
> there is still something to do. We can add and remove a label multiple
> times if required (when having backporting issues).
> 
> So for example a new issue is opened and handled in the following sequence?
> 
> - OP opens a new issue
> - we assign generic default labels, for example: needs-triage
> - first human responder may ask for further information's, adds
> status: gathering feedback
> - OP responds with additional information's
> - triaging occurs, removing status: gathering feedback, needs-triage;
> adding bug, dev-affected, 1.8-affected, 1.7-affected, bisected
> - assigning for example a MAINTAINER to the bug (would be useful if
> MAINTAINERS had github accounts and we document those in the file)
> - the bug is fixed in -dev and marked for backport, removing dev-affected
> - backported to 1.8, removing 1.8-affected
> - backported to 1.7, removing 1.7-affected and closing issue (all
> backports completed)
> - OP reports the bug is still present in 1.7 (post fix)
> - we re-open the issue add 1.7-affected again

This last point is exactly what I was thinking as well and I like this.
I consider issues a cleaner and more reliable todo-list. It follows
exactly the process we're currently living with. In my todo notes it's
sometimes written "backport Foo's fix to 1.7". And this can be added
at any point in time, even when backporting it to 1.8 because it was
only diagnosed as affecting 1.8 and during the backport it was figured
that it in fact also affects another one.

Another good point is that it can allow us to emit an emergency fix
for a previously closed branch if we think it comes with a low cost
and is worth it. Then it's trivial to reopen the issue for this
unplanned operation.

> - after a new fix for 1.7 has been committed, remove the label and
> close the issue again

Yep.

> Just to get a feel for it, I'm playing with a trial repo here:
> https://github.com/lukastribus/hap-issue-trial/
> 
> I added some labels, stole template from another project (restic) with
> slight modifications and talked to myself over some issue. Also tried
> referencing issues from commits and vice-versa.

It's a good idea to have a label the suggested severity level. It doesn't
prevent the developer from changing it later (especially increasing it)
but it definitely helps. It even allows to lower it when the last backports
only are pending and the issue is less important (this is quite common,
like crashes in 1.9 but only returns an error in 1.8).

> I don't like how github automatically closes issues when commits refer
> to a issue prepended with some specific words like Fix or resolves:
> https://help.github.com/articles/closing-issues-using-keywords/

It's always been one of my concerns as well. In some projects, contributors
provide fixes with their internal bug IDs, and this can automatically close
random issues when IDs collide. As usual it shows that the tool focuses
more on ease of use and limited effort than accuracy and fine-grained
control.

> The following issue was closed ... :
> https://github.com/lukastribus/hap-issue-trial/issues/3
> 
> from another repository, just because I referenced the issue
> prepending the word "Fix":
> https://github.com/lukastribus/hap-issue-trial-1.8/commit/91a0776fec856766c64b8f3a34a796718c2368c1

This one is less of a problem because the likelihood that someone writes
"fixes haproxy/haproxy/#4" in a commit message is particularly low, unless
they do it on purpose to annoy us of course.

> As our intention I believe is to keep the issue open until all
> affected branches are fixed, this github feature is a little
> inconvenient. But I guess we can just refer to the issue by prepending
> it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like
> we are working against the system.

As often yes. I'm wondering if based on the previous work you did on the
pull requests using the API it would be possible to :
  - reopen closed issues that still have a "*-affected" or "needs triage" label
  - close issues that don't have "*-affected" nor "needs triage"

In this case it would mean we just need to use the labels and not care
about the state at all.

> So we'd have to define:
> 
> - a rough consensus of the process (like the sequence above)
> - the actual set of labels

Your proposal below looks reasonably good, probably we can refine them
later.

> - and issue and feature request template

For this one I have no idea since I don't know much how it works.

> I like the type and status labels 

Re: haproxy issue tracker discussion

[Lukas Tribus]

Hi Tim, Willy,



apologies for not responding sooner, I always have to force myself to
policy/organizational discussions, when I can also read stack or
straces :)


>> When should the binary "issue open" / "issue closed" property be
>> toggled? When the issue is fixed in Dev? When the issue is fixed in the
>> lowest affected version?
>
> [...]
> Conclusion : the affected status is only temporary and enough to go
> once the backport is done. This simply means we don't need a "fixed-1.9"
> or whatever, we just have to remove the "affected" label exactly as it
> would have been if the issue had been reported the day after.
>
> So in the end we can live with simply "affects-1.8" etc and remove these
> flags once the fix(es) is/are backported.

I like that. If it has that branch specific affected label, we know
there is still something to do. We can add and remove a label multiple
times if required (when having backporting issues).

So for example a new issue is opened and handled in the following sequence?

- OP opens a new issue
- we assign generic default labels, for example: needs-triage
- first human responder may ask for further information's, adds
status: gathering feedback
- OP responds with additional information's
- triaging occurs, removing status: gathering feedback, needs-triage;
adding bug, dev-affected, 1.8-affected, 1.7-affected, bisected
- assigning for example a MAINTAINER to the bug (would be useful if
MAINTAINERS had github accounts and we document those in the file)
- the bug is fixed in -dev and marked for backport, removing dev-affected
- backported to 1.8, removing 1.8-affected
- backported to 1.7, removing 1.7-affected and closing issue (all
backports completed)
- OP reports the bug is still present in 1.7 (post fix)
- we re-open the issue add 1.7-affected again
- after a new fix for 1.7 has been committed, remove the label and
close the issue again


Just to get a feel for it, I'm playing with a trial repo here:
https://github.com/lukastribus/hap-issue-trial/

I added some labels, stole template from another project (restic) with
slight modifications and talked to myself over some issue. Also tried
referencing issues from commits and vice-versa.

I don't like how github automatically closes issues when commits refer
to a issue prepended with some specific words like Fix or resolves:
https://help.github.com/articles/closing-issues-using-keywords/

The following issue was closed ... :
https://github.com/lukastribus/hap-issue-trial/issues/3

from another repository, just because I referenced the issue
prepending the word "Fix":
https://github.com/lukastribus/hap-issue-trial-1.8/commit/91a0776fec856766c64b8f3a34a796718c2368c1


As our intention I believe is to keep the issue open until all
affected branches are fixed, this github feature is a little
inconvenient. But I guess we can just refer to the issue by prepending
it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like
we are working against the system.



So we'd have to define:

- a rough consensus of the process (like the sequence above)
- the actual set of labels
- and issue and feature request template


I like the type and status labels of netbox:
https://github.com/digitalocean/netbox/labels


How about something like this (status: and type: should be unique):

help wanted
needs-triage
bisected

affected/dev
affected/1.9
affected/1.8
affected/1.7
affected/1.6

status: accepted
status: blocked
status: duplicate
status: gathering feedback
status: rejected
status: revisions needed
status: pending-backport
status: done

type: bug
type: documentation
type: change request
type: housekeeping
type: major feature
type: minor feature

and maybe some technical labels like "subsystem: xyz". Maybe
needs-triage should be "status: needs-triage".


Regards,
Lukas

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,

Am 10.01.19 um 19:40 schrieb Willy Tarreau:
> Conclusion : the affected status is only temporary and enough to go
> once the backport is done. This simply means we don't need a "fixed-1.9"
> or whatever, we just have to remove the "affected" label exactly as it
> would have been if the issue had been reported the day after.
> 
> So in the end we can live with simply "affects-1.8" etc and remove these
> flags once the fix(es) is/are backported.

Makes sense.

> We could decide that bugs for which no "affects-X.Y" label exist anymore
> can be closed. That doesn't mean the issue doesn't affect older branch,
> it means it's not known to affect them yet, which is similar to before
> the bug report (since an issue tracker only tracks known defects and not
> hypothetical ones).

Ideally the backports would happen more timely to keep the list of
"Open" issues clean. Otherwise some of the "Open" issues are completely
unfixed, while for others "merely" the backport is missing.

> With this model, there is less work for everyone involved, all the info
> is concentrated together, users can see that their version remains bogus
> because we don't know how to backport the fix but the next one is fixed
> so it might be time to upgrade, and there's much less info duplication
> leading to the inevitable consistency that comes from it.

I guess that will work then.

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Willy Tarreau]

Hi Tim,

On Thu, Jan 10, 2019 at 04:12:54PM +0100, Tim Düsterhus wrote:
> > I tend to think that if labels already mark the relevance to a branch,
> > then they override the status and probably we don't really care about
> > the status. The "moby" project above does that by the way, with
> > "status/foo" labels. We could possibly have had "v1.8-open" and
> > "v1.8x-done". This way instead of searching by status users can
> > search by clicking on the labels. I could just be missing something.
> 
> When should the binary "issue open" / "issue closed" property be
> toggled? When the issue is fixed in Dev? When the issue is fixed in the
> lowest affected version?

In fact, I've given some thinking to this and came to the conclusion
that a status is only valid at the moment it is consulted. Example :

 - bug is reported as affecting 1.8
 - it is diagnosed
 - it is figured that 1.9 is affected as well, but for an unkonwn
   reason, dev is not
 - it gets marked for 1.9, 1.8, all of which have to be fixed.
 - in the mean time another backport from dev to 1.9 happens to fix
   it, so the "affects 1.9" status is not true anymore.
 - later it is figured that dev was safe and 1.9 became safe thanks
   to this later commit

=> in this case both 1.8 and 1.9 were initially marked as affected

But now imagine the exact same bug was reported only one day later :

 - a seemingly unrelated backport from dev to 1.9 protects 1.9 against
   the bug
 - bug is reported as affecting 1.8
 - it is diagnosed
 - it is figured that 1.8 is the only one affected, but for an unkonwn
   reason, 1.9 and dev are not
 - later it is figured that dev and 1.9 were safe thanks to the former
   commit

=> in this case only 1.8 was marked as affected

Conclusion : the affected status is only temporary and enough to go
once the backport is done. This simply means we don't need a "fixed-1.9"
or whatever, we just have to remove the "affected" label exactly as it
would have been if the issue had been reported the day after.

So in the end we can live with simply "affects-1.8" etc and remove these
flags once the fix(es) is/are backported.

> Both is not ideal, I guess. Maybe we need to automatically create follow
> up issues for the various branches once the fix lands in dev:

I really don't like this for the reason I explained : they cut the discussion
in the middle most often to restart it in another one for the exact branch the
issue was reported for. User reports issue on 1.9, we create it, then create
another issue for 1.9, which makes no sense for users' point of view and is
extremely confusing from the outside. You look at the bug fixed in dev, it
was reported as 1.9 and marked fixed, while 1.9 is still affected. Given that
the primary purpose of the public issue tracker is to expose statuses that
users can search into, I'd really want to have them all together. There's
hardly version-specific discussions, and the rare times it will happen, it
doesn't cost much to have them together but it is a huge pain to have them
separate. Also, if an issue is met during the backport (while working on
the automatically created branch-specific issue), there's no easy way to
share the info with the other branches which are covered by different issues.

Since the other branches statuses will have to be checked in the primary one
anyway, better have all statuses there.

> 1. User creates issue #123.
> 
> > Subject: If I foo then haproxy replies with bar instead of baz
> >
> > If I foo then haproxy replies with bar and this is very bad!
> 
> 2. Developer fixes the issue in dev, noting the branches to backport in
> the commit message. Ideal in a machine-parseable format (Backport-To: 1.8)
> 
> > BUG/MINOR: foo: Make haproxy reply with baz
> >
> > This fixes issue #123.
> >
> > Backport-To: 1.8
> > Backport-To: 1.7

There is a race here : the diag of affected branches arrives much earlier
than the fix, hence the commit message. And very often the whole extent is
not known at fix time, and has to be extended afterwards when doing the
backports to the other branches. We already have the cherry-picked tracking
in the commit messages, so I'd suggest that anyone aware of another affected
branch adds the "affects-X.Y" label, and that (once we have it) a bot simply
checks for the cherry-picked commits to figure the issue and remove the
label. For the rare cases where it doesn't work correctly (because as I said
cherry-picking is not rocket science), it's easy to manually remove the label
to mark the branch as unaffected at the time of reading.

We could decide that bugs for which no "affects-X.Y" label exist anymore
can be closed. That doesn't mean the issue doesn't affect older branch,
it means it's not known to affect them yet, which is similar to before
the bug report (since an issue tracker only tracks known defects and not
hypothetical ones).

With this model, there is less work for everyone involved, all the info
is concentrated together, users can see that their 

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Aleks,

Am 10.01.19 um 15:30 schrieb Aleksandar Lazic:
> In general I also see a huge benefit to add a issue tracker I also know 
> that's a
> workflow change for the developers.
> 
> As I also follow the discussion let suggest me the following.
> 
> * add some templates for the different cases e. g.: ISSUE_TEMPLATE.md
>   https://blog.github.com/2016-02-17-issue-and-pull-request-templates/

Yes. We definitely need one template for "Bug" and another for "Wishlist".

> * use some labels, as labels are very flexible and easy to use as selector.
>   for example: bug, 1.7, backport-1.7, 2.0-dev, fixed_in_1.9.1, ...

I disagree here. We should not create too many labels, because one
should not need to search for the proper labels. Also once an issue is
marked closed it disappears from the view.

Labels that make sense:
- Affected version: affects/1.7, affects/1.8, ...
- Type: Bug, Wishlist
- Subsystem: dns, h2, ...
- Resolution: fixed, invalid, cannot-reproduce, ...

To track whether an issue is fixed in a specific branch Milestones +
automated follow-up issues are superior.

> * in the commit message(s) can the issue number be added to create a 
> corelation
> to the issue with `#`.
> https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests

Yes, this should be done.

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,

Am 09.01.19 um 15:22 schrieb Willy Tarreau:
>> Here's some more recent projects that probably grew up with GitHub. I
>> can't comment how they do the backports, though:
>>
>> https://github.com/nodejs/node/issues (has LTS / Edge)
>> https://github.com/zfsonlinux/zfs/issues (has stable / dev)
>> https://github.com/antirez/redis/issues
>> https://github.com/moby/moby/issues (tons of automation based on an
>> issue template)
> 
> I only knew 3 of them by name and never used any ;-)
> 
> Node is interesting here. the have tags per affected version. E.g.
> https://github.com/nodejs/node/issues/25221

Yes, that definitely makes sense.

> I tend to think that if labels already mark the relevance to a branch,
> then they override the status and probably we don't really care about
> the status. The "moby" project above does that by the way, with
> "status/foo" labels. We could possibly have had "v1.8-open" and
> "v1.8x-done". This way instead of searching by status users can
> search by clicking on the labels. I could just be missing something.

When should the binary "issue open" / "issue closed" property be
toggled? When the issue is fixed in Dev? When the issue is fixed in the
lowest affected version?

Both is not ideal, I guess. Maybe we need to automatically create follow
up issues for the various branches once the fix lands in dev:

1. User creates issue #123.

> Subject: If I foo then haproxy replies with bar instead of baz
>
> If I foo then haproxy replies with bar and this is very bad!

2. Developer fixes the issue in dev, noting the branches to backport in
the commit message. Ideal in a machine-parseable format (Backport-To: 1.8)

> BUG/MINOR: foo: Make haproxy reply with baz
>
> This fixes issue #123.
>
> Backport-To: 1.8
> Backport-To: 1.7

3. A bot automatically creates follow-up issues for each noted branch
referring to the initial issue, stating that a backport is needed:

> Subject: Backport 1.7: If I foo then haproxy replies with bar instead
of baz
>
> This is a follow-up issue, because #123 is not yet fixed for haproxy 1.7.

4. Developer backports the commit, closing the follow-up issues whenever
he did so (this probably can be automated as well. If a Backport-To: 1.7
line appears in the 1.7 branch the matching issue will be closed).

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Aleksandar Lazic]

Am 09.01.2019 um 15:22 schrieb Willy Tarreau:
> Hi Tim,
> 
> On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote:
>> Am 09.01.19 um 05:31 schrieb Willy Tarreau:
>>> Except that the "naturally" part here is manually performed by someone,
>>> and an issue tracker is nothing more than an organized todo list, which
>>> *is* useful to remind that you missed some backports. It regularly happens
>>> to us, like when the safety of some fixes is not certain and we prefer to
>>> let them run for a while in the most recent versions before backporting
>>> them to older branches. This is exactly where an issue tracker is needed,
>>> to remind us that these fixes are still needed in older branches.
>>
>> So the commits are not being cherry-picked in the original order? I
>> imagined that the process went like this:
>>
>> 1. List all the commits since the last cherry-picks
>> 2. Look in the commit message to see whether the commit should be
>> backported.
>> 3. Cherry-pick the commit.
> 
> It's what we *try* to do, but cherry-picking never is rocket science, for
> various reasons, some ranging from uncertainty regarding some fixes that
> need to cool down later, other because an add-on was made, requiring an
> extra patch that are much more convenient to deal with together (think
> about bisect for example). That's why I created the git-show-backport
> script which gives us significant help in comparing lists of commits from
> various branches.
> 
>>> If the issue tracker only tracks issues related to the most recent branch,
>>
>> I believe you misunderstood me. What I attempted to say is:
>>
>> The issue tracker tracks which branches the bug affects. But IMO it does
>> not need to track whether the backport already happened, because the
>> information that the backport needs to happen is in the commit itself
>> (see above).
> 
> For me it is important to have the info that the branch is still unfixed
> because as I explained, the presence of a given commit is not equivalent
> to the issue being fixed. A commit is for a branch. It will often beckport
> as a 1-to-1 to the closest branches, but 10% of the time you need to
> backport extra stuff as well that is not part of the fix but which the
> fix uses, and sometimes you figure that the issue is still not completely
> fixed despite the backport being there because it's more subtle.
> 
>>> it will only solve the problem for this branch. For example, Veiko Kukk
>>> reported in November that compression in 1.7.11 was broken again. How do
>>> I know this ? Just because I've added an entry for this in my TODO file.
>>> This bug is apparently a failed backport, so it requires that the original
>>> bug is reopened and that any backport attempt to an older version is paused.
>>
>> Is the failed backport a new bug or is it not? I'd say it's a new bug,
>> because the situation changed. It's a new bug (someone messed up the
>> backport) that affects haproxy-1.7, but does not affect haproxy-dev. You
>> describe it as an old bug that needs to be re-opened.
> 
> For me it's not a new bug at all, it's the same description. Worse, often
> it will even be the one the reporter used! For example someone might report
> an issue with 1.7, that we diagnose covers 1.7 to 2.0-dev. We finally find
> the bug and if it in 2.0-dev then backport it. The backport stops working
> when reaching 1.7. It's hard to claim it's a new bug while it exactly is the
> bug the person reported! Doing otherwise would make issue lookups very
> cumbersome, even more than the mailing list archives where at least you
> can sort by threads. Thus for me it's only the status in the old branch
> which is not resolved. It's also more convenient for users looking for a
> solution to figure that the same bug is already fixed in 1.8 and that
> possibly an upgrade would be the path to least pain.
> 
>>> You'll note that for many of them the repository is only a mirror by
>>> the way, so that's another hint.
>>
>> I suspect the reason is simple: The project already had a working issue
>> tracker that predated GitHub. Many of these projects are way older than
>> GitHub.
> 
> It's possible.
> 
>> Here's some more recent projects that probably grew up with GitHub. I
>> can't comment how they do the backports, though:
>>
>> https://github.com/nodejs/node/issues (has LTS / Edge)
>> https://github.com/zfsonlinux/zfs/issues (has stable / dev)
>> https://github.com/antirez/redis/issues
>> https://github.com/moby/moby/issues (tons of automation based on an
>> issue template)
> 
> I only knew 3 of them by name and never used any ;-)
> 
> Node is interesting here. the have tags per affected version. E.g.
> https://github.com/nodejs/node/issues/25221

I like this as then you can see all effected Versions for a issue and PR.

> I tend to think that if labels already mark the relevance to a branch,
> then they override the status and probably we don't really care about
> the status. The "moby" project above does that by the way, 

Re: haproxy issue tracker discussion

[Willy Tarreau]

Hi Tim,

On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote:
> Am 09.01.19 um 05:31 schrieb Willy Tarreau:
> > Except that the "naturally" part here is manually performed by someone,
> > and an issue tracker is nothing more than an organized todo list, which
> > *is* useful to remind that you missed some backports. It regularly happens
> > to us, like when the safety of some fixes is not certain and we prefer to
> > let them run for a while in the most recent versions before backporting
> > them to older branches. This is exactly where an issue tracker is needed,
> > to remind us that these fixes are still needed in older branches.
> 
> So the commits are not being cherry-picked in the original order? I
> imagined that the process went like this:
> 
> 1. List all the commits since the last cherry-picks
> 2. Look in the commit message to see whether the commit should be
> backported.
> 3. Cherry-pick the commit.

It's what we *try* to do, but cherry-picking never is rocket science, for
various reasons, some ranging from uncertainty regarding some fixes that
need to cool down later, other because an add-on was made, requiring an
extra patch that are much more convenient to deal with together (think
about bisect for example). That's why I created the git-show-backport
script which gives us significant help in comparing lists of commits from
various branches.

> > If the issue tracker only tracks issues related to the most recent branch,
> 
> I believe you misunderstood me. What I attempted to say is:
> 
> The issue tracker tracks which branches the bug affects. But IMO it does
> not need to track whether the backport already happened, because the
> information that the backport needs to happen is in the commit itself
> (see above).

For me it is important to have the info that the branch is still unfixed
because as I explained, the presence of a given commit is not equivalent
to the issue being fixed. A commit is for a branch. It will often beckport
as a 1-to-1 to the closest branches, but 10% of the time you need to
backport extra stuff as well that is not part of the fix but which the
fix uses, and sometimes you figure that the issue is still not completely
fixed despite the backport being there because it's more subtle.

> > it will only solve the problem for this branch. For example, Veiko Kukk
> > reported in November that compression in 1.7.11 was broken again. How do
> > I know this ? Just because I've added an entry for this in my TODO file.
> > This bug is apparently a failed backport, so it requires that the original
> > bug is reopened and that any backport attempt to an older version is paused.
> 
> Is the failed backport a new bug or is it not? I'd say it's a new bug,
> because the situation changed. It's a new bug (someone messed up the
> backport) that affects haproxy-1.7, but does not affect haproxy-dev. You
> describe it as an old bug that needs to be re-opened.

For me it's not a new bug at all, it's the same description. Worse, often
it will even be the one the reporter used! For example someone might report
an issue with 1.7, that we diagnose covers 1.7 to 2.0-dev. We finally find
the bug and if it in 2.0-dev then backport it. The backport stops working
when reaching 1.7. It's hard to claim it's a new bug while it exactly is the
bug the person reported! Doing otherwise would make issue lookups very
cumbersome, even more than the mailing list archives where at least you
can sort by threads. Thus for me it's only the status in the old branch
which is not resolved. It's also more convenient for users looking for a
solution to figure that the same bug is already fixed in 1.8 and that
possibly an upgrade would be the path to least pain.

> > You'll note that for many of them the repository is only a mirror by
> > the way, so that's another hint.
> 
> I suspect the reason is simple: The project already had a working issue
> tracker that predated GitHub. Many of these projects are way older than
> GitHub.

It's possible.

> Here's some more recent projects that probably grew up with GitHub. I
> can't comment how they do the backports, though:
> 
> https://github.com/nodejs/node/issues (has LTS / Edge)
> https://github.com/zfsonlinux/zfs/issues (has stable / dev)
> https://github.com/antirez/redis/issues
> https://github.com/moby/moby/issues (tons of automation based on an
> issue template)

I only knew 3 of them by name and never used any ;-)

Node is interesting here. the have tags per affected version. E.g.
https://github.com/nodejs/node/issues/25221

I tend to think that if labels already mark the relevance to a branch,
then they override the status and probably we don't really care about
the status. The "moby" project above does that by the way, with
"status/foo" labels. We could possibly have had "v1.8-open" and
"v1.8x-done". This way instead of searching by status users can
search by clicking on the labels. I could just be missing something.

> > To be totally transparent, I 

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,

Am 09.01.19 um 05:31 schrieb Willy Tarreau:
> Except that the "naturally" part here is manually performed by someone,
> and an issue tracker is nothing more than an organized todo list, which
> *is* useful to remind that you missed some backports. It regularly happens
> to us, like when the safety of some fixes is not certain and we prefer to
> let them run for a while in the most recent versions before backporting
> them to older branches. This is exactly where an issue tracker is needed,
> to remind us that these fixes are still needed in older branches.

So the commits are not being cherry-picked in the original order? I
imagined that the process went like this:

1. List all the commits since the last cherry-picks
2. Look in the commit message to see whether the commit should be
backported.
3. Cherry-pick the commit.

In the specific case of GitHub's issue tracker: If a issue is referenced
in a commit message the commit will automatically appear in the timeline
of that issue. This works even across repositories (by using
haproxy/haproxy#123 instead of just #123). It only shows when
specifically looking at a single issue, though and thus is not available
directly in the list of issues.

> If the issue tracker only tracks issues related to the most recent branch,

I believe you misunderstood me. What I attempted to say is:

The issue tracker tracks which branches the bug affects. But IMO it does
not need to track whether the backport already happened, because the
information that the backport needs to happen is in the commit itself
(see above).

> it will only solve the problem for this branch. For example, Veiko Kukk
> reported in November that compression in 1.7.11 was broken again. How do
> I know this ? Just because I've added an entry for this in my TODO file.
> This bug is apparently a failed backport, so it requires that the original
> bug is reopened and that any backport attempt to an older version is paused.

Is the failed backport a new bug or is it not? I'd say it's a new bug,
because the situation changed. It's a new bug (someone messed up the
backport) that affects haproxy-1.7, but does not affect haproxy-dev. You
describe it as an old bug that needs to be re-opened.

>> I'd throw my hat into the ring as well. I maintain a few Open Source
>> projects myself (though not of the size and importance of haproxy) and
>> actually use the GitHub issue tracker.
> 
> Thanks. From what I've been used to see on github, very very few projects
> do care about maintenance. Most of them are rolling releases. It actually
> took me a very long time to try to figure one project with multiple
> maintenance branches to see how they dealt with issues, and the few I
> found by then had disabled issues, which could have already been a hint
> about its suitability to the task. Just a few examples :
> 
> *snip*
> 
> You'll note that for many of them the repository is only a mirror by
> the way, so that's another hint.

I suspect the reason is simple: The project already had a working issue
tracker that predated GitHub. Many of these projects are way older than
GitHub.

Here's some more recent projects that probably grew up with GitHub. I
can't comment how they do the backports, though:

https://github.com/nodejs/node/issues (has LTS / Edge)
https://github.com/zfsonlinux/zfs/issues (has stable / dev)
https://github.com/antirez/redis/issues
https://github.com/moby/moby/issues (tons of automation based on an
issue template)

>>> With that said at the moment we don't have anything and the situation is
>>> not better than having a suboptimal tool.
>>
>> I agree.
> 
> To be totally transparent, I really think the tool is not well suited and
> that its main value is its large user base. But I also know that with you
> and Lukas suggesting to use it, you both will deploy a lot of efforts to
> build something good to prove me I'm wrong, possibly resulting in a nice
> solution in the end. And if some people are willing to invest time
> building something, it would be unfair from me to try to steer their

Clearly it's important that the developer team / you are able to
efficiently work with it as well.

> technical choices. Also, Lukas already managed to use the API to develop
> some tools, maybe this will be welcome to add some automated state
> transitions at some point.
> 
> So unless anyone has a better idea for now, and if you're feeling brave
> enough, let's give it a try.
> 

It's probably impossible to build something absolutely perfect without
real world data points. If a pain point arises it can be specifically
worked on. Currently this discussion is completely hypothetical.

Best regards
Tim Düsterhus

Re: haproxy issue tracker discussion

[Willy Tarreau]

On Tue, Jan 08, 2019 at 07:18:07PM +0100, Tim Düsterhus wrote:
> Willy,
> 
> Am 08.01.19 um 18:30 schrieb Willy Tarreau:
> > I totally agree. This is the tool I'm missing the most currently. I'm
> > not aware of a *good* and manageable issue tracker. Having a status for
> > a bug per branch most likely eliminates most of them...
> 
> I'm not sure this is required. The bugfixes naturally land in the
> current development repository and have the affected branches in their
> commit message. They naturally "trickle down" to the maintained
> branches. So if the issue is marked as fixed the fix will *eventually*
> appear in the stable branch of the reporter.

Except that the "naturally" part here is manually performed by someone,
and an issue tracker is nothing more than an organized todo list, which
*is* useful to remind that you missed some backports. It regularly happens
to us, like when the safety of some fixes is not certain and we prefer to
let them run for a while in the most recent versions before backporting
them to older branches. This is exactly where an issue tracker is needed,
to remind us that these fixes are still needed in older branches.

If the issue tracker only tracks issues related to the most recent branch,
it will only solve the problem for this branch. For example, Veiko Kukk
reported in November that compression in 1.7.11 was broken again. How do
I know this ? Just because I've added an entry for this in my TODO file.
This bug is apparently a failed backport, so it requires that the original
bug is reopened and that any backport attempt to an older version is paused.
Without having cross-branches indications, you can't reliably do this. There
is a significant risk that the faulty fix gets backported to 1.6 before
anyone qualifies the issue.

This can possibly be dealt with using labels, I'm not sure how convenient
it will be.

> In my experience non-issues (a.k.a. RTFM) are usually easy to detect
> when reading through the explanation.

As long as there is manpower to clear them up it's OK, but this means
that some of us will count on you guys for this. With e-mails I don't
even need to do anything to stop reading a faulty bug report. The mail
is marked read once I glance over it, and I don't see it anymore. I
can also mark a whole thread as read when I see that any of the people
I trust here on the list start to respond. When reading an issue tracker,
the same issues pop up until I've done something with them. This makes a
huge difference. This is why I've always been highly concerned with the
risk of pollution.

> >> What you are describing basically is a unmaintained issue tracker,
> >> which is of course useless.
> >>
> >> But keeping people from filing new issues is the wrong approach to
> >> this, imho. Proper templating, triaging and correct labeling of the
> >> issues is the difference between a useless and a useful issue tracker
> >> from my point of view.
> > 
> > I do have strong doubts but I'm open to trying :-)
> 
> I have to agree with Lukas here. Proper triaging is key here. And this
> is no different to email. You have to read email to decide what to do.

Yes but you don't have to act on them to stop seeing them ;-)

> And you have to read the issue to decide what to do.

Most of the time many of us will conclude they have nothing to do because
they're not the best people for this. When you have 10 people responsible
for different areas, on average 10% of the issues will be of interest to
them, and I want to be sure that we will not end up with developers looking
at the issue tracker and constantly seeing stuff that's not for them without
an easy way to definitely skip it and focus on their stuff. Again with
e-mail it's easy because without doing anything you don't see the same
e-mail again. Here if you have to label or ack all the stuff that's not
for you just in order not to see it again, it's inefficient.

But it can likely be improved with proper triaging.

> Labels in the issue tracker are like folders in your mailbox and the
> issue tracker itself is like a public mailbox.

That's exactly the problem. With e-mails, there's one state per reader,
here there's a single state that everyone has to share.

> I'd throw my hat into the ring as well. I maintain a few Open Source
> projects myself (though not of the size and importance of haproxy) and
> actually use the GitHub issue tracker.

Thanks. From what I've been used to see on github, very very few projects
do care about maintenance. Most of them are rolling releases. It actually
took me a very long time to try to figure one project with multiple
maintenance branches to see how they dealt with issues, and the few I
found by then had disabled issues, which could have already been a hint
about its suitability to the task. Just a few examples :

   Apache  : https://github.com/apache/httpd
   Squid   : https://github.com/squid-cache/squid
   Nginx   : https://github.com/nginx/nginx
   Linux   : 

Re: haproxy issue tracker discussion

[Tim Düsterhus]

Willy,

Am 08.01.19 um 18:30 schrieb Willy Tarreau:
> I totally agree. This is the tool I'm missing the most currently. I'm
> not aware of a *good* and manageable issue tracker. Having a status for
> a bug per branch most likely eliminates most of them...

I'm not sure this is required. The bugfixes naturally land in the
current development repository and have the affected branches in their
commit message. They naturally "trickle down" to the maintained
branches. So if the issue is marked as fixed the fix will *eventually*
appear in the stable branch of the reporter.

The "first responder" will try to reproduce the issue both in the
current dev version (to see if appears in bleeding edge) as well as the
most recent version of the branch the reporter uses (in case it was
accidentally fixed during a refactor). If possible the first responder
creates a reg-test showing the issue.

> I'm really not convinced it would change anything. We've put prominently
> on the previous repo an indication that it was not the official project
> and that issues / PRs were not accepted, despite this your automatic bot
> was needed to close them. My goal is contributors efficiency. Several of
> us are on the critical path and every minute they waste slows someone
> else down. So if it becomes more annoying for everyone to create a new
> issue just for the purpose of discouraging wanderers from trying to
> create them, it will only have a globally negative effect.

In my experience non-issues (a.k.a. RTFM) are usually easy to detect
when reading through the explanation.

>>
>> What you are describing basically is a unmaintained issue tracker,
>> which is of course useless.
>>
>> But keeping people from filing new issues is the wrong approach to
>> this, imho. Proper templating, triaging and correct labeling of the
>> issues is the difference between a useless and a useful issue tracker
>> from my point of view.
> 
> I do have strong doubts but I'm open to trying :-)

I have to agree with Lukas here. Proper triaging is key here. And this
is no different to email. You have to read email to decide what to do.
And you have to read the issue to decide what to do.

Labels in the issue tracker are like folders in your mailbox and the
issue tracker itself is like a public mailbox.

>> I'm in favor of the former, because I believe triage will be required
>> for both and I don't think the amount of bogus issues will be
>> unmanageable. I'd also volunteer to triage incoming issues - not that
>> it's much different from what's currently done discourse anyway - as
>> Tim already said.
> 
> Oh yes! I just want to be sure we don't burn you out! This is also why
> I'm open to trying what those doing the work propose. If I'm imposing
> a painful or inefficient process for those doing the work, it will not
> work either.

I'd throw my hat into the ring as well. I maintain a few Open Source
projects myself (though not of the size and importance of haproxy) and
actually use the GitHub issue tracker.

>> Regarding what tool to use, in the "open to everyone" case I'd opt for
>> github simply because it has the lowest barrier of entry for everyone,
>> as well as me being mildly familiar with it personally. Pre-existing
>> github labels would have to be replaced by useful ones and a issue
>> template would have to be created.

I would suggest using GitHub's issue tracker as well. It works fairly
well in my experience.

> I'd say that we managed to close the issues there when we discovered
> them. It took a huge amount of efforts, sure, but eventually it was
> done. So if we figure later that it was a wrong choice, we know it can
> be done again. In this regard I think it's the lowest cost to *try*.
> 
> However I'd like that we spend some time thinking about what can be
> done to properly route the bugs to the various branches. Bugs in dev
> are useless, we want them to be fixed in stable branches. So we have

See the very top of my email.

> Thanks a lot for these links, they are very informative. This utility
> doesn't "yet" support cross-branches, but it's said that bugseverywhere
> does. But bugseverywhere claims that its value is in keeping a hard
> relation between bug's state and the fix in the tree, which precisely
> is the wrong way to do it for me : I strongly prefer that the bug tracker
> is never fully up to date regarding the resolved status for a branch than
> having it believe the branch is fixed because it doesn't know that this
> branch requires an extra patch. An apparently unresolved bug will be
> noticed by the next person trying to resolve it. It's how it really
> works with most developers and bug trackers in real life. I had too
> quick a look at the other ones for now.

Please don't opt for some obscure system. The biggest value of a public
issue tracker to me is that people are actually are able to research
whether their issue is already known / a duplicate and possible
workarounds. The mail archive is not really accessible.

Re: haproxy issue tracker discussion

[Willy Tarreau]

On Sun, Jan 06, 2019 at 07:41:08PM +0300, Alexey Elymanov wrote:
> Ansible, for example (https://github.com/ansible/ansible/issues), uses some
> advanced automation and templates to manage their enormous issues stream.
> Issue are checked against conforming rules/tests/codestyle checks or, for
> example, automatically closed due inactivity
> I believe most if not all soluitons they use are opensource.

Thank you for this link Alexey, it definitely brings some value to this
discussion!

Willy

Re: haproxy issue tracker discussion

[Willy Tarreau]

Hi guys,

sorry for the long delay, it was not the best week for me to restart
all of this discussion, but now it's OK, I'm catching up!

On Sun, Jan 06, 2019 at 05:29:43PM +0100, Lukas Tribus wrote:
> Hello everyone,
> 
> 
> as per Tim's suggestion I'm restarting the discussion about the issue
> tracker, started in "haproxy 1.9 status update" (2018-05-25),
> Message-ID 20180525161044.ga6...@1wt.eu:
> https://www.mail-archive.com/haproxy@formilux.org/msg30139.html
> 
> 
> > It would be nice to show what's pending or being worked on, and
> > to sometimes add extra info regarding a given task.
> 
> Yes, we are in need of an issue tracker, not only to handle open bugs,
> but even more so to handle feature/change requests that often need
> more time. Those do get lost on the mailing list, even when everyone
> already agreed it's needed.

I totally agree. This is the tool I'm missing the most currently. I'm
not aware of a *good* and manageable issue tracker. Having a status for
a bug per branch most likely eliminates most of them...

> > The problem we've faced in the past with GitHub's issue tracker
> > is that it's impossible to restrict the creation of new issues to
> > participants. Given that haproxy is a complex component, the boundary
> > between human error, misunderstanding and bug is extremely thin.
> 
> It is, but I don't like restricting the creation of new issues to 
> participants.
> 
> Issue templates need to be clear that the issue tracker is not a
> support forum.

I'm really not convinced it would change anything. We've put prominently
on the previous repo an indication that it was not the official project
and that issues / PRs were not accepted, despite this your automatic bot
was needed to close them. My goal is contributors efficiency. Several of
us are on the critical path and every minute they waste slows someone
else down. So if it becomes more annoying for everyone to create a new
issue just for the purpose of discouraging wanderers from trying to
create them, it will only have a globally negative effect.

Based on your experience dealing with all these reports on discourse,
what is the approximate ratio between valid and invalid reports ?

> Triaging new issues will be needed anyway, and that
> also includes closing misdirected support request.

Sure, and any support / issue reporting chain requires this since you
only know what it was once the issue is fixed (and sometimes even after
it's fixed you discover new impacts).

> To be clear: I think developers should not receive an email
> notifications for new or untriaged issues - only when specifically
> assigned to the issue or if they commented previously on it. Instead,
> maybe an automated weekly report or something like that (similar to
> what we have now for the stable-queue) could go out to the mailing
> list with a summary of the open issues, grouped by it's labels.

Maybe. But right now issues reported here are dealt with because all
of us presume that "someone will surely look at this one", and if we
see a long unresponded e-mail, we try to assign more time to it (and
sometimes we miss it, of course). And what is nice is that actually a
large number of people respond, some with links to a similar previous
report, others suggesting to adapt the config to narrow the issue down,
etc. So there is a huge value in having the community participate to
issue resolution and not just some developers. The problem with batches
is that when you get 20 new bugs at once that you hadn't had the time
to look at previously, well, you don't know where to start and you
simply prefer to pretend you didn't see them. So possibly that having
the triaged issues being forwarded here in real time with a visible tag
would maintain the same level of participation with a higher accuracy
and less losses.

> > It resulted in the issue tracker being filled with wrong bugs, 100% of
> > which were in fact requests for help. It makes the utility totally
> > useless for development and bug fixing as it requires more time to
> > maintain in a clean state than it takes to put issues in a mailbox.
> 
> What you are describing basically is a unmaintained issue tracker,
> which is of course useless.
> 
> But keeping people from filing new issues is the wrong approach to
> this, imho. Proper templating, triaging and correct labeling of the
> issues is the difference between a useless and a useful issue tracker
> from my point of view.

I do have strong doubts but I'm open to trying :-)

> So I guess we ultimately have to decide between:
> 
>   - an issue tracker open to everyone, however requiring some
> volunteers to triage incoming bugs (and close invalid ones)
>   - an issue tracker that is open to "previous participants", with the
> expectation to require less manpower for triage
> 
> 
> I'm in favor of the former, because I believe triage will be required
> for both and I don't think the amount of bogus issues will be
> unmanageable. I'd also volunteer to triage 

Re: haproxy issue tracker discussion

[Alexey Elymanov]

Ansible, for example (https://github.com/ansible/ansible/issues), uses some
advanced automation and templates to manage their enormous issues stream.
Issue are checked against conforming rules/tests/codestyle checks or, for
example, automatically closed due inactivity
I believe most if not all soluitons they use are opensource.

On Sun, Jan 6, 2019 at 7:32 PM Lukas Tribus  wrote:

> Hello everyone,
>
>
> as per Tim's suggestion I'm restarting the discussion about the issue
> tracker, started in "haproxy 1.9 status update" (2018-05-25),
> Message-ID 20180525161044.ga6...@1wt.eu:
> https://www.mail-archive.com/haproxy@formilux.org/msg30139.html
>
>
> > It would be nice to show what's pending or being worked on, and
> > to sometimes add extra info regarding a given task.
>
> Yes, we are in need of an issue tracker, not only to handle open bugs,
> but even more so to handle feature/change requests that often need
> more time. Those do get lost on the mailing list, even when everyone
> already agreed it's needed.
>
>
> > The problem we've faced in the past with GitHub's issue tracker
> > is that it's impossible to restrict the creation of new issues to
> > participants. Given that haproxy is a complex component, the boundary
> > between human error, misunderstanding and bug is extremely thin.
>
> It is, but I don't like restricting the creation of new issues to
> participants.
>
> Issue templates need to be clear that the issue tracker is not a
> support forum. Triaging new issues will be needed anyway, and that
> also includes closing misdirected support request.
>
>
> To be clear: I think developers should not receive an email
> notifications for new or untriaged issues - only when specifically
> assigned to the issue or if they commented previously on it. Instead,
> maybe an automated weekly report or something like that (similar to
> what we have now for the stable-queue) could go out to the mailing
> list with a summary of the open issues, grouped by it's labels.
>
>
> > It resulted in the issue tracker being filled with wrong bugs, 100% of
> > which were in fact requests for help. It makes the utility totally
> > useless for development and bug fixing as it requires more time to
> > maintain in a clean state than it takes to put issues in a mailbox.
>
> What you are describing basically is a unmaintained issue tracker,
> which is of course useless.
>
> But keeping people from filing new issues is the wrong approach to
> this, imho. Proper templating, triaging and correct labeling of the
> issues is the difference between a useless and a useful issue tracker
> from my point of view.
>
>
> So I guess we ultimately have to decide between:
>
>   - an issue tracker open to everyone, however requiring some
> volunteers to triage incoming bugs (and close invalid ones)
>   - an issue tracker that is open to "previous participants", with the
> expectation to require less manpower for triage
>
>
> I'm in favor of the former, because I believe triage will be required
> for both and I don't think the amount of bogus issues will be
> unmanageable. I'd also volunteer to triage incoming issues - not that
> it's much different from what's currently done discourse anyway - as
> Tim already said.
>
> Regarding what tool to use, in the "open to everyone" case I'd opt for
> github simply because it has the lowest barrier of entry for everyone,
> as well as me being mildly familiar with it personally. Pre-existing
> github labels would have to be replaced by useful ones and a issue
> template would have to be created.
>
>
> > A limitation that isn't addressed by any of them is that an issue has
> > a single status and not one per maintenance branch. Some will say that
> > labels replace this but I'd say that this isn't true, it just vaguely
> > emulates this. Anyway if we don't have better we can go with this. I
> > often dream of the day someone pissed of by using prehistoric issue
> > trackers writes a modern one, just like when Linus created Git...
>
> There are some niche tools allowing a "distributed issue tracking
> system" within git, but they seem very fragmented, none of it gets a
> lot of traction and it would certainly over complicate things for a
> lot of people, including myself. See git-bug [1] and it's HN
> discussion [2], containing a log of other references [3-7].
>
> Well I guess we would certainly not have many bogus issues reported on
> those systems ;)
>
>
>
> Regards,
> Lukas
>
>
> [1] https://github.com/MichaelMure/git-bug
> [2] https://news.ycombinator.com/item?id=17782121
> [3] http://bugseverywhere.org/
> [4] http://mrzv.org/software/artemis/
> [5] https://github.com/sit-fyi/issue-tracking
> [6} https://github.com/dspinellis/git-issue
> [7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html
>
>

haproxy issue tracker discussion

[Lukas Tribus]

Hello everyone,


as per Tim's suggestion I'm restarting the discussion about the issue
tracker, started in "haproxy 1.9 status update" (2018-05-25),
Message-ID 20180525161044.ga6...@1wt.eu:
https://www.mail-archive.com/haproxy@formilux.org/msg30139.html


> It would be nice to show what's pending or being worked on, and
> to sometimes add extra info regarding a given task.

Yes, we are in need of an issue tracker, not only to handle open bugs,
but even more so to handle feature/change requests that often need
more time. Those do get lost on the mailing list, even when everyone
already agreed it's needed.


> The problem we've faced in the past with GitHub's issue tracker
> is that it's impossible to restrict the creation of new issues to
> participants. Given that haproxy is a complex component, the boundary
> between human error, misunderstanding and bug is extremely thin.

It is, but I don't like restricting the creation of new issues to participants.

Issue templates need to be clear that the issue tracker is not a
support forum. Triaging new issues will be needed anyway, and that
also includes closing misdirected support request.


To be clear: I think developers should not receive an email
notifications for new or untriaged issues - only when specifically
assigned to the issue or if they commented previously on it. Instead,
maybe an automated weekly report or something like that (similar to
what we have now for the stable-queue) could go out to the mailing
list with a summary of the open issues, grouped by it's labels.


> It resulted in the issue tracker being filled with wrong bugs, 100% of
> which were in fact requests for help. It makes the utility totally
> useless for development and bug fixing as it requires more time to
> maintain in a clean state than it takes to put issues in a mailbox.

What you are describing basically is a unmaintained issue tracker,
which is of course useless.

But keeping people from filing new issues is the wrong approach to
this, imho. Proper templating, triaging and correct labeling of the
issues is the difference between a useless and a useful issue tracker
from my point of view.


So I guess we ultimately have to decide between:

  - an issue tracker open to everyone, however requiring some
volunteers to triage incoming bugs (and close invalid ones)
  - an issue tracker that is open to "previous participants", with the
expectation to require less manpower for triage


I'm in favor of the former, because I believe triage will be required
for both and I don't think the amount of bogus issues will be
unmanageable. I'd also volunteer to triage incoming issues - not that
it's much different from what's currently done discourse anyway - as
Tim already said.

Regarding what tool to use, in the "open to everyone" case I'd opt for
github simply because it has the lowest barrier of entry for everyone,
as well as me being mildly familiar with it personally. Pre-existing
github labels would have to be replaced by useful ones and a issue
template would have to be created.


> A limitation that isn't addressed by any of them is that an issue has
> a single status and not one per maintenance branch. Some will say that
> labels replace this but I'd say that this isn't true, it just vaguely
> emulates this. Anyway if we don't have better we can go with this. I
> often dream of the day someone pissed of by using prehistoric issue
> trackers writes a modern one, just like when Linus created Git...

There are some niche tools allowing a "distributed issue tracking
system" within git, but they seem very fragmented, none of it gets a
lot of traction and it would certainly over complicate things for a
lot of people, including myself. See git-bug [1] and it's HN
discussion [2], containing a log of other references [3-7].

Well I guess we would certainly not have many bogus issues reported on
those systems ;)



Regards,
Lukas


[1] https://github.com/MichaelMure/git-bug
[2] https://news.ycombinator.com/item?id=17782121
[3] http://bugseverywhere.org/
[4] http://mrzv.org/software/artemis/
[5] https://github.com/sit-fyi/issue-tracking
[6} https://github.com/dspinellis/git-issue
[7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html

Re: Active-Passive HAProxy Issue enquiry

[Jonathan Matthews]

On 15 February 2018 at 10:08, Swarup Saha  wrote:
> Hi,
> I need help from HAProxy organization.

Hello there. This is the haproxy user mailing list. It is received and
read by a wider range of users across the world, many of whom read it
in an individual capacity.
If you want *commercial* support, then here is a link to organisations
which provide it: https://www.haproxy.org/#supp

> We all know that when we configure HAProxy in the Active-Passive manner then
> there is a VIP. Outside service will access the VIP and the traffic will be
> routed to appropriate inner services via Active Load Balancer.
>
> I have configured one Active Load Balancer in Site 1 and Passive Load
> Balancer in Site 2, They are connected via LAN, Outside traffic will be
> routed through VIP.
>
> Now, my question is if the LAN connectivity between the Active-Passive
> HAProxy goes down will the VIP still exist?

This is *entirely* the concern of the technology and methods you use
to create the VIP across multiple haproxy instances in your different
sites.
It isn't under the control of haproxy, which deals with failover of
the *backend* services you're load balancing.

Failure of an entire loadbalancer, and how your setup deals with that,
is *100%* a concern of the technology (not haproxy) with which you've
chosen to implement resilience.

People *might* be able to assist on this list if you gave some more
detail about the technologies you're using.

HTH!
J

Active-Passive HAProxy Issue enquiry

[Swarup Saha]

Hi,

We all know that when we configure HAProxy in the Active-Passive manner
then there is a VIP. Outside service will access the VIP and the traffic
will be routed to appropriate inner services via Active Load Balancer.

I have configured one Active Load Balancer in Site 1 and Passive Load
Balancer in Site 2, They are connected via LAN, Outside traffic will be
routed through VIP.

Now, my question is if the LAN connectivity between the Active-Passive
HAProxy goes down will the VIP still exist? And if so,

(1) The Active Load Balancer of Site 1 will still be active and Passive
Load Balancer in Site 2 will still be Passive or

(2) The Active Load Balancer of Site 1 will be Passive and Passive Load
Balancer in Site 2 will be Active.


Which one is correct? I have posted the question in many forums but no
response, so I need help from HAProxy organization.


-- 
Regards,
Swarup Saha
Solutions Architect, RS Software
9830933123

Sent from MacBook Air

Re: Haproxy issue

[Daniel Schneller]

Just adding this back to the list.

> On 14. Feb. 2017, at 18:12, <thibault.dai...@orange.com> 
> <thibault.dai...@orange.com> wrote:
> 
> Ok thank you for your reply !
> I found my error
> Haproxy was not happy with http request
>  
> I was doing https://test-rest.net:8089 <https://test-rest.net:8089/> so error 
> because I was checking only “test-rest.net <http://test-rest.net/>”
>  
> So I change my file and add ‘:8089’ after  “acl host_rest_services  
> hdr(Host) -i test-rest.net <http://test-rest.net:8089/>:8089 
> <http://test-rest.net:8089/>” :
>  
> frontend rest-in
> bind *:8089 ssl crt /etc/ssl/*
> reqadd X-Forwarded-Proto:\ https
>  acl host_rest_services  hdr(Host) -i test-rest.net 
> <http://test-rest.net:8089/>:8089 <http://test-rest.net:8089/>
>  use_backend rest_services if host_rest_services
>  backend rest_services
>  server shstand 10.0.0.2:8089 ssl verify none
> So It works
>  
> De : Daniel Schneller [mailto:daniel.schnel...@centerdevice.com] 
> Envoyé : mardi 14 février 2017 17:17
> À : Skarbek, John
> Cc : DAIGNE Thibault OBS/OAB; haproxy+h...@formilux.org
> Objet : Re: Haproxy issue
>  
> Hi!
> 
> frontend rest-in
> bind *:8089 ssl crt /etc/ssl/*
> acl host_rest_services  hdr(Host) -i test-rest.net 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__test-2Drest.net=DwQFAg=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=BZ2S09kcMRiJIUh57WZsng=552Ig6nEOMH9wg2ks1WhxrWEHEMdG8cMbcbCkjD_Gog=UVyuxV46M6Snh0R8nhltBxZLBuVcrVsIcTLAaVp7nQg=>
> It would appear that your acl was not matched.  It was up to `rest-in` to 
> determine how to route the request, and since there's no other backend to 
> choose from, there was no place for the request to go.  I would advise that 
> you validate your acl is configured as you desired.
> My guess would be that the Host header actually says “test-rest.net:8089 
> <http://test-rest.net:8089/>”, which would lead the ACL to not match.
>  
> It would also be a good idea to setup a `default backend` as a way to help 
> test where your requests are going.
> For debugging these kinds of things I usually run haproxy in debug mode: 
> haproxy -d -f haproxy.cfg 
> That way it will echo incoming and outgoing headers.
>  
> Daniel
>  
> -- 
> Daniel Schneller
> Principal Cloud Engineer
>  
> CenterDevice GmbH  | Hochstraße 11
>| 42697 Solingen
> tel: +49 1754155711| Deutschland
> daniel.schnel...@centerdevice.de <mailto:daniel.schnel...@centerdevice.de>   
> | www.centerdevice.de <http://www.centerdevice.de/>
> 
> Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
> Michael Rosbach, Handelsregister-Nr.: HRB 18655,
> HR-Gericht: Bonn, USt-IdNr.: DE-815299431
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.

Re: Haproxy issue

[Daniel Schneller]

Hi!
>> frontend rest-in
>> 
>> bind *:8089 ssl crt /etc/ssl/*
>> 
>> acl host_rest_services  hdr(Host) -i test-rest.net 
>> 
> It would appear that your acl was not matched.  It was up to `rest-in` to 
> determine how to route the request, and since there's no other backend to 
> choose from, there was no place for the request to go.  I would advise that 
> you validate your acl is configured as you desired.
> 
My guess would be that the Host header actually says “test-rest.net:8089 
”, which would lead the ACL to not match.

> It would also be a good idea to setup a `default backend` as a way to help 
> test where your requests are going.
> 
For debugging these kinds of things I usually run haproxy in debug mode: 
haproxy -d -f haproxy.cfg 
That way it will echo incoming and outgoing headers.

Daniel

-- 
Daniel Schneller
Principal Cloud Engineer
 
CenterDevice GmbH  | Hochstraße 11
   | 42697 Solingen
tel: +49 1754155711| Deutschland
daniel.schnel...@centerdevice.de   | www.centerdevice.de

Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431

Re: Haproxy issue

[Skarbek, John]

On February 14, 2017 at 10:46:05, thibault.dai...@orange.com 
(thibault.dai...@orange.com) wrote:
Hi,

I’ve got an issue with Haproxy conf need help please !!

See my haproxy.cfg

frontend rest-in
bind *:8089 ssl crt /etc/ssl/*
reqadd X-Forwarded-Proto:\ https

acl host_rest_services  hdr(Host) -i 
test-rest.net

use_backend rest_services if host_rest_services

backend rest_services
 server shstand 10.0.0.2:8089 ssl verify none

see my log in /var/log/haproxy.log

[14/Feb/2017:16:02:36.860] rest-in~ rest-in/ -1/-1/-1/-1/35 503 212 - - 
SC-- 0/0/0/0/0 0/0 "GET / HTTP/1.1"


It would appear that your acl was not matched.  It was up to `rest-in` to 
determine how to route the request, and since there's no other backend to 
choose from, there was no place for the request to go.  I would advise that you 
validate your acl is configured as you desired.


It would also be a good idea to setup a `default backend` as a way to help test 
where your requests are going.


Why my “use_backend” is not working ? I’ve got nothing between my haproxy and 
my backend (NO proxy, no firewall, etc )

Thanks for your help
Regards,


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Haproxy issue

[thibault.daigne]

Hi,

I've got an issue with Haproxy conf need help please !!

See my haproxy.cfg

frontend rest-in
bind *:8089 ssl crt /etc/ssl/*
reqadd X-Forwarded-Proto:\ https

acl host_rest_services  hdr(Host) -i test-rest.net

use_backend rest_services if host_rest_services

backend rest_services
 server shstand 10.0.0.2:8089 ssl verify none

see my log in /var/log/haproxy.log

[14/Feb/2017:16:02:36.860] rest-in~ rest-in/ -1/-1/-1/-1/35 503 212 - - 
SC-- 0/0/0/0/0 0/0 "GET / HTTP/1.1"

Why my "use_backend" is not working ? I've got nothing between my haproxy and 
my backend (NO proxy, no firewall, etc )

Thanks for your help
Regards,


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: Need help to reolsve haproxy issue

[Praveen Koppula]

 Sorry for the late reply, I was on unplanned leave.

What I observed in my investigation, when I commented below line it's
working as expected. Means even after reboot the machine the haproxy
service get started automatically.
#stats socket /etc/haproxy/haproxysock level admin
I'm not sure what is the significance of this line.
Can we proceed with this in our configuration or will it cause any
issues further?

NOTE : I couldn't find haproxy-wrapper under below location
/usr/sbin> ls -ltr *haproxy*
-rwxr-xr-x 1 root root  35152 Sep  3  2014 haproxy-halog
-rwxr-xr-x 1 root root 788672 Sep  3  2014 haproxy
lrwxrwxrwx 1 root root 19 Jan  9 01:47 rchaproxy -> /etc/init.d/haproxy

Thanks in advance.

On Mon, Jan 16, 2017 at 11:43 AM, Aaron West  wrote:
> I've not personally had any issues with systemd which I know doesn't mean
> there isn't any... However, on closer inspection, it gets started through a
> wrapper "haproxy-systemd-wrapper" for me :
>
> [Unit]
> Description=HAProxy Load Balancer
> After=network.target
>
> [Service]
> ExecStartPre=/usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -c -q
> ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f
> /etc/haproxy/haproxy.cfg -$
> ExecReload=/bin/kill -USR2 $MAINPID
> KillMode=mixed
> Restart=always
>
> [Install]
> WantedBy=multi-user.target
>
> So definitely check if you are using that wrapper or not if systemd is being
> used.
>
> Otherwise, my feeling is that for whatever reason you cannot access the
> socket previously created due to permissions... I mean I can get the same
> error trying to start HAproxy as an unprivileged user who cannot write to
> the file/directory.
>
> Aaron West
>
> Loadbalancer.org Limited
> +44 (0)330 380 1064
> www.loadbalancer.org
>
> On 16 January 2017 at 16:21, Baptiste  wrote:
>>
>> Might be a systemd dependency issue, where the socket is not created
>> before the process is started.
>>
>> Baptiste
>>
>> On Mon, Jan 16, 2017 at 4:46 PM, Aaron West 
>> wrote:
>>>
>>> Hi Praveen,
>>>
>>> Am I right in assuming it's a socket for the stats page? Also what user
>>> is starting HAproxy because maybe it doesn't have permissions to create the
>>> socket?
>>>
>>> We might need your whole config or at least the GLOBAL section...
>>>
>>> Aaron West
>>>
>>> Loadbalancer.org Limited
>>> +44 (0)330 380 1064
>>> www.loadbalancer.org
>>>
>>> On 16 January 2017 at 15:38, Praveen Koppula
>>>  wrote:

 Some content was missing. Adding again.

 When we reboot our machine (Where haproxy installed) teh haproxy going
 to be down and it's not starting after machine boot.
 When we force to start haproxy service getting below error.
 Error: Starting haproxy [ALERT] 047/083514 : Starting frontend GLOBAL:
 error when trying to preserve previous UNIX socket
 [/etc/haproxy/haproxysock] startproc: exit status of parent of
 /usr/sbin/haproxy: 1 Failed

 On Mon, Jan 16, 2017 at 10:32 AM, Praveen Koppula
  wrote:
>
> Can you please help me on this.
>
> Haproxy version is : 1.5.4-2.1
>
> Thanks in advance


>>>
>>
>

Re: Need help to reolsve haproxy issue

[Aaron West]

I've not personally had any issues with systemd which I know doesn't mean
there isn't any... However, on closer inspection, it gets started through a
wrapper "haproxy-systemd-wrapper" for me :

[Unit]
Description=HAProxy Load Balancer
After=network.target

[Service]
ExecStartPre=/usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -c -q
ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f
/etc/haproxy/haproxy.cfg -$
ExecReload=/bin/kill -USR2 $MAINPID
KillMode=mixed
Restart=always

[Install]
WantedBy=multi-user.target

So definitely check if you are using that wrapper or not if systemd is
being used.

Otherwise, my feeling is that for whatever reason you cannot access the
socket previously created due to permissions... I mean I can get the same
error trying to start HAproxy as an unprivileged user who cannot write to
the file/directory.

Aaron West

Loadbalancer.org Limited
+44 (0)330 380 1064
www.loadbalancer.org

On 16 January 2017 at 16:21, Baptiste  wrote:

> Might be a systemd dependency issue, where the socket is not created
> before the process is started.
>
> Baptiste
>
> On Mon, Jan 16, 2017 at 4:46 PM, Aaron West 
> wrote:
>
>> Hi Praveen,
>>
>> Am I right in assuming it's a socket for the stats page? Also what user
>> is starting HAproxy because maybe it doesn't have permissions to create the
>> socket?
>>
>> We might need your whole config or at least the GLOBAL section...
>>
>> Aaron West
>>
>> Loadbalancer.org Limited
>> +44 (0)330 380 1064
>> www.loadbalancer.org
>>
>> On 16 January 2017 at 15:38, Praveen Koppula <
>> praveenkumarkopp...@gmail.com> wrote:
>>
>>> Some content was missing. Adding again.
>>>
>>> When we reboot our machine (Where haproxy installed) teh haproxy going
>>> to be down and it's not starting after machine boot.
>>> When we force to start haproxy service getting below error.
>>> Error: Starting haproxy [ALERT] 047/083514 : Starting frontend GLOBAL:
>>> error when trying to preserve previous UNIX socket
>>> [/etc/haproxy/haproxysock] startproc: exit status of parent of
>>> /usr/sbin/haproxy: 1 Failed
>>>
>>> On Mon, Jan 16, 2017 at 10:32 AM, Praveen Koppula <
>>> praveenkumarkopp...@gmail.com> wrote:
>>>
 Can you please help me on this.

 Haproxy version is : 1.5.4-2.1

 Thanks in advance

>>>
>>>
>>
>

Re: Need help to reolsve haproxy issue

[Baptiste]

Might be a systemd dependency issue, where the socket is not created before
the process is started.

Baptiste

On Mon, Jan 16, 2017 at 4:46 PM, Aaron West  wrote:

> Hi Praveen,
>
> Am I right in assuming it's a socket for the stats page? Also what user is
> starting HAproxy because maybe it doesn't have permissions to create the
> socket?
>
> We might need your whole config or at least the GLOBAL section...
>
> Aaron West
>
> Loadbalancer.org Limited
> +44 (0)330 380 1064
> www.loadbalancer.org
>
> On 16 January 2017 at 15:38, Praveen Koppula <
> praveenkumarkopp...@gmail.com> wrote:
>
>> Some content was missing. Adding again.
>>
>> When we reboot our machine (Where haproxy installed) teh haproxy going to
>> be down and it's not starting after machine boot.
>> When we force to start haproxy service getting below error.
>> Error: Starting haproxy [ALERT] 047/083514 : Starting frontend GLOBAL:
>> error when trying to preserve previous UNIX socket
>> [/etc/haproxy/haproxysock] startproc: exit status of parent of
>> /usr/sbin/haproxy: 1 Failed
>>
>> On Mon, Jan 16, 2017 at 10:32 AM, Praveen Koppula <
>> praveenkumarkopp...@gmail.com> wrote:
>>
>>> Can you please help me on this.
>>>
>>> Haproxy version is : 1.5.4-2.1
>>>
>>> Thanks in advance
>>>
>>
>>
>

Re: Need help to reolsve haproxy issue

[Aaron West]

Hi Praveen,

Am I right in assuming it's a socket for the stats page? Also what user is
starting HAproxy because maybe it doesn't have permissions to create the
socket?

We might need your whole config or at least the GLOBAL section...

Aaron West

Loadbalancer.org Limited
+44 (0)330 380 1064
www.loadbalancer.org

On 16 January 2017 at 15:38, Praveen Koppula 
wrote:

> Some content was missing. Adding again.
>
> When we reboot our machine (Where haproxy installed) teh haproxy going to
> be down and it's not starting after machine boot.
> When we force to start haproxy service getting below error.
> Error: Starting haproxy [ALERT] 047/083514 : Starting frontend GLOBAL:
> error when trying to preserve previous UNIX socket
> [/etc/haproxy/haproxysock] startproc: exit status of parent of
> /usr/sbin/haproxy: 1 Failed
>
> On Mon, Jan 16, 2017 at 10:32 AM, Praveen Koppula <
> praveenkumarkopp...@gmail.com> wrote:
>
>> Can you please help me on this.
>>
>> Haproxy version is : 1.5.4-2.1
>>
>> Thanks in advance
>>
>
>

Re: Need help to reolsve haproxy issue

[Aaron West]

There are some very knowledgeable people on this list so I'm sure someone
can help, however, what might the problem actually be?


Aaron West

Loadbalancer.org Limited
+44 (0)330 380 1064
www.loadbalancer.org

On 16 January 2017 at 15:32, Praveen Koppula 
wrote:

> Can you please help me on this.
>
> Haproxy version is : 1.5.4-2.1
>
> Thanks in advance
>

Re: Need help to reolsve haproxy issue

[Praveen Koppula]

Some content was missing. Adding again.

When we reboot our machine (Where haproxy installed) teh haproxy going to
be down and it's not starting after machine boot.
When we force to start haproxy service getting below error.
Error: Starting haproxy [ALERT] 047/083514 : Starting frontend GLOBAL:
error when trying to preserve previous UNIX socket
[/etc/haproxy/haproxysock] startproc: exit status of parent of
/usr/sbin/haproxy: 1 Failed

On Mon, Jan 16, 2017 at 10:32 AM, Praveen Koppula <
praveenkumarkopp...@gmail.com> wrote:

> Can you please help me on this.
>
> Haproxy version is : 1.5.4-2.1
>
> Thanks in advance
>

Need help to reolsve haproxy issue

[Praveen Koppula]

Can you please help me on this.

Haproxy version is : 1.5.4-2.1

Thanks in advance

Re: haproxy issue

[Jarno Huuskonen]

Hi,

On Wed, Oct 15, pasquale scalea wrote:
 i have configure haproxy-1.5.4-1.el6.x86_64 with this config
...
 backend view_https
 mode tcp
 option tcplog
 option httpchk OPTIONS /
 http-check expect status 200
 option ssl-hello-chk #make sure we can talk SSL, not just TCP
 balance source
 balance roundrobin
 stick on src
 stick-table type ip size 100m expire 1h
 server milap9900 172.16.74.17:443 check id 1 inter 10s rise 5 fall 2
 server milap9901 172.16.74.18:443 check id 2 inter 10s rise 5 fall 2

How are you trying to do the server health checks ? Are you trying to
use OPTIONS / over ssl connection or just ssl-hello-chk ?

If you're trying to do OPTIONS / with ssl then maybe something like
this might work:
   # disable option ssl-hello-chk
   option httpchk OPTIONS /
   server milap9900 172.16.74.17:443 check ssl id 1 inter 10s rise 5 fall 2
   server milap9901 172.16.74.18:443 check ssl id 2 inter 10s rise 5 fall 2
(and make sure you've compiled haproxy with ssl support: haproxy -vv)
(and you need to configure ca certs or use verify none/ssl-server-verify none)
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-ssl
or
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-check-ssl

Also check that the backend server responds to OPTIONS / with (for
example with: openssl s_client -connect 172.16.74.18:443 and
type OPTIONS / HTTP/1.0 and hit enter twice)

Also are you trying to send the same client to the same server:
balance source / balance roundrobin / stick on src ?
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-balance
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-stick%20on
Then balance source or balance roundrobin + stick on src should do the trick
I don't think you'll need all three.

Cheers, 
-Jarno  

-- 
Jarno Huuskonen

haproxy issue

[pasquale scalea]

Hi,
i have configure haproxy-1.5.4-1.el6.x86_64 with this config

frontend inbound-https
bind :443 #ssl crt ./my_view_cert.pem
mode tcp
option tcplog
default_backend view_https

backend view_https
mode tcp
option tcplog
option httpchk OPTIONS /
http-check expect status 200
option ssl-hello-chk #make sure we can talk SSL, not just TCP
balance source
balance roundrobin
stick on src
stick-table type ip size 100m expire 1h
server milap9900 172.16.74.17:443 check id 1 inter 10s rise 5 fall 2
server milap9901 172.16.74.18:443 check id 2 inter 10s rise 5 fall 2

but when one server responding with 503 haproxy not exclude a fail node

from haproxy machine i check:

wget  https://172.16.74.17 --no-check-certificate
--2014-10-15 16:17:15--  https://172.16.74.17/
Connessione a 172.16.74.17:443...connesso.
AVVERTIMENTO: impossibile verificare il certificato di 172.16.74.17,
rilasciato da /O=VMware, Inc./OU=VMware View default
certificate/CN=milap9900:
  Impossibile verificare localmente l'autorità dell'emittente.
AVVERTIMENTO: certificate common name milap9900 doesn't match
requested host name 172.16.74.17.
HTTP richiesta inviata, in attesa di risposta... 503 Service Unavailable
2014-10-15 16:17:36 ERRORE 503: Service Unavailable.

where am I wrong?

Best Regard
Pasquale