>
>
>
> 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" 
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
