-
Notifications
You must be signed in to change notification settings - Fork 828
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
prow-build-canary-cluster: provisioning scripts #5063
prow-build-canary-cluster: provisioning scripts #5063
Conversation
/assign @pkprzekwas |
/hold After discussing with @xmudrii , I want to refactor this a bit. |
infra/aws/terraform/prow-build-cluster/tfbackends/canary.tfbackend
Outdated
Show resolved
Hide resolved
infra/aws/terraform/prow-build-cluster/tfbackends/prod.tfbackend
Outdated
Show resolved
Hide resolved
/unhold |
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.
Just two nits, otherwise LGTM.
data "aws_availability_zones" "available" {} | ||
|
||
locals { | ||
canary_prefix = terraform.workspace != "prod" ? "canary-" : "" |
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.
we want to be consistent about prefixes added:
canary_prefix = terraform.workspace != "prod" ? "canary-" : "" | |
canary_prefix = terraform.workspace != "prod-" ? "canary-" : "" |
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.
I also prefer we have a prefix
variable defining the environment.
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.
I was thinking about that, but unfortunately we haven't planned that in advance. The production cluster has been already created and introducing prod-
prefix would require re-provisioning.
|
||
# Recognize federated identities from the prow trusted cluster | ||
resource "aws_iam_openid_connect_provider" "k8s_prow" { | ||
count = terraform.workspace == "prod" ? 1 : 0 |
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.
we are not creating a OIDC provider for the canary env ?
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.
No, we don't have Prow on the canary environment. We use it only for testing infra changes, not Prow changes. That would require some additional effort if we want to go that route.
vpc_intra_subnet = ["10.5.0.0/18", "10.5.64.0/18", "10.5.128.0/18"] | ||
|
||
# Ubuntu EKS optimized AMI: https://cloud-images.ubuntu.com/aws-eks/ | ||
node_ami = "ami-03de35fda144b3672" |
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.
we should replace this with a data resource.
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.
I personally prefer binding the AMI. If we query the AMI, the node group is going to recreated each time there's a new AMI. That can affect running tests. We might want to be able to do run terraform apply
without actually having to rotate nodes.
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.
I don't have strong opinion here. In case we want to keep this AMI hardcoded we need to think about its update schedule. AWS releases new AMIs pretty often.
Thank you for working on this! My understanding is that we'll use the same AWS account for prod and canary clusters, which I'm not sure is the desired state. I believe that account isolation can help us reduce security risks associated with access. |
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.
/lgtm
/approve
/hold
for @ameukam to take a look
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pkprzekwas, xmudrii 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 |
/lgtm |
/hold cancel |
As we started migrating Prow jobs to EKS Prow, applying infrastructure changes on that cluster became risky. For that reason, here are changes for conditionally provisioning canary cluster.
This new cluster is meant for:
Can be considered as part of #4686
/assign @xmudrii @ameukam