On Sep 2, 2014, at 13:11 , Liron Aravot <lara...@redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Federico Simoncelli" <fsimo...@redhat.com>
>> To: de...@ovirt.org
>> Cc: "Liron Aravot" <lara...@redhat.com>, users@ovirt.org, 
>> smizr...@redhat.com, "Michal Skrivanek"
>> <mskri...@redhat.com>, "Vinzenz Feenstra" <vfeen...@redhat.com>, "Allon 
>> Mureinik" <amure...@redhat.com>, "Dan
>> Kenigsberg" <dan...@redhat.com>
>> Sent: Tuesday, September 2, 2014 12:50:28 PM
>> Subject: Re: feature review - ReportGuestDisksLogicalDeviceName
>> 
>> ----- Original Message -----
>>> From: "Dan Kenigsberg" <dan...@redhat.com>
>>> To: "Liron Aravot" <lara...@redhat.com>
>>> Cc: users@ovirt.org, de...@ovirt.org, smizr...@redhat.com,
>>> fsimo...@redhat.com, "Michal Skrivanek"
>>> <mskri...@redhat.com>, "Vinzenz Feenstra" <vfeen...@redhat.com>, "Allon
>>> Mureinik" <amure...@redhat.com>
>>> Sent: Monday, September 1, 2014 11:23:45 PM
>>> Subject: Re: feature review - ReportGuestDisksLogicalDeviceName
>>> 
>>> On Sun, Aug 31, 2014 at 07:20:04AM -0400, Liron Aravot wrote:
>>>> Feel free to review the the following feature.
>>>> 
>>>> http://www.ovirt.org/Features/ReportGuestDisksLogicalDeviceName
>>> 
>>> Thanks for posting this feature page. Two things worry me about this
>>> feature. The first is timing. It is not reasonable to suggest an API
>>> change, and expect it to get to ovirt-3.5.0. We are two late anyway.
>>> 
>>> The other one is the suggested API. You suggest placing volatile and
>>> optional infomation in getVMList. It won't be the first time that we
>>> have it (guestIPs, guestFQDN, clientIP, and displayIP are there) but
>>> it's foreign to the notion of "conf" reported by getVMList() - the set
>>> of parameters needed to recreate the VM.
> 
> The fact is that today we return guest information in list(Full=true), We 
> decide on it's notion
> and it seems like we already made our minds when guest info was added there 
> :) . I don't see any harm in returning the disk mapping there
> and if we'll want to extract the guest info out, we can extract all of it in 
> later version (4?) without need for BC. Having
> the information spread between different verbs is no better imo.
>> 
>> At first sight this seems something belonging to getVmStats (which
>> is reporting already other guest agent information).
>> 
> 
> Fede, I've mentioned in the wiki, getVmStats is called by the engine every 
> few seconds and therefore that info
> wasn't added there but to list() which is called only when the hash is 
> changed. If everyone is in for that simple
> solution i'm fine with that, but Michal/Vincenz preferred it that way.

yes, that was the main reason me and Vinzenz suggested to use list(). 15s is a 
reasonable compromise, IMHO.
And since it's also reported by guest agent in a similar manner (and actually 
via the same vdsm<->ga API call) as other guest information I think it should 
sit alongside guestIPs, FQDN, etc…

Maybe not the best place, but I would leave that for a bigger discussion 
if/when we want to refactor reporting of the guest agent information

Thanks,
michal


> 
>> Federico
>> 
> _______________________________________________
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to