to symlink or not to symlink?

[Mike Pontillo]

On Mon, Nov 21, 2016 at 5:32 PM, Horacio Duran <horacio.duran at canonical.com>
wrote:

> To me the question is, does systems allow this practice? Or at least does
> it discourage it? If not this sounds a lot like a Maas bug that could
> potentially bite them with different services.
> I was not the one to write that code but I know it's written that way to
> avoid the need to call on systemd reload (the actual name escapes me) when
> we do changes on the script also it is shared between systemd and upstart.
>

MAAS does not have an opinion about filesystem organization. If a
particular filesystem organization isn't working out for its users'
deployments, the admin can adjust it as necessary. That said, normally I
see MAAS users mount extra space on a separate, unused path... and that
seems wise, because issues like this are not unique to systemd and juju.

Mounting /var on another disk is a commonly-accepted UNIX practice. It
would be nice if it worked.


> On Mon, Nov 21, 2016 at 10:22 PM Anastasia Macmood <
> anastasia.macmood at canonical.com> wrote:
>
>> There is a nice, yummy bug [1] with respect to change in Juju behavior,
>> possibly related to changes when systemd support was added, where we
>> started symlinking to /var/lib/juju/init & /etc.
>>
>> Simple solution seems to be stop symlinking \o/ Thoughts?
>>
>
I think this should be explored. I'm not a systemd expert, but I assume
they have a requirement that all of the runtime dependencies reside on the
same disk. (Maybe so it continues to work if /var is unmounted.)

But if it's desirable to have a symlink, then the question in my mind is:
does Juju change the file post-install [at runtime]?
 - If yes, that's probably why it was placed in /var -- and then the real
bug becomes "how can we re-design it to not do that?". ;-)
 - If no, (for example, if the file only changes when Juju is upgraded) I
would say it should probably go into /etc/juju somewhere. That way, the
symlink would resolve to somewhere that is most likely on the same disk.


> [1]
>> https://bugs.launchpad.net/bugs/1634390
>>
>
Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161121/c60f3c67/attachment.html>