In T66150 I ran into the problem that labs_lvm creates a file resource for the mount point. If the mount point is also a file resource in another module, these clash. I think that volume.pp's file resource should be replaced with a "resource collector" ("User <| title == 'luke' |>").
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | scfc | T66150 tools-redis is down | |||
| Declined | scfc | T91225 labs_lvm can clash file resource for mount point with other packages |
Event Timeline
Comment Actions
Unless I'm mistaken, that would work iff there already is a resource for the mount point (which there generally will not be). Perhaps remove the file resource from labs_lvm (with its dependency) and require that it either be a system directory (as /srv or /mnt would be) or that it be defined elsewhere?
It would work for the current use cases, (/srv, /var/log, /mnt) at least.
Comment Actions
I think you're right. We probably need to use ensure_resource() instead.
(Ceterum censeo: Moving partitions around in a running system is black magic :-). OpenStack should provide a way to specify the partitioning of an instance (similar to but probably simpler than modules/install-server/files/autoinstall/partman/*.cfg) that is set up when the instance is created, and if the partitioning is changed in the OpenStack UI, at the next reboot data is moved & Co. in a DWIM fashion. So no worries about open files existing in two places, etc., instead just a short downtime once and if the instance is up and running, it is up and running for good.)
Comment Actions
Technically, the problem still persists; but without people hitting that error regularly, there is no real point in fixing it.