On Dec 7, 2009, at 10:58 AM, Wichmann, Mats D wrote:
> Fascinating topic. I think jbj's deliniation
> into package vs. config management is useful.
> Without going into a massive discussion, not that
> I'm necessarily competent to do so anyway, let me
> pick just one item and worry at it, and see if I
> can just irritate everyone :)
> Packages as containers for immutable files is where package management "works".
> The corollary is that mutable files, either through configuration/patch management,
> or for files that aren't contained in packages, doesn't work very well with RPM.
> On a shared-storage "cluster" - loosely used term, I mean
> any set up where there are lots of "nodes" and few
> corresponding humans to watch over things :) - you're
> going to have some local stuff that you want to keep
> small, and everything else gets pushed to the shared
> storage. I think there's a lot of agreement that single-system-
> image type solutions are a good way to go for the
> "system" part, stuff that always has to be there for a
> client to be useful. But what is an "application"? Is
> it part of "system" because it's been been put into a
> package and installed through the same package manager used
> to handle the base system part? Or is an "application"
> somehow different (this is, of course, an ancient argument
> with no clear answer)?
> It you put a key application into shared storage because
> either you don't want to dedicate the space locally or
> just as likely want absolute control that the bits are
> the same for everyone, then the app is effctively mutable -
> the bits might fit the definition of immutable from someone's
> perspective, but not from the perspective of a node, which
> wouldn't be in control of the changes made (someone updates
> the package from somewhere else). So if you're using an image,
> does the image contain knowledge of accessing an app
> on the share, whatever it may be, or not? Locally
> stored rpm metadata would seem to me to be a bad
> way to refer to bits that are under someone else's
> Is there a place in this for rpm? Or is this picture
> in the "doesn't work very well" part and we just stop
> thinking about it?
Perhaps my use of "immutable" brings in the wrong concepts. Clearly
file content can be altered at will as easily and files can
be copied around as well.
For a package manager to address configuration/patch management
meaningfully, the current concept of a file as a blob of plaintext
whose integrity is verified with a digest would need to be abandoned.
Instead, the sequence of operations performed on the file would
need to be managed, just like any VCS does, with other means
of integrity checking than using a file digest from signed metadata.
The traditional use of an archive to carry the plain text, with
package metadata carrying a digest (or signature, @rpm5.org
is perfectly prepared to validate clearsigned files through
a run-time dependency probe within the assertion checker,
and the run-time probes can be extended to non-package file content through
/etc/rpm/sysinfo/Requirename configurable assertions ... but I digress)
is what is at fault, nothing more.
Note that @rpm5.org already embeds Augeas for configuration management,
and I will add a VCS (likely subversion, libgit.a and libgit2.a just
aren't there yet) to handle configuration management.
Note also bsdiff/bspatch added last week for eventual embedding in RPM.
But there's lots more design work (essentially duplicating a VCS implementation
into RPM) that would be needed for patch management to become part of package
73 de Jeff
Received on Mon Dec 7 17:34:58 2009