I just submitted a gerrit change to introduce a new ubik RPC: <http://gerrit.openafs.org/10461>. The DISK_ service is possibly not the best place to introduce such an RPC, but it doesn't look like there's an existing place for it that makes much sense to me. So I thought I'd open up some discussion about this kind of thing to the list. My understanding is that this is not a conversation appropriate for afs3-stds, since this deals with RPCs and such internal to OpenAFS, and we don't guarantee interop since we're not dealing with clients.
Some background: the motivation for this and the current proposed ubik_cp tool functionality is the ability to 'read' and 'write' a full ubik database without needing to stop/shutdown dbservers or worry about consistency, etc, etc. So we can 'read' a database while the server is online, and we can perform some analysis on it or transmit it to another cell or whatever. And, with something like gerrit 10461, we can 'restore' a database if we want to copy a database into the running machine. Gerrit 9700 achieved the 'read' functionality by sort-of hijacking an existing ubik RPC that's used for sending the database data in bulk to sites that don't have the database. That may not be great way to do it long-term, but it does work for existing sites with unmodified dbserveres, which is why it was useful. There is no way to (for the general case) do the same thing for a 'write' operation, which is why gerrit 10461 exists. However, the new DISK_RestoreDB RPC is quite different from all of the other DISK_ RPCs that exist right now. The other DISK_ procs are intended to be used in an automated way between dbservers to handle transaction and database modifications inside a transaction, etc. DISK_RestoreDB (as it exists in gerrit) instead operates at a higher level, creating a transaction itself, and it's not meant for the other dbserver sites to be running it as part of normal operation. Instead, it's to be run by an administrator or by some automated process outside of ubik. So, to me this sounds like a new service; it's not similar to anything in VOTE_ or DISK_ (except maybe the debug RPCs), but it needs to run in the ubik layer, not e.g. the vlserver or ptserver layer, since it applies to anything using a ubik db. The RPCs in this service would allow you to consistently read the db, restore the db, maybe enter and exit a kind of 'read-only' mode... stuff like that. If such a new service existed, we could then maybe have a new command suite called 'ubik' (or ubikctl, ubikcmd, etc) that generally calls the RPCs in that service. I would then use that command for the functionality I'm currently including in ubik_cp, and drop ubik_cp. Any thoughts? -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
