Comment 6 for bug 1803203
Revision history for this message
| Heitor Alves de Siqueira (halves) wrote | #6 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Some notes for reference:
We might actually have some trouble in expressing the Lifetime of an Address in the Netplan schema. From the Netplan Reference [0] we can see that the 'addresses:' field accepts a list of mixed IPv4 and IPv6 addresses. We can't just add a 'lifetime:' field to the schema, because then we wouldn't have a way to link that value to one of the addresses in the mixed list. I can see a few different ways to change the configuration to accommodate the lifetime change:
1) Implement a list of lifetimes, which would "follow" the list of addresses
(i.e. lifetime[0] corresponds to addresses[0] and so on)
2) Modify the address syntax inside the list to allow an optional lifetime, e.g.:
addresses: [127.0.0.1 (forever), "2001:1::1/64 (0)"]
3) Allow the definition of an address+lifetime mapping and use that in the
'addresses' field, e.g.:
myaddr:
value: 127.0.0.1
lifetime: 0
...
addresses: [ myaddr, 2001:1::1/64 ]
Option 1 has the obvious problem of matching one lifetime to a list of multiple addresses. Say we want to specify a lifetime to address number K in the list, would we need to specify a lifetime for all of them? How would we "skip" default lifetimes with this approach?
Option 2 has the benefit of being somewhat compatible with the current schema in the sense that if no lifetime is specified, we can keep the current behavior. I feel like it would introduce a lot of complexity in the schema parsing code to sort the addresses from the lifetime though, and this might not be something that we want in a sensitive code section.
Option 3 looks very flexible, but I'm not familiar enough with the schema and its parsing code to estimate the impact that would have. I think we would need quite a few significant changes, and I'm not really sure where we would place the 'myaddr' definition in the schema either.
None of the above options feel like a good way to solve the lifetime problem, but I'm not sure we have an easy way to integrate that into the current netplan schema. Perhaps someone more experienced with the Netplan schema/codebase might offer better insight on how to tackle this issue.
[0] https:/