Re: [Engine-devel] Report vNic Implementation Details

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.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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >