On 19/12/19 10:18 -0600, Ken Gaillot wrote: > On Thu, 2019-12-19 at 15:01 +0000, Marcus Vinicius wrote: >> Is there any intention to abandon CLUSTERIP > > yes > >> in favor of xt_cluster.ko? > > no > > :) > > A recent thread about this: > https://lists.clusterlabs.org/pipermail/users/2019-December/026663.html > > resulted in a change to allow IPaddr2 clones to continue working on > newer systems if "iptables-legacy" is available: > https://github.com/ClusterLabs/resource-agents/pull/1439
Note also a closer look later in that thread: https://lists.clusterlabs.org/pipermail/users/2019-December/026671.html that eventually, on the side axis, led to an updated man page (coming to iptables v1.8.5 or so): https://git.netfilter.org/iptables/commit/?id=37ff0d667d346dd455e08f52a785685185f01b15 so there are no doubts about where this is headed, and shall call for action where the risk is imminent, as also mentioned: > tl;dr Cloned IPaddr2 is supported only on platforms that support > CLUSTERIP, and can be considered deprecated since CLUSTERIP itself is > deprecated. A pull request with an xt_cluster implementation would be > very welcome, as it's a low priority for available developers. Good news is that sinking the support for that in would be rather non-intrusive from the operational perspective, since xt_cluster (aliased also as ipt_cluster, for that matter) was around with Linux kernels as old as 2.6.30[*1] -- of course, YMMV. Another good news regarding possible future decline from iptables/xtables as such in the face of nftables -- technology that is itself around in the Linux kernel for ages, since Linux 3.13 in particular[*2] -- slowly getting prefered, I think, is that you can manually rewrite the respective firewall rules using xt_cluster extension statically (hence right in the agent) even if you lack iptables-legacy at those very cluster machines. All you need is a side (not necessarily local) installation of iptables with iptables-translate (comes with iptables-nft package in a fairly recent Fedora) command working so that you can yield the right incantation of the nft tool controlling said nftables, see examples of that: https://git.netfilter.org/iptables/tree/extensions/libxt_cluster.txlate?h=v1.8.4 Capturing generalizations of the intention-to-exact-recipe translation logic in the agent itself would then be the best way to proceed, since that way, no dependency on "transitional legacy stuff" (read: unnecessary code cruft in the agent when supported in parallel) would be needed, yay! * * * So, any takers? :-) Of course, as discussed before, this overhaul would deserve a strict separation of the function in question under a dedicated agent like LoadSharingIP, letting the equivalent one in IPaddr2 agent and based on something practically deprecated on arrival slowly die out. Existing agent is pretty complex even without that semantically overriding piggy-backing already -- no more gravity boosting like that, please (not to speak of its naming that simply won't "click"). Also note there are missing puzzles regarding IPv6 support, still: https://lists.clusterlabs.org/pipermail/users/2019-December/026710.html [*1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0269ea4937343536ec7e85649932bc8c9686ea78 [*2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96518518cc417bb0a8c80b9fb736202e28acdf96 -- Jan (Poki)
pgpBKXj7MZ5xg.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/