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

-- 
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to