Hi Andy, list, Nic draw my attention to the fact that I did not reply to this message, and he did well because I could have sworn I did :-p. Your suggestion is a nice proposal, and we would of course be totally willing to accept such contribution and simplify the packaging dependencies of the targetcli stack. On Thu, Oct 20, 2011 at 2:19 AM, Andy Grover <agrover@xxxxxxxxxx> wrote: > > SAVING > > 1) walk the tree of UINodes from the root > > 2) for nodes that are instances of UIRTSLibNode, call a method to get a > > string (or a dict) that represents their saved state (includes > > attributes, parameters, and other data like path, size, wwn that are > > backstore-specific) > > 3) Save this all to a config file > > this seems straightforward. It's easy to walk the UIRTSLibNodes, we just > > need to extend classes to support a call that encapsulates all their > state into something we can save. I would suggest a slightly different approach here. Instead of using UIRTSLibNodes, you might want to directly use rtslib to do that. The point being that the UIRTSLibNodes are just UI abstractions, and config state is not a UI thing, but a lower-level one. Here is how I see it, in the context of something that would be "human-readable" as opposed to using direct serialization with pickle: - Add a _dump() method to rtslib classes, recursively calling on its children objects dump methods and aggregating their output. Separate the output in three parts for each object: . The class name . The class instanciation-time arguments . The additional method names + parameters for setting attributes. - Add a master dump() method to rtslib.RTSRoot, calling on its own _dump(), and taking care of saving the data to a config file. > > RESTORING > > 1) new cmdline parameter to targetcli that takes a config file, and > builds UINode tree based on config file This is fine. > > 2) kernel configfs synced with with the UINode tree > > This differs from lio-utils' method, which builds a list of commands to > > poke configfs that just get run on reboot. It may be more work but it > > should be more robust, enable idempotence, and allow better error recovery. > > How hard would you say extending the code to support this would be? Do > we need another creation mode? Well, using the dump method described above, pretty straightforward: - Add a restore() method to RTSRoot. - Use it to load the data and: . Restore the config by calling on the classes whose names where saved, starting with virtual HBAs first, and then fabric modules in any order. . Within virtual HBAs and fabric modules, if you take care of preserving the ordering on the recursive dump, then just following the order depth-first is enough to restore the targets tree if the virtual HBAs/storage backend were restore first. > > Finally, I think it's important to have the saved config be > > human-readable as well as machine-parsable. Json, python, html, > > whatever, we just need to be able to reconstitute the python objects > from it, and still allow some emergency sysadmin tweaking. Sure. I would suggest JSON serialization, which is pretty readable. Probably organizing the dump data as a python dict and then serializing it to JSON is the simplest approach. This was, the disk-data format is only handled at the top-level (RTSRoot) dump() method and is easily changeable. Hope this helps. Best, -- Jérôme Martin -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
