[ovirt-devel] feature review - ReportGuestDisksLogicalDeviceName
Michal Skrivanek
mskrivan at redhat.com
Tue Sep 2 12:29:57 UTC 2014
On Sep 2, 2014, at 13:11 , Liron Aravot <laravot at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Federico Simoncelli" <fsimonce at redhat.com>
>> To: devel at ovirt.org
>> Cc: "Liron Aravot" <laravot at redhat.com>, users at ovirt.org, smizrahi at redhat.com, "Michal Skrivanek"
>> <mskrivan at redhat.com>, "Vinzenz Feenstra" <vfeenstr at redhat.com>, "Allon Mureinik" <amureini at redhat.com>, "Dan
>> Kenigsberg" <danken at redhat.com>
>> Sent: Tuesday, September 2, 2014 12:50:28 PM
>> Subject: Re: feature review - ReportGuestDisksLogicalDeviceName
>>
>> ----- Original Message -----
>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>> To: "Liron Aravot" <laravot at redhat.com>
>>> Cc: users at ovirt.org, devel at ovirt.org, smizrahi at redhat.com,
>>> fsimonce at redhat.com, "Michal Skrivanek"
>>> <mskrivan at redhat.com>, "Vinzenz Feenstra" <vfeenstr at redhat.com>, "Allon
>>> Mureinik" <amureini at 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
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
More information about the Devel
mailing list