On the Wiki page for TemplateWriting , what do `@host.mac` and `@host.subnet.mask` actually mean?

I am reviewing the Wiki page for TemplateWriting at
http://projects.theforeman.org/projects/foreman/wiki/TemplateWriting#Functions-and-macros
, and I'm a bit confused by the following descriptions under "Functions and
Macros":

> @host.ip | The IP address of the host |

> @host.mac | The HW address of the host |

> @host.subnet.mask | The subnet mask of the host |

On Linux, don't things like the MAC address, IP address and Subnet really
belong to the Interface, not the Host?

I also noticed that the @host.interfaces.each array doesn't return any
values for the "Primary Interface". The array only contains values for any
secondary interface, including BMC interfaces. Same as with
@host.interfaces.all. Why is the primary interface not in this same array?

I'm not trying to be pedantic. I'm just trying to understand these
Functions and Macros and what they mean. I understand that the Linux
networking stack is a bit convoluted (see "Linux considers an IP address as
belonging to a host rather than an interface"<https://www.ibm.com/developerworks/community/blogs/tclaret/entry/linux_considers_an_ip_address_as_belonging_to_a_host_rather_than_an_interface?lang=en>at IBM DeveloperWorks).

-= Stefan

It's just a consequence of how Foreman stores the data, the "primary"
(provisioning?) interface attributes are stored on the host object
(hence @host.ip) while other interfaces are additional objects ("Nic").

··· On 10/12/13 04:57, Stefan Lasiewski wrote: > I am reviewing the Wiki page for TemplateWriting at > http://projects.theforeman.org/projects/foreman/wiki/TemplateWriting#Functions-and-macros > , and I'm a bit confused by the following descriptions under "Functions > and Macros": > > > > > @host.ip | The IP address of the host | > > > > @host.mac | The HW address of the host | > > > > @host.subnet.mask | The subnet mask of the host | > > On Linux, don't things like the MAC address, IP address and Subnet > really belong to the Interface, not the Host? > > I also noticed that the `@host.interfaces.each` array doesn't return any > values for the "Primary Interface". The array only contains values for > any secondary interface, including BMC interfaces. Same as with > `@host.interfaces.all`. Why is the primary interface not in this same array? > > I'm not trying to be pedantic. I'm just trying to understand these > Functions and Macros and what they mean. I understand that the Linux > networking stack is a bit convoluted (see "Linux considers an IP address > as belonging to a host rather than an interface" > > at IBM DeveloperWorks).


Dominic Cleal
Red Hat Engineering

Wouldn't it be more correct then, to instead have the primary NIC still be
a (mandatory?) NIC object, same as possibly existing additional ones, so
you do not have to juggle the "which is the primary NIC" information back
and forth between the HostObjects host.ip and NicOther, in case you
redeploy a machine using a different Nic than last time?

Case:
You have a hardware machine with 4 nics. You deploy via Nic0 (your
host.nic) today, having configured all other NICs in foreman at deploy time
as well.
Tomorrow you redeploy via iPXE, using Nic3.

What happens (internally) to both Nics information, within foreman and its
DB?
If I understood you correctly, foreman would in some way have to juggle the
information on which Nic is the primary one and essentially has to switch
all data previously belonging to Nic3 to reside in the HostObjects
networking data and vice versa?

Wouldn't it be more correct to just have a flag on the current primary
interface, and link to that Interfaces data to fill the host.stuff,
wherever needed?
I too am not trying to be pedantic to be pedantic (+ I'm not a dev, so what
do I know how this would be best handled…), but I feel that something like
this could lead to headaches down the line (I actually think we are already
there, judging from Sefans "The array only contains values for any
secondary interface"), without having a more specific example in mind.

There is no functional difference between the host Nic as it is currently
used within foreman and any additional Nic. It's a thing that does that
UDP/TCP stuff, the fact that you used this or that NIC to deploy last time
should not lead to it being treated in any way different from the others,
when it comes to storing its data, right? Its as important as the other
Nics which could at any given moment be used to deploy with, without any
stunts to be performed beforehand (iPXE), why should it be handled
differently within foremans data structure?

Not saying "I am right, cahnge that!", more saying "please tell me why I am
wrong/ why I am right but it does not actually matter" :wink:

Cheers,
Simon

··· On Tuesday, December 10, 2013 10:28:13 AM UTC+1, Dominic Cleal wrote: > > > It's just a consequence of how Foreman stores the data, the "primary" > (provisioning?) interface attributes are stored on the host object > (hence @host.ip) while other interfaces are additional objects ("Nic"). > > -- > Dominic Cleal > Red Hat Engineering >

>
>
>
> It's just a consequence of how Foreman stores the data, the "primary"
> (provisioning?) interface attributes are stored on the host object
> (hence @host.ip) while other interfaces are additional objects ("Nic").
>
> –
> Dominic Cleal
> Red Hat Engineering
>
>
> Wouldn't it be more correct then, to instead have the primary NIC still
> be a (mandatory?) NIC object, same as possibly existing additional ones,
> so you do not have to juggle the "which is the primary NIC" information
> back and forth between the HostObjects host.ip and NicOther, in case you
> redeploy a machine using a different Nic than last time?
>
> Case:
> You have a hardware machine with 4 nics. You deploy via Nic0 (your
> host.nic) today, having configured all other NICs in foreman at deploy
> time as well.
> Tomorrow you redeploy via iPXE, using Nic3.
>
> What happens (internally) to both Nics information, within foreman and
> its DB?
> If I understood you correctly, foreman would in some way have to juggle
> the information on which Nic is the primary one and essentially has to
> switch all data previously belonging to Nic3 to reside in the
> HostObjects networking data and vice versa?
>
> Wouldn't it be more correct to just have a flag on the current primary
> interface, and link to that Interfaces data to fill the host.stuff,
> wherever needed?

Indeed, see below.

> I too am not trying to be pedantic to be pedantic (+ I'm not a dev, so
> what do I know how this would be best handled…), but I feel that
> something like this could lead to headaches down the line (I actually
> think we are already there, judging from Sefans "The array only contains
> values for any secondary interface"), without having a more specific
> example in mind.
>
> There is no functional difference between the host Nic as it is
> currently used within foreman and any additional Nic. It's a thing that
> does that UDP/TCP stuff, the fact that you used this or that NIC to
> deploy last time should not lead to it being treated in any way
> different from the others, when it comes to storing its data, right? Its
> as important as the other Nics which could at any given moment be used
> to deploy with, without any stunts to be performed beforehand (iPXE),
> why should it be handled differently within foremans data structure?

nod the main difference in how they're treated by Foreman today is
that only the primary interface has PXE menus set up for it, while
secondary interfaces don't. This gets particularly messy for people
using build networks, but wanting the primary hostname and IP to be
Foreman's primary identifier.

> Not saying "I am right, cahnge that!", more saying "please tell me why I
> am wrong/ why I am right but it does not actually matter" :wink:

No, I think you're entirely correct. I think it's like that for
"historical reasons", probably due to how Foreman was originally
developed where it shared tables and a database with Puppet's
ActiveRecord-based storeconfigs.

Many of the oddities in the internal schema stem from this and
occasionally get fixed as it's no longer relevant.

I'd love to see it fixed, and I know others on the dev team feel similarly!

··· On 09/07/14 15:25, Simon Mügge wrote: > On Tuesday, December 10, 2013 10:28:13 AM UTC+1, Dominic Cleal wrote:


Dominic Cleal
Red Hat Engineering