4.2 Elastic and public IP handling

Steve Jones edited this page Sep 21, 2017 · 1 revision

This document details changes to elastic and public IP address handling made in Eucalyptus 4.2.

Background

There are two main reasons for the 4.2 changes, networking mode updates and an EDGE/VPCMIDO bug causing address metadata to be lost on service restart.

Networking Updates

In 4.2 the MANAGED network modes were updated broadcast network information as per EDGE/VPCMIDO modes. This change obsoleted the 2 phase address state management and addressing callbacks / dispatcher.

Address Metadata

EDGE and VPCMIDO modes were relying on restoration of elastic IP address state from the database on service restart but other than initial allocation the address state was not persisted.

4.2 Changes

Address Batching

As the address actions performed against the cluster controller in previous releases are replaced by updates via the network broadcast we need to group actions for efficiency. Address batching is used to group together addressing changes and then send a broadcast containing all changes rather than broadcasting an update for every change. Batching is handled via the Addresses facade, with explicit batching via Addresses#batch which should be used in a try-with-resources statement.

Address Registry

The enabled/disabled address registry is separated out as a new AddressRegistry class, leaving Addresses as a facade/utility for working with addresses. Direct use of the AddressRegistry should be avoided where possible, ideally the registry will be an implementation detail rather than part of the address API.

Address

Address is no longer an entity, this class is now used for handling atomic state transitions for in-memory (registered) addresses.

Address Persistence

An AllocatedAddressEntity is added for persistence of address metadata, new columns are added for instance information and the unique key is updated to consist of only the IP (was previously account scoped)

User Facing Service Functionality

Non-verbose address describe is now handled by the EC2 UFS. This is possible as the database reflects the current state of address allocations and associations. Verbose/administrator listing of addresses is forwarded to the stateful compute service which uses in-memory data, this allows access to all address information including unused addresses.

4.2 Upgrade

On upgrade to 4.2 the persistent address metadata is updated based on the available information from addresses and instances. The AllocatedAddressEntity420Upgrade entity upgrade handles the update.


category.confluence

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.