Re: [Engine-devel] Report vNic Implementation Details

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.