feat: an HA pair's DHCP peers and config sync as facts (4.11.0)
CI / test (3.10) (push) Successful in 26s
CI / test (3.11) (push) Successful in 24s
CI / test (3.12) (push) Successful in 27s
CI / test (3.13) (push) Successful in 26s
CI / test (3.10) (pull_request) Successful in 26s
CI / test (3.11) (pull_request) Successful in 24s
CI / test (3.12) (pull_request) Successful in 27s
CI / test (3.13) (pull_request) Successful in 25s
CI / test (3.10) (push) Successful in 26s
CI / test (3.11) (push) Successful in 24s
CI / test (3.12) (push) Successful in 27s
CI / test (3.13) (push) Successful in 26s
CI / test (3.10) (pull_request) Successful in 26s
CI / test (3.11) (pull_request) Successful in 24s
CI / test (3.12) (pull_request) Successful in 27s
CI / test (3.13) (pull_request) Successful in 25s
get_dhcp_ha (declared on DhcpServerMixin, optional) is what a DHCP server's own HA configuration says: on or off, this server's peer name, each peer's name, role as the server words it, and HA URL. ConfigSyncMixin.get_config_sync is where a host pushes its configuration and for which services, by the names get_services reports; sync items without a service name stay visible under `unmapped`. A driver mixes it in, no role promises it. Both raise when they could not read. What the facts mean for a pair -- hot standby, which side to write to -- is the caller's (NetOrk/netork#1125).
This commit is contained in:
1 parent
2739f10ecd
commit
90367c1370
7 files changed
+183
-1
No files matched your search
+1
-1
@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
|
||||
|
||||
[project]
|
||||
name = "napalm-device-types"
|
||||
version = "4.10.1"
|
||||
version = "4.11.0"
|
||||
description = "Abstract device-type base classes for NAPALM drivers"
|
||||
readme = "README.md"
|
||||
requires-python = ">=3.10"
|
||||
|
||||
Reference in new issue
Block a user