please move /etc/eucalyptus/cloud.d/scripts to /usr/lib/eucalyptus/cloud.d/scripts

[Dustin Kirkland ]

The eucalyptus-java-common package install /etc/eucalyptus/cloud.d.

The upstream eucalyptus build puts some groovy scripts in /etc/eucalyptus/cloud.d/scripts.

This is causing issues with the 1.6.2 upgrade procedure.

First, scripts really shouldn't be installed in /etc. /etc should really only contain configuration information that an Administrator or distro might need to edit.

Because these are installed in /etc, they're not placed there by the debian packaging until after unpack time, in the postinst.

The euca_upgrade script runs during the eucalyptus-common.postinst, and euca_upgrade actually needs to run /etc/eucalyptus/cloud.d/scripts/Import_162.groovy. But this won't exist yet, and hence the upgrade won't happen.

I have a really, really, really gross, hopefully temporary hack in debian/rules, that moves the /etc/eucalyptus/cloud.d/scripts to /usr/lib/eucalyptus/cloud.d/scripts, and then symlinks it back to /etc/eucalyptus/cloud.d/scripts.

Please, upstream, if possible, change your build process to install these scripts here in /usr/lib/eucalyptus/cloud.d/scripts rather than /etc/eucalyptus/cloud.d/scripts. You're welcome to symlink it back to /etc/eucalyptus/cloud.d/scripts if that ensures a minimal diff and other callers can continue finding these scripts there.

Thanks,
:-Dustin

[Dustin Kirkland  (kirkland)]

Dan, can you get someone to take a look at this?

[chris grzegorczyk (chris-grze)]

> First, scripts really shouldn't be installed in /etc. /etc should really only contain configuration information that an Administrator or > distro might need to edit.

This is exactly what they are -- configuration scripts. In each case they are scripts only because there may be a need for the administrator to edit them. The directory name is misleading it seems, it should be 'config'. They are similar to /etc/default and /etc/{init.d,rc.d} in their use.

The Import scripts are indeed different and can be moved to where ever FHS demands. Nonetheless, that is not going to solve the problem as the import scripts depend on the configuration information that is in the others. Specifically, bootstrapping the database to do the update needs to configure it correctly, so, it depends on the configuration information.

It sounds like the hack you have works around the problem in dpkg, for now. Do you have any other suggestions?

cheers.
chris

[Dustin Kirkland  (kirkland)]

Unfortunately, the hacks and workarounds are not working properly.

In order for euca_upgrade to run in any package's postinst, we are going to need all scripts that it depends on to be installed in /usr/lib/eucalyptus somewhere.

I believe this is Import_162.groovy, but perhaps you can tell me if there are more.

Upgrades from 9.10 to 10.04 are totally blocked on this issue right now. As we expect some user to begin upgrading at Beta1, we need some attention to this issue ASAP.

[Daniel Nurmi (nurmi)]

Talked with Dustin, we're going to attempt to

a.) back up old scripts/ to the backup directory
b.) remove the old scripts/
c.) install new scripts in /usr/lib/eucalyptus/scripts/
d.) create softlink from /usr/lib/eucalyptus/scripts to /etc/eucalyptus/cloud.d

-Dan