ADSM-L

Re: Initial problems and bugs with ISC (long)

2005-03-03 10:25:20
Subject: Re: Initial problems and bugs with ISC (long)
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 3 Mar 2005 08:24:58 -0700
        Nice write up. 
        #5 in your list was the one that drove me nuts. It just does not
work as expected and I had to go to the command line to create a new
domain and policy.

Ben 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul Fielding
Sent: Thursday, March 03, 2005 2:49 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Initial problems and bugs with ISC (long)

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