Azure: Allow customer provisioned virtual networks & subnets#2441
Conversation
4deca35 to
8fbef2f
Compare
|
/test e2e-azure |
8fbef2f to
dc252ba
Compare
|
/test e2e-azure |
435177f to
faefead
Compare
|
/test e2e-azure |
jstuever
left a comment
There was a problem hiding this comment.
I had a few questions. I'd also like to see @patrickdillon review considering he did this for gcp.
There was a problem hiding this comment.
Why is this rule only dependent on preexisting_network?
There was a problem hiding this comment.
In Azure, only one network security group can be attached to a vnet. Since we are depending on an existing vnet, we can't create network security groups or network security rules. So if a vnet exists already, we condition this rule (and others) to not be created.
There was a problem hiding this comment.
Can this also be part of the vnet submodule?
There was a problem hiding this comment.
I've placed this here since this is where the vnet resource is created. If we can confirm it can be safely moved, I'll move it.
There was a problem hiding this comment.
Do we really need and/or want to only deploy security groups when not byo vnet?
There was a problem hiding this comment.
Yes, reasoning as described above.
There was a problem hiding this comment.
I don't see where this is used other than output. Perhaps consolidate all into output?
There was a problem hiding this comment.
I now see where it is 'like gcp'. It was used there because the subnet creation was handled in the vpc module. However, here that is done in the main module. This would need to stay if it gets moved down into the vnet module like recommended elsewhere. Otherwise it can be removed and output can use var.virtual_network instead.
|
/cc @patrickdillon |
5078525 to
c20f9bc
Compare
|
/test e2e-azure |
cc42082 to
ff034bd
Compare
|
/test e2e-azure |
ff034bd to
b7832d2
Compare
|
/test e2e-azure |
b7832d2 to
ee2dc6f
Compare
|
/test e2e-azure |
|
/retest |
ee2dc6f to
c9feab7
Compare
|
/test e2e-azure |
c9feab7 to
47374f3
Compare
Add NetworkResourceGroupName, VirtualNetwork, ControlPlaneSubnet, and ComputeSubnet to the Azure platform struct and pass them to terraform. This is the initial implementation, therefore, there is no error checking, isolation, destroying, or terminal prompts. This is for install-config only. For existing virtual networks, the installer will no longer create subnets, route tables, virtual networks and network security groups. https://jira.coreos.com/browse/CORS-1206
47374f3 to
f84c103
Compare
|
/test e2e-azure |
The newtork resources like Virtual Network and Subnets are created currently for each cluster in the cluster's resource group. To support reusing exisitng Virtual network and Subnets for OpenShift clusters, the cluster uses pre-existing ones in a separate resource group. `networkResourceGroupName` is the resource group that contains the Virtual network and subnets for the cluster. The resource group for network resources is the same as cluster unless specifically specified, therefore, this field is optional. This is based on work in PR openshift/installer#2441
|
To test this, I have created the following resources: All resources are created using the jhixson_vnet_rg resource group. I am testing with the following config: platform:
azure:
baseDomainResourceGroupName: os4-common
region: centralus
networkResourceGroupName: jhixson_vnet_rg
virtualNetwork: jhixson_test_vnet
controlPlaneSubnet: jhixson_test_master_subnet
computeSubnet: jhixson_test_worker_subnet
Once the installer is kicked off, I run this script: while true; do
__appid="$(oc --config=${INSTALL_DIR}/auth/kubeconfig \
get credentialsrequests -n \
openshift-cloud-credential-operator \
openshift-machine-api-azure \
-ojsonpath='{.status.providerStatus.appID}{"\n"}')"
if [ -n "${__appid}" ]
then
az role assignment create --resource-group jhixson_vnet_rg --assignee "${__appid}" --role 'Contributor'
exit 0
fi
sleep 5
done
This is a current workaround so that machine-api can read the subnets in the network resource group. I believe there is a PR to fix this by @abhinavdahiya in the works. The install is successful. The install log can be viewed here. |
|
Following the install instructions from #2441 (comment) So to test that service type LoadBalancer is working. Step 1: Create an application from aks-example Step 2: find the LB IPs Step 3: Access the public IP for LB Step 4: Jump on the cluster to access the internal endpoint. This satisfies all the requirements from #2441 (comment) |
|
/test e2e-azure |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, jhixson74 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@jhixson74: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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. |
Add NetworkResourceGroupName, VirtualNetwork, ControlPlaneSubnet, and
ComputeSubnet to the Azure platform struct and pass them to terraform. This is
the initial implementation, therefore, there is no error checking, isolation,
destroying, or terminal prompts. This is for install-config only.
For existing virtual networks, the installer will no longer create route tables, subnets,
virtual networks or network security groups.
https://jira.coreos.com/browse/CORS-1206