[email protected] wrote: > On Mon, Feb 02, 2009 at 02:56:49PM -0600, Shawn Walker wrote: >> Brock Pytlik wrote: >>> I'm sure you've thought of this, but why not leverage ZFS for all this? >>> You could have the depot always serving from a read-only zfs snapshot >>> (clone?). When you're publishing, you publish to the >>> current/live/writable file system, when you're done with the staged >>> publishing (including generating the search indexes and feed cache if >>> necessary), a zfs snap shot is taken (and a clone if necessary). The >>> depot then repoints itself to serve out of the new snapshot/clone. >>> >>> Sorry if I'm rehashing something you've already thought of and >>> dismissed, it just seems strange to be reinventing a snap shotting >>> mechanism, especially since I don't think we'll be able to duplicate the >>> ondisk space savings of snapshots, which if you want to serve from >>> arbitrary past snapshots, seem significant. >> You are correct that ZFS may be more efficient for a snapshot system. >> However, there are some administrative and development tradeoffs that I >> felt were too limiting: >> >> * Would require zfs for snapshot support. >> >> * Would require that either the repository directory of the repository >> "metasets" be a zfs filesystem. >> >> * Is significantly more complex to implement. >> >> * Would require that the depot software run with the privileges >> necessary to create and/or destroy filesystems or snapshots. >> >> * Assuming the the entire repository directory is represented by a >> snapshot, that would pre-clude the ability to have a file/ directory >> with files for packages newer than that being served by the current >> snapshot/metaset. >> >> The basic idea here is that the repository metadata is essentially split >> during publishing; it publishes to one and serves the other until a >> "commit" is done. This allows a single depot server to handle both >> requesting and publishing clients. > > There seems to be some confusion about the purpose of this proposed > change. > > When Dan and I discussed this, it was to solve a distributed consistency > problem with rolling out new builds on a load-balanced group of depots. > > When performing a rollout, Dan saw that some depots restarted faster > than others. Since there's no session persistence in the load-balancer, > clients can be routed to a different depot for every request. In some > cases, a client would get the catalog from an updated depot, but would > be unable to fetch a manifest, or files. The subsequent request was > hitting a depot that was still out of date. > > We're still going to use ZFS snapshots to move the depot's data around, > since it simplifies administrative tasks. The changes to the depot > software are to allow a rollout of a build to appear consistent in a > distributed environment.
The proposed changes are not solely about solving the case you've mentioned; they're also about solving some of the issues that occur when publishing to a live repository. It's merely fortuitous that solving one problem can possibly provide a solution for the other. Specifically, the technical changes needed to allow the depot to serve file data from one place and some "metadata" from another. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
