Our physical hosts are all connected to trunk/tagged ports, with the native
vlan (ex. 123) being used for the installation, and the real vlan (ex. 500,
or number of choice depending on function) being used for prod traffic.
The host boots, uses the native vlan to get an ip via dhcp and to boot the
installer via pxe, and then the installation starts. At the end, the tagged
networking config is configured by puppet in the OS. At reboot - which is
done manually - the network config is applied and the host is on the prod
VLAN.
I would like to continue with this workflow by using Foreman, but I don't
know how to make the installer fetch a "temporary" ip for the installation
and use the "real" ip for creating the config. I am aware of the concept of
"provisioning" vs "primary" interface, but this is one single interface so
I'm afraid this can't be done.
I am open to alternative approaches, even getting rid of the trunks, if
necessary (which would make things ridiculously simpler).
To expand on my previous question, here's the description of the
alternative workflows I had in mind:
Workflow A: We retain the "trunk interfaces + install network" layout:
Host boots in discovery mode on installation vlan (123) since it's the
native vlan
Host reports to Foreman. Start provisioning on vlan of choice (500)
Trigger reboot
Installation begins on install vlan (123)
Configure trunk in installer (late script) for next boot
Installation complete. Reboot
Configure switch trunk via external script for production vlan of
choice
Host boots
Done
Workflow B: We get rid of the trunk interfaces and only use access ports
with install vlan:
New host needs to be installed, external script sets the port to
install mode (untagged vlan 123)
Host boots in discovery mode on installation vlan (123)
Host reports to Foreman. Start provisioning and set host on vlan of
choice (500)
Trigger reboot
Install on vlan 123. Reboot after completion
Configure switch port via external script for vlan of choice (500)
Done
Workflow C: We get rid of the trunk interfaces and only use access ports:
New host needs to be installed, external script sets the port to
install mode (untagged vlan 123)
Host boots in discovery mode on installation vlan (123)
Host reports to Foreman. Start provisioning and set host on vlan of
choice (500)
Trigger reboot
Configure switch port via external script for vlan of choice (500)
Install on vlan 500 with prod IP. Reboot after completion
Done
Now, question: how does foreman react to the installation being done with
one IP (in subnet/vlan 123) and the host ending up in another subnet/vlan
(500)? I suppose Foreman will create the DNS records for the first IP (in
vlan 123), not for the real (500), causing a mismatch.
I still wonder if these workflows make sense at all and whether there's a
better way. Any example?
Thank you
Foreman itself cant manage one NIC (MAC address) for multiple subnets,
a NIC is one entity which is assigned exactly to one subnet.
Foreman is capable of re-configuring NICs on fact upload (this can be
turned off or on in settings), so you can let facter to do the job for
you during initial fact upload.
So I think your initial idea (workflow 1) is doable. One more thing.
Our PXELinux templates don't ship with VLAN configuration flags as
most of our users use non-VLANs for provisioning. Feel free to make
adjustments there (and file pull request in our https://github.com/theforeman/community-templates repo) for that.
Usually it's just a flag on kernel command line to set vlan. Oh I see
now you are using untagged VLAN for provisioning, then you should be
fine.
···
On Fri, Mar 10, 2017 at 11:49 AM, Alexander Rilik wrote:
> Now, question: how does foreman react to the installation being done with
> one IP (in subnet/vlan 123) and the host ending up in another subnet/vlan
> (500)? I suppose Foreman will create the DNS records for the first IP (in
> vlan 123), not for the real (500), causing a mismatch.
>
> Foreman is capable of re-configuring NICs on fact upload (this can be
> turned off or on in settings), so you can let facter to do the job for
> you during initial fact upload.
>
>
Hello Lukas,
Thanks for the quick reply.
So, if I understand correctly, this re-configuration would take care of the
DNS side as well?
So I think your initial idea (workflow 1) is doable. One more thing.
>
> Our PXELinux templates don't ship with VLAN configuration flags as
> most of our users use non-VLANs for provisioning. Feel free to make
> adjustments there (and file pull request in our
> https://github.com/theforeman/community-templates repo) for that.
>
I would love to expand some of those templates, I will do my best!
Thank you
···
On Friday, March 10, 2017 at 2:29:11 PM UTC+1, Lukas Zapletal wrote:
