ADSM-L

Initial problems and bugs with ISC (long)

2005-03-03 04:49:50
Subject: Initial problems and bugs with ISC (long)
From: Paul Fielding <paul AT FIELDING DOT CA>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 3 Mar 2005 02:49:11 -0700
Ok IBM, here's my initial ISC findings for you.  There'll probably be more down 
the road, I'm sure....

Bugs/Annoyances:

1. When setting the dbbackup trigger, the ISC doesn't let you set 0 
incrementals between fulls.  If I want to have every dbbbackuptriggered 
dbbackup run as a full, I need to set the trigger from the command line.

2. When adding node associations to a client schedule, the final list of nodes 
displayed is only wide enough for nodenames roughly 8 characters wide.  Any 
decently long nodename gets wrapped, making it a pain in the butt to read.

3. The Actlog is a pain in the butt to read.  Either give us back a clean 
window that can display standard actlog output (as per the old web interface) 
or at least fix the actlog display so that it
  a) has the timestamp first, instead of way off to the left where one has to 
scroll to see it, 
  b) let us choose a begint
  c) show us *all* entries - currently it seems to me that not all messages get 
displayed.

4. When looking at a client schedule: if there are nodes associated with the 
schedule, the ISC displays only the nodes that are associated (good).  If there 
are *no* nodes associated with the schedule, it displays *all* nodes that exist 
(bad).  It gives the impression that all of those nodes are associated.

5. **BIG BUG**  Management Classes.  The new ISC philosophy seems to be that we 
now hide the existence of Policy Sets and Copy Groups from the end user.  
Policy sets are completely hidden, and copy groups are simply shown as values 
that can be set within a mgmt class.  Ok, I can live with that.  Except that 
it's inconsistent and in one case genuinely wrong.  In order to hide policy 
sets from the end user, the ISC needs (and tries) to validate and activate the 
STANDARD policyset after changes have been made to the mgmt class/copy group.  
If we ignore the fact that one probably shouldn't be blindly letting the ISC 
validate and activate the policy set, we cannot igore the fact that it doesn't 
always do it.

When you make changes to a mgmt class/copy group, the ISC automatically 
validates/activates the policy set.

However, when you *add* or *remove* a mgmt class/copy group, the ISC does *NOT* 
validate/activate the policy set.  The mgmtclass is added or removed from 
STANDARD, but ACTIVE is untouched.  Worse yet, the ISC happily declares that 
your changes were successful and then displays your changes.  ie. it displays 
what the STANDARD policy set is doing, not what the ACTIVE one is doing.  This 
gives you the false impression that your changes are active.

Fortunately, there is one single place in the ISC where policy sets are 
mentioned - the teeny drop down option under Policy Domains that says "Activate 
Policy".  Of course,  this is the one case where rather than being it's usually 
over wordy self it instead explains none of this to the end user.   If you use 
this action, the policy set will indeed be activated.

One of two things needs to happen: a) val/act when adding or removing a mgmt 
class, or b) never val/act and instead make it more clear that this needs to be 
done by the user after making changes.

If IBM fixes nothing else on my above list, this issue must, must, must be 
addressed.

6. Comand line.   Please - give us back a usable command line from within the 
ISC.  The great thing about the command line in the old web interface was that 
it sat at the bottom of the browser, out of the way when you were pointin' and 
clickin' around the GUI, but was right-there-now when you wanted to enter a 
command, and the results showed up nice and big in a grand window that was wide 
enough to show the output and you could scroll down easily to see the results.  
The command line interface in the ISC is in a dumb, annoying to reach place - 
you need to make a million clicks to find it, and then it's annoying to use 
when you get there.

The GUI has some advantages, but sometimes there's just no substitute for being 
able to fire off a few ad-hoc commands.

7. The FINISH button.  Every other wizard in existence, after asking you all 
your questions, gives you a FINISH button - at which point you may either click 
on FINISH to make the action take place, or you can cancel out, knowing you 
haven't changed anything.   The ISC wizards actually do their action after you 
press an arbitrary NEXT button, and only displays FINISH *after* the action has 
taken place.   You don't get that last ditch chance to not make your change.  
Not very intuitive.



I'm sure I'll have more, but these are all I can think of right now.  I hope 
somebody passes these on to the right people...

later,

Paul