On 11/15/2016 10:41 AM, Gabriele Cerami wrote:
On 18 Oct, Gabriele Cerami wrote:
Hello,
after adding coverage in CI for HA IPv6 scenario here
https://review.openstack.org/363674 we wanted to add IPv6 testing on the
gates.
To not use any more resources the first suggestion to add IPv6 to the
gates was to make all HA jobs IPv6, move network isolation testing for
IPv4 on non-ha job, and test non-netiso environment on multinode.
This is still up for debate, another possibility is to test IPv6 just in
the updates jobs.
The updates job with ipv6 should be working now. I've proposed
https://review.openstack.org/405560 to get it back in the check queue as
non-voting for now.
I do want to note that I've softened my position on this though. I
still think we need the updates job and that 3 jobs provides us the
necessary test coverage (no net-iso, ipv4 net-iso, ipv6 net-iso), but I
do recognize that we're far more likely to break ipv6 than the no
net-iso case so if the updates job ends up blocked for some reason I'd
be okay with the changes proposed here.
This is almost done here https://review.openstack.org/382515 with one
exception. Liberty HA IPv6 fails during ping test with the error:
503 Service unavailable.
This issue was solved during the summit
Moreover, swift memecache code in liberty is clearly not IPv6
compatible, it gives an error on the overcloud, not being able to get
host and port from a correctly formed IPv6 URL. To make it compatible
with IPv6 this should be backported https://review.openstack.org/258704
This still remains.
Before continuing the debugging I wanted to be sure that:
- this is an acceptable shuffle for the gates jobs
- we are really interested in testing liberty IPv6
I have another question to add to the mix. Do we care to test IPv6 with
SSL ? Our current certificate handling code is dealing only with IPv4
addresses, so if we need to test both, we'll have to add that part too.
Agree with Emilien that this is something we should do. I believe I saw
a patch up for the updates job to add this, which will be good to have.
I would prefer to wait on adding features to either ipv6-based job until
we have something voting on patches though. Getting some sort of ipv6
coverage in is higher priority in the short-term IMHO than getting all
the features enabled there, and every feature we add is one more
potential thing to block the ipv6 job becoming voting.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
