This repository has been archived by the owner on May 7, 2024. It is now read-only.
Releases: giantswarm/gsctl
Releases · giantswarm/gsctl
gsctl v0.16.2
Minor changes
- The
gsctl create keypair
command now allows to create a kubeconfig pointing to the internal API endpoint. (#435)
gsctl v0.16.1
Bugfixes
- The
gsctl show cluster
command now shows a user-friendly error message again and also exits with code 1 in case the given cluster ID does not exist. (#429)
gsctl v0.16.0
New features
gsctl create cluster
now supports passing cluster definition YAML via standard input. This can save you the step to create a YAML file first. (#421)
Minor changes
- gsctl now provides more user-friendly feedback in the case of TLS problems. (#419)
gsctl info
andgsctl version
now show more build details, including Github links and the commit hash. (#408, #422)- gsctl binaries are now built using Go 1.12.9. (#423)
Bugfixes
gsctl v0.15.4
Bugfixes
- A problem in OIDC authentication, affecting Giant Swarm staff logins, has been fixed. gscliauth#7
gsctl v0.15.3
Minor changes
- The
gsctl completion
command now allows writing to standard output. This way the output can be used with thesource
command, e. g.source $(gsctl completion bash --stdout)
. #379
gsctl v0.15.2
Bugfixes
- Enabled the
gsctl ping
command again which was accidentally disabled in a refactoring effort.
gsctl v0.15.1
gsctl v0.15.0
This release of gsctl focuses on support new API features introduced to enable cluster autoscaling on AWS for releases starting at 6.3.0. (#325)
For more details on autoscaling, please consult our documentation.
Changes
gsctl create cluster
- Two new (optional) flags
--workers-min
and--workers-max
are introduced to set the initial scaling settings for the number of worker nodes in a cluster. The autoscaler will control the number of worker nodes within this range. For AWS releases prior to 6.3.0, and on Azure and KVM, both flags must be set to the same value. As before, once a cluster is created, the worker node count (or the range) cna be influenced usinggsctl scale cluster
. - The flag
--num-workers
can still be used to set the initial cluster size, as an alternative to--workers-min
and--workers-max
. The value given will be applied to both the minimum and maximum cluster size, effectively disabling autoscaling.
- Two new (optional) flags
gsctl scale cluster
- The new flags
--workers-min
and--workers-max
are introduced to set the scaling limits for a cluster. On releases supporting autoscaling (AWS <= 6.3.0), they can be used independent of each other to adjust only the upper or lower limit. - The
--num-workers
/-w
flag can still be used. In releases supporting autoscaling, tis will result in setting the minimum and maximum worker node count to the same value, effectively disabling autoscaling. - The flags
--memory-gb
,--num-cpus
, and--storage-gb
got removed as they were no longer functional
- The new flags
gsctl show cluster
- The new line
Worker node scaling
is added, informing about the current scaling settings. - The new line
Worker nodes running
replaces the formerWorkers
line, informing about the number of worker nodes running. - The new line
Desired worker node count
is shown when the cluster supports autoscaling and the worker node count is not pinned to a specific number. It shows the number of worker nodes the autoscaler attempts to have running currently.
- The new line
gsctl delete cluster
now accepts the ID of the cluster to be deleted as a positional argument. The old-c
/--cluster
flag is deprecated and will be removed in a future gsctl version. (#344, #346)
Bugfixes
- The attempt to delete a cluster that does not exist now yields a user-friendly error message. (#346)
gsctl v0.14.4
Minor changes
- The
gsctl version
command now uses a different URL to detect which is the latestgsctl
version. The URL used bygsctl
until 0.14.3 will only be updated one more time, to inform about this release being available. - The single-sign-on HTML code has been improved for readability.
gsctl v0.14.3
Minor changes
The gsctl show cluster
command now also shows a list of availability zones the cluster is running in. The availability zones get selected randomly.
Note: On AWS the names of availability zones are randomized per account. So eu-west-1a
in the clusters account can be any other availability zone in a different account
Find more information in our docs: https://docs.giantswarm.io/basics/multiaz/