pkg/tfvars/aws: Drop custom subnets #698
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This functionality was originally from 8324c21 (AWS: VPC subnets with custom CIDRs and AZs per workers / masters, 2017-04-20, coreos/tectonic-installer#267), but we haven't exposed it in openshift-install (which has never used the parsers removed by f7a4e68, pkg/types/config: Drop ParseConfig and other Parse* methods, 2018-10-02, openshift#403). Currently we are unable to scale masters post-install, because auto-scaling etcd is difficult. Depending on how long that takes us to get working, we may need to re-enable this for masters later. Workers are already managable via the cluster API and MachineSets, so folks who need custom worker subnets can create a cluster without workers and then launch their worker machine-sets directly as a day-2 operation. The cluster-API type chain is: * MachineSet.Spec [1] * MachineSetSpec.Template [2] * MachineTemplateSpec.Spec [3] * MachineSpec.ProviderConfig [4] * ProviderConfig.Value [5] * RawExtension which is nice and generic, but a dead-end for structured configuration ;). Jumping over to the OpenShift AWS provider, there is an AWSMachineProviderConfig.Subnet [6]. I don't see code for auto-creating those subnets, but an admin could manually create the subnet wherever they wanted and then use the cluster API to launch new workers into that subnet. And maybe there will be generic tooling to automate that subnet creation (setting up routing, etc.) to make that less tedious/error-prone. Also in this space, see [7,8] [1]: https://github.com/kubernetes-sigs/cluster-api/blob/0734939e05aeb64ab198e3feeee8b4e90ee5cbb2/pkg/apis/cluster/v1alpha1/machineset_types.go#L42 [2]: https://github.com/kubernetes-sigs/cluster-api/blob/0734939e05aeb64ab198e3feeee8b4e90ee5cbb2/pkg/apis/cluster/v1alpha1/machineset_types.go#L68-L71 [3]: https://github.com/kubernetes-sigs/cluster-api/blob/0734939e05aeb64ab198e3feeee8b4e90ee5cbb2/pkg/apis/cluster/v1alpha1/machineset_types.go#L84-L87 [4]: https://github.com/kubernetes-sigs/cluster-api/blob/0734939e05aeb64ab198e3feeee8b4e90ee5cbb2/pkg/apis/cluster/v1alpha1/machine_types.go#L62-L64 [5]: https://github.com/kubernetes-sigs/cluster-api/blob/0734939e05aeb64ab198e3feeee8b4e90ee5cbb2/pkg/apis/cluster/v1alpha1/common_types.go#L29-L34 [6]: https://github.com/openshift/cluster-api-provider-aws/blob/e6986093d1fbac2084c50b04fe2f78125ffca582/pkg/apis/awsproviderconfig/v1alpha1/awsmachineproviderconfig_types.go#L130-L131 [7]: kubernetes/kops#1333 [8]: https://github.com/kubernetes-sigs/cluster-api/blob/0734939e05aeb64ab198e3feeee8b4e90ee5cbb2/pkg/apis/cluster/v1alpha1/cluster_types.go#L62-L82
openshift-ci-robot
added
the
size/M
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: wking 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 |
openshift-ci-robot
added
the
approved
wking
force-pushed
the
drop-new-subnet-configs
branch
from
0178f20 to
efbc74c
Compare
|
@wking: PR needs rebase. 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-robot
added
the
needs-rebase
|
@wking: The following test 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. 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. |
|
This was covered by #654. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This functionality was originally from 8324c21 (coreos/tectonic-installer#267), but we haven't exposed it in
openshift-install(which has never used the parsers removed by f7a4e68, #403).Currently we are unable to scale masters post-install, because auto-scaling etcd is difficult. Depending on how long that takes us to get working, we may need to re-enable this for masters later.
Workers are already managable via the cluster API and
MachineSets, so folks who need custom worker subnets can create a cluster without workers and then launch their worker machine-sets directly as a day-2 operation. The cluster-API type chain is:MachineSet.SpecMachineSetSpec.TemplateMachineTemplateSpec.SpecMachineSpec.ProviderConfigProviderConfig.ValueRawExtensionwhich is nice and generic, but a dead-end for structured configuration ;). Jumping over to the OpenShift AWS provider, there is an
AWSMachineProviderConfig.Subnet. I don't see code for auto-creating those subnets, but an admin could manually create the subnet wherever they wanted and then use the cluster API to launch new workers into that subnet. And maybe there will be generic tooling to automate that subnet creation (setting up routing, etc.) to make that less tedious/error-prone.Also in this space, see kubernetes/kops#1333 and here.