Priorities and Permissions

[sosborne76]

I work for a college so managing priorities is a tricky business.

Ideally student users shouldn't be able to prioritise their own jobs over someone elses, whether this be submitting a job at a higher priority or bumping it up. But it would be handy to give some provision in certain circumstances to allow for proritising. For example, a 3rd year student over a 1st year student or a student working on their final project over all others. But for any of these circumstances you wouldn't want the same class of user, say two third years, to be able to prioritise their job in front of their peers. In the case of users of the same class first in first out rules should apply. Obviously having an administrative class of user who has ultimate authority is a must.

Now I have been experimenting with user permissions, priorities, and looking into group memberships but unless I am missing something I can't figure out how to do what I have in mind. I have been starting to read up on clustering too but its the end of the day and nothing is making sense. Is there a way for me to achieve my goals? And what is the cleanest and most college friendly way to do it?

Furthermore I don't want any of the students to be able to manipulate each others jobs in anyway. This seems to be handled by the default user permissions as the user doesn't have admin priveledge as far as I can see. Is this right?

Thanks in advance.

Simon

[sosborne76]

I have been doing some testing working with clusters. Initial tests of submitting two jobs to a single host (/test cluster), the first to the default cluster and the last to the test cluster result in what you would expect (the latter being run first). But I am not sure how I can make it work for the college environment given that their are three different year groups and that two of those year groups have important projects that they need to do.

[sosborne76]

Furthermore I have read and re-read the documentation on user permissions, and I have also had a look round the site and forums. To be honest there isn't enough detail in the documentation on permissions. For instance what exactly do bump, shove, callback and globalcallback give the user the ability to do? Does a given permission give a user the ability to manipulate the jobs of others in that way? What do admin, sudo, impersonate and lock give permission for? Is it possible to deny people permission to prioritise their jobs as anything but 9999?

I do have some assumptions on some of these but rather than testing everything to the nth degree a more detailed explanation would make life easier and eliminate grey areas.

Also user groups seem to be an unusual proposition. Rather than groups being a way to collect together users with identical priviledges (thereby creating classes of users) they allow the group members to manipulate each others jobs. Helpful if you have different teams working on different projects, but in an education environment (or the like) where you have students submitting jobs you don't want to give them any rights over their peers apart from in a special circumstance. Am I missing the point here?

I am wondering actually when it comes to a working environment how useful specifying permissions can be, as in reality who would want to prevent a user from killing their own job? Surely the beauty of permissions is giving priviledge to users in order to make group working possible, provide certain users heightened permissions (perhaps they have important projects), and have administrative users who can maintain the queue? Well I guess the group one is possible vis user groups but after that I am not so sure.

Sorry for rambling a bit here but I have been left wondering how I can provide the live working environment my users require using the permissions, group and queuing features of Qube.

[sosborne76]

Any help admins? Or someone who knows Qube really well for that matter.

[eric]

In general, the permissions grant you the ability to use those features of Qube only for your jobs. There are two means by which you can use those features with someone else's jobs: as an admin (with the admin permission) or if you are all granted those permissions inside a group.

The group permission model was designed in order to facilitate granting a full set of permissions to an isolated group, usually a set of render wranglers. They can manipulate their own jobs, but no one's outside the group. That way, one member of the group could come on to their shift, submit a series of jobs, but then a later staff member could come along later in the day and add subjobs (modify cpus) or kill them if the need arises. The only other means would be for each wrangler to login under the same name, which poses its set of issues/problems.

I hope this helps to clarify things.

[sosborne76]

Thanks for the reply.

It reinforces what I already thought about permissions and in particular the admin permission.

they allow the group members to manipulate each others jobs. Helpful if you have different teams working on different projects...

And also that groups are a way for all members to manage each others jobs.

I still don't know if there is a priviledge that can limit the ability to change priority or submit at a higher priority. Or what some of the more obscure priorities do. And I don't know how useful clusters will be for all the levels of priorities we require.

So today I am going to experiment with clusters and nested clusters to see if I can achieve my aims. And otherwise I will have to recommend that all users use priority 1 to avoid the bad feeling and contention that will undoubtedbly ensue with students involved.

Does anyone have any further advice?

[sosborne76]

I have run numerous tests on the farm:

- Worker group Test (nodeA, nodeB), nodeA (/rave), nodeB (/rave/1st). Worker services stopped.  Jobs sent to clusters /, /rave and /rave/1st. Worker services started. The /rave/1st job runs 1st, then the /rave and finally the /.

Nothing strange there.

- Worker group Test (nodeA, nodeB, nodeC), nodeA (/rave), nodeB (/rave/1st), nodeC (/other). Worker services stopped. Jobs sent to clusters /, /rave, rave/1st and /other. Worker services started. The /rave/1st job runs 1st, then the /other, then the /rave and finally the /.

All of which makes sense again given that /other has priority on nodeC.

- Worker group Test (nodeA, nodeB, nodeC), nodeA (/rave), nodeB (/rave/1st), nodeC (/). Jobs sent to clusters /, /rave, and /rave/1st. The /rave/1st job runs 1st but doesn't use nodeC even though its free, and then the /rave on nodeC. Odd as I would have expected on the FIFO order of things job / to be next. And finally the /.

Some oddities here given that free cpu's weren't used to start with and that FIFO queueing didn't then apply for the non-clustered (job /) given that cpu's were free.
What happened in both these cases?

Another oddity I noticed in general was that in most cases (I ran more tests than these) it isn't always the job that starts first is finished first. Now all jobs executed were the same, but in most cases the /rave/1st job started first and finished last and the / job start last but finished first. This was because a couple of frames on the 1st job inexplicably took over 10 mins to complete. Whereas the /job all completed in a short time. What was going on with the total completion times here?

But at least the /rave/1st always seemed to start before the /rave or the /.