I always prefer a consistent and unambiguous

Release x.x.x

commit message rather than the variations of

Prepare release

Update for release

style commit messages that we sometimes also get.

yes, prepare for release is making sure 'Release x.y.z' can happen, not an actual release

This message was deleted.

This message was deleted.

I vaguely recall someone working on that. (FWIW, using slack threads in this channel can be confusing to our IRC only users).

oh yes, reviewing that was on my (long) TODO list :(

https://github.com/voxpupuli/voxpupuli.github.io/pull/269 that was

oh, I thought you meant this one. https://github.com/voxpupuli/voxpupuli-release/pull/44

oh, I thought you meant this one. https://github.com/voxpupuli/voxpupuli-release/pull/44

Could use review on openldap module release - https://github.com/voxpupuli/puppet-openldap/pull/361

Could use review on openldap module release - https://github.com/voxpupuli/puppet-openldap/pull/361

i have read about puppet 8 deprecating legacy facts. can someone confirm? would be a huge impact for unmaintained modules.

the idea is to implement a switch to disable legacy facts in the agent. this will be introduced in Puppet 7 and defaults to not disable legavy facts

and this might flip on puppet 8. but you will be able to continue using them

for all vox pupuli modules we already use a linter plugin to identify and replace all legacy facts

UGH. Under el9, the backwards compat

ifup

scripts can not handle /etc/sysconfig/network-scripts/ifcfg- scripts which setup vlan interfaces. It handles bonds and bridges but a trivial vlan interface doesn't work

time for systemd-networkd <3

I guess we should really try and get our networkmanager module into a better state for public publishing

(I hate it for servers)

I need to admit, I'm not the biggest fan of networkmanager

Usually servers don't need the whole connection-based design of networkmanager, they're more often on links where the connection is configured on the switch after all

@ananace I am not a fan of NM for anything other than a laptop but RH has decided otherwise. I have a fair number of host that are multihomed and static routes are pushed out via puppet (largely because "multicast routing").

The situation is bad until EL9. Even

nmcli conn migrate

doesn't handle the vlan interfaces

and the .nmconnection files seem to be using a UUID to map the relationship between an interface and a bridge.

E.g.

[connection]
id=VLAN connection 1
uuid=0576810c-53b0-4b55-ac02-f5ce13636d81
type=vlan
interface-name=bond0.1234
master=65e8129e-3771-b239-f1fb-6549e4cb69f4
slave-type=bridge

[ethernet]

[vlan]
flags=1
id=1234
parent=bond0

[bridge-port]

Where

65e8129e-3771-b239-f1fb-6549e4cb69f4

is the UUID of the bridge that vlan1234 from bond0 should be added to.

Where

65e8129e-3771-b239-f1fb-6549e4cb69f4

is the UUID of the bridge that vlan1234 from bond0 should be added to.

having the ncurses nmcli thing segfault on me was my favourite bit during the redhat exams

The fact that there are at least 4 different cli tools for configuration networking should be a clue that there is a problem.

look at this: https://access.redhat.com/documentation/hi-in/red_hat_enterprise_linux/9/html/configu[…]configuring-vlan-tagging_configuring-and-managing-networking