Aleksander, On Thu, Apr 20, 2023 at 1:22 PM Aleksander Alekseev < aleksan...@timescale.com> wrote:
> Hi, > > > Also, I don't think there's a case for distributed systems here because > we're only managing a single computer's resource: the allocation of local > ports. > > I don't suggest building a distributed system but rather using > well-known solutions from this area. For the described case the > "resource manager" will be as simple a single Consul instance (a > single binary file, since Consul is written in Go) running locally. > The "complexity" would be for the test framework to use a few extra > REST queries. Arguably not that complicated. > Bringing in a process that works over REST API (requiring itself to have a port, by the way) and increasing the rollout of such an environment is antithetical to simplicity and, thus, will make it only worse. If this is the alternative, I'd rather have a few retries or some other small hacks. Bringing in a new dependency with Python is also a heavy solution I'd rather avoid. I find that this is rather a problem with a relatively small surface. If the patch won't go through, I'll just find a workaround to live with, but I'd rather stay away from blowing the development environment out of proportion for something so minuscule. > > > using a KV store to lease a port does not guarantee the port's > availability > > I assume you don't have random processes doing random things (like > listening random ports) on a CI machine. You know that certain ports > are reserved for the tests and are going to be used only for this > purpose using the same leasing protocol. > This is intended to be used by CI and development workstations, where all bets are kind of off. > > > For example, I'd suggest adding an option to Postgres to receive sockets > it should listen [...] > > Not sure if I fully understood the idea, but it looks like you are > suggesting to build in certain rather complicated functionality for an > arguably rare use case so that a QA engineer didn't have one extra > small dependency to worry about in this rare case. I'm quite skeptical > that this is going to happen. > My suggestion was to simply allow listening for a wildcard port and be able to read it out in some way. Nothing particularly complicated. The fact that the process may die before it is connected to is rather a strange argument as the same can happen outside of this use case. -- Y.
