Daniel P. Berrange wrote:
On Thu, Jan 08, 2009 at 01:29:12PM +0100, Hans de Goede wrote:
As discussed before I've been working on a simple userspace library for
iscsi
so that various tools (such as anaconda) can use that instead of having to
invoke iscsiadm.
The latest version of the (proposed) API documentation for this library is
here:
http://people.atrpms.net/~hdegoede/html/libiscsi_8h.html
A few random thoughts from reading the API docs
- It is fully synchronous & blocking, which means an app would have
to run it in a separate thread. Not a show-stopper for libvirt since
we already have to run iscisadm in a completely separate process, but
it would be nice to be able to integrate with an app event loop so
we can just poll on I/O completion asynchronously.
This is by design. I can understand this may not be convenient in some cases,
but it is very convenient for the case I'm writing this for (anaconda).
- The API for auth credentials is hardcoded to the 4 credentials
needed for CHAP auth. Might be desirable to have a more generic
interface to pass arbitrary credentials to avoid the API being
tied to CHAP.
I'll think a bit about this, I might be able to come up with something. Note
that currently only CHAP is supported by open-iscsi AFAIK.
- Need an API to determine if we're already logged into a specific iSCSI
target - unless there's a reliable error code from iscsi_login() that
lets you identify when it failed due to already being logged in.
It would be good to have both (reliable error code and a query login state
function).
- No API for enumerating the LUNs in a target once you're logged in ?
open-iscsi / iscsiadm does not do this, it merely creates a virtual scsi
adapter and then the generic kernel scsi code does this (AFAIK).
- What are the thread safety rules for the API ? Is it safe for mutliple
threads to use the API concurrently ?
No, maybe one day it will be safe for multiple threads to use it, as long as
they use a separate context per thread. But the open-iscsi code this library
uses is full of globals. The main purpose of the context purpose is to allow
this in the future, but it is not possible right now.
- For logging it'd be preferable to allow an application to register
a function callback to receive log messages, rather than hardcoding
an internal logging framework. This lets the caller integrate iSCSI
API logs with their primary logging mechanism.
That is something which could be implemented.
More generally, is it your intent to maintain a long term stable ABI for
this library ?
Yes that is a specific goal of this lib.
FYI all virtualization storage mgmt is done by libvirt in C, so python
bindings aren't important to our needs.
Ok.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
