Bug 1247286

Summary: rhos-d uses non-RFC1918 address schemes, possible external conflicts
Product: Red Hat OpenStack Reporter: Will Foster <wfoster>
Component: rhosp-directorAssignee: Hugh Brock <hbrock>
Status: CLOSED WONTFIX QA Contact: Shai Revivo <srevivo>
Severity: unspecified Docs Contact:
Priority: medium    
Version: DirectorCC: dsneddon, jcoufal, mburns, rhel-osp-director-maint
Target Milestone: ---   
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-14 20:38:13 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:
Embargoed:
Attachments:
Description Flags
Attached: Example undercloud.conf.sample shipped none

Description Will Foster 2015-07-27 17:44:14 UTC 
Description of problem:

In undercloud.conf and other places non-RFC1918 address ranges are used for private networks.  This can cause problems as these networks are associated with ARIN for testing (or may be allocated externally).  The network ranges in question are 192.0.2.0 based.

Please use an RFC1918 address range:
https://en.wikipedia.org/wiki/Private_network

Examples:

whois 192.0.2.0
[Querying whois.iana.org]
[whois.iana.org]
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

inetnum:      192.0.2.0 - 192.0.2.255
organisation: IANA
status:       assigned

remarks:      http://www.iana.org/go/rfc5737

source:       IANA

dig 0.192.in-addr.arpa ns

; <<>> DiG 9.10.2-P2-RedHat-9.10.2-3.P2.fc22 <<>> 0.192.in-addr.arpa ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60507
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.192.in-addr.arpa.		IN	NS

;; AUTHORITY SECTION:
192.in-addr.arpa.	10800	IN	SOA	z.arin.net. dns-ops.arin.net. 2015062452 1800 900 691200 10800




Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 3 Will Foster 2015-07-27 17:59:19 UTC 
Adding, 192.0.2 is reserved via IANA as a "testnet" used for documentation.
http://tools.ietf.org/html/rfc5737

192.0.2.0/24        TEST-NET-1                 RFC 5737

"The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation."

For undercloud deployments or internal purposes this type of range shouldn't be used, we should stick to RFC1918 allotment.
Comment 4 Will Foster 2015-07-27 18:06:56 UTC 
Created attachment 1056693 [details]
Attached: Example undercloud.conf.sample shipped

Attaching undercloud.conf.sample used with 192.0.2.x addressing scheme.
Comment 6 Mike Burns 2016-04-07 20:47:27 UTC 
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 8 Dan Sneddon 2016-10-14 20:38:13 UTC 
(In reply to Will Foster from comment #4)
> Created attachment 1056693 [details]
> Attached: Example undercloud.conf.sample shipped
> 
> Attaching undercloud.conf.sample used with 192.0.2.x addressing scheme.

I disagree that we are misusing the network 192.0.2.x as the default in our ctlplane configuration. The whole reason this range was chosen is that it is for documentation and examples. We definitively do not want people deploying in production with 192.0.2.x, so the default is actually intended to encourage people to choose their own subnet. Perhaps we could do a better job documenting that.

This is in contrast to the isolated networks, where we chose 172. addresses specifically to indicate that they are private, and the defaults may be used as-is.

If there were a similar "example" network available that would be a good fit for the External network default (currently 10.0.0.0/24), I would prefer to use that, because this is another network that we intend for people to customize.