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:
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.
Created attachment 1056693 [details] Attached: Example undercloud.conf.sample shipped Attaching undercloud.conf.sample used with 192.0.2.x addressing scheme.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
(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.