<div dir="ltr">As a side note: <br>In Slurm 23.x a new rate limiting feature for client RPC calls was added: (see this commit: <a href="https://github.com/SchedMD/slurm/commit/674f118140e171d10c2501444a0040e1492f4eab#diff-b4e84d09d9b1d817a964fb78baba0a2ea6316bfc10c1405329a95ad0353ca33e">https://github.com/SchedMD/slurm/commit/674f118140e171d10c2501444a0040e1492f4eab#diff-b4e84d09d9b1d817a964fb78baba0a2ea6316bfc10c1405329a95ad0353ca33e</a>) <div>This would give operators the ability to limit the negative effect of workflow managers on the scheduler. <br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 27, 2023 at 4:57 PM Davide DelVento <<a href="mailto:davide.quantum@gmail.com">davide.quantum@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > And if you are seeing a workflow management system causing trouble on<br>
> > your system, probably the most sustainable way of getting this resolved<br>
> > is to file issues or pull requests with the respective project, with<br>
> > suggestions like the ones you made. For snakemake, a second good point<br>
> > to currently chime in, would be the issue discussing Slurm job array<br>
> > support: <a href="https://github.com/snakemake/snakemake/issues/301" rel="noreferrer" target="_blank">https://github.com/snakemake/snakemake/issues/301</a><br>
><br>
> I have to disagree here.  I think the onus is on the people in a given<br>
> community to ensure that their software behaves well on the systems they<br>
> want to use, not on the operators of those system.  Those of us running<br>
> HPC systems often have to deal with a very large range of different<br>
> pieces of software and time and personell are limited.  If some program<br>
> used by only a subset of the users is causing disruption, then it<br>
> already costs us time and energy to mitigate those effects.  Even if I<br>
> had the appropriate skill set, I don't see my self be writing many<br>
> patches for workflow managers any time soon.<br>
<br>
As someone who has worked in both roles (and to a degree still is) and<br>
therefore can better understand the perspective from both parties, I<br>
side more with David than with Loris here.<br>
<br>
Yes, David wrote "or pull requests", but that's an OR.<br>
<br>
Loris, if you know or experience a problem, it takes close to zero<br>
time to file a bug report educating the author of the software about<br>
the problem (or pointing them to places where they can educate<br>
themselves). Otherwise they will never know about it, they will never<br>
fix it, and potentially they think it's fine and will make the problem<br>
worse. Yes, you could alternatively forbid the use of the problematic<br>
software on the machine (I've done that on our systems), but users<br>
with those needs will find ways to create the very same problem, and<br>
perhaps worse, in other ways (they have done it on our system). Yes,<br>
time is limited, and as operators of HPC systems we often don't have<br>
the time to understand all the nuances and needs of all the users, but<br>
that's not the point I am advocating. In fact it does seem to me that<br>
David is putting the onus on himself and his community to make the<br>
software behave correctly, and he is trying to educate himself about<br>
what "correct" is like. So just give him the input he's looking for,<br>
both here and (if and when snakemake causes troubles on your system)<br>
by opening tickets on that repo, explaining the problem (definitely<br>
not writing a PR for you, sorry David)<br>
<br>
</blockquote></div>