Bump github.com/k8snetworkplumbingwg/network-attachment-definition-client from 0.0.0-20200626054723-37f83d1996bc to 1.7.5

[dependabot]

Bumps github.com/k8snetworkplumbingwg/network-attachment-definition-client from 0.0.0-20200626054723-37f83d1996bc to 1.7.5.

Release notes

Sourced from github.com/k8snetworkplumbingwg/network-attachment-definition-client's releases.

v1.7.5

This release contains a fix related to the determination of the default interface, e.g. setting the default parameter to true in the network-status annotation based on the presence of a gateway in the CNI ADD success result ips.gateway and makes the determination of the default based on the first interface that has an associated value of gateway (using the interface index in the ips element in the CNI ADD success result).

This provides flexibility especially in CRI-O which uses the first interface and IP addresses for the pod.IP in Kubernetes, therefore. Containerd functionality is unchanged in that it uses the value for the IP addresses specifically

It's worth noting that CNI ADD success results which do not contain any interfaces will be discarded in this determination of the default, therefore it's recommended to set one with an associated gateway if aiming to have it be noted as the default.

v1.7.4

This release accounts for CNI plugins which do not use the sandbox field in results when calculating the network-status annotation, doing so for backwards compatibility for plugins which choose to not use this field (such as Calico)

v1.7.3

This release accounts for the sandox interfaces when reporting the interfaces in the network-status annotation; in case the CreateNetworkStatuses clients invoke it with a CNI result featuring non-sandbox interfaces as the first item in the list, this release accounts for that condition.

v1.7.2

When the CreateNetworkStatuses method was created to properly set the network-status annotation when a CNI result includes multiple interfaces in the return, it was found that it when setting the "default" parameter in the network-status, it was setting it to all the returned interfaces to true, which doesn't fit the NPWG net-attach-def specification.

This release fixes that issue by using the first interface in the CNI result set to "default": true for the cluster default network and not the following interfaces.

NOTE Do not use this version, use >= v1.7.3

v1.7.1

Adds the CreateNetworkStatuses method to properly set the network-status annotation when a CNI result includes multiple interfaces in the return.

For details of the before/after, see this gist: https://gist.github.com/dougbtv/1eb8ac2d61d494b56d65a6b236a86e61

For the related suggested update to the NPWG net-attach-def specification (for clarity only), see this proposal @ https://docs.google.com/document/d/1DUTV-o6E6zlRTKZkxeDhAeyGrmq03qPgPbU580Rm7-g/edit

v1.7.0

Adds MTU to network-status

v1.6.0

Adds IPAMClaimReference to network-selection-elements

v1.5.0

What's Changed

• Add NOTICE file for Apache license 2.0 by @​s1061123 in k8snetworkplumbingwg/network-attachment-definition-client#53
• Update venodrs by @​s1061123 in k8snetworkplumbingwg/network-attachment-definition-client#62

New Contributors

Full Changelog: k8snetworkplumbingwg/network-attachment-definition-client@v1.4.0...v1.5.0

v1.4.0

What's Changed

• network-status: add GW info by @​maiqueb in k8snetworkplumbingwg/network-attachment-definition-client#42
• Update DeviceInfo spec to 1.1.0 by @​ykulazhenkov in k8snetworkplumbingwg/network-attachment-definition-client#49

Full Changelog: k8snetworkplumbingwg/network-attachment-definition-client@v1.3.0...v1.4.0

v1.3.0

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dependabot[bot]
Once this PR has been reviewed and has the lgtm label, please assign olliewalsh 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

[openshift-ci]

Hi @dependabot[bot]. Thanks for your PR.

I'm waiting for a openstack-k8s-operators member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.