as part of kickstart networking rewrite and shift towards configuring the network via Anaconda, I would like to propose removal of interface aliases from Foreman. There is a partial support built-in, when user checks Virtual NIC and (I think) does not fill in VLAN ID, then the interface is created as an alias. This only works in static mode.
I believe this is confusing, rarely used, not documented and heck even I don’t know exactly this is supposed to work. I propose to remove this behavior completely from Foreman and templates. If aliases are needed, they can easily be set up by customizing provisioning templates as needed.
Sounds good to me. It may not be possible to fully remove it from 2.0 codebase (e.g. facts parsing) but at least mark it as obsolete and no longer supported would be good. And not implemented in new way of setting up networking ofc.
This makes sense. Back in the days of ifconfig this was normal and the only way to assign multiple IPs to an interface, but on a moderncurrent userland with ip you can just assign multiple IPs to a single interface. The RHEL 6 documentation states:
The use of secondary addresses rather than alias is still preferred.
I wouldn’t call EL 6 modern
That said, do interface aliases in Foreman is currently the only way to assign multiple IPs to a single interface. Stated in another way: on Linux (and probably other OSes) the interface to IP relation is 1:n where in Foreman it’s 1:1. It used to be very common to have multiple IPs assigned (back when we couldn’t rely on SNI) but I don’t know how important this is nowadays.
This is not the complete story. Currently you can assign multiple IPs, make sure they are assigned from the free pool, get a DNS record. If you need to manually make this happen in templates, you’re bypassing a large portion of Foreman.
IMHO this shouldn’t be in the development category. RFC or community is a better place. Given we don’t really know how much this is used, I’d lean to the community in this case.
In time of virtualization I do not see it very often, but I know at least some environments which require a much more complicated network configuration for physical systems than just one ip on one interface. And I like that foreman is capable to manage this out-of-the-box. So I would prefer if it is confusing and not documented, we document it and if is still confusing then make it easier instead of just drop this capability and force the user to work around.
Explain me how virtual interface flag should work. We have the “Virtual NIC” check box, when checked two new fields appear:
Tag
Attached to
To me it looks like to configure VLAN only tag needs to be set either on Subnet or NIC level. Attached to should on the other hand be only needed when you want this to be an alias. Is my assumption correct? Because currently in our templates what I see is:
if iface.tag.present? && iface.attached_to.present?
# configure vlan
end
This does not appear to be correct (VLAN does not need attached to information it is always the same interface). Or do I miss something?
Note, that attached to is required for bonded interfaces. Something we do support and should definitely support.
In a datacenter you usually want your bare metal servers to be high available. You reach that with redundancy (devs hate that, ops guys love it). So you usually configure two network cards connected to two separate switches in a active/backup bond.
We currently have the workflow, that discovered bare metal hosts will be configured during provisioning to set the primary (and backup nic) as managed. And a new bond interface is created and the identifiers of the active & backup interfaces added in the attached to input field. Foreman will then setup dhcp provisioning for both interfaces. And the kickstart templates then configure the bond properly.
Discovery actually has a feature that auto-detects a bond setup.
Please make sure not to break this when removing the alias feature.
Yeah, that one is clear. What I am asking is why we actually require attached_to to be present for VLAN. I mean, VLAN is defined on a interface itself, it has a MAC and identifier. Theoretically I could create regular interface em1 and then create new (regular) interface em2 with VLAN flag checked and attached_to set to em1. This does not make sense, does it?
Edit: Maybe this is needed for puppet parser to work properly. I can probably just ignore this, when VLAN flag is checked I would just pass this to Anaconda.
Wait, it looks like for each VLAN I need to create new (regular) NIC with attached_to and VLANID set. This way I can create multiple VLAN devices. Now I am following.
Not sure if my knowledge is completely outdated or still valid as I do not do such things so often nowadays.
In the past I had for example eth0 as the physical interface, if this was a trunk and I had to create my own vlan interfaces it was eth0.VLANID (e.g. eth0.2 for VLANID 2) and if I wanted to have additional addresses it was eth0:0 as a virtual interface with the first additional address, eth0:1 for the second one, …
Eventually, IPv6 implementation ended up to be built on top of ifcfg scripts. Aliases are no longer an issue as Anaconda is not used to configure the network.
Long-term we would probably like to drop aliases, but it is not currently on the table.
