5:20 p.m.
On Mon, Jan 23, 2012 at 04:54:10PM -0500, Saggi Mizrahi wrote:
Nitty Gritty:
This seems like a good API but I have some suggestions with respect to API
naming:
manageStorageServer
===================
Could we name this manageStorageConnection or manageStorageServerConnection?
Manage storage server is confusing because it implies you are managing the
server itself (ie. server configuration, NFS exports, reboot, etc).
Synopsis:
manageStorageServer(uri, connectionID):
Parameters:
uri - a uri pointing to a storage target (eg: nfs://server:export,
iscsi://host/iqn;portal=1)
connectionID - string with any char except "/".
Description:
Tells VDSM to start managing the connection. From this moment on VDSM will try and have
the connection available when needed. VDSM will monitor the connection and will
automatically reconnect on failure.
Returns:
Success code if VDSM was able to manage the connection.
It usually just verifies that the arguments are sane and that the CID is not already in
use.
This doesn't mean the host is connected.
----
unmanageStorageServer
=====================
To match above: unmanageStorageConnection or unmanageStorageServerConnection
Synopsis:
unmanageStorageServer(connectionID):
Parameters:
connectionID - string with any char except "/".
Descriptions:
Tells VDSM to stop managing the connection. VDSM will try and disconnect for the storage
target if this is the last CID referencing the storage connection.
Returns:
Success code if VDSM was able to unmanage the connection.
It will return an error if the CID is not registered with VDSM. Disconnect failures are
not reported. Active unmanaged connections can be tracked with getStorageServerList()
----
getStorageServerList
====================
getStorageConnectionList or getStorageServerConnectionList
> Synopsis:
> getStorageServerList()
>
> Description:
> Will return list of all managed and unmanaged connections. Unmanaged connections have
temporary IDs and are not guaranteed to be consistent across calls.
>
> Results:VDSM was able to manage the connection.
> It usually just verifies that the arguments are sane and that the CID is not already
in use.
> This doesn't mean the host is connected.
> ----
> unmanageStorageServer
> =====================
Synopsis:
unmanageStorageServer(connectionID):
Parameters:
connectionID - string with any char except "/".
Descriptions:
Tells VDSM to stop managing the connection. VDSM will try and disconnect for the storage
target if this is the last CID referencing the storage connection.
Returns:
Success code if VDSM was able to unmanage the connection.
It will return an error if the CID is not registered with VDSM. Disconnect failures are
not reported. Active unmanaged connections can be tracked with getStorageServerList()
----
getStorageServerList
====================
> Synopsis:
> getStorageServerList()
>
> Description:
> Will return list of all managed and unmanaged connections. Unmanaged connections have
temporary IDs and are not guaranteed to be consistent across calls.
>
> Results:
> A mapping between CIDs and the status.
> example return value (Actual key names may differ)
>
> {'conA': {'connected': True, 'managed': True,
'lastError': 0, 'connectionInfo': {
> 'remotePath': 'server:/export
> 'retrans': 3
> 'version': 4
> }}
> 'iscsi_session_34': {'connected': False, 'managed': False,
'lastError': 339, 'connectionIfno': {
> 'hostname': 'dandylopn'
> 'portal': 1}}
> }
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center