[one-users] Alternative java bindings
Tiago Batista
tiagosbatista at gmail.com
Mon Oct 11 15:20:09 PDT 2010
A lot more clear!
The extra information on the vm.info when compared to the vmpool.info
methods dis not strike me as odd, what struck me as odd was mostly the
extra username in the vmpool result as that is an extra join in the db
(I think, I did not look at it). This explanation does clear most of my
doubts, and I think that a careful reading of the source will explain
the remaining doubts as your software is quite well written!
Thanks
Tiago
On Mon, 2010-10-11 at 23:14 +0200, Ruben S. Montero wrote:
> Hi
>
>
> The reason for this is to speed up DB access times and improve
> scalability. There are two types of queries:
>
>
> 1.- PoolInfos. This gives an overview (not all information about the
> object is returned) of the elements of the pool, it basically access
> the corresponding DB table. Also, OpenNebula caches part of the DB in
> memory, so the memory footprint of oned is under control, this means
> that if you need a VM that is not in the cache it is loaded from the
> DB, replacing another VM entry in the cache. PoolInfo methods do not
> modified the cache and goes to DB directly for the information (dump
> methods is a SELECT + xml formatting).
>
>
> 2.- Info. This gives extended information for a given object
> (in-memory). For example VM includes history (that is not returned in
> VMPoolInfo), VirtualNetworks includes leases and so on. (info methods
> is XML marshaling of a C++ class)
>
>
> Those are the two main reasons: 1.- efficiency in DB access 2.-
> different information is returned.
>
>
> Also there is a dump_extended for VMs. The reason here is to help
> schedulers in large-scale deployments. For example scheduling 15K VMs
> will require 1 pool info + 15K VMinfo method with the associated cache
> trashing. Dump extended performs a couple of joins in the DB tables so
> a scheduler can get all the needed information without overloading
> oned.
>
>
> Hope now it is clearer ;)
>
>
> Cheers
>
>
> Ruben
>
> On Mon, Oct 11, 2010 at 10:24 AM, Tiago Batista
> <tiagosbatista at gmail.com> wrote:
> Any insight on this from the original developers?
>
> I too looked at the source code, and this struck me as odd...
>
> TIA
>
> Tiago
>
>
> On Fri, Oct 8, 2010 at 11:54 AM, Tiago Batista
> <tiagosbatista at gmail.com> wrote:
> > Thanks,
> >
> > This is my first JAXB experience, so looking at someone
> else's code
> > actually helped a lot on what I am doing...
> >
> > I am mostly writing stylesheets for the rpc responses, so I
> am still
> > not at the point where I want to be, my current purpose with
> this is
> > to expose most or all of the functionality to a java
> experienced
> > programmer, removing as much of the opennebula specific
> parlance as
> > possible (notice that *Pool becomes a list() as an example).
> >
> > As a test application, I am exposing the methods as a web
> service
> > (opennebula specific), something like a soap interface for
> the rpc...
> > If there is interest, I think I can release the full app
> (have to ask
> > my superiors)...
> >
> > As for the rpc responses, I have found a few
> inconsistencies, mostly
> > between the *.info and the *pool.info methods that are
> slowing me down
> > a bit as I have to account for them... Is this expected
> behavior or a
> > bug?
> >
> > As an example note the USERNAME:
> >
> > <xs:complexType name="vmType">
> > <xs:sequence>
> > <xs:element name="ID" type="xs:int" />
> > <xs:element name="UID" type="xs:int" />
> > <xs:element name="USERNAME" type="xs:string"
> minOccurs="0"
> > /> <!-- only on the pool -->
> > <xs:element name="NAME" type="xs:string" />
> > <xs:element name="LAST_POLL"
> type="xs:unsignedLong" />
> > <xs:element name="STATE" type="xs:string" />
> > <xs:element name="LCM_STATE" type="xs:string" />
> > <xs:element name="STIME"
> type="xs:unsignedLong" />
> > <xs:element name="ETIME"
> type="xs:unsignedLong" />
> > <xs:element name="DEPLOY_ID" type="xs:string" />
> > <xs:element name="MEMORY"
> type="xs:unsignedLong" />
> > <xs:element name="CPU" type="xs:unsignedLong" />
> > <xs:element name="NET_TX"
> type="xs:unsignedLong" />
> > <xs:element name="NET_RX"
> type="xs:unsignedLong" />
> > <xs:element name="LAST_SEQ"
> type="xs:unsignedLong" />
> >
> > <xs:element name="TEMPLATE" type="vmTemplateType"
> minOccurs="0"/>
> > <xs:element name="HISTORY" type="vmHistoryType"
> minOccurs="0"/>
> > </xs:sequence>
> > </xs:complexType>
> >
> >
> > The username appears only in the pool method, but not on the
> info
> > method... The same is valid for vnet methods if I recall.
> >
> > Again, thanks for your input!
> >
> > Tiago
> >
> > On Thu, Oct 7, 2010 at 11:46 PM,
> <Carsten.Friedrich at csiro.au> wrote:
> >> Hi Tiago,
> >>
> >>
> >>
> >> I did something similar some time ago (attached for your
> perusal, you need
> >> to add the JAXB libraries yourself). The binding of
> returned templates is a
> >> bit patchy, but it works well enough for me here. It
> supports most 2.0
> >> features.
> >>
> >>
> >>
> >> Carsten
> >>
> >>
> >>
> >> From: users-bounces at lists.opennebula.org
> >> [mailto:users-bounces at lists.opennebula.org] On Behalf Of
> Tiago Batista
> >> Sent: Thursday, 7 October 2010 21:06
> >> To: Users at lists.opennebula.org
> >> Subject: [one-users] Alternative java bindings
> >>
> >>
> >>
> >> I am in the process of creating alternative java bindings
> for OpenNebula.
> >> (Dont ask and I wont tell why!)
> >>
> >> They are now at a very embrionary state, and I would like
> to expose them a
> >> little. There are some parts that are specific to my setup,
> and a lot of
> >> refactoring is required but most of the code is
> automatically generated.
> >>
> >> I use JAXB to bind the xmlrpc responses to POJOs, and I use
> a catchall class
> >> to perform the required operations on the server. A usage
> example:
> >>
> >> Client client = new Client("username", "password",
> >> "http://hostname:2633/RPC2");
> >> VMOperations vmOps = new VMOperations(client);
> >> VmType vm = vmOps.info(id);
> >>
> >> This way, adding features is as simple as editing the
> apropriate xsd. By the
> >> way, extensions to the existing xsd, or new xsd files are
> welcome! With a
> >> little refactoring I think I can wrap the VmType that is
> read only on a
> >> class that allows some operations to be performed over
> it...
> >>
> >> Also, this is better for environments where the data must
> be used across a
> >> network, as the classes (although not marked as such)
> should face no
> >> serialization problems. Even is none of the code seems
> useful, you should
> >> really consider replacing the standard Client class with a
> serializable one!
> >>
> >> What do you think of this?
> >
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
>
>
> --
> Dr. Ruben Santiago Montero
> Associate Professor (Profesor Titular), Complutense University of
> Madrid
>
> URL: http://dsa-research.org/doku.php?id=people:ruben
> Weblog: http://blog.dsa-research.org/?author=7
>
More information about the Users
mailing list