Bug 1301923

Summary: When one of the leading zeros of the last IPv6 quartet is omitted the public VIP gets set on all 3 controllers
Product: Red Hat OpenStack Reporter: Marius Cornea <mcornea>
Component: rhosp-directorAssignee: Dan Sneddon <dsneddon>
Status: CLOSED WONTFIX QA Contact: yeylon <yeylon>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: athomas, bfournie, dsneddon, jcoufal, mburns, mcornea, morazi, rhel-osp-director-maint, srevivo
Target Milestone: y3   
Target Release: 7.0 (Kilo)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Known Issue
Doc Text:
Cause: IPv6 addresses should be expressed either with no leading zeros, or with enough leading zeroes to pad out the full address. Consequence: If an IPv6 is supplied with only some of the leading zeroes, this will cause the IP address to be interpreted incorrectly. Workaround (if any): Always use full leading zeroes, or do not use leading zeroes. For instance, the IPv6 address 2001:db8::1 may also be expressed as 2001:db8:0001, but 2001:db8:01 will fail. Result: You must pay attention that IPv6 addresses are specified in the above way, or deployment may fail as a result.
Story Points: ---
Clone Of:
: 1302081 (view as bug list) Environment:
Last Closed: 2016-02-07 16:03:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1302081    
Attachments:
Description Flags
/var/log/messages none

Description Marius Cornea 2016-01-26 11:54:08 UTC
Created attachment 1118437 [details]
/var/log/messages

Description of problem:
When one of the leading zeros of the last IPv6 quartet is omitted the public VIP gets set on all 3 controllers.

Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-0.8.6-112.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Deploy IPv6 enabled overcloud with the following external allocation pool:
  ExternalInterfaceDefaultRoute: 2001:db8:fd00:1000:dead:beef:cafe:f00
  ExternalNetCidr: '2001:db8:fd00:1000::/64'
  ExternalAllocationPools: [{'start': '2001:db8:fd00:1000:dead:beef:cafe:001', 'end': '2001:db8:fd00:1000:dead:beef:cafe:009'}] 


Actual results:
stack@instack:~>>> for ctrl in $(nova list | grep controller | awk {'print $12'} | awk -F'=' {'print $2'}); do ssh heat-admin@$ctrl 'cat /etc/hostname; /usr/sbin/ip a s dev vlan10 | grep inet6 | grep 2001';done
overcloud-controller-0.localdomain
    inet6 2001:db8:fd00:1000:dead:beef:cafe:1/64 scope global tentative dadfailed 
    inet6 2001:db8:fd00:1000:dead:beef:cafe:3/64 scope global 
overcloud-controller-1.localdomain
    inet6 2001:db8:fd00:1000:dead:beef:cafe:1/64 scope global tentative dadfailed 
    inet6 2001:db8:fd00:1000:dead:beef:cafe:2/64 scope global 
overcloud-controller-2.localdomain
    inet6 2001:db8:fd00:1000:dead:beef:cafe:1/64 scope global 
    inet6 2001:db8:fd00:1000:dead:beef:cafe:4/64 scope global 

 ip-2001.db8.fd00.1000.dead.beef.cafe.001	(ocf::heartbeat:IPaddr2):	Stopped

Expected results:
The VIP resource is started and the IP address gets set only on one of the nodes at a time.

Additional info:
Attaching /var/log/messages.

Comment 1 Angus Thomas 2016-01-26 17:45:00 UTC
We should add a 7.3 release note for this.

Comment 3 Mike Burns 2016-01-27 14:48:02 UTC
Dan, can you provide the release note text here?

Comment 4 Dan Sneddon 2016-02-03 14:52:21 UTC
(In reply to Marius Cornea from comment #0)

Marius, 

It sounds like this does not occur if the leading zero is not omitted? So, if we tell people to use this:

[{'start': '2001:db8:fd00:1000:dead:beef:cafe:0001', 'end': '2001:db8:fd00:1000:dead:beef:cafe:0009'}]

Instead of this:

[{'start': '2001:db8:fd00:1000:dead:beef:cafe:001', 'end': '2001:db8:fd00:1000:dead:beef:cafe:009'}]

Then it works?

I need to understand what the workaround is to help write the release note.

Comment 5 Marius Cornea 2016-02-03 15:07:30 UTC
Yes, when providing all the zeros it works as expected:

2001:db8:fd00:1000:dead:beef:cafe:0001