[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Schedule Requirements




>>>>> Thippanna Hongal writes:

Thippanna> Here is the list of requirement I did compile to associate
Thippanna> time with the policies.

Thanks for posting this summary. Let me try to rephrase your
requirements to see whether I did understand you correctly:

  The requirement is to support two additional scheduling types. Both
  new scheduling types schedule time intervals, which means they create
  a set operation at the beginning of a time interval and at the end of
  the time interval. It is sufficient if the sets triggered by the
  scheduler modifies the same integer variable. However, it is necessary
  to be able to set two different values at the start and the end of the
  time interval.

  The first new scheduling type (A) specifies the time interval based on
  calendar time. The second new scheduling type (B) specifies the start
  point based on calendar time and the duration of the time interval.

  (Well, you actually wrote in your email that the second starts
  immediately when something (the schedTable entry?) is enabled and runs
  for the duration specified, but the proposed solution you described is
  not really consistent with this. Anyway, I will call this variation
  (B').)

Is that summary of the requirements correct so far?

Now lets look what we have right now in RFC 2591. I believe you can
realize all schedules described above as follows with RFC 2591:

(A)  You create two oneshot schedules in the schedTable, one for
     the start time and one for the end time.

(B)  Similar to (A), you create two oneshot schedules in the
     schedTable, one for the start time and one for the end time.  You
     simply let the manager calculate the end time by adding the time
     interval to the start time.

(B') You generate a single oneshot schedule for the end time and once
     the manager has calculated the end time based on the current
     time. (An alternative would be a very slight modification to add
     a new scheduling type which is basically a periodic schedule
     which disables itself after the first scheduled event.)

Now, from looking at the proposed solution, it looks like you are for
some reason uncomfortable with what I have described above. Is it
possible to clearly describe why the solutions outlined above do not
work or are way too ugly in the snmpconf context? Can you provide
examples to demonstrate your points?

[There are many issues I have with the proposed solutions. But before
 discussing this in detail, I would first like to better understand
 what the problem really is. Maybe there are other solutions that fit
 better into the design of the current scheduler.]

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>