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

NE-226: Support both DNSZone and PrivateDNSZone resources #300

Merged

Conversation

abhinavdahiya
Copy link
Contributor

https://github.com/openshift/api/blob/c4807bb1ed5f3830874a2f78c6acd1235bdbe79c/config/v1/types_dns.go#L55

on Azure currently we use DNSZone resource with type Private to store the DNS records private to the cluster.

There are certain shortcomings with this resource when using type Private

  1. This has been deprecated by Azure for Private DNS Zones preview
  2. This does not allow attaching itself to pre-existing Virtual Networks

The new resource Private DNS Zone solves all the shortcoming of the previous generation and is required for Installing OpenShift in pre-exisiting VNets in Azure.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 20, 2019
@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

@openshift-ci-robot openshift-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Sep 20, 2019
@ironcladlou
Copy link
Contributor

/approve

@abhinavdahiya thanks for this... what's left to do?

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 23, 2019
@abhinavdahiya
Copy link
Contributor Author

/approve

@abhinavdahiya thanks for this... what's left to do?

still doing some test with the PrivateDNSZone resource.

@abhinavdahiya
Copy link
Contributor Author

/retest

@abhinavdahiya
Copy link
Contributor Author

This is what I did to test this change.

$ OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE=registry.svc.ci.openshift.org/ci-op-62nsqh5i/release:latest ./bin/openshift-install --dir dev create manifests

# edit the manifests/cluster-dns-02-config.yml
# to have 
#  privateZone:
#    id: /subscriptions/xxxxxxxxxxxxxxxxxx/resourceGroups/adahiya-4-jhd4v-rg/providers/Microsoft.Network/privateDnsZones/adahiya-4.installer-azure.devcluster.openshift.com
# This will force the cluster-ingress-operator to use the new resource when trying to create DNS records.

$ OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE=registry.svc.ci.openshift.org/ci-op-62nsqh5i/release:latest ./bin/openshift-install --dir dev create cluster

# create a privateDNSZone manually as the installer isn't creating it.

$ oc get dnsrecords.ingress.operator.openshift.io -n openshift-ingress-operator default-wildcard -oyaml
apiVersion: ingress.operator.openshift.io/v1
kind: DNSRecord
metadata:
  creationTimestamp: "2019-09-24T18:52:29Z"
  finalizers:
  - operator.openshift.io/ingress-dns
  generation: 1
  labels:
    ingresscontroller.operator.openshift.io/owning-ingresscontroller: default
  name: default-wildcard
  namespace: openshift-ingress-operator
  ownerReferences:
  - apiVersion: operator.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: IngressController
    name: default
    uid: a9585766-8a5e-406b-919b-732c0cad7d2c
  resourceVersion: "35292"
  selfLink: /apis/ingress.operator.openshift.io/v1/namespaces/openshift-ingress-operator/dnsrecords/default-wildcard
  uid: 181c6c1a-0a08-4e06-96eb-d4ff9d2e8654
spec:
  dnsName: '*.apps.adahiya-4.installer-azure.devcluster.openshift.com.'
  recordTTL: 30
  recordType: A
  targets:
  - 13.89.142.136
status:
  zones:
  - dnsZone:
      id: /subscriptions/433715e6-37fe-4328-af75-3661e13b15fc/resourceGroups/adahiya-4-jhd4v-rg/providers/Microsoft.Network/privateDnsZones/adahiya-4.installer-azure.devcluster.openshift.com
  - dnsZone:
      id: /subscriptions/433715e6-37fe-4328-af75-3661e13b15fc/resourceGroups/os4-common/providers/Microsoft.Network/dnszones/installer-azure.devcluster.openshift.com

# ingress created the record correctly.

$ az network private-dns record-set a list -g adahiya-4-jhd4v-rg --zone-name "adahiya-4.installer-azure.devcluster.openshift.com" -otable
Name    ResourceGroup       Ttl    Type    AutoRegistered    Metadata
------  ------------------  -----  ------  ----------------  ----------
*.apps  adahiya-4-jhd4v-rg  30     A       False

@abhinavdahiya abhinavdahiya changed the title WIP: NE-226: Support both DNSZone and PrivateDNSZone resources NE-226: Support both DNSZone and PrivateDNSZone resources Sep 24, 2019
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 24, 2019
@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

@abhinavdahiya
Copy link
Contributor Author

/retest

}

// New returns an authenticated DNSClient
func New(config Config, userAgentExtension string) (DNSClient, error) {
rsc, err := newRecordSetClient(config, userAgentExtension)
if err != nil {
return nil, errors.Wrap(err, "failed to create newRecordSetClient")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

newRecordSetClientrecordSetClient.


prsc, err := newPrivateRecordSetClient(config, userAgentExtension)
if err != nil {
return nil, errors.Wrap(err, "failed to create newPrivateRecordSetClient")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

newPrivateRecordSetClientprivateRecordSetClient.

@@ -16,5 +18,5 @@ func ParseZone(id string) (*Zone, error) {
if len(s) < 9 {
return nil, errors.New("invalid azure dns zone id")
}
return &Zone{SubscriptionID: s[2], ResourceGroup: s[4], Name: s[8]}, nil
return &Zone{SubscriptionID: s[2], ResourceGroup: s[4], Provider: fmt.Sprintf("%s/%s", s[6], s[7]), Name: s[8]}, nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the structure of the string id documented?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well i couldn't find any documentations around it, but https://docs.microsoft.com/en-us/rest/api/resources/resources/getbyid

has information on the resource id structure.

secondly, i think i have errors for unknown cases, which should be clear to identify when things are out of place.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, maybe I'm misunderstanding, but maybe it has to be okay because we're using IDs instead of tags to address zones generally in Azure. So if that ID format isn't stable, some day we're going to lose track of all our zones. I'm not sure how to assess the stability of the documented ID format.

This PR certainly isn't making the situation worse and there's literally nothing else right now for it to go by.

A regex with named capture groups might at least be more readable at this point, but that's a nit.

If the reliability of ID's format is in question, should we open a parallel investigation into our strategy for addressing Azure zones?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Err, wait a sec, if you have the opaque resource ID, can you not do some versioned API call to get back a resource containing the info we're currently extracting from the ID itself (presumed to be opaque)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can take the ID and request a get using https://docs.microsoft.com/en-us/rest/api/resources/resources/getbyid to get a response..
https://docs.microsoft.com/en-us/rest/api/resources/resources/getbyid#genericresource

but the response doesn't give us any more information that we would need, compared to the already parsing one.

I think for now the resource ID is standard enough like https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/helpers/azure/resourceid.go

that it should be good enough IMO.

@ironcladlou
Copy link
Contributor

Will look at this more closely Monday, thanks.

I'm going to hold it until #301 is merged since it's just about ready.

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 27, 2019
@ironcladlou
Copy link
Contributor

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 30, 2019
@ironcladlou
Copy link
Contributor

@abhinavdahiya looks like just a couple of nits from @Miciah to address and then we can merge this

… zones

Uses the ZoneID to differentiate the type of zone, and calls the corresponding resource-type handler to PUT and DELETE the records.

* creates `recordSetClient` to manage the records for DNSZone resource type.
* creates `privateRecordSetClient` to manage the records for PrivateDNSZone resource type.
* `dnsClient` now picks one of the above based on the Zone's provider
@abhinavdahiya
Copy link
Contributor Author

/test e2e-azure

@abhinavdahiya
Copy link
Contributor Author

abhinavdahiya commented Sep 30, 2019

@abhinavdahiya looks like just a couple of nits from @Miciah to address and then we can merge this

@ironcladlou @Miciah fixed the nits in 0038ee3...5265fad

@abhinavdahiya
Copy link
Contributor Author

/retest

@abhinavdahiya
Copy link
Contributor Author

Also this is blocking installer from moving on https://jira.coreos.com/browse/CORS-1205, so if we can move forward on this for now and come back and improve later on that would be super helpful. @ironcladlou @Miciah

@ironcladlou
Copy link
Contributor

I want to believe there's some API we're just missing that would let us avoid parsing the IDs, but I agree that nobody knows that that would be yet, and the parsing works, and we're already implicitly relying on the parsing even before this change, so let's merge it and move on.

/lgtm
/approve

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

[APPROVALNOTIFIER] This PR is APPROVED

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

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

@openshift-merge-robot openshift-merge-robot merged commit 3c24f65 into openshift:master Oct 7, 2019
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this pull request Oct 8, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this pull request Oct 8, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this pull request Oct 8, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
abhinavdahiya added a commit to abhinavdahiya/installer that referenced this pull request Oct 8, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
alaypatel07 pushed a commit to alaypatel07/installer that referenced this pull request Nov 13, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
jhixson74 pushed a commit to jhixson74/installer that referenced this pull request Dec 6, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300
jhixson74 pushed a commit to jhixson74/installer that referenced this pull request Dec 16, 2019
the ingress-operator can handle the Private DNS Zone since [1]

[1]: openshift/cluster-ingress-operator#300

(cherry picked from commit 7d3119f)
@Miciah
Copy link
Contributor

Miciah commented Jan 7, 2020

/cherrypick release-4.2

@openshift-cherrypick-robot

@Miciah: new pull request created: #344

In response to this:

/cherrypick release-4.2

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.

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.

6 participants