Adam,

I think this has nothing to do with DPM but your assumption that continous 
release model makes sense only with automatic updates is, as for me, 
completely wrong. As a site admin, I'll never run automatic update on the 
background, without confirming in some way I want the update to proceed. 
There are many components in the middleware where you cannot guarantee that 
there is no manual action required to update the service (there was the 
same issue with the LCG RB a few updates ago).

We don't use YAIM, we use Quattor. But it doesn't matter. With Quattor we 
download the update (more or less automatically) as soon as it is announced 
and we review it before deciding to go with it or not. After making the 
decision (a matter of a few commands), everything goes unattended, if 
possible. Or we do the proper schedule (including downtimes), if it is 
required for a service.

For me, one of the main advantage of "continuous release" is not unattended 
update but the fact that one update generally doesn't update more than one 
service, sometimes 2, so this is easier to schedule the update appropriatly 
with the service requirements than with a huge update with many services 
involved.

Michel

--On samedi 10 mars 2007 15:43 +0100 Adam Padee <[log in to unmask]> 
wrote:

> 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



     *************************************************************
     * Michel Jouvin                 Email : [log in to unmask] *
     * LAL / CNRS                    Tel : +33 1 64468932        *
     * B.P. 34                       Fax : +33 1 69079404        *
     * 91898 Orsay Cedex                                         *
     * France                                                    *
     *************************************************************