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
