[Users] simple networking? [SOLVED] mostly

[Dan Kenigsberg]

On Mon, Dec 16, 2013 at 06:01:51PM -0500, Antoni Segura Puimedon wrote:
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > Cc: users at ovirt.org, "Juan Pablo Lorier" <jplorier at gmail.com>
> > Sent: Monday, December 16, 2013 8:43:24 PM
> > Subject: Re: [Users] simple networking? [SOLVED] mostly
> > 
> > By looking at the output of 'getCapabilities' i noticed vdsm
> > didn't report any value for 'lastClientIface': 'lastClientIface': ''
> > 
> > It seems like the first 'getCapabilities' which the engine relies
> > on to report the nic for configuring the management network on top
> > of is missing.
> > 
> > Toni, any idea in which case it might not be reported ?
> 
> Sure, this is fixed now (or at least the behavior was changed). The thing
> is that this Caps reports the management_ip as 0.0.0.0, which leads me to
> believe that this is probably an all in one setup. The code for getting
> lastClientIface used to check for which device had assigned the management_ip,
> which doesn't exist in this case.

management_ip 0.0.0.0 means very little: only that Vdsm has kept its
default of listening on all interfaces. I do not see how it is related.

> 
> If we were to use the current code, that tries to route a packet, it would
> behave differently. However, it would still leave us out of luck as the device
> that would be reported to the engine would be, if this is indeed
> an allinone, the loopback device.

I am confused about this reasoning. The vdsm.log.26.xz shows 10 calls to
getCabilities, all from 192.168.128.79. Two of them (the first included)
reports that odd lastClient = '0.0.0.0'. Both happen to be the first
call after Vdsm has started up.

It smells like a race (or a more consistent fault) in how we set
    self.server.lastClient = self.client_address[0]

I'd apreciate a bug opened on that, for a closer scrutiny.

Dan.