clockwork-developers — Discussion about development of Clockwork

Re: [Clockwork-developers] Kicking around some requirements

[Shawn M. <smc...@ei...>]

This one time, at band camp, Joel Loudermilk wrote:
>=20
> * Management GUI. Of course you can do everything from the command line, =
but
>   if you have a large enough schedule, a GUI might be the only way to
>   manage your schedule effectively. The GUI would be the only component
>   that might should be able to also run on Windows.

Two thoughts:

1) I think we should at least look at the feasibility of the client
running on Windows.  Like it or not, most enterprises have some Windows
in production as well.  I don't see much point in making the server run
on Windows, since security and reliability are design goals.

2) It'd be nice if the GUI layout was subject to configuration, not just
completely auto-generated.  I.E., if you could drag a box from one place
to another, so that it makes more sense to the humans staring blankly at
the screen, and retain that setting across invocations of the GUI.  I'm=20
not sure how to do that scalably, but then I'm not sure how to do it=20
non-scalably either.  :-)

[Clockwork-developers] Kicking around some requirements

[Joel L. <jo...@lo...>]

In doing a little research on the web by looking at commercial job schedulers,
it seems that there are very different approaches to the architecture of a
scheduler. But before I started thinking about that too much, I wanted to
build a list of the things I wanted to see in a scheduler.

Here's what I came up with:

* Cross-platform. It needs to run on lots of UNIX variants. This is an
  enterprise tool, and enterprises rarely have only one platform.

* Reliable. One process or node going down shouldn't hose the schedule. And
  recovering from failures should be easy.

* Management GUI. Of course you can do everything from the command line, but
  if you have a large enough schedule, a GUI might be the only way to
  manage your schedule effectively. The GUI would be the only component
  that might should be able to also run on Windows.

* Scalability. The scheduler needs to work with thousands upon thousands of
  jobs, without requiring heaps of resources or clever kludge-like solutions
  from its operators. I think that AutoSys fails miserably at this.

* Performance. Reactions from the scheduler should be quick. If you have
  enough jobs, AutoSys fails here, too.

* Security. Listening to the scheduler's traffic on the network shouldn't
  give away any secrets. And allowing a system to be managed by the scheduler
  shouldn't open it up to spoof job requests from malicious people on the
  network.

* Flexibility in management. The larger the shop, the more custom a solution
  they'll need for managing the schedule. Things should be configureable
  enough so that it's possible to easily have different groups that monitor
  different parts of the schedule, and different types of roles/access for
  managing them.

I'm trying not to think about implementation details, but just of the things
I would want to see in an enterprise job scheduler.

If you've got any thoughts along this line, please post them. I'm sure
we've all had enough experience with AutoSys to at least have an opinion
on what's important and what's not.

-- 
Joel

[Clockwork-developers] First post!

[Joel L. <jo...@lo...>]

I've always wanted to do that.

Seriously, though, I'm checking to see that the list and archive work.

-- 
Joel