Skip to content
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

Use PrivateDNSZones instead of DNSZones type Private for clusters #2470

Merged

Conversation

abhinavdahiya
Copy link
Contributor

terraform/exec/plugins: add embedded 'azureprivatedns' provider to handle private_dns zone

Using the upstream azurerm provider is not possible for now because of following reasons:

  1. There is not srv record resource for private dns zone

  2. The version of provider that has the private dns zone resources 1.34.0 has a lot of bugs like

    Another reason moving to 1.36.0 which might have all the fixes we need is the provider has moved to using
    standalone terraform plugin SDK v1.1.1 azurerm-sdk-bump. Because we vendor both terraform and providers, this causes errors like
    panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType

    Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere

A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.

data/azure: use azureprivatedns provider to create private records

Using the Private DNS Zone also allows us to remove our previous hack

More information in individual commits.

@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

@openshift-ci-robot openshift-ci-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Oct 8, 2019
@abhinavdahiya
Copy link
Contributor Author

Missing capability for handle Private DNS Zone and its records blocks @jhixson74 Azure bring your own work as the current DNS Zone type Private has restrictions that it cannot be attached to a Vnet that already has resources attached.

ERROR Error: Error creating/updating DNS Zone "farfymcfarf.installer.azure.devcluster.openshift.com" (Resource Group "farfymcfarf-f7qpl-rg"): dns.ZonesClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="BadRequest" Message="Virtual networks that are non-empty (have Virtual Machines or other resources) are not allowed during association with a private zone."

@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

@abhinavdahiya
Copy link
Contributor Author

/retest

@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

…ndle private_dns zone

Using the upstream azurerm provider is not possible for now because of following reasons:

1) There is not srv record resource for private dns zone

2) The version of provider that has the private dns zone resources `1.34.0` has a lot of bugs like
    * hashicorp/terraform-provider-azurerm#4452
    * hashicorp/terraform-provider-azurerm#4453
    * hashicorp/terraform-provider-azurerm#4501
    Some of these bugs are fixed, and some are in flight.

    Another reason moving to `1.36.0` which might have all the fixes we need is the provider has moved to using
    `standalone terraform plugin SDK v1.1.1` [1]. Because we vendor both terraform and providers, this causes errors like
    `panic: gob: registering duplicate types for "github.com/zclconf/go-cty/cty.primitiveType": cty.primitiveType != cty.primitiveType`

   Therefore, we would have to move towards a single vendor for terraform and plugins for correct inter-operation, which is tricker due to conflicts elsewhere

A simple 4 resource plugin that re-uses the already vendored azurerm provider as library and carries over the required resources seems like an easy fix for now.

[1]: hashicorp/terraform-provider-azurerm#4474
Using the Private DNS Zone also allows us to remove our previous hack [1]

[1]: openshift@8ac9ab4
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
… deleting public records

Updates the destroy to look for both DNS Zones type Private and Private DNS Zones to find the private records and the corresponding DNS Zone type Public.

Since the zone name for both types of private dns zone is the same, we can try both to calculate the private records and then re-use the same codepath to delete the public records.
@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

@abhinavdahiya
Copy link
Contributor Author

So azure was green https://prow.svc.ci.openshift.org/view/gcs/origin-ci-test/pr-logs/pull/openshift_installer/2470/pull-ci-openshift-installer-master-e2e-azure/211

yay!

/assign @jhixson74

@abhinavdahiya
Copy link
Contributor Author

/retest

1 similar comment
@abhinavdahiya
Copy link
Contributor Author

/retest

@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Oct 8, 2019

@abhinavdahiya: The following tests failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/prow/e2e-openstack 65111a0 link /test e2e-openstack
ci/prow/e2e-aws-scaleup-rhel7 65111a0 link /test e2e-aws-scaleup-rhel7

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@abhinavdahiya
Copy link
Contributor Author

/test e2e-aws

/test e2e-azure

@jhixson74
Copy link
Member

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 8, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, jhixson74

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants