Bug 1283387 - Fact required for IPv6 Compatibility For TripleO
Fact required for IPv6 Compatibility For TripleO
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: facter (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
high Severity high
: async
: 7.0 (Kilo)
Assigned To: Mike Burns
: Triaged, ZStream
: 1282328 (view as bug list)
Depends On:
Blocks: 1289834
  Show dependency treegraph
 
Reported: 2015-11-18 15:48 EST by Dan Sneddon
Modified: 2017-07-24 13:06 EDT (History)
13 users (show)

See Also:
Fixed In Version: facter-2.4.3-2.el7
Doc Type: Bug Fix
Doc Text:
Previously, facter did not fully provide facts for IPv6 addresses. As a result, the netmask6 and netmaks6_<interface> facts were missing. With this update, the 'netmask6' family of facts are added to Facter 2.x. This updates lib/facter/util/ip.rb, lib/facter/util/netmask.rb, and lib/facter/interfaces.rb files. As a result, facter returns netmask for default IPv6 address and IPv6 interfaces with an IPv6 address.
Story Points: ---
Clone Of:
: 1289834 (view as bug list)
Environment:
Last Closed: 2016-02-08 10:13:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Archive of netmask6 drop-in solution for facter 2.x (4.52 KB, application/x-gzip)
2015-11-25 21:25 EST, Gilles Dubreuil
no flags Details
Patch (3.39 KB, patch)
2015-12-04 09:59 EST, Lon Hohberger
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 249793 None None None Never

  None (edit)
Description Dan Sneddon 2015-11-18 15:48:30 EST
Description of problem:
Current version family of Facter 2.4 doesn't entirely support IPv6

Version-Release number of selected component (if applicable):
facter.x86_64                      2.4.3-1.el7

The netmask6 facts are missing.

This can be reproduced:
1. Install facter
# yum install -y facter

2.By default IPv6 is active and at least the loopback interface (::1) should be set:
# ip addr show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever


3. Try to obtain a netmask6 fact
# facter netmask6_lo

Actual results:
Nothing is returned

Expected results:
# facter netmask6_lo
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Additional Information:
This is fixed in Facter 3+, but that is not currently available in RHEL or Fedora. We may need to add Facter 3 to the OpenStack repositories to cover this requirement.
Comment 2 Dan Sneddon 2015-11-18 15:49:03 EST
*** Bug 1282328 has been marked as a duplicate of this bug. ***
Comment 4 Dan Sneddon 2015-11-19 14:53:26 EST
From an email from Martin Magr:

-----
  sadly I never did facter packaging before, so I have no time estimation for you right now. Considering there is not Facter3 package even in Fedora world it may take some time. IIRC there has been some backend changes between v2 and v3, so maybe even build process will have to be changed.

From BZ it seems like you're just missing a fact. I'll investigate if it would not be possible to backport the netmask6 fact (please comment the BZ if there are more facts you are missing) to 2.4 facter. Hopefully it will be easy backport work. Unfortunately it is already EOD today for me, but I'll start with it tomorrow and let you know the status as soon as I will know it. 
-----

Gilles, can you confirm that netmask6 is the only missing fact that we need (at least the only one we know about so far)?
Comment 5 Gilles Dubreuil 2015-11-19 17:04:09 EST
This BZ was marked as a duplicate of BZ#1282328. This is not correct, one is for RDO and this one for RHOS/OSP. Therefore I've reopened the other BZ.


Facter 3+ facts
---------------
There are many new facts in Facter 3.

Facter 3.1 contains much more facts than Facter 2.4:
http://docs.puppetlabs.com/facter/2.4/core_facts.html
https://docs.puppetlabs.com/facter/3.0/core_facts.html

Also the facts are now structured by default (still accessible the standard way)

Also Facter 3.1 is the recommended version to use for the Puppet open source version while Facter 4.1 is the one for Puppet Enterprise 3.8


Backporting
-----------

I'm not sure netmask6 can be backported to 2.4, seems like there are many issues around ipv6 and some of them might be structural. 

On the long run we need to get going with Facter 3 anyway.

Build
----- 

It might effectively take a while until Fedora/EPEL repos provides Facter3, this is why, as we have been doing before, make the package available as part of Openstack Repos.

Note: To build latest Facter version 3.1.1, I had to use Fedora because it requires boost version >= 1.54
Comment 7 Dan Sneddon 2015-11-19 17:24:54 EST
(In reply to Gilles Dubreuil from comment #5)

> I'm not sure netmask6 can be backported to 2.4, seems like there are many
> issues around ipv6 and some of them might be structural. 

Looking at the missing facts (everything about IPv6 apart from ipaddress6), I think you're right. Especially looking at this comment in the Facter 2.4 documentation:
----------
ipaddress6

Purpose:
Returns the “main” IPv6 IP address of a system.

Resolution:
OS-dependent code that parses the output of various networking tools and currently not very intelligent. Returns the first non-loopback and non-linklocal address found in the ouput unless a default route can be mapped to a routable interface. Guessing an interface is currently only possible with BSD-type systems; too many assumptions have to be made on other platforms to make this work with the current code. Most of this code is ported or modeled after the ipaddress fact for the sake of similar functionality and familiar mechanics.
----------


This will certainly not be a complete enough implementation to do what we need, especially since we will have multiple IPv6 addresses, and mapping the an IP to an interface is exactly what we need to do. By contrast, in Facter 3 we have the ipaddress6_<interface> fact:

----------
ipaddress6_<interface>

This legacy fact is hidden by default in Facter’s command-line output.

Type: ip6

Purpose:

Return the IPv6 address for a network interface.
----------
 
So unless all of the IPv6 internals can be backported over from Facter 3 to Facter 2.4, I think we need to push forward with rolling Facter 3 + dependencies for the OpenStack repos.

> On the long run we need to get going with Facter 3 anyway.
> 
> Build
> ----- 
> 
> It might effectively take a while until Fedora/EPEL repos provides Facter3,
> this is why, as we have been doing before, make the package available as
> part of Openstack Repos.
> 
> Note: To build latest Facter version 3.1.1, I had to use Fedora because it
> requires boost version >= 1.54

OK. Unfortunately, boost has a whole collection of subpackages that would also need to be bumped to satisfy this dependency:

boost-python-0:1.53.0-23.el7.x86_64
boost-atomic-0:1.53.0-23.el7.x86_64
boost-context-0:1.53.0-23.el7.i686
boost-signals-0:1.53.0-23.el7.i686
boost-math-0:1.53.0-23.el7.x86_64
boost-random-0:1.53.0-23.el7.i686
boost-system-0:1.53.0-23.el7.i686
boost-test-0:1.53.0-23.el7.x86_64
boost-signals-0:1.53.0-23.el7.x86_64
boost-random-0:1.53.0-23.el7.x86_64
boost-regex-0:1.53.0-23.el7.x86_64
boost-program-options-0:1.53.0-23.el7.i686
boost-timer-0:1.53.0-23.el7.i686
boost-chrono-0:1.53.0-23.el7.i686
boost-locale-0:1.53.0-23.el7.i686
boost-serialization-0:1.53.0-23.el7.i686
boost-system-0:1.53.0-23.el7.x86_64
boost-iostreams-0:1.53.0-23.el7.x86_64
boost-iostreams-0:1.53.0-23.el7.i686
boost-program-options-0:1.53.0-23.el7.x86_64
boost-wave-0:1.53.0-23.el7.i686
boost-atomic-0:1.53.0-23.el7.i686
boost-filesystem-0:1.53.0-23.el7.i686
boost-locale-0:1.53.0-23.el7.x86_64
boost-test-0:1.53.0-23.el7.i686
boost-graph-0:1.53.0-23.el7.i686
boost-date-time-0:1.53.0-23.el7.i686
boost-timer-0:1.53.0-23.el7.x86_64
boost-date-time-0:1.53.0-23.el7.x86_64
boost-math-0:1.53.0-23.el7.i686
boost-wave-0:1.53.0-23.el7.x86_64
boost-python-0:1.53.0-23.el7.i686
boost-regex-0:1.53.0-23.el7.i686
boost-thread-0:1.53.0-23.el7.i686
boost-serialization-0:1.53.0-23.el7.x86_64
boost-chrono-0:1.53.0-23.el7.x86_64
boost-thread-0:1.53.0-23.el7.x86_64
boost-graph-0:1.53.0-23.el7.x86_64
boost-context-0:1.53.0-23.el7.x86_64
boost-filesystem-0:1.53.0-23.el7.x86_64
Comment 8 Dan Sneddon 2015-11-19 19:30:08 EST
It looks like these are the only boost packages that are in use in OSP:

boost-filesystem.x86_64         1.53.0-23.el7       @rhos-7.0-pmgr-rhel-7-signed
boost-program-options.x86_64    1.53.0-23.el7       @rhos-7.0-pmgr-rhel-7-signed
boost-system.x86_64             1.53.0-23.el7       @rhos-7.0-pmgr-rhel-7-signed
boost-thread.x86_64             1.53.0-23.el7       @rhos-7.0-pmgr-rhel-7
Comment 9 Martin Magr 2015-11-20 09:16:13 EST
Ok, so Facter-3 is complete rewrite [1] from Ruby to C++. Considering the implementation changes, backporting netmask6* facts are indeed not possible.

As was written in the comment #7, to build and support Facter3 we would need to update and support boost, but also cmake package [2]. 

Also please consider, that we still use puppet-3.6.2-3.el7 in RDO, which I'm not sure can co-operate with new Facter, which basically means to support Puppet-4 in RDO too.

Note that there are indeed ipaddress6_<interface> facts in Facter-2.4 too. So in case you are missing only netmask6 together with netmask6_<interface> facts now, we still can implement those facts in Ruby and make them part of puppet-tripleo. 


[1] https://docs.puppetlabs.com/facter/3.0/release_notes.html#facter-300
[2] https://github.com/puppetlabs/facter/tree/3.1.2#build-requirements
Comment 10 Dan Sneddon 2015-11-20 13:17:07 EST
(In reply to Martin Magr from comment #9)

> Note that there are indeed ipaddress6_<interface> facts in Facter-2.4 too.
> So in case you are missing only netmask6 together with netmask6_<interface>
> facts now, we still can implement those facts in Ruby and make them part of
> puppet-tripleo. 

Where did you find ipaddress6_<interface> in Facter 2.4? This isn't in the documentation, is it actually implemented but not documented?
Comment 14 Gilles Dubreuil 2015-11-22 23:14:45 EST
The ipaddress6_<interface> is documented here:
https://docs.puppetlabs.com/facter/2.0/core_facts.html
Comment 22 Martin Magr 2015-11-25 08:51:30 EST
Please check attached puppet-tripleo patch as quickfix for required functionality.
Comment 25 Gilles Dubreuil 2015-11-25 21:25 EST
Created attachment 1099076 [details]
Archive of netmask6 drop-in solution for facter 2.x

The netmask6 facts provided by the attached archive are the facter 2.x files to replace/add.
Comment 28 Gilles Dubreuil 2015-12-04 01:08:04 EST
The initial title mentioning Facter 3+ was confusing.

Effectively Facter 2.x doesn't contain netmask6 and that cannot be back-ported from Facter 3 because the latter is a complete reimplementation in C++.

This is why on the long run, outside of this bug scope, Facter 3 needs to be added to RHEL OSes, please use BZ#1285600 as tracker.

Meanwhile the netmask6 facts are available for facter 2 as a drop-in solution, see attached "Archive of netmask6 drop-in solution for facter 2.x".
Comment 29 Gilles Dubreuil 2015-12-04 01:10:34 EST
*** Bug 1282328 has been marked as a duplicate of this bug. ***
Comment 32 Lon Hohberger 2015-12-04 09:59 EST
Created attachment 1102313 [details]
Patch
Comment 37 Gilles Dubreuil 2015-12-15 00:39:57 EST
This bug must be closed because:

1. Patching Facter 2.x is not always possible for channels like RDO (unless Facter package is added to it)

2. Avoiding patching downstream is preferable since the process is heavy.

Therefore another solution has been found, as part of the related BZ#1280523,
which provides the needed Facter facts as custom facts included into the involved module puppet-tripleo.

The downstream patch created so far for OSP7 must be removed.
Comment 38 Mike Burns 2015-12-15 07:29:02 EST
Lon, is this even possible? or are we too late in 7.0.3?

Note You need to log in before you can comment on or make changes to this bug.