Feature #33

Need for new methods for getting all hosts and all VMs information

Added by Anonymous almost 13 years ago. Updated almost 12 years ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:Javi Fontan% Done:


Category:Client API & Library
Target version:Release 1.4
Resolution: Pull request:


I'm in need for a new method in ONE's XML-RPC API, which would return
information about all hosts added to ONE.
I'm writing a code that needs to retrieve all hosts without knowing
hosts ids in advance. To solve this requirement, one could consider
two approaches: either to create a method that would return full
information about all nodes in a single call or to create a method
that would only return a list of host ids. In the later case, full
information about all hosts would be obtained by successively calling
For now the need is for hosts information only, but we could extend this requirement for all VMs information as well.


#1 Updated by Anonymous almost 13 years ago

Borja explain the approach of using the DB directly:

The current approach used in "onehost list" and in the OpenNebula/Haizea integration is to access the ONE database directly. I believe the rationale for this was that (1) the physical host information is something you typically only need to know locally (e.g., admin commands, the Haizea scheduler, etc.) and not remotely and (2) polling for a (potentially large) host list through XMLRPC could be an expensive operation, so direct database access was used instead.

I can see how rationale (1) is not really valid if you want a third-party component (like VWS, which could be in a different machine) to access the host list, so it may make sense to add a new operation to the API to retrieve the host list (even if this operation is not used by "onehost list"; at least it would be available for other components to use). Could you create a ticket in the Trac so we can track the issue there?

Finally, as a workaround, you can access the ONE database directly for now (the only limitation is that VWS and ONE will have to be running on the same node; but this assumption can be easily removed when an API call for this becomes available). There are a number of options for accessing a SQLite database from Java: http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers. If you have any trouble parsing the ONE db, don't hesitate to ask here.

#2 Updated by Ruben S. Montero almost 13 years ago

  • Status changed from New to Closed
  • Resolution set to wontfix

As Borja explained a list operation in the XML-RPC server could be expensive. Additionally, the preferred method to perform list operations is ti directly access the DB using the SQlite interface. In the case of VWS integration, this imposes the constraint, so the ONE daemon and the container should be running in the same machine.

As a patch is already available, we will close this ticket and reopen it in case we needed.

#3 Updated by Redmine Admin over 12 years ago

I would still like to have it as an XML-RPC method. Several reasons come to mind:

a) I was under the impression that the administration tools (one{vm,host,vnet}) were using XML-RPC because that would allow them to run one a different host than oned. If that was never the intent, perhaps ONE could use a UNIX socket for access instead, which would remove the need for the session identifier in the XML-RPC interface, since access could be handled at the filesystem layer (or alternatively using SO_PEERCRED).

b) I don't really see why this operation would be much more expensive than e.g. one.hostinfo? Also, if I really do need this info, I'll query the database for it, so whether that is done using libsqlite or and xml-rpc interface shouldn't make much of a difference, should it?

c) To get access to the information, you need full read access to the database. I'm imagining that we at some point would want to let people fetch the list of hosts, but perhaps wouldn't be comfortable letting the read all the information from the database.

#4 Updated by Ruben S. Montero over 12 years ago

Re-open this, and schedule to 1.4.

#5 Updated by Ruben S. Montero over 12 years ago

  • Status changed from Closed to 4
  • Resolution deleted (wontfix)

#6 Updated by Ruben S. Montero about 12 years ago

  • Target version deleted (Release 1.4)

#7 Updated by Javi Fontan almost 12 years ago

  • Status changed from 4 to Closed
  • Target version set to Release 1.4

Also available in: Atom PDF