Manage all files in a directory

[https://www.google.com/accounts/o8/id?id=AItOawm53g_OvEixgi55cBdUXTHWrAwrQcK1PlU]

Bcfg2 should be able to manage a directory, such that it could report and possibly remove files that are not packaged or specified as Path entries.

[solj]

This should be possible in 1.2.0 with the new VCS stuff.

[solj]

Oh, nevermind. I think this is the thing where you wanted the client to be smart enough to know about files owned by the Packages listed.

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

This already exists somewhat with the prune="true" attribute of a <Path type="directory"/>. Making pruning aware of files provided by packages is not impossible, but it's quite unfeasible.

On a sampling of systems I checked, rpm -qal takes between 2 and 4 seconds. If we do that server-side (e.g., in the Packages plugin), you're looking at adding 2-4 seconds to each client render time. (That estimate is overinflated by the time it takes to write all that data to /dev/stdout, but that's offset by the fact that it's not getting crammed into memory as lxml.etree._Element objects.) Additionally, doing it server-side would add around 6-10 Mb (!!!) to the specification sent to each client just for the file paths alone -- probably twice that once it was all wrapped up in <Path> tags.

Running it server-side, which is where it really should be done, is clearly not reasonable. We could gather package file lists client-side, but a key tenet of Bcfg2 is to never trust the client. We also don't really have any support for one client tool to gather an inventory of items that is not used in the final report (i.e., of extra entries), but instead by a different tool. That would have to be a new phase in the client, which would be a fair amount of work. You also introduce interdependencies between tools (POSIX would depend for a portion of its functionality on a package tool that supports inventorying files being enabled), which we don't currently have.

If this would be implemented, it would have to be done on the client, but the barrier to entry is quite high. A much easier implementation would be to simply manage all of the files you don't want to remove, and then prune the directory. (Files distributed by a package could be managed as <Path type="permissions"/> to avoid having to manage the content in Bcfg2.) This could be automated with a probe (to determine the files listed in a particular package) and a templated bundle (to manage those files so they aren't pruned).

Given the ease with which that could be implemented, and the intractable issues of adding this to Bcfg2 itself, I'm closing this wontfix.