I brought this up at one of the Condor team meetings, but I think it
needs me to scream about it a little more...
SCHEDD_ROUND_ATTR as currently implemented needs to die, and soon.
How do I hate thee, let me count the ways...
1.) It causes confusion. If I do "condor_q" or "condor_history" with
a "-format" that prints a certain attribute, I have no way of knowing
that I might be seeing a rounded value other than by asking for both
the value and its potential "_RAW" value and parsing the output. This
is stupid.
2.) It causes incorrect values to be calculated. If "CommittedTime",
"RemoteUserCpu", or "NumCkpts" are rounded attributes then the values
are corrupted after a checkpoint restart. If you wonder why someone
might make these be rounded attributes, it is because some sites we
were flocking to had these terms in their "START" expressions and
without rounding the autoclustering was being rendered useless.
3.) It causes errors in the history file. If "ImageSize" is a rounded
attribute, its value in "condor_history" gets messed up with both the
"_RAW" and rounded values being identical. I'm not sure if this only
happens after a checkpoint restart or not.
4.) It can break tools. If "CommittedTime" is a rounded attribute
then "condor_q -goodput" will print out nonsensical results.
5.) It causes stupid hacks to be put into the source code. I see that
in 6.8.2 the fix for the "NumCkpts" problem is to explicitly check for
the "_RAW" value first. That is insane. Is every potential problem
going to have to be fixed by an explicit hack?
6.) It leaves the door open for other things I haven't come across
yet. A user deciding to round an arbitrary attribute shouldn't have
the potential to cause so many unknown side effects.
What should be done IMNSHO...
The whole "_RAW" scheme needs to go away. If you need a rounded value
for an attribute it needs to be stored in a new name. My suggestion
is "_ROUNDED" or some such. Since these rounded values are intended
for autoclustering and matchmaking, the scheduler should be made aware
of them, but their influence should not propagate beyond there.
--
Daniel K. Forrest Laboratory for Molecular and
forrest@xxxxxxxxxxxxx Computational Genomics
(608) 262 - 9479 University of Wisconsin, Madison
_______________________________________________
Condor-devel mailing list
Condor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
