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

openshift-ingress: Change namespace and permissions #16

Conversation

Miciah
Copy link
Contributor

@Miciah Miciah commented Jan 19, 2019

Move the cloud-credentials secret from the operand namespace (openshift-ingress) to the operator namespace (openshift-ingress-operator): The operator already has permission to read secrets in its own namespace, but not from its operands', and the cloud-credentials secret is an input to the operator, not an operand, so having the secret in the operator's namespace simplifies RBAC and is more consistent with how we place other resources related to the operator.

Refine the set of permissions for cluster-ingress-operator: The operator needs to be able to look up Route 53 zones using the ListHostedZones and GetResources APIs, list load balancers using DescribeLoadBalancers, update hosted zones using the ChangeResourceRecordSets API, and nothing else.

This PR is related to NE-140.

  • manifests/03-cred-openshift-ingress.yaml: Change the namespace for the secret from openshift-ingress to openshift-ingress-operator.
    Update the permissions to be exactly what cluster-ingress-operator needs.

@ironcladlou

@openshift-ci-robot openshift-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Jan 19, 2019
Move the "cloud-credentials" secret from the operand namespace
("openshift-ingress") to the operator namespace
("openshift-ingress-operator"): The operator already has permission to read
secrets in its own namespace, but not from its operands', and the
"cloud-credentials" secret is an input to the operator, not an operand, so
having the secret in the operator's namespace simplifies RBAC and is more
consistent with how we place other resources related to the operator.

Refine the set of permissions for cluster-ingress-operator: The operator
needs to be able to look up Route 53 zones using the ListHostedZones and
GetResources APIs, list load balancers using DescribeLoadBalancers, update
hosted zones using the ChangeResourceRecordSets API, and nothing else.

This commit is related to NE-140.

https://jira.coreos.com/browse/NE-140

* manifests/03-cred-openshift-ingress.yaml: Change the namespace for the
secret from "openshift-ingress" to "openshift-ingress-operator".
Update the permissions to be exactly what cluster-ingress-operator needs.
@Miciah Miciah force-pushed the NE-140-openshift-ingress-change-namespace-and-permission branch from db6e45e to b78cbd6 Compare January 19, 2019 00:31
@Miciah
Copy link
Contributor Author

Miciah commented Jan 19, 2019

level=error msg="1 error occurred:"
level=error msg="\t* module.vpc.aws_route_table_association.route_net[4]: 1 error occurred:"
level=error msg="\t* aws_route_table_association.route_net.4: timeout while waiting for state to become 'success' (timeout: 5m0s)"

/retest

@dgoodwin
Copy link
Contributor

/lgtm

Thanks Miciah!

Look good to you @ironcladlou ?

/hold

@openshift-ci-robot openshift-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. labels Jan 21, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dgoodwin, Miciah

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-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 21, 2019
@ironcladlou
Copy link

@dgoodwin @Miciah looks fine to me in theory, but since openshift/origin#21617 is still pending we have no automated regression testing. Does this sequence make sense:

  1. Merge Add default wildcard routing e2e test origin#21617 so e2e-aws will exercise ingress DNS management
  2. Expect Use credentials from cloud-credential-operator cluster-ingress-operator#106 to fail (as it depends on this PR)
  3. Merge this PR (Add default wildcard routing e2e test origin#21617 should detect any DNS regressions at this point)
  4. Expect Use credentials from cloud-credential-operator cluster-ingress-operator#106 to begin passing
  5. Merge Use credentials from cloud-credential-operator cluster-ingress-operator#106

Future changes to cloud-credentials-operator which could impact ingress DNS management should then be tested via e2e-aws.

@dgoodwin
Copy link
Contributor

Sounds good to me. Just cancel the hold when you're ready.

@Miciah
Copy link
Contributor Author

Miciah commented Jan 21, 2019

@ironcladlou, your plan looks fine.

@ironcladlou
Copy link

/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 Jan 30, 2019
@openshift-merge-robot openshift-merge-robot merged commit df8cdda into openshift:master Jan 30, 2019
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/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants