Platform Network Address Reduction - AIO-SX

Storyboard: https://storyboard.openstack.org/#!/story/2011191

One of the objectives of this feature is to reduce the number of network addresses used for platform networks (OAM, management, admin, PXE boot, cluster-host, and storage) when an AIO-SX system is deployed.

Another objective is to provide flexibility for subcloud installation by making it possible to have overlapping admin or management subnet configurations between several subclouds, allowing the system controller to add multiple subclouds on the same subnet.

The decision was made to keep the floating address for each platform network and remove the usage of the node addresses (controller-0 and controller-1) from the AIO-SX deployments.

Problem description

Currently, on a StarlingX system, only the OAM network uses just one IP address on its interface; the others allocate three addresses (controller-0, controller-1, and floating) to their respective interfaces. This is deemed unnecessary as a single address should suffice to operate an AIO-SX system. Removing the extra address will impact all host subsystems that configure themselves with the node address.

The distributed cloud does not allow overlap of admin or management between its subclouds. On IPv4 systems, this impacts address allocation by the network operators as the current requirements (for single or multi-node systems) of /29 subnets are considered inadequate for DC systems consisting of thousands of AIO-SX subclouds.

Use Cases

With the introduction of this feature, the system will experience minimal impact, as it is primarily an optimization of address allocation.

  • End users: No operational impact is expected for end users, as all services will remain accessible via the floating address.

  • Deployers: Deployers will be able to plan network allocation using the minimal number of addresses necessary to operate an AIO-SX system.

Proposed Change

  • Modify address pool allocation during bootstrap to use only one address from the bootstrap variables, and designate that address as the floating address. Node addresses (controller-0 and controller-1) can still be allocated in the database but will be ignored during configuration.

  • Review hieradata generation to ensure that variables referencing the floating and controller-0 addresses contain the same value (i.e., the floating address) in AIO-SX. This approach minimizes the need to modify scripts, as they will ultimately configure the correct address.

Alternatives

  • Address allocation is currently hardcoded, and there are no available alternatives to reduce it through configuration alone.

Data model impact

None

REST API impact

None

Security impact

None

Other end user impact

None

Performance Impact

None

Other deployer impact

None

Developer impact

None

Upgrade impact

  • System upgrade In AIO-SX systems the extra unit addresses (controller-0 and controller-1) in the address pool DB table will be deallocated and removed from the table.

Implementation

Assignee(s)

Primary assignee:

Other Contributors:

Repos Impacted

  • starlingx/ansible-playbooks

  • starlingx/config

  • starlingx/distcloud

  • starlingx/update

  • starlingx/stx-puppet

  • starlingx/docs

Work Items

The following work items are expected, with the understanding that the storyboard will be updated as more work items are found to be necessary.

Development Work Items

  • Spike: investigate if storage network can use just one IP

  • Change admin network subnet semantic check restriction from entire subnet

  • Admin Address Pool Reduction: Configuration Management: Runtime operation

  • Admin Address Pool Reduction: Configuration Management: Ansible Bootstrap

  • Admin Address Pool Reduction: upgrade/rollback implementation

  • mgmt Address Pool Reduction: Configuration Management: Ansible Bootstrap

  • mgmt Address Pool Reduction: Configuration Management: Runtime operation

  • mgmt Address Pool Reduction: DistCloud implementation

  • mgmt Address Pool Reduction: upgrade/rollback implementation

  • cluster-host Address Pool Reduction: Configuration Management: Ansible Bootstrap

  • cluster-host Address Pool Reduction: Configuration Management: Runtime operation

  • pxeboot Address Pool Reduction: Configuration Management: Ansible Boostrap

  • pxeboot Address Pool Reduction: Configuration Management: Runtime operation

  • storage Address Pool Reduction: Configuration Management: Ansible Bootstrap

  • storage Address Pool Reduction: Configuration Management: Runtime operation

  • cluster-host,pxeboot,storage Address Pool Reduction: upgrade/rollback implementation

Customer Documentation

  • Provide clarification on the customer doc about address allocation on AIO-SX systems

Dependencies

None

Testing

System configuration

The tests will be conducted in the following system configurations:

  • AIO-SX

  • AIO-DX

  • Standard

Test Scenarios

  • Installation of AIO-SX stand-alone and check allocated addresses on linux and services availabilty on the floating address

  • Installation of AIO-DX and Standard in stand-alone and look for regression

  • Backup and Restore of an AIO-SX system

  • Migration from AIO-SX to AIO-DX

  • Upgrade and Rollback of an AIO-SX system from stx-10.0 to stx-11.0

  • AIO-SX subcloud addition, rehoming, enrollment, and removal

  • AIO-SX subcloud addition, rehoming, enrollment, and removal using overlaped admin or management networks

Documentation Impact

The end-user documentation will be updated on the chapters: * “Network Addressing Requirements” * “Install a Subcloud Using Redfish Platform Management Service” * “Install a Subcloud Without Redfish Platform Management Service” * “Migrate an AIO-SX to an AIO-DX Subcloud”

History

Revisions

Release Name

Description

stx-11.0

Introduced