I have first hand knowledge with large consultant companies, they are largely sales teams with minimal IT knowledge. I had to help a one of their overseas "senior cloud professional" that had issues even understanding how to navigate the cloud UI.
But obviously it would be far from accuracy that LLM would be able to do. E.g. generate search keywords, tags, other type of meta data for a certain document.
Yup that's exactly it. By being able to tag things with all sorts of in house meta data we were then able to search and group things extremely accurately. There was still a lot of human in the mix, but this made the whole task going from "idk if we can even consider doing this" to "great, we can break this down and chip away at it over the next few months/throw some interns at it".
Yeah, I don't know - hearing arguments that this was already done by ML algorithms is to me hearing like "moving from place A to B existed already before cars". But it seems like a common sentiment. So much that simple ML attempted to be doing required massive amount of training and training data specific to your domain before you could use it, and LLM can do it out of the box, and actually consider nuance.
I think organizing and structuring data from unorganized data from the past is a massive use case that seems heavily underrated by so many right now. People spend a lot of time on figuring out where to find some data, internally in companies, etc.
DSC has a really really wide variety of windows modules and unfortunately there isn't really anything comparable, Puppet and Ansible do have interfaces to DSC modules but it's kind of janky compared to just using DSC.
Canada has very lax crime punishment, which is sad for the victims. There's been cases where people have killed others after 3-x crimes and released with future court dates.
So HAProxy has a bit of a love/hate relationship in Kubernetes, the problem really being UDP and the mess(?) that is proxying stateless traffic. The Gateway API kind of expecting UDP proxying support doesn't help.
UDP through a proxy is total non-sense. There isn't any single UDP-based service that is cleanly proxyable. Not just one. Most of them rely on the source IP address itself (plus port) or announce it in the protocol, then require either to spoof the source address and reconfigure all servers to route responses through the proxy, or the proxy to mangle the contents (not even always possible). There's no notion or indication of beginning nor end of connection, packet direction, nor number of packets expected in each direction. Sometimes assigned ports on both sides are not even compatible anymore with some protocols. And it's even funnier when some users want to proxy some IPv6 traffic to an IPv4 server and they don't even understand that it's not possible to perform transparent proxying in this case. UDP has always been for light stateless stuff on direct connections, and a proxy is everything but that.
In short, only services that support being NATted by a firewall will be transportable over a proxy (sometimes with some efforts), and will always be better handled using LVS that does that natively, with less overhead, less resources and less configuration. I've yet to see a single valid case for generic UDP proxying.
The only cases that make sense are service proxies (syslog proxy, DNS proxy etc), which I'm perfectly fine with. For example our syslog proxy can listen to UDP and forward to UDP, TCP and/or stdout, message by message. But for now I'll continue to firmly oppose to the supporting generic UDP in haproxy and I will continue to tell requesters that their demand is stupid and proves a very poor understanding of networking basics.
In the end there's a nice tradeoff: internally at HAProxyTech some of my coworkers have implemented generic proxying in the enterprise edition for all those whom we don't want to say their demand is stupid, because they're willing to pay to avoid using their brain. They're happy with that (at least I hope so), and we don't have to pollute the core with code trying to plug uncovered areas for people complaining on an issue tracker that something does not work due to their uneducated architectural choices. So in the end everyone wins.
I've been knee deep into TURN lately, so while it would be a terrible idea, I think you could do something like TURN in 'server mode', where the origins are TURN clients and the proxy is a TURN server.
Then when a packet comes in, you decide which origin to forward it to (by unspecified magic), and then send it on annotated with the source ip and port. Replies from the server would include the desired destination ip and port. TURN can also setup a 'channel' so data packets skip the addressing. The end client facing service ip and port would be implicitly linked to the internal TURN service ip and port.
I think the turn server I've been working with could do this out of the box for a single origin server with specific configuration. With a single origin server, it's not very useful other than proof of concept, of course.
But LVS or some other lower level balancing, where ideally the origins are configured with the service ip and port, and outbound packets don't need munging (DSR) sounds like a much better idea. Any sort of rules based forwarding based on a generic UDP packet seems hopelessly complex because of tracking state on stateless protocols.
An example of what seems to be a reasonable usecase for UDP proxy is Quilkin[1] from Google.
Made for hosting game servers on Kubernetes, and supports session auth, routing, monitoring, and various other features, some of them using prefix bits in UDP packages.
Also used for DOS protection without the traffic hitting the server.
Not sure how usable it is but Google actually has a lot of open-source stuff for game hosting on kubernetes with agones + openmatch + quilkin, I am somewhat tempted to play with them at some point.
It is an interesting topic. We don't see UDP in Kubernetes that often but we do support it in various ways depending on the application. HAProxy Community supports QUIC, which is UDP and Syslog load balancing. HAProxy Enterprise (the paid one) has a UDP module that supports other applications too.
reply