Direct Host Address

[Dan Kenigsberg]

On Sun, Feb 17, 2013 at 06:12:35AM -0500, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Muli Salem" <msalem at redhat.com>, arch at ovirt.org
> > Sent: Sunday, February 17, 2013 12:44:02 PM
> > Subject: Re: Direct Host Address
> > 
> > On Thu, Feb 14, 2013 at 03:27:57PM -0500, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Muli Salem" <msalem at redhat.com>
> > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Sunday, February 10, 2013 6:09:30 PM
> > > > Subject: Re: Direct Host Address
> > > > > 
> > > > > "Current behaviour assumes the network interface with the
> > > > > specified
> > > > > address is configured properly in the engine although this may
> > > > > not
> > > > > be the case initially"
> > > > > 
> > > > > I don't understand what does this mean, which interface are you
> > > > > referring to and what does it have to do with being configured
> > > > > in
> > > > > the engine?
> > > > > The next line is also unclear to me:
> > > > > "The direct address allows the engine to connect to the host,
> > > > > without
> > > > > knowing the exact configuration of the network interface that
> > > > > has
> > > > > the address. "
> > > > > 
> > > > 
> > > > Regarding the last two sentences you quoted:
> > > > 
> > > > I am referring to the interface that has the IP that the user
> > > > gives
> > > > us (with regards to current behavior).
> > > > At the moment, we assume that the given IP is for an interface
> > > > that
> > > > can communicate with the engine (when in practice, this may not
> > > > be
> > > > the case).
> > > > So separating the two addresses, allows us to ask the admin for
> > > > an
> > > > alternate IP address that will allow communication without
> > > > needing
> > > > to know the specific configuration (for example, whether this is
> > > > a
> > > > VLAN network or not).
> > > > 
> > > > Perhaps the wording should be changed a bit to clarify.
> > > 
> > > I still don't get it... can you please provide real world use case?
> > > 
> > > When can we access the alternate address and not the management
> > > address?
> > 
> > We have customers who want to install vdsm via native connection, but
> > manage it over a VLAN. If you want to add a fresh host, you cannot
> > use
> > its management address (that sits inside the vlan).
> > 
> 
> So as far as I understand the prerequisite of this feature is to perform host deploy (ovirt-host-deploy) without constructing the management bridge.
> 
> In this mode, during host deployment (ovirt-host-deploy) the engine uses the host name only to be able to construct proper CN field for the certificate of VDSM.
> 
> Then the engine performs provisioning of the host to define the host name's ip address on the optional vlan id that is shared by the entire cluster.
> 
> Maybe there will not be a management bridge at all, which makes me happy!
> 
> This means that:
> 1. No management bridge name is to be provided to ovirt-host-deply (this is to do in the prerequisite of the feature).
> 2. New parameter for the VdsDeploy at engine side of IP address to SSH.
> 3. After VdsDeploy is finished, there is provisioning to define the management address on the host using standard VDSM communication.
> 
> Am I missing anything?

You haven't - but apprently I have. Your point (2) would be useful only
when we can use it to tunnel getVdsCaps and setupNetworks verbs on top
of ssh. Without this ability, we gain hardly anything: the first
Engine-to-vdsm call would have to go to the management interface, using
its proper CN, meaning that we have to have the management interface up
and running and answering xmlrpc before we have a chance to setup a vlan
tag for it. Thus, we decided to scrap this point (2) for now.