tarmak
tarmak copied to clipboard
jetstack
Flexible instance types
What this PR does / why we need it: Although users are already able to chose their own instance types, this validates the supported types and restricts the types available to master
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #310
NONE
This adds some validation to the instance types and restricts the master instance types. /cc @MattiasGees What do you think?
I tested this and this works great. I encountered one problem. When we use the default settings we assign to the instances atm we get verification errors due to small instance types :). So I think we should adjust that.
Currently we set etcd to small and vault to tiny which translates to an t2.medium and t2.nano.
For etcd I would switch the default to an m5.large but for vault I am not sure we should go that big as we only request SSL certs from time to time and don't do anything heavy on it.
I have bumped up etcd instances to use medium (m4.large) as default at init. I think there should be some consensus though on these sizes and what vault should have / be burstable.
@JoshVanL I discussed this a bit with @simonswine. We agreed that denying of certain instance types shouldn't happen.
As for development environments we can see it happen that you run way less and that a burst-able type could work. We agreed instead of giving an error that a warning like It is not advised to use t2.nano for etcd would be better. Is that something we can implement in an easy way?
@JoshVanL I tried bringing up a cluster with smallest instances for etcd and master, but couldn't see any warnings displayed. So I think there is something wrong with the warning logger.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: To fully approve this pull request, please assign additional approvers. We suggest the following additional approver: simonswine
If they are not already assigned, you can assign the PR to them by writing /assign @simonswine in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@JoshVanL: 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.
@JoshVanL: The following test failed, say /retest to rerun them all:
| Test name | Commit | Details | Rerun command |
|---|---|---|---|
| tarmak-puppet-module-tarmak-acceptance-1-14-centos | 650ca81fd07f1cf9cc32cf28244d11feb041be25 | link | /test puppet-tarmak-acceptance-centos v1.14 |
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.