Hi Raphaƫl, On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote: > I want to know it precisely in the context of selecting a worker. I don't > want to schedule a task on a worker and later get back an answer "sorry I > can't handle your task", and then have to schedule it on some other > worker.
I'm a little unsure what you mean precisely here. Do you want your scheduler call out to your worker and ask it whether it can handle the build? Or do you want to locally decide whether your worker can handle it (e.g. using data previously acquired from the worker and cached on the scheduler)? Or do you want to know whether a backend is capable of satisfying a request in principle without considering the concrete system performing the build? I guess it is not the last variant, because you cannot validate the distribution in any way. I guess it also is not the first variant, because you don't want to call into every single worker for every single build object. Do you confirm that you want the second variant? That might be a little more difficult due to the data collection part. I'm not sure I can reasonably cover that. > When I have selected a worker, I want to be sure that the worker > is properly configured to be able to run that specific task. That much makes sense in principle, but what do you want debusine to do when one of your workers is misconfigured and cannot reach its primary mirror? All builds there will fail and likely you can identify that the failure happened too early for the package to be at fault. You can either pass down the failure such that users have to deal with temporary issues or automatically reschedule the build elsewhere. Additionally, you can disable such a worker of course. Still, I suggest that you cannot rule out all possible worker-specific failure modes ahead of time. > Yes, but using the ssh backend will require specific user configuration > while the sbuild/pbuilder one could potientially be auto-selected based > on whether the user did run the appropriate sbuild-create-chroot or > pbuilder --create earlier. That definitely is implementable. It could be a simple "use sbuild if it works, else try pbuilder, else try mmdebstrap with a default mirror". I don't think I'd use it, but it might be a good default value for tools that need to perform builds. I've taken a note and will look into implementing this. > "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I > don't care how it gets built!). Indeed, one of my use cases is to get a log and no .debs. You can explicitly request no artifacts and that'll prevent them from being transferred over mdbp-ssh. > "deblord" or "debring" - the lord of the ring to tie all package builders > together Hmm. The more I think about this, the more I like the untypable mdbp: You only type it once to configure your application that does perform builds. If you actually type mdbp regularly, you're doing it wrong. It really is not meant as a frontend to be used interactively. Helmut