Here's some information from the developers:
"We are aware of the troubles created by the last DPM upgrades. Sorry
about that, we are trying to improve them.
Thanks for your suggestion, however, we don't want to include the
database schema changes in a post install step.
In my opinion, the main reason is to let the site admin take a database
backup beforehand.
Also, keep in mind that the daemons are not restarted by a post install
script either..."
Cheers,
Greig
Greig Alan Cowan wrote:
> Hi Stephen,
>
> The schema changes have been necessary in recent releases in order to
> support VOMs secondary groups (also for the LFC) and SRM2.2. The
> developer has plans to implement more detailed accounting within DPM
> (which should allow for quotas to be imposed), so there is a good chance
> that additional database tables will be added in the future.
>
> I'll forward your question to the developers about adding the scripts to
> the RPM post install.
>
> Cheers,
> Greig
>
> Stephen Childs wrote:
>> What are people's feelings about the constant schema changes in DPM
>> for point releases (e.g. 1.6.3 to 1.6.4 to 1.6.5)? This doesn't seem
>> to fit with the concept of "production-quality" middleware. Does
>> anyone have a feel for when this churn will end? Has it been
>> communicated to the developers that schema changes should not be made
>> lightly? The problem is bad enough with Yaim, but for those using
>> other solutions (e.g. Quattor), the database update scripts have to be
>> integrated and run as part of each upgrade. (Would adding the upgrade
>> scripts to the RPM post install be an option?)
>>
>> Stephen
|