Modify

Ticket #1078 (closed enhancement: wontfix)

Opened 10 years ago

Last modified 9 years ago

Manage all files in a directory

Reported by: https://www.google.com/accounts/o8/id?id=AItOawm53g_OvEixgi55cBdUXTHWrAwrQcK1PlU Owned by: https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc
Priority: major Milestone: Bcfg2 1.3.0 Release
Component: bcfg2-client Version: 1.0
Keywords: Cc: jsbillin@…

Description

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.

Attachments

Change History

comment:1 Changed 10 years ago by https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc

  • Owner changed from desai to https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc
  • Status changed from new to accepted

comment:2 Changed 10 years ago by solj

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

comment:3 Changed 10 years ago by 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.

comment:4 Changed 9 years ago by https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc

  • Status changed from accepted to closed
  • Resolution set to wontfix

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.

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.