lookupDomainById returns empty object about node-libvirt HOT 11 CLOSED

@jra11 can you try just directly looking it up without using the loop? We have a test that runs to validate that this works correctly with the test driver, but we'll need to narrow down what's happening in your case. So you'd have:

var libvirt = require('libvirt');
function test() {
   var hv = new libvirt.Hypervisor('qemu:///system');
   return hv.connectAsync()
     .then(() => hv.lookupDomainByIdAsync(15))
     .then((domain) => { console.log(domain); });
}

test();

from node-libvirt.

@mbroadst

Sorry I deleted my message before viewing your answer. My code was working well.

The disturbing part was the "console.log(domain)", which prints a weird object (the "_parent" stuff without any other property, how to explain that?), but all methods called on this domain object worked well, such as domain.destroy(...) etc.

from node-libvirt.

For others:

console.log on a valid Domain object prints that:
{ _parent:
{ uri: 'qemu:///system',
username: '',
password: '',
readOnly: false } }

This is how a Domain object appears in console.log, on nodeJS server-side.

from node-libvirt.

@jra11 ah yes, that's a side-effect of the way we bind to libvirt and sort of a holdover from the original implementation.

That _parent object is a solution we came up with rather recently to ensure child objects are properly cleaned up in order with their parent objects (in this case the domain is a child of the top level hypervisor object) - memory management is a bit tricky when you're mixing C++ with javascript here.

The reason that your domain object isn't full of all the properties you might expect to be there is the holdover from the original implementation I mentioned: we basically do a 1-1 mapping with the libvirt API. This means that the object that's returned to you is essentially a wrapper around a handle for that domain object, as well as methods that allow you to retrieve information about that handle. You can think of this as a "non eager" strategy for libvirt data, and I totally agree with you that from a users perspective this seems not very ideal as you expect to see all sorts of data associated with that domain immediately.

I think this warrants some discussion with the community. When you have a Domain object, for instance, you can call e.g. getName on it, but I imagine your expectation was to lookup that domain, and be able to immediately do a console.log(domain.name); and see it. That would require that during the lookup process, we then simultaneously kick off a number of other requests on that object to populate it.

/cc @c4milo @Rush others?

from node-libvirt.

The main reason the domain object is not automatically populated, upon look up, is efficiency. As, it may require multiple I/O operations, depending on the hypervisor. So, it is better to let users get the specific information on demand.

from node-libvirt.

@mbroadst, perhaps we should also make the _parent property not enumerable?

from node-libvirt.

@c4milo yeah that's a very good idea. To the other point, it might be more complicated but we could provide optional behavior to prefetch data?

from node-libvirt.

User view as I don't have your expertise:
a short section in the doc and a function to populate one full object in case of need would be welcomed Indeed It is really tricky as such dynamic behaviour is not usual for JS developers, and as the library is already not easy to use (you have to read the code and read the libvirt api, which is itself not very easy), being able to prefetch the full object to print it if needed would be perfect :-)

from node-libvirt.

I'm basically of a mind (given time, and resources), that a top-level configuration option on the initial library import for "eager loading" should be provided. It's sometimes very silly how long a promise chain needs to be in order to get the data you want to work with, the module as is is very "low level".

I can definitely see the benefit in making it much more user friendly, with an opt-out for the performance-conscious. It's also worth noting that no benchmarking has been done to actually observe the penalty for an eager load. Having said that, we also need to determine WHAT data should be eagerly loaded for these types.

from node-libvirt.

Can someone explain (in a laymen's term) what's being discussed here? Is it even related to the issue I reported at the top?

from node-libvirt.

@soichih can you please try your test again with the latest codebase? I suspect the issue you're running into is because the object "looks" empty, but is in fact a useable interface to the domain.

from node-libvirt.