-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openstack: No neutron dns #1294
openstack: No neutron dns #1294
Conversation
0f9dea0
to
052d28c
Compare
b9fa4a9
to
82d38f9
Compare
/hold cancel |
82d38f9
to
1e0da5d
Compare
1e0da5d
to
e560f45
Compare
/lgtm |
Technically, network names in OpenStack are not unique. We would expect almost every deployment to be using a unique name for its external network, though. In the rare case where you must disambiguate networks, it's possible to specify the UUID via a terraform variable. $ env TF_VAR_openstack_external_network_id="6a32627e-d98d-40d8-9324-5da7cf1452fc" \ > bin/openshift-install create cluster
e560f45
to
d7a4edc
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flaper87, trown The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test e2e-aws |
/retest Please review the full test history for this PR and help us cut down flakes. |
Through c8b3b55 (Merge pull request openshift#1338 from flaper87/sec-groups-update, 2019-05-01). I've left 8d0847c (openstack: Support setting network UUID via terraform variable, 2018-12-05, openshift#794) undocumented, since it seems like an unstable-enough user-facing API approach that I don't think we want to noise it about and deal with the fall-out when we change the API ;). That commit also made it into this history via 44a9cd3 (openshift#1294). I've also left off eecf496 (openstack: remove neutron dns, 2019-02-19, openshift#1294), because I have no idea what that's about ;). I'll fill in an entry for it later once one of the OpenStack devs explains it to me :p.
We've stopped depending on neutron DNS being configured and instead we're fully relying on the CoreDNS instance running on the service VM. This allows us to support more OpenStack clouds, without changing our architecture.