Bug 1247286 - rhos-d uses non-RFC1918 address schemes, possible external conflicts
rhos-d uses non-RFC1918 address schemes, possible external conflicts
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
Unspecified Unspecified
medium Severity unspecified
: ---
: 10.0 (Newton)
Assigned To: Hugh Brock
Shai Revivo
Depends On:
  Show dependency treegraph
Reported: 2015-07-27 13:44 EDT by Will Foster
Modified: 2016-10-14 16:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-10-14 16:38:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached: Example undercloud.conf.sample shipped (5.10 KB, text/plain)
2015-07-27 14:06 EDT, Will Foster
no flags Details

  None (edit)
Description Will Foster 2015-07-27 13:44:14 EDT
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 based.

Please use an RFC1918 address range:


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

inetnum: -
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

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

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:

Actual results:

Expected results:

Additional info:
Comment 3 Will Foster 2015-07-27 13:59:19 EDT
Adding, 192.0.2 is reserved via IANA as a "testnet" used for documentation.
http://tools.ietf.org/html/rfc5737        TEST-NET-1                 RFC 5737

"The blocks (TEST-NET-1), (TEST-NET-2),
and (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 14:06:56 EDT
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 16:47:27 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 8 Dan Sneddon 2016-10-14 16:38:13 EDT
(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, I would prefer to use that, because this is another network that we intend for people to customize.

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