OCPSTRAT-660: AWS Shared VPC [release-4.12]

[patrickdillon]

4.12 backport of #1529

Adds a field to the DNS config to hold a role to assume when performing cross-account installs in an AWS shared VPC environment.

[openshift-ci-robot]

@patrickdillon: This pull request references OCPSTRAT-660 which is a valid jira issue.

Details

In response to this:

4.12 backport of #1529

Adds a field to the DNS config to hold a role to assume when performing cross-account installs in an AWS shared VPC environment.

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.

[openshift-ci]

Hello @patrickdillon! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

[patrickdillon]

cc @gcs278

[gcs278]

@patrickdillon thanks - looks like there is an verify failure on verify-update-codegen-crds. I'll vendor it in a NE PR once that is worked out.

[patrickdillon]

@patrickdillon thanks - looks like there is an verify failure on verify-update-codegen-crds. I'll vendor it in a NE PR once that is worked out.

hah! yeah I was waiting to dm you in slack until I fixed this. forgot I cc'd you in gh.

Hopefully this push fixed it.

[patrickdillon]

When I run make update locally I'm getting some extra CRDs, which, if included, break the verify-update-codegen-crds test. Two examples:

$ git diff
diff --git a/example/v1alpha1/0000_50_notstabletype-techpreview.crd.yaml b/example/v1alpha1/0000_50_notstabletype-techpreview.crd.yaml
index 263f945f..f5c352b6 100644
--- a/example/v1alpha1/0000_50_notstabletype-techpreview.crd.yaml
+++ b/example/v1alpha1/0000_50_notstabletype-techpreview.crd.yaml
@@ -64,19 +64,30 @@ spec:
                       message:
                         description: message is a human readable message indicating details about the transition. This may be an empty string.
                         type: string
+                        maxLength: 32768
                       observedGeneration:
                         description: observedGeneration represents the .metadata.generation that the condition was set based upon. For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance.
                         type: integer
                         format: int64
+                        minimum: 0
                       reason:
                         description: reason contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field, and whether the values are considered a guaranteed API. The value should be a CamelCase string. This field may not be empty.
                         type: string
+                        maxLength: 1024
+                        minLength: 1
+                        pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
                       status:
                         description: status of the condition, one of True, False, Unknown.
                         type: string
+                        enum:
+                          - "True"
+                          - "False"
+                          - Unknown
                       type:
                         description: type of condition in CamelCase or in foo.example.com/CamelCase. --- Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be useful (see .node.status.conditions), the ability to deconflict is important. The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
                         type: string
+                        maxLength: 316
+                        pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$
                   x-kubernetes-list-map-keys:
                     - type
                   x-kubernetes-list-type: map
diff --git a/machine/v1beta1/0000_10_machine.crd.yaml b/machine/v1beta1/0000_10_machine.crd.yaml
index fc67ec1e..4b968e51 100644
--- a/machine/v1beta1/0000_10_machine.crd.yaml
+++ b/machine/v1beta1/0000_10_machine.crd.yaml
@@ -175,6 +175,7 @@ spec:
                           uid:
                             description: 'UID of the referent. More info: http://kubernetes.io/docs/user-guide/identifiers#uids'
                             type: string
+                        x-kubernetes-map-type: atomic
                 providerID:
                   description: ProviderID is the identification ID of the machine provided by the provider. This field must match the provider ID as seen on the node object corresponding to this machine. This field is required by higher level consumers of cluster-api. Example use case is cluster autoscaler with cluster-api as provider. Clean-up logic in the autoscaler compares machines to nodes to find out machines at provider which could not get registered as Kubernetes nodes. With cluster-api as a generic out-of-tree provider for autoscaler, this field is required by autoscaler to be able to have a provider view of the list of machines. Another list of nodes is queried from the k8s apiserver and then a comparison is done to find out unregistered machines and are marked for delete. This field will be set by the actuators and consumed by higher level entities like autoscaler that will be interfacing with cluster-api as generic provider.
                   type: string

	modified:   machine/v1beta1/0000_10_machinehealthcheck.yaml
	modified:   machine/v1beta1/0000_10_machineset.crd.yaml

have the same diff as the last example, adding: + x-kubernetes-map-type: atomic

[patrickdillon]

/hold
While we investigate #1551 (comment)

[patrickdillon]

/hold cancel
Joel pointed me to make -C tools clean codegen which resolved any doubts about this issue. Ready to merge.

[deads2k]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, patrickdillon

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [deads2k]

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

[sdodson]

Adding jira/valid-bug for this approved feature backport.

[openshift-ci]

@patrickdillon: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.