The v2.2 work in #3491 added Dynamic, Fixed, and Retained address allocation across the supported ExpectedMachine interface roles. That core feature is complete. During the work, we found two related lifecycle cases that deserve separate v2.3 follow-up.
Before association, NICo can materialize an address from ExpectedMachine, but a later configuration change does not update or remove that address. After association, an interface can request an address in another family and consult a newer ExpectedMachine policy than the one used for its existing address.
These are different transitions, but they share one question: which version of the ExpectedMachine allocation policy controls an address after NICo has materialized part of the interface state? This epic defines that contract and applies it consistently without reopening the v2.2 role and policy work.
What This Needs To Accomplish
- Define when an
ExpectedMachine allocation policy takes effect and how long it applies.
- Decide whether an unassociated address created from
ExpectedMachine changes immediately when its declaration changes or remains unchanged until interface deletion and later ingestion.
- Decide whether a later IPv4 or IPv6 allocation uses the current declaration or the policy selected earlier in the machine lifetime.
- Distinguish addresses created from
ExpectedMachine from operator-created Static addresses, and do not rewrite operator-created addresses.
- Define behavior for association,
ExpectedMachine deletion, interface deletion, force deletion, and later ingestion.
- Coordinate any transition with DHCP and Site Explorer so concurrent work cannot apply only part of a policy change.
- Add only the persisted state and reconciliation required by the selected contract.
- Preserve existing behavior when it already satisfies the contract; do not add live reconciliation solely for symmetry.
Included Work
Follow-up to #3491. The expected interface allocation feature remains part of v2.2; this epic tracks lifecycle consistency work scheduled for v2.3.
The v2.2 work in #3491 added
Dynamic,Fixed, andRetainedaddress allocation across the supportedExpectedMachineinterface roles. That core feature is complete. During the work, we found two related lifecycle cases that deserve separate v2.3 follow-up.Before association, NICo can materialize an address from
ExpectedMachine, but a later configuration change does not update or remove that address. After association, an interface can request an address in another family and consult a newerExpectedMachinepolicy than the one used for its existing address.These are different transitions, but they share one question: which version of the
ExpectedMachineallocation policy controls an address after NICo has materialized part of the interface state? This epic defines that contract and applies it consistently without reopening the v2.2 role and policy work.What This Needs To Accomplish
ExpectedMachineallocation policy takes effect and how long it applies.ExpectedMachinechanges immediately when its declaration changes or remains unchanged until interface deletion and later ingestion.ExpectedMachinefrom operator-createdStaticaddresses, and do not rewrite operator-created addresses.ExpectedMachinedeletion, interface deletion, force deletion, and later ingestion.Included Work
Follow-up to #3491. The expected interface allocation feature remains part of v2.2; this epic tracks lifecycle consistency work scheduled for v2.3.