[Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 25/11/12 15:58, Dan Kenigsberg wrote:
> On Sun, Nov 25, 2012 at 03:21:28PM +0200, Livnat Peer wrote:
>> 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.
> 
> Yeah, it's a bit unfair to the UI users: it's like saying "we do not
> want to get API users confused by an evil guest agent, but we allow this
> to happen to those in the UI".
>>
>> 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.
> 
> Still, the reasonable UI user is less likely to correlate
> Engine-configured mac addresses to GA-reported ones. So presenting the
> naive correlation between the two has a benefit.

I think it can be confusing for users who use both API and UI.
Also if I have to explain that later on the users list I don't see a
good reason or logic behind this that I can use.
I think we should keep it aligned (UI-API).


> 
> Dan.
>