-
Notifications
You must be signed in to change notification settings - Fork 191
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
NE-226: Support both DNSZone and PrivateDNSZone resources #300
Conversation
/test e2e-azure |
/approve @abhinavdahiya thanks for this... what's left to do? |
still doing some test with the PrivateDNSZone resource. |
/retest |
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 |
c34ce28
to
0038ee3
Compare
/test e2e-azure |
/retest |
pkg/dns/azure/client/client.go
Outdated
} | ||
|
||
// 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") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
newRecordSetClient
→recordSetClient
.
pkg/dns/azure/client/client.go
Outdated
|
||
prsc, err := newPrivateRecordSetClient(config, userAgentExtension) | ||
if err != nil { | ||
return nil, errors.Wrap(err, "failed to create newPrivateRecordSetClient") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
newPrivateRecordSetClient
→privateRecordSetClient
.
@@ -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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
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 |
/hold cancel |
@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
0038ee3
to
5265fad
Compare
/test e2e-azure |
@ironcladlou @Miciah fixed the nits in 0038ee3...5265fad |
/retest |
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 |
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 |
[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 |
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300
the ingress-operator can handle the Private DNS Zone since [1] [1]: openshift/cluster-ingress-operator#300 (cherry picked from commit 7d3119f)
/cherrypick release-4.2 |
@Miciah: new pull request created: #344 In response to this:
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. |
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
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.