[Spike] Setting directory for .crc folder

[Maurycy-Krzeminski]

Is there consideration to use XDG base directory, or maybe using some other named env variable that would allow to set where .crc folder should be?

From what i saw issue 220 about XDG was closed.

[anjannath]

If we change the crc home dir, we should also do automated migration of the config file to the new location. I think XDG base directory as the default and allowing users to override with $CRC_HOME_DIR both should be added

[vyasgun]

/assign

[vyasgun]

Please correct me if I am wrong -- The .crc directory stores the cache, machine info, and socket for communicating with the crc daemon and is used in multiple parts of the lifecycle (setup, start). Just setting the environment variable can create a discrepancy if the user sets it multiple times

export CRC_HOME_DIR=/tmp/crc1
crc start
crc stop
export CRC_HOME_DIR=/tmp/crc2

It is difficult to keep track of all the values the variable can take and migrating over and over does not seem like a feasible idea. (I made a draft PR for this)

My suggestion is to use crc config to store the path of the .crc directory which can be set and unset using the crc config command. This makes validation easier, it's more explicit, and easier to keep track of. Also, it reinforces the idea that we cannot have multiple .crc directories each having its own cache, socket etc.

[praveenkumar]

My suggestion is to use crc config to store the path of the .crc directory which can be set and unset using the crc config command. This makes validation easier, it's more explicit, and easier to keep track of. Also, it reinforces the idea that we cannot have multiple .crc directories each having its own cache, socket etc.

In this case also user can do following

crc config set base-directory foo
crc start
crc stop
crc config unset base-directory

One thing we can do as part config option is have a callback function which check if current set directory already have content or not, if it have let user know and ask for override otherwise carry on with provided option?

[vyasgun]

I was thinking we could migrate from the existing base directory (if nothing is set, we would use the default $HOME/.crc to the newly set one. (Unset could trigger reverse migration from the custom location to the default location).

[cfergeau]

My suggestion is to use crc config to store the path of the .crc directory which can be set and unset using the crc config command. This makes validation easier, it's more explicit, and easier to keep track of.

I'd first make that work well before thinking too much about corner cases (such has the user changing the base directory while using crc). Though a callback would make sense to check if there's already a configured directory. This callback could offer the user to migrate. But this is starting to get complicated ^^

The suggested approach will not solve the initial request to use the XDG directory structure, where we'd need to use ~/.cache/crc, ~/.local/share, and (.local/state and/or XDG_RUNTIME_DIR) (only mentioning this for clarity, not saying this has to be solved - it could be too late for that, though once we can relocate/migrate ~/.crc, we can think how hard it would be to have optional migration to XDG)

[gbraad]

XDG directory structure

Which complicates deployment on platforms other than Linux, so this might not have been the solution to begin with.

The question that has not been answered is the 'Why' is this requested?

• large files/storage requirement not available on the default location
• permissions maybe not available
• roaming profile or other issues with user directory on a network share/'removable media'
• ...

[Maurycy-Krzeminski]

For my case it was large files/storage requirement not available on the default location, currently I just run it from my fork with this one small change and this works for me commit

[gbraad]

default location

are you on Linux or MacOS? Would a re-location with a symlink have worked?

The issue is that we use a standardized location to ensure the VM files are always in the same location; if we allow this to be configured, there can be a inconsistency; the VMM already has a registration with a VM called 'crc', while the executable sees nothing in it's own .crc/machines folder.

The commit you show is an elegant solution that might work for platforms that support this;

I would say:

• if XDG_DATA_HOME (linux only) is set or a possible override CRC_DATA_HOME (all platforms?) is given.
• check permissions in the home (something we didn't do before; as relocation might not be OK)
• ...

[Maurycy-Krzeminski]

I run it on Windows 10. I didn't try to use symlinks, I will test them next week, mabe they actually solve all my problems.

[gbraad]

On windows junctions might be able to do this, or a remapped location for a disk with Disk Manager. But be aware, on Windows you can NOT store VM disk files on anything that is a "Removable Media"; USB or disks that are dynamic.

I run it on Windows 10.

But most likely not with the XDG value, as this is unknown on a Windows system:

C:\> powershell
PS> $env:XDG_DATA_HOME
PS> $env:HOME
C:\Users\gbraad

Note: in your commit you check for an empty value, so that would be ignored. However, if this is not possible on the platform, best to use constants_linux.go for platform specific solution, or use an additional CRC_DATA_HOME to override either if existent, as this would work on all platforms and is more explicit. This would also allow you to set export CRC_DATA_HOME=$XDG_DATA_HOME to achieve the same.

[gbraad]

As commented on the Spike PR by @vyasgun:

---

The objective of this spike was to test whether the crc config can be used to configure a custom .crc location. The conclusion is that it is not something that will solve the problem and could potentially cause unexpected issues in certain edge cases:

• If VM has already been started, modifying .crc location could result in inconsistent behaviour.
• The base case (for the default directory to open from) has to be defined outside of .crc folder as it will result in a chicken and egg problem.
• The major request to use a custom directory mainly comes from having a custom location to store the larger files such as cache and machine configs. Using more straightforward solution such as using environment variable related configuration may be more helpful to accomplish this.
• The original request for using XDG base directory env variables in certain cases may be solved using this commit:

Next steps:

• Redefine the problem and come up with a solution that enables the user to manage their storage more effectively.

[praveenkumar]

. The original request for using XDG base directory env variables in certain cases may be solved using this commit:

I think if this is something user want then we can set CRC_DATA_DIR env variable and can be used across platform but user should set required permission and selinux context to that directory manually before use it.