Please make sure groups honor secondary posix groups, not just primary posix group.

Hey Nate -

Please remember to set the Site to UCAR, or you'll get stuck in Severity 6 for a while.

We generally eschew anything related to the unix groups for performance reasons - constantly polling LDAP / NIS / whatever to verify user permissions is horrendously expensive, whereas slurmctld can always know which accounts correspond to which users.

Is there a reason you cannot use Slurm accounts here, and are thus asking for unix groups?

- Tim

Accounts are based on our funding sources and do not track directly with our unix groups. Accounts also come in and out of existence to what is effectively random timing to a systems perspective. We use local files for groups but wouldn't nscd also act to cache the groups to dull any performance hit. Would it also not be possible to document the perf hit to warn sites that have ldap/nis?

(In reply to NCAR SSG from comment #3)
> Accounts are based on our funding sources and do not track directly with our
> unix groups. Accounts also come in and out of existence to what is
> effectively random timing to a systems perspective. We use local files for
> groups but wouldn't nscd also act to cache the groups to dull any
> performance hit. Would it also not be possible to document the perf hit to
> warn sites that have ldap/nis?

How do these reservations work then? Why can't whatever's creating them also figure out which account(s) to add in?

And yes, while it's technically feasible to build that, we really don't like giving people easy ways to shoot themselves in the foot. And the performance hit can be quite significant.

If you'd like, I can tag this as an enhancement request. My standard disclaimer does apply here though - we do not promise when/if we'll get to any of them, outside of requests handled under a custom development contract.

> How do these reservations work then? Why can't whatever's creating them also
> figure out which account(s) to add in?


Humans create them, and what might be one or two unix groups can map to a bunch of accounting groups. We don't get to influence the accounting groups (Slurm associations) too much - that's determined by financial allocations.

>
> How do these reservations work then?

With longer reservations, membership in groups can changes as projects
change and as people are hired/depart.


> Why can't whatever's creating them also figure out which account(s) to add
> in?

We could do this, some kind of cron job or maybe even a daemon that watches
for changes to groups and updates the reseveration. I personally rather not
write a scheduler to schedule our scheduler though.

we really don't like giving people easy ways to shoot themselves in the foot

 I like that plan but isn't documenting it sufficient, maybe even with a
warning at reservation creation?

tag this as an enhancement request
>
Please do if that is how this works. I also ask documentation be updated to
make it explicit groups are not support (yet).

Thanks
--Nate

On Mon, Jan 8, 2018 at 1:16 PM, <bugs@schedmd.com> wrote:

> *Comment # 4 <https://bugs.schedmd.com/show_bug.cgi?id=4591#c4> on bug
> 4591 <https://bugs.schedmd.com/show_bug.cgi?id=4591> from Tim Wickberg
> <tim@schedmd.com> *
>
> (In reply to NCAR SSG from comment #3 <https://bugs.schedmd.com/show_bug.cgi?id=4591#c3>)> Accounts are based on our funding sources and do not track directly with our
> > unix groups. Accounts also come in and out of existence to what is
> > effectively random timing to a systems perspective. We use local files for
> > groups but wouldn't nscd also act to cache the groups to dull any
> > performance hit. Would it also not be possible to document the perf hit to
> > warn sites that have ldap/nis?
>
> How do these reservations work then? Why can't whatever's creating them also
> figure out which account(s) to add in?
>
> And yes, while it's technically feasible to build that, we really don't like
> giving people easy ways to shoot themselves in the foot. And the performance
> hit can be quite significant.
>
> If you'd like, I can tag this as an enhancement request. My standard disclaimer
> does apply here though - we do not promise when/if we'll get to any of them,
> outside of requests handled under a custom development contract.
>
> ------------------------------
> You are receiving this mail because:
>
>    - You reported the bug.
>
>

To jump back a bit, based on what you've described I don't see why the Accounts aren't sufficient.

Is there a disconnect between how your accounts are provisioned, vs. the projects that should have access to these long-lived reservations?

In such a case, would extending the reservations to handle access control based on QOS work instead?

I have no real interest in extending the reservation model to work on *nix groups, for the reasons previously outlined.

Nate -

I haven't seen a response on comment 7, and am moving ahead to close this out. Please reopen + respond to those questions if you'd like to pursue this further.

- Tim