[Engine-devel] Report vNic Implementation Details

[Dan Kenigsberg]

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.

Dan.