I absolutely agree with the findings. Especially the automatic activation of
Policy is really dangerous.
Rajesh Oak
----- Original Message -----
From: "Ben Bullock" <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Initial problems and bugs with ISC (long)
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
--
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
|
