[Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 25/11/12 15:00, Itamar Heim wrote:
> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>> On 22/11/12 23:18, Itamar Heim wrote:
>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>> Back to the original question:
>>>>
>>>> What is most inconvenient for many users is:
>>>> 1. The name we provide while creating the VNIC differs from the one in
>>>> the guest
>>>> 2. No correlation between IP and NIC
>>>>
>>>> The current page covers for this but indeed as raised here does not
>>>> cover what happens if this information is not easy to retrieve due to
>>>> non strait forward configurations.
>>>>
>>>> What I suggest is,
>>>>
>>>> For the short term:
>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>> engine to match these to the existing and show
>>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>>> page, but...
>>>>
>>>> - If a match could not be found then just report Name in Engine N/A
>>>> and then the rest and keep it in dynamic only table.
>>>> This is useful for NICs created by hooks, advanced topology that we
>>>> can't support ATM etc.
>>>>
>>>> *The above does require the agent to at least match MAC to IP.
>>>>
>>>>
>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>> same code at least for Linux guests?) and present it similar to what
>>>> we present in the host tab. In most cases this will collapse to the
>>>> short term.
>>>>
>>>> MTU, is good to have in any of the two if we can get it.
>>>>
>>>> More?
>>>
>>> I don't think the guest agent ip information should be correlated to the
>>> vnic engine information at rest api level.
>>> the vm (and vnic) api provides the authoritative configuration
>>> information of the guest as defined in the engine.
>>> I don't think we should 'taint' it with untrusted data from the guest.
>>> it would make sense to place there IPs configured/allocated by engine
>>> when we deal with ip allocation though.
>>>
>>
>>
>> I was too quick to say we have an agreement...
>>
>> The comment above seems to give more emphasis on the segregation between
>> data collected via the GA and data configured via the engine.
>>
>> In the API we have today the following modeling: per VM entity we hold
>> GuestInfo entity and there we hold a list of IP addresses.
>>
>> Are you suggesting to keep this approach and not report anything on the
>> vNIC level at this point (until we'll be able to configure IP addresses
>> via the engine)?
> 
> yes.
> 
>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>> should be additional to the one on the VM level (as we discussed before
>> the correlation between VNIC and GA reported data is not always possible)
> 
> i didn't think about reporting guest info at vnic level, only at vm
> level. it could be a valid option, but since some network information
> doesn't correlate to vnic's, i think a more natural modeling at vm level
> may be easier.
> 
>>
>> Also what you have in mind for the UI?
> 
> at ui level i do think/agree it would make sense to show the ip per vnic
> if the correlation between the two is clean and direct (based on mac
> address i assume).
> you do need to make sure "bad data" won't break the ui though.

I'm not sure I agree with the differentiation you are doing between UI
and API in this case.

If we think the IP address field per vNIC should display info configured
via the engine and not untrusted data (reported via the guest agent)
then we should keep this approach in the UI as well.

I agree that in some cases the API can model data differently, or enable
more complicated actions, but this is not the case, here we have the
same data modeled differently which can cause confusion with users.

I think that we should keep the separation in the UI as well and add GA
sub-tab in VM and there have a field network devices with the data given
by the GA. no correlation (between engine configured vNICs and GA
report) at this point, when we'll have the ip address configuration via
the engine we'll present per vNIC the address.



> 
>>
>>
>>
>>
>>> i.e., the guest info element in the rest api provides good separation
>>> between engine level data, and guest agent data.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
>