[Engine-devel] [RFC] New Connection Management API

[Adam Litke]

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 at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center