LSF schedudling: developers vs admins

[Quentin]

I'm curious if it is common / best practice to allow individual developers to schedule LSF flows, or if that is more commonly managed by administrators?

I'm working on a new server where the admins create flows and schedule them, after developers have created and deployed a job.

I can see benefits of this approch, but as a developer one challenge is after a flow has been created and scheduled, I can't manually trigger it to test it out.  I'm not the owner of the flow since I didn't create it.  In SAS Management Console I don't have the scheduler plug-in.  And in Flow Manager I can view a flow but can't trigger it.  So I can edit a job or whatever, and then have to wait for the next scheduled run to see if it works.

And if I need to kill one of my flows while it's running, I won't be able to do it, because it's not my flow, it's owned by an admin account.

So two questions really:

1.  Is there a way for me to trigger a flow even if I don't own it and I'm not an admin?  Could an admin define a metadata group, and give developers permission to trigger (and kill) existing flows without giving them permission to create or schedule flows? 

2.  Do most admins centralize management of scheduled flows, or let individual developers schedule (and own) their own flows.

Thanks.

[twocanbazza]

There are particular options in LSF that enable you to allow non-owners to trigger jobs... although the are still called 'Administrators'...

Role	Where defined	Summary of permissions
Normal user	Any operating system user on LSF hosts. All users are automatically assigned this role.	Normal users can view flow definitions, flows, calendars, and jobs that are owned by all users but can control only work items that they own.
Process Manager administrator	Users that are specified in JS_ADMINS in the file js.conf after the first one that is listed.	Process Manager administrators have full control over all Process Manager items of all users. Process Manager administrators can view, control, and modify flow definitions, flows, calendars, and jobs on behalf of other users.
Process Manager Control administrator	Users that are specified in JS_CONTROL_ADMINS in the file js.conf.	Process Manager Control administrators can view flow definitions, flows, calendars, and jobs that are owned by all users and can control flows and jobs on behalf of other users.
Process Manager Group administrator	Users that are specified as GROUP_ADMIN in LSF user groups in thelsb.users file when JS_ENABLE_GROUP_ADMIN=true in js.conf.	Group administrators can view flow definitions, flows, and calendars owned by all users. Group administrators can control flows and jobs on behalf of users who are members of the same LSF user group.

As an admin I for one like the Idea to only allow admin to schedule (Should have been tested in UAT prior to being released and scheduled in production so no need to test) however this has other issues like who monitors job and resolves issues if it failes etc

[Quentin]

Thanks @twocanbazza.  So when you say a job should have been tested in UAT prior to being released and scheduled in PROD, does that mean you have a UAT / TEST envrionment that includes LSF scheduler?  In that environment (or in an early DEV environment), do you allow developers to schedule their own jobs?

I agree, as a developer, if I had a good DEV environment where I could shedule jobs and trigger them myself, then I wouldn't need that access in PROD. 

Sadly, for one server I work on there is no DEV environment.  I can fake /Dev and /Test and /Prod with diretory structures (metadata and OS).  But there's just one PROD SAS server, and one PROD LSF scheduler. From the helpful info you posted I suppose in theory I could try to convince our admin to make me a Group_Admin and have all of the flows I submit be owned by an admin account in the same group.  But I don't think I'll make much progress.

Thanks again for your response.  It's just the sort of admin perspective I was looking for.

[twocanbazza]

Hi @Quentin,

Ideally yes a second environment with SAS and LSF to test the deployment and scheduling (obviously the schedule wouldn't run in the same frequency but it enables the developer to get things right before handing over for release).  

However in the real world, like your site and a site we manage this sometimes doesn't fit; At a site we manage the developers who have rights to schedule etc are now finding issues like what happens when they go on leave for a period of time, who monitors the job and re-triggers if they fail - given the jobs are scheduled using their ID becomes painful - you need to find a happy medium and have a good relationship with your SAS administrators 😉 .

You could have a group setup in LSF with a lower priority that you could test your schedules and then pass to your admins to release in the production queue etc.

Barry