Discovery image and intialization of ifaces

Hello,

by default foreman-discovery-image acquires DHCP addresses on all
interfaces. In the develop branch currently (nightly build) it only
acquires DHCP credentials from the primary interface. This can be
overriden by fdi.initnet option at the moment.

When provisioning discovered host, there is a different behavior now.
When provisioning new host, all the secondary interfaces have only MAC
filled in. Previously, there was also IP address filled in.

Since secondary interfaces are provisioned in Unmanaged mode by default
(the checkbox must be ticked and subnet selected), I think this is sane
default now. Also since we also recommend to setup Subnet IP range
outside of pool (which prevents from conflicts between
discovered/managed hosts), the IP address that was assigned from DHCP
might not be even valid and user would need to click on Suggest new
anyway.

Comments? (Ohad you had one during my demo, can you elaborate your
concern please?)

··· -- Later, Lukas #lzap Zapletal

> Hello,
>
> by default foreman-discovery-image acquires DHCP addresses on all
> interfaces. In the develop branch currently (nightly build) it only
> acquires DHCP credentials from the primary interface. This can be
> overriden by fdi.initnet option at the moment.
>
> When provisioning discovered host, there is a different behavior now.
> When provisioning new host, all the secondary interfaces have only MAC
> filled in. Previously, there was also IP address filled in.
>
> Since secondary interfaces are provisioned in Unmanaged mode by default
> (the checkbox must be ticked and subnet selected), I think this is sane
> default now. Also since we also recommend to setup Subnet IP range
> outside of pool (which prevents from conflicts between
> discovered/managed hosts), the IP address that was assigned from DHCP
> might not be even valid and user would need to click on Suggest new
> anyway.
>
> Comments? (Ohad you had one during my demo, can you elaborate your
> concern please?)
>

My only comment was if all of the interfaces are still visible when
provisioning the host.

In general I agree with this change, I beleive there are two primary usage
cases for multiple nics with discovery:

  1. have multiple interfaces connected to the same VLAN without any vlan
    tagging (mostly for bonds?)
  2. have a provisioning/discovery interface, and other interfaces are going
    to consume other vlans (most likely tagged).

in the first scenario, having multple dhcp requests are probably waste of
leases (or easily exhaust it as each server would use at least two ips),
and I believe that also in the second usage case, since the network is
tagged, grabbing the ip address of the untagged network is not that useful
either.

did I miss another usage case?

Ohad

··· On Thu, Aug 6, 2015 at 4:56 PM, Lukas Zapletal wrote:


Later,
Lukas #lzap Zapletal


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

> My only comment was if all of the interfaces are still visible when
> provisioning the host.

Yes, they are listed in "interfaces" fact and they have
"macaddress_IFNAME" facts therefore they are imported. The only
difference is the missing DHCP lease, which is actually an improvement
for those who are short on leases (servers with many NICs consume lots
of them).

Also the old default behavior was problematic on deployments with
multiple NICs on the same (provisioning) network. This is causing
routing/MAC filtering issues making the discovered host unavailable.

> In general I agree with this change, I beleive there are two primary usage
> cases for multiple nics with discovery:
> 1. have multiple interfaces connected to the same VLAN without any vlan
> tagging (mostly for bonds?)
> 2. have a provisioning/discovery interface, and other interfaces are going
> to consume other vlans (most likely tagged).
>
> in the first scenario, having multple dhcp requests are probably waste of
> leases (or easily exhaust it as each server would use at least two ips),
> and I believe that also in the second usage case, since the network is
> tagged, grabbing the ip address of the untagged network is not that useful
> either.
>
> did I miss another usage case?

Can you explain to me why initializing all network interfaces in the
discovery phase makes any advantage? I don't see it at all.

··· -- Later, Lukas #lzap Zapletal