Add option to set extensible attributes necessary for cloud infoblox instances to infoblox provider

[staerion]

Description

Added flags to the infoblox provider in order to set the mandatory "extensible attributes" required for infoblox using a "cloud network automation" setup. The MR proposes to:

• Add three separate flags for the three mandatory extensibile attributes that need to be sent to the infoblox api when the "cloud network automation" feature is enabled.
• Accept all extensible attribute flags only as strings.
• Only include the extensible attributes in the infoblox api calls when they are explicitly set and not empty.

Fixes https://github.com/kubernetes-sigs/external-dns/issues/3582

Checklist

• [x] Unit tests updated
• [x] End user documentation updated (N/A imo)

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: staerion (41c2231f0a333e5ed300de2f539294ee8813d5a8)

[k8s-ci-robot]

Welcome @staerion!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. :smiley:

[jastBytes]

Is there something we can do here to get this thing on the road?

[johngmyers]

The author needs to rebase and address the review comment.

[staerion]

I'll rebase and see what I can do with the suggestion.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: staerion Once this PR has been reviewed and has the lgtm label, please assign njuettner for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[johngmyers]

How is an administrator to figure out what values to supply for these three settings?

[staerion]

How is an administrator to figure out what values to supply for these three settings?

Normally these values don't have to be set. They are mandatory for cloud api requests and at that point the values required are decided based on the cloud provider used. The attributes are described by infoblox here and here.

I have created an issue that I linked in this MR that explains our use case and with links to the infoblox documentation.

[johngmyers]

The Infoblox documentation is not clear at all. The linked issue says almost nothing about the use cases.

I can't even find a definition of "CMP". Is external-dns the CMP? Does it have its own value for "CMP Type"? Is external-dns the "Cloud API"? Is there a reason we shouldn't always send a "Cloud API Owned" value of always "True" or always "False" (possibly only if there's a Tenant ID)?

[staerion]

The definitions for the extensible attributes are here: https://docs.infoblox.com/space/nios85/35785430/Extensible+Attributes+for+Cloud+Objects. For example:

CMP Type | String | This is read-only. Defines the type of CMP, such as VMware or OpenStack.

CMP itself is an abbreviation for Cloud Management Platform. So in our use case, we'd have external-dns running on AKS and would assign "CMP" the value of "azure".

The use case is simply that when using infoblox with a "Cloud Network Automation" setup (https://www.infoblox.com/wp-content/uploads/CNA-Quick-Start.pdf) you have the supply these three attributes. Without the attributes the request will be denied. From my experience so far, these attributes can be seen as metadata added to the dns records.

I think it's a valid option to always set "Cloud API Owned" to true in case the TenantID is present. Downsides would be that we don't know how infoblox will treat these attributes in the future and as a user it could be confusing at first that you can only set two out of three mandatory attributes. If that is an acceptable tradeoff I'm happy to convert the string to boolean.

[mloiseleur]

I think it's a valid option to always set "Cloud API Owned" to true in case the TenantID is present. Downsides would be that we don't know how infoblox will treat these attributes in the future and as a user it could be confusing at first that you can only set two out of three mandatory attributes. If that is an acceptable tradeoff I'm happy to convert the string to boolean.

I understood the three attributes were mandatory : Cloud API Owned, TenantID and CMP Type. So wdyt about setting Cloud API Owned to true in case both TenantID and CMP Type are present ?

[staerion]

I think it's a valid option to always set "Cloud API Owned" to true in case the TenantID is present. Downsides would be that we don't know how infoblox will treat these attributes in the future and as a user it could be confusing at first that you can only set two out of three mandatory attributes. If that is an acceptable tradeoff I'm happy to convert the string to boolean.

I understood the three attributes were mandatory : Cloud API Owned, TenantID and CMP Type. So wdyt about setting Cloud API Owned to true in case both TenantID and CMP Type are present ?

Personally I think it's a fair solution, but I don't know how @johngmyers feels about it.

[k8s-ci-robot]

PR needs rebase.

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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-sigs/prow repository.