2.4. Georedundancy Use cases (Draft)

2.4.1. Connection between different OpenStack cells

2.4.1.1. Description

There should be an API to manage the infrastructure-s networks between two OpenStack cells. (Note: In the Mitaka release of OpenStack cells v1 are considered as, cells v2 functionaity is under implementation)

2.4.1.2. Derrived Requirements

• Possibility to define a remote and a local endpoint
• Possiblity to define an overlay/segregation technology
• As in case of cells the nova-api service is shared it should be possible to identify the cell in the API calls

2.4.1.2.1. Northbound API / Workflow

• An infrastructure network management API is needed
• When the endpoints are created neutron is configured to use the new network. (Note: Nova networking is not considered as it is deprecated.)

2.4.1.2.2. Data model objects

• TBD

2.4.1.2.3. Orchestration

• TBD

2.4.1.2.4. Dependencies on compute services

• TBD

2.4.1.2.5. Potential implementation

• TBD

2.4.2. Connection between different OpenStack regions or cloud instances

2.4.2.1. Description

There should be an API to manage the infrastructure-s networks between two OpenStack regions or between two OpenStack cloud instances. (The only difference is the shared keystone in case of a region)

2.4.2.2. Derrived Requirements

• Possibility to define a remote and a local endpoint
• Possiblity to define an overlay/segregation technology

2.4.2.2.1. Northbound API / Workflow

• An infrastructure network management API is needed
• When the endpoints are created neutron is configured to use the new network. (Note: Nova networking is not considered as it is deprecated.)

2.4.2.2.2. Data model objects

• TBD

2.4.2.2.3. Orchestration

• TBD

2.4.2.2.4. Dependencies on compute services

• TBD

2.4.2.2.5. Potential implementation

• TBD