v2.0.0-alpha.3 -2023-04-13

[bryanculver]

2.0 IPAM Overhaul Alpha Release

Overview

This alpha introduces the Namespace concept to IPAM and makes many robust improvements to relationships between models:

• Namespace introduced to provide a uniqueness boundary for IPAddresses and Prefixes
• Prefixes have concrete relationships to their parents instead of derived
• IPAddresses have concrete relationships to their parent prefixes
• VRF is no longer used as a uniqueness constraint for IPAddresses and Prefixes

⚠️ NOTE: Because we are validating these new data models the data migrations have not been implemented. You will have to re-input your data largely via the UI to prove if these models will work for you. We will implement the migrations in an upcoming beta if the relationships between Namespace and other IPAM objects prove to be the right design. As such, do not expect to migrate future releases on these installs. The data migration steps won't be re-performed.

For more detailed information, please view: #1032, #3337 (comment)

❗ This has been recreated to fix a bug with the prerelease workflow.

---

Changelog

• Add missing plugin links to docs page menu by @matt852 in Add missing plugin links to docs page menu #3447
• Removed block sidebar from aggregate_list.html and objectchange_list.html. by @HanlinMiao in Removed block sidebar from aggregate_list.html and objectchange_list.html. #3463
• Implement Prefix.parent concrete foreign key to self. by @jathanism in Implement Prefix.parent concrete foreign key to self. #3452
• IPAddress lookup fix by @glennmatthews in IPAddress lookup fix #3487
• Fix Docker Prerelease Tag Syntax by @bryanculver in Fix Docker Prerelease Tag Syntax #3475
• Fixes to Prefix views and functionality by @glennmatthews in Fixes to Prefix views and functionality #3496
• Update README.md by @lampwins in Update README.md #3515
• Release 2.0.0-alpha.2 by @jathanism in Release 2.0.0-alpha.2 #3511
• Introduced IPAddress.parent concrete foreign key to Parent by @jathanism in Introduced IPAddress.parent concrete foreign key to Parent #3489
• VRF namespace enhancements by @glennmatthews in VRF namespace enhancements #3505
• Merge develop into next for docker tag fix by @gsnider2195 in Merge develop into next for docker tag fix #3522
• Bump redis from 4.3.4 to 4.5.4 by @dependabot in Bump redis from 4.3.4 to 4.5.4 #3499
• Remove slug from models by @timizuoebideri1 in Remove slug from models #3439
• Release/1.5.15 by @bryanculver in Release/1.5.15 #3537
• Main to develop post v1.5.15 by @bryanculver in Main to develop post v1.5.15 #3539
• Add note to ViewSet Attributes. by @scetron in Add note to ViewSet Attributes. #3478
• Remove nat_outside by @timizuoebideri1 in Remove nat_outside #3523
• Adds doc page for Circuit Maintenance by @jvanderaa in Adds doc page for Circuit Maintenance #3558
• Drop python 3.7 support for 2.0 by @glennmatthews in Drop python 3.7 support for 2.0 #3554
• Update README.md by @lampwins in Update README.md #3564
• Use plugins next-2.0 branch for next upstream tests by @snaselj in Use plugins next-2.0 branch for next upstream tests #3502
• Batch of things to improve working with relationships. by @bryanculver in Batch of things to improve working with relationships. #3550
• Fix Docker Container 2.0.0-alpha.2 is missing Python Module 'packaging' #3525 - add missing dependency by @glennmatthews in Fix #3525 - add missing dependency #3563
• Release/1.5.16 by @bryanculver in Release/1.5.16 #3565
• Main to develop post v1.5.16 by @bryanculver in Main to develop post v1.5.16 #3569
• Defense against Docker Container 2.0.0-alpha.2 is missing Python Module 'packaging' #3525 - add explicit dependency to develop as well by @glennmatthews in Defense against #3525 - add explicit dependency to develop as well #3566
• Develop to next post 1.5.16 by @bryanculver in Develop to next post 1.5.16 #3570
• [REVIEW ONLY] next into Namespaces Prototype by @bryanculver in [REVIEW ONLY] next into Namespaces Prototype #3572

Full Changelog: v2.0.0-alpha.2...v2.0.0-alpha.3

---

This discussion was created from the release v2.0.0-alpha.3 -2023-04-13.

[kingfetty]

Addresses still require CIDR notation but the CIDR notation is not needed as it does not appear to be taken into account in any of the calculation for parent/child relationships.
example: Prefix 192.168.1.0/24
Address[0] 192.168.1.1/24
Address[1] 192.168.1.2/32
Address[2] 192.168.1.3/16
Address[3] 192.168.1.4/27
All these were acceptable. When in reality if these were true CIDRs of these it would create issues.
Suggestion, pull the CIDR from the Prefix since there is a required parent anyway. Or if the CIDR is smaller than the prefix, have the option of creating a new prefix along with the address?

[jathanism]

@kingfetty Thanks for the observations! We've had discussions about this and the reality is that the prefix length for an IP address does not matter. In actuality or even in practice it's really just shorthand for the netmask you're specifying when configuring that IP on a device--and exactly to your point--we could just inherit it from the parent Prefix.

Obviously at this time we have not yet removed it, but very well may do so.

One last thing, however, is that having the prefix length on the IP address as it is currently does not impact the CIDR notation or parenting algorithm whatsoever because all IPs are leaf nodes and cannot have children. While it might be confusing to see a Prefix with address 192.168.1.2/31 (which is valid, containing .2 and .3 as children) an IPAddress with the same address would merely represent 192.168.1.2 with a netmask of 255.255.255.254, indicating that its parent is the Prefix of the same length. Because it is confusing however, is a good reason to change the semantics in the data design and user experience in Nautobot 2.0! :)