Description of problem: I am implementing IPv6 for TripleO, and I am getting the following failure on deployment because the keepalived module is not accepting an IPv6 address: Error: address family is not same at /etc/puppet/modules/tripleo/manifests/loadbalancer.pp:331 on node overcloud-controller-0.localdomain Wrapped exception: address family is not same Error: address family is not same at /etc/puppet/modules/tripleo/manifests/loadbalancer.pp:331 on node overcloud-controller-0.localdomain Version-Release number of selected component (if applicable): OSP 7.0.2/OSP-D 7.2 beta puddle 2015-10-20.2 How reproducible: 100% Steps to Reproduce: 1. Obtain templates from https://review.openstack.org/#/c/235423/ 2. Deploy using IPv6 templates 3. Actual results: The error above happens because loadbalancer.pp can't handle internal_api_virutal_ip being an IPv6 address. I'm not sure if it's choking on the comparison between internal_api_virtual (IPv6) and control_virtual_interface (IPv4), or if it's the interface_for_ip method that can't take an IPv6 address. Expected results: This Puppet module should accept IPv6 as well as IPv4 inputs for the IP addresses and VIPs. Additional info: These IPv6 templates are a work in progress. I can provide access to an environment to test them out if need be.
The keepalived puppet module (https://github.com/Unyonsys/puppet-module-keepalived.git)) is working fine with IPv6 addresses. The issue resides in the tripleo module itself as it seems to be coming from the interface_for_ip function (lib/puppet/parser/functions/interface_for_ip.rb). The function can't handle IPv6 addresses. For instance when using an IPv6 address the following should be using 'address6_' instead of 'address': https://github.com/openstack/puppet-tripleo/blob/master/lib/puppet/parser/functions/interface_for_ip.rb#L15 Also, testing on latest centos7.1/facter 2.4.1, there are not netmask returned by facter for any IPv6 address. That definitely breaks this function too.
netmastk6 is only available from Facter 3.0+: https://docs.puppetlabs.com/facter/3.0/core_facts.html#netmask6interface The fix (see attached) provides support for IPv6, provided Facter 3.0+ is available. That means with an older version of Facter, the match will fail. Bumping up Facter 3+ to RHEL7/CENTOS7/Fedora23 is therefore needed.
(In reply to Gilles Dubreuil from comment #4) We can pass the netmask via Heat, since we know that value. Are there other values that we need to make this work?
In order to give time for facter 3 to land, we effectively need working around those facts. Can the interface be provided to the puppet module? If yes then no need to search for it and we don't have to use the interface_for_ip method for now.
The backport from facter 3 being impossible because it's structurally completely different, it also use ip (iproute) instead of ifconfig (facter 2). And because of issue reported with ifconfig, I was not keen on a drop in solution to have netmask6 in facter 2. That's why one solution is to pass (from heat) the information required (since it seems to have it) and avoid using facter altogether on IPv6 related data: All we need is the interface for those IPs: internal_api_virtual_ip storage_virtual_ip storage_mgmt_virtual_ip In parallel I'm trying the drop in solution for netmask6.
Created attachment 1099075 [details] Archive of netmask6 drop-in solution for facter 2.x
Tar file provided in comment #* provides netmask6 and netmask6_<interface> facts for Facter 2.x
Sorry for the confusion, removing the attached file which belongs to BZ#1283387. Please ignore comment #8 and comment #9. The gerrit patch provided earlier works using facter facts netmask6 and netmask6_<interface> available in BZ#1283387
I'm completely confused about what is happening with this bug now. Are we in fact going to use the fact mmagr wrote for ipv6 netmask with facter2, attached to BZ#1283387 ? This seems like the path we should be following for 8 and for the required backport to 7.
I believe we have two ways to work around that issue, either we use the new fact or the fix for netmask6.
(In reply to Hugh Brock from comment #11) > I'm completely confused about what is happening with this bug now. Are we in > fact going to use the fact mmagr wrote for ipv6 netmask with facter2, > attached to BZ#1283387 ? This seems like the path we should be following for > 8 and for the required backport to 7. Yes, we are going with the custom netmask6 fact that Martin wrote. There is another related issue which is being addressed: With IPv6 URLs, IP addresses in the context of a host address may be written as-is, but when the IP address is part of a URL it should be enclosed in square brackets (YUCK!). I am in the process of modifying the TripleO Heat Templates to return the IP address with or without the brackets depending on which parameter is used. Then I will modify the calls that construct URLs to use the new bracketed parameter, while the parameters that contain host IP addresses will continue to use raw unbracketed IPs. Currently gdubreui is assigned to the Puppet side, and he will be making any changes required (if any) to integrate the new netmask6 fact into Puppet while I am on the hook for the TripleO Heat Templates. I'll update this ticket when I have a patchset posted.
Re-attached external tracker [1] fixing the loadbalancer issue by adding proper ipv4/ipv6 interface detection in order to call either ipaddress/netmask or ipaddress6/netmaks6 respectively. Since facter 2.x doesn't have netmask6 a drop-in solution provides the fact. This is the purpose of BZ#1283387 [1] https://review.openstack.org/#/c/245643/
This was initially created on OSP 7 but it needs to target OSP 8
OSP 8 being Liberty, the patch needs to land in master branch first so it can be backported to puppet-trippleo stable/liberty branch.
Comment on attachment 1099075 [details] Archive of netmask6 drop-in solution for facter 2.x The drop-in solution patching Facter 2.x to provide netmask6 facts has been replaced with custom facts. This avoids to patch Facter downstream.
Can't verify until depends on BZ fixed. https://bugzilla.redhat.com/show_bug.cgi?id=1283387
(In reply to Leonid Natapov from comment #21) > Can't verify until depends on BZ fixed. > https://bugzilla.redhat.com/show_bug.cgi?id=1283387 If I recall correctly. The approach used does not rely on bug 1283387, and I don't think that work will be done before GA. Is there a blocking need for that functionality in order to verify the bug?
what are the steps to verify this bug ? I have latest official ospd8 installed and I don't have v6 templates,so i can't deploy ospd8 with ipv6.
openstack-tripleo-heat-templates-0.8.7-2.el7ost.noarch
successfully deployed ipv6 ospd8. openstack-puppet-modules-7.0.15-1.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0603.html