I have been finding the scripting mode that is shown here‹ http://linux-iscsi.org/wiki/ISCSI#Scripting_with_RTSlib very useful. More convenient, for some things, than having to do a little configuration dance inside targetcli. Do the changes you describe extend that, or are they something different? On 2/26/14, 9:35 PM, "Jerome Martin" <tramjoe.merin@xxxxxxxxx> wrote: >Hello Everyone, > >For those of you who do not know me, I am Jerome Martin, the original >author of >targetcli, configshell and rtslib, the userspace tools currently used to >configure the LIO kernel SCSI target. > >As some may have noticed, Datera recently opened up the licensing even >more for those tools, transitioning to an Apache v2 license. The project >is >now available on GitHub (github.com/Datera), and this location will be the >primary repository for the development of the LIO userspace tools. > >Today, I want to announce a new development track for those tools, and >open the >discussion on this mailling-list as to which direction this development >should >take. > >You will find on the GitHub repository for rtslib a new branch, called >lio-config. This branch contains a prototype augmented rtslib API, as >well as a >proof-of-concept CLI tool (simply called lio) using it. > >This new API uses a configuration-centric approach on top of legqacy >rtslib. >When using the API or the lio CLI, you simply edit a configuration. >This is a drastic change from the targetcli approach. >Where targetcli is imperative, lio CLI is more declarative. > >Instead of directly impacting the running system, you can carefully craft >a >candidate configuration for it, by using CLI commands, but also by loading >and merging saved configuration snippets into the candidate configuration. > >Via the API and CLI, you can issue simple statements, identical in form >to the >syntax of the configuration files themselves (they use the same parser), >that >are matched against the loaded configuration. For advanced search or set >operations, full regex support is available when writing configuration >statements, i.e. you can search for "fabric iscsi target .* tpgt [1-3]". >This gives a lot of expressive power that could be leveraged for a lot >of cool features. > >Regarding day-to-day usage of the tools, the fundamental operations that >were missing in targetcli are there: > >- Unlimited undo support, for all load/merge/set/clear/delete operations, > within a CLI session (and potentially accross sessions, to be >implemented), > along with full tagging of operations history within a session (you >can tell > where a specific object or value configuration comes from, when, etc.) > >- A commit/rollback mechanism, simple to use and augmented with the >possibility > of listing the configuration changes, both against the running >system, but > also (via the API, soon in the CLI) against previously saved >configurations > >- The system uses a policy engine that parses and apply policy rules. > Those use the same configuration format as configuration statements, > but describe instead expected value types, default values, available > attributes, the structure of the configuration, etc. This could easily >be > extended to user-defined policy rules files, for simplifying recurring > administration tasks, like setting particular default values for >configuration > objects. > >Enough rambling on supposed merits of that piece of code, I'll let you >all see >for yourself and give it a try. The implementation is not complete by any >means, it is intended as a Proof-of-concept for now. But this is a great >opportunity to discuss what features should be part of the future >development. > >I will chime in later in March with a list of features that could be >implemented, so we could all discuss them and decide what is the most >interesting roadmap. For now, you can look at the # TODO tags in my code >;-) > >Meanwhile, please write your comments, suggestions and any sort of >feedback on >the list. There are also packaging questions to discuss, as for now this >is >implemented in the rtslib tree, and that might be suboptimal. >Package maintainers are welcome to send me their preferences. > >Best, >-- >Jerome 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 >This message contains confidential information. If you are not the >intended recipient you are hereby notified that disclosing,copying, >distributing or taking any action in reliance on the contents of this >information is strictly prohibited. Please notify the sender immediately >and delete this e-mail from your system. This message contains confidential information. If you are not the intended recipient you are hereby notified that disclosing,copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify the sender immediately and delete this e-mail from your system. -- 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
