Merge "Rewrite IPv6 goal to be clearer that we already v6"
This commit is contained in:
commit
cee1e8f7a8
|
@ -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