I’m working on updating the lxc-local script and have done this: Comparing lxc:main...desultory:main · lxc/lxc · GitHub
Is there anything about this that would break current usage? I’m also not really sure how that “in_userns” check is supposed to function.
I think it makes sense that a metadata tarball is not required, but used if supplied.
It’s pretty difficult to review, at least in the way that Github shows it.
If you have the time, those kind of changes are usually far easier to review when split as multiple commits within your pull request.
You basically want to have each commit focused on one thing, whether it’s renaming a variable throughout the code, or move a chunk of code into its own function and have it be called, that kind of stuff.
That also makes it easier to separate purely cosmetic/reshuffling commits where all the old code is still run, it’s just re-located/re-indented/… vs functional code changes that need to be more thought through.
Would it be possible for me to annotate the commit?
80% of it is reshuffing, I tried to format it more nicely, improve logging/variable names a bit, and make most procedures functions.
Is there some documentation for what lxc-create is doing behind the scenes? I think it uses some environment stuff which is checked in the script but is not really used in the script.
Would it be considered harmful to allow no metadata tarball being specified? It seems entirely optional given a totally empty one works.
Would it be harmful to allow for tarball extraction failures? In some cases they fail because device nodes cannot be created, but this is not an actual issue. It causes the script to try to cleanup and this fails with btrfs subvols where users can’t delete them.
I think this should be better, still not sure about the userns/uid mapping stuff within this template script