Metallb: Plans for a new release/milestone please?

Created on 21 Apr 2019  路  7Comments  路  Source: metallb/metallb

What are the current plans for future milestones and release? I realise that this can often be a difficult topic with open-source projects but this project has proved highly useful and we could really like to know what your plans are for the future.

many thanks

question

Most helpful comment

Great question. Right now, I don't have solid plans for the future. My life circumstances have changed, and the amount of free time I have to play with MetalLB has gone to approximately zero.

There are still things I want to do, and experiments I want to try. I'd say the biggest would be:

  • Set up a healthchecking mesh between speakers, so that L2 failover can be faster.
  • Use that healthchecking mesh to also probe backend health, in externalTrafficPolicy: Local mode, and use that to control announcements. This conflicts a bit with what Kubernetes itself does, but it would give another degree of speed to failovers.
  • Integrate either Facebook's Katran or Github's GLB as a second-hop load balancer. This would completely detach us from the (usually broken) behaviors of kube-proxy, and also give us the traffic stabilization properties of Maglev (Google's LB, there's a paper on it). MetalLB with this functionality would be a much more robust load-balancer.
  • Some kind of voluntary telemetry system, so I can collect anonymized data from MetalLB deployments to see how it's being used (BGP vs. L2 mode, how many balancers, how many nodes, frequency of failovers, ...). I honestly don't know what I'd do with that data, partially it's just for vanity so I can see how much it's being used... But it might also help influence the future of the design.
  • Lots of little changes. Some HTTP pages for human debugging. Some degree of control over assignments. Multiple IPs per balancer.

Currently, aside from lack of time, I've blocked all that on getting better e2e tests set up, because the release of 0.7 was pretty bad in terms of regression. There were major internal changes, and they broke a bunch of people because I simply couldn't track all the kinds of deployments people had.

Hope that helps a bit. I'm sure it's not the answer you'd like to hear, but that's the reality of things currently.

I'd also love to figure out a way to crowdsource priorities. Right now the priorities are "whatever I think is important", but that doesn't tell me much about "how much good does this do overall?"

All 7 comments

Great question. Right now, I don't have solid plans for the future. My life circumstances have changed, and the amount of free time I have to play with MetalLB has gone to approximately zero.

There are still things I want to do, and experiments I want to try. I'd say the biggest would be:

  • Set up a healthchecking mesh between speakers, so that L2 failover can be faster.
  • Use that healthchecking mesh to also probe backend health, in externalTrafficPolicy: Local mode, and use that to control announcements. This conflicts a bit with what Kubernetes itself does, but it would give another degree of speed to failovers.
  • Integrate either Facebook's Katran or Github's GLB as a second-hop load balancer. This would completely detach us from the (usually broken) behaviors of kube-proxy, and also give us the traffic stabilization properties of Maglev (Google's LB, there's a paper on it). MetalLB with this functionality would be a much more robust load-balancer.
  • Some kind of voluntary telemetry system, so I can collect anonymized data from MetalLB deployments to see how it's being used (BGP vs. L2 mode, how many balancers, how many nodes, frequency of failovers, ...). I honestly don't know what I'd do with that data, partially it's just for vanity so I can see how much it's being used... But it might also help influence the future of the design.
  • Lots of little changes. Some HTTP pages for human debugging. Some degree of control over assignments. Multiple IPs per balancer.

Currently, aside from lack of time, I've blocked all that on getting better e2e tests set up, because the release of 0.7 was pretty bad in terms of regression. There were major internal changes, and they broke a bunch of people because I simply couldn't track all the kinds of deployments people had.

Hope that helps a bit. I'm sure it's not the answer you'd like to hear, but that's the reality of things currently.

I'd also love to figure out a way to crowdsource priorities. Right now the priorities are "whatever I think is important", but that doesn't tell me much about "how much good does this do overall?"

@danderson Would you be interested in a bounty system like boss https://www.boss.dev/ to generate funds for new releases, features, and bugfixes? Full disclosure: I made boss (for situations just like this)

In theory, yes. In practice, as soon as I'm taking money, it's a job. I already have a job, and I doubt anyone would be willing to fund me well enough to make me want to have a 2nd job.

Put another way: if there are bounties for me working on MetalLB, my most likely reaction will be "you want my free time for _how little_ money? Hell no".

I'm willing to be surprised by how much people are willing to fund MetalLB, but based on how little funding way more successful and "important" projects are getting, I'm not optimistic :)

Fair enough.

I like the general idea of trying to figure out how to get more people involved though.

Is there anything in the relm of an "open source project help wanted" website, rather then one for funding?

That's a totally fair assessment. I'm certainly not going to promise you can make as much as 2 jobs. I know of 2 companies that have used MetalLB and I'd guess there are more out there. And I'm hoping boss will lead to corporate contributions in a way we haven't seen before.

If it helps, using boss doesn't guarantee your time any more than simply having a github repo. And if you want you can say /boss ask $2000 to let everyone know what it will take to close an issue. People and companies who care can pool their bounties until they reach it.

I don't want to solicit anymore in this issue. Feel free to email me if you've got any questions: [email protected]

Thanks for the suggestion! I didn't mean to reject it out of hand. I'm just very aware that as soon as money comes into play, all the dynamics change dramatically, and I'm not sure I'm willing to go there. Right now I can just feel guilty for not doing stuff all by myself, which is easier to do when I don't owe anyone anything in the first place ;)

Well another solution would be asking for help from those that have submitted code contributions to participate in the project.
Perhaps create a metallb organization on GitHub and invite contributors to take part of the project.
Also implementing a CI pipeline could help reducing your time needed on this project and at the same time assuring a baseline code quality being merged into master.
Allowing you control still while having more hands helping with the code writing.

Was this page helpful?
0 / 5 - 0 ratings