one_primary_ipv4 not respected on Proxmox VE (Debian 10.2)

[t4nec0]

I set up a bunch of nodes (CentOS 7.4) using the default settings for the module, in particular one_primary_ipv4, with no issues. These nodes are multi-hosted and I wanted the hostname to resolve to the "internal" (cluster) interface instead of the public one (default route).

With one_primary_ipv4=true (default) the # Primary address section is empty, as expected.

I replicated the same configuration for another bunch of nodes, this time based on Proxmox VE (Debian 10.2), but this time the result was different.

In fact I got the (wrong) primary address inserted, resulting in a duplication of the name. Since this entry comes before the other I set, it was used and corosync did not behave correctly anymore.

By reading the module code I found no reason for this... but I may have missed something.

To fix this I set hosts::enable_ipv4 to false and put 127.0.0.1 localhost explicitly in my entries list.

[chrekh]

The code puts the facter value for ipaddress first in the list of addresses used, and with one_primary_address=true that one should be the only one used.

Does 'facter ipaddress' return the same (wrong) address you get as the primary address?

If the primary addres is not the one yoy want you might be able to get the one you want by specify it with param primary_ipv4, the values from 'facter ipaddress' and collected addresses from interfaces is used as default for primary_ipv4, so you should be able to override that, and still have enable_ipv4=true.

[t4nec0]

On our CentOS 7 nodes we have two interfaces:

172.19.240.XX -> internal network
172.19.243.XX -> routed network (default route)

On these nodes:

# facter ipaddress
172.19.243.XX

but I wanted the internal interface to be used by default (hostname "resolves" to 172.19.240.XX), so all the hosts::entries are on 240

Here, by using one_primary_ipv4=true (default) the # Primary address section is empty:

# Primary address

# Additional entries (use hosts::entries to add)
172.19.240.XX       xxxxxxxxxxxxxxxxx

Setting it to false I get the two entries:

# Primary address
172.19.243.XX       xxxxxxxxxxxxxxxxx

# Additional entries (use hosts::entries to add)
172.19.240.XX       xxxxxxxxxxxxxxxxx

On the Proxmox/Debian nodes the situation is similar. The only difference is that here I want the 172.19.243.XX addresses to be in /etc/hosts. With the same puppet settings I got:

# Primary address
172.19.240.XX       xxxxxxxxxxxxxxxxx

# Additional entries (use hosts::entries to add)
...
172.19.243.XX       xxxxxxxxxxxxxxxxx

Default route is, again, on 172.19.243.XX And:

# facter ipaddress
172.19.243.XX

Which looks like a different behaviour from the other CentOS nodes...

[chrekh]

The code collects ipaddresses for all interfaces, putting the facter value for ipaddress first in that list. one_primary_ipv4 simply uses only the first entry in that list. But then ipaddresses specified using hosts::entries gets removed, this is the reason you don't get a # Primary address.

I thing the simplest way for you to accomplish what you want is to use param hosts::primary_ipv4 to override the collected ipaddresses from interfaces and facter, and only use the address you want to have. Example using hieradata

hosts::one_primare_ipv4: true
hosts::entries:
  172.19.240.2:
    - host-240-2
hosts::primary_ipv4:
  - 172.19.240.1

Resulting in

# Primary address
172.19.240.1        <facter_fqdn> <facter_hostname>

# Additional entries (use hosts::entries to add)
172.19.240.2        host-240-2

[t4nec0]

Hi @chrekh thanks for your comment. What puzzles me is the different behaviour between the two classes of hosts/operating systems. Your solution makes sense but implies the definition of hosts::primary_ipv4 for every host. I was looking for a solution with a onetime-only definition for the whole class of hosts, which means using the same hosts::entries for all. I got this result by way of setting hosts::enable_ipv4 to false. Thanks again for your effort on this beautiful module.

[PandemiK911]

Hi Just a thought : in your corosync config, you used the internal network's ip to declare hosts right ? Per PVE documentation : "Note that we always recommend to reference nodes by their IP addresses in the cluster configuration."

The different behavior could be caused by the different 'hostname -f' output ? In PVE, I always had the shortname instead of fqdn. I did not investigate.

[chrekh]

Hi @t4nec0

Would it be possible for you to test the recent rewriting I have been working on? (merged to master), and possibly even examine the testcases I have added to spec/classes/init_spec.rb (using addresses from spec/default_module_facts.yml) to see if you could suggest a addition to the tests for your problem?

[t4nec0]

Thanks @chrekh, we just need to add some nodes to our cluster and will give a try to the new version. Feedback ASAP

[chrekh]

I just released version 4.0.0