Sophie Lemaitre wrote:
> Wait, I agree only with the documentation change time and date.
>
> But, starting and stoping the services is done by YAIM as needed.
> This is also explained in the Wiki documentation (since the beginning) as well as in the release notes.
>
>
Well, you're right. Probably the best way to do it was to use YAIM. But,
as I mentioned previously, my SE was upgraded by apt-autoupdate, which
unfortunately doesn't run YAIM. When I woke up in the morning, my
databases were already corrupt. So I had to deal with the problem manually.
I don't mind updating things manually. But gLite adopted continuous
update model, which makes sense only with automatic update tools. I
agree, that some things cannot be done without manual intervention. But
in such a case I would like to have it stated explicitly in the release
notes that come to my mailbox. As updates are "continuous", I look at
these notes only superficially, and unless I find something really
serious, stated in capital letters, I let it go automatically. If I had
to update all the nodes manually after every minor update, then the
"continuous" update model = much more work than in the previous
"release" model.
In the update 16 release notes I see only "pay close attention to
glite-CE and lcg-CE_torque". Nothing at all about reconfiguration of
SE_dpm_mysql.
I really don't like to repeat the discussion that has already taken
place here in Sept'06 along with the openssh update. But I think that
putting to the production repository the packages that without special
treatment may cause services' malfunction, when lot of people use
apt-autoupdate, is not a very good idea. I (partially) understand the
openssh case, as it is an external package. But if the same thing
happens with EGEE packages, which are not critical security updates, I
begin to wonder what PPS is for?
> We are always happy to answer all GGUS tickets we get, so please send a mail if you are "fighting", or not sure in which order to do what.
>
>
I appreciate that, and I'm really grateful for the help I already
received from DPM team (for example with my problem with dpm-drain in
ver 1.5.6), but GGUS tickets have to travel very long way before they
reach your desk. Usually they are sorted by TPM shift, sent to ROC,
analyzed by ROC 1st line support, sent back to GGUS, and then assigned
to your group. At least this is what has happened with my previous
ticket concerning DPM. When the harm is already done, and my site does
not work, I don't think that gong through GGUS is the quickest way to
solve the problem.
Cheers,
Adam
|