diff --git a/goals/train/ipv6-support-and-testing.rst b/goals/train/ipv6-support-and-testing.rst index acd8934c7..dadb90b86 100644 --- a/goals/train/ipv6-support-and-testing.rst +++ b/goals/train/ipv6-support-and-testing.rst @@ -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.