Open Stack

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.