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.
This is what our release engineering group does when doing the
OpenSolaris imports internally. We clone the "live" repository and
restart the repo daemon with the same port but as a read-only clone.
This lets people continue to pull the previous build as the new one take
some time to complete it's import to a private port. Then (after some
validation) we restart the public repo daemon with the updated packages.
There is still a window during which someone might get an image-update
failure as the repositories are swapped over and back, but the window is
much smaller.
What's the exact behavior when pkg.depotd is stopped in the middle of an
image-update, and then restarted with a newer catalog?
-- Alan
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.
Shawn Walker wrote:
Brock Pytlik wrote:
Shawn Walker wrote:
There is a major flaw here that just came to mind; notably, that the
catalog, index, and updatelog directory all have to be included as
part of this. In other words, if I'm serving a particular version
of a catalog, then I also have to serve a corresponding version of
the search index and updatelog.
Because the search index is already being built in an alternate
location then moved into place when it's able to, it would be a
fairly simple change to alter this behavior to not replace the
current search index until actually told to.
Since I need the ability to serve any previous snapshot, I'd also need
to snapshot the search data, etc. One copy of the search data alone
wouldn't suffice, unless I'm misunderstanding you.
Oh, didn't know you wanted to be able to do any previous snapshot.
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
