Rewrite IPv6 goal to be clearer that we already v6
The original IPv6 community goal is laudable, but misleading. It behooves us to avoid incorrectly implying that we lack solid IPv6 support. We've provided solutions for IPv6 connectivity to user resources for a very long time and even have users successfully deploying OpenStack environments with IPv6 control planes. What we can't demonstrate with confidence yet is that OpenStack is usable in IPv6-only environments (those with no traditional IPv4 addressing), so we should clarify that the goal is about taking that next step. Change-Id: Ic657850a06ec70dedf153ac754cfa707dbee2b90
This commit is contained in:
Jeremy Stanley
parent
4c16d1cdc6
commit
a8fb6b3bd0
|
|
@ -1,39 +1,27 @@
|
|||
========================
|
||||
IPv6 Support and Testing
|
||||
========================
|
||||
=============================
|
||||
Support IPv6-Only Deployments
|
||||
=============================
|
||||
|
||||
IPv6 has been around over 10 years and most of the OpenStack projects do
|
||||
have IPv6 supports in general or at some extent depends on
|
||||
various scenarios and use cases. There are multiple levels of IPv6 support.
|
||||
For example, the two primary IPv6 use cases are:
|
||||
|
||||
* OpenStack services listen and communicate with each other on IPv6.
|
||||
* OpenStack resources, for example Compute VM are assigned an IPv6
|
||||
address and able to ssh and communicate with each other over IPv6.
|
||||
|
||||
All these scenarios are good to target in OpenStack as complete software and
|
||||
most of them might have been working. But we do not have concrete testing for
|
||||
any of IPv6 scenario or use cases which means we do not know what all scenarios
|
||||
work properly or not regressed or never worked at all.
|
||||
|
||||
It is always difficult to guarantee that all the use cases of IPv6 work and
|
||||
have been tested in the upstream gate. We can target to test and fix that one
|
||||
by one.
|
||||
For years now, OpenStack has included and continually tested
|
||||
features for providing IPv6-ready environments, to the point where
|
||||
we've also seen interest in operating environments which have no
|
||||
traditional IPv4 at all. As a result, we need tests which can
|
||||
confirm this scenario also works well and does not regress.
|
||||
|
||||
This community wide goal cover the below scenarios:
|
||||
|
||||
#. OpenStack services (include mysql, rabbitmq etc) listen and communicate with
|
||||
each other on IPv6.
|
||||
each other on only IPv6.
|
||||
|
||||
#. OpenStack booted VMs can communicate (to other VMs or OpenStack service
|
||||
endpoint) over IPv6. This scenario is much needed when OpenStack services
|
||||
like Octavia and Sahara need to communicate to other services from compute
|
||||
VM.
|
||||
endpoint) over only IPv6. This scenario is much needed when OpenStack
|
||||
services like Octavia and Sahara need to communicate to other services from
|
||||
compute VM.
|
||||
|
||||
In most of the cases, above two scenarios might work fine but there is not
|
||||
enough testing of IPv6. The purpose of this goal is to add the integration
|
||||
testing of IPv6-only support setting for all the projects and adding the
|
||||
IPv6 support for inter-service communication where it doesn't exist.
|
||||
In most of the cases, above two scenarios might work fine but there is
|
||||
insufficient testing to prove it. The purpose of this goal is to add the
|
||||
integration testing of IPv6-only support setting for all the projects and
|
||||
adding the IPv6 support for inter-service communication where it doesn't exist.
|
||||
This way we can at least make sure that OpenStack services work fine on
|
||||
IPv6-only environment.
|
||||
|
||||
|
|
@ -44,11 +32,12 @@ IPv6-only environment.
|
|||
goal. That might need more work and a large number of testing across all
|
||||
projects with various drivers. Each project team should encourage their
|
||||
vendors and partners to head in the direction of ipv6 native operation.
|
||||
This goal may also entail the drafting of new standards such as a v6
|
||||
equivalent for metadata services which popular clients can eventually
|
||||
implement.
|
||||
|
||||
Once we have integration jobs running as voting on gate to test the
|
||||
OpenStack services listen on IPv6 address and VM connectivity over
|
||||
IPv6, below are the next steps for respective team to extend the
|
||||
IPv6 testing scope or documentation:
|
||||
Below are the next steps for respective team to extend the IPv6 testing scope
|
||||
or documentation:
|
||||
|
||||
#. Encourage vendors/backends to extend the IPv6-only testing as per
|
||||
their specific scenarios and use cases. Corresponding Project team
|
||||
|
|
@ -91,13 +80,14 @@ In order for a project to call this goal complete it must:
|
|||
any hard-coded value or any other variables not adjusted by
|
||||
devstack when it is configured for IPv6.
|
||||
|
||||
#. Run the voting integration job with IPv6-only setting in check and gate
|
||||
pipeline. This job will be suffixed as -IPv6-only. This integration job does
|
||||
not need to run all the tests present (or running in other integration
|
||||
jobs) in that project. The set of tests to run on these jobs will be
|
||||
decided on runtime based on each project requirement and considering the
|
||||
two scenarios listed above under the scope of this goal.
|
||||
For example:
|
||||
#. Run the voting integration job with IPv6-only setting (or through
|
||||
supervision which will fail the job if intra-stack communication attempts to
|
||||
utilize IP version 4 protocol) in check and gate pipeline. This job will be
|
||||
suffixed as -IPv6-only. This integration job does not need to run all the
|
||||
tests present (or running in other integration jobs) in that project. The
|
||||
set of tests to run on these jobs will be decided on runtime based on each
|
||||
project requirement and considering the two scenarios listed above under the
|
||||
scope of this goal. For example:
|
||||
|
||||
* New IPv6-only Tempest job can install devstack with
|
||||
default services with IPv6-only mode and run the IPv6 related tests
|
||||
|
|
@ -173,7 +163,9 @@ etherpad(#14).
|
|||
Current State / Anticipated Impact
|
||||
==================================
|
||||
|
||||
Most projects might be working fine with IPv6, but there is no testing
|
||||
to confirm IPv6 functionality and to avoid any breaking change to merge.
|
||||
By having a voting job running IPv6-only setting will make sure we have
|
||||
basic IPv6 scenario working and will not regress.
|
||||
Most projects work fine with IPv6 already, but there is no testing
|
||||
to confirm IPv6-only functionality and to avoid any breaking change
|
||||
to merge. By having a voting job running IPv6-only setting (or
|
||||
failing on any v4 communication which hasn't been whitelisted) will
|
||||
make sure we have the IPv6-only scenario working and will not
|
||||
regress.
|
||||
|
|
|
|||
Loading…
Reference in New Issue