List view
- No due date•2/2 issues closed
- No due date
- No due date
- No due date
- No due date
- No due date•13/13 issues closed
- No due date•13/13 issues closed
- No due date•14/14 issues closed
- Overdue by 3 year(s)•Due by November 17, 2021
Initial Giant Swarm Cluster API (CAPI) release for VMware with feature alignment between Giant Swarm clusters and Cluster API clusters. This is alpha quality and only intended for testing. There is no migration path to or from this release. We should have a decision on all features part of our Giant Swarm clusters. Such a decision could be: already implemented; will be implemented within this milestone; will be implemented at a later point in time (which milestone, TBD); optional feature (not on the critical path; might be implemented if we have customers using it); dropped feature (we don't want to support it anymore; migration path might be needed if we have customers using it); What should be part of this milestone? feature alignment (see above); cluster creation; cluster deletion; cluster access; cluster monitoring (metrics & dashboards) cluster alerting, with the option to disable it per cluster (also, useful for our existing clusters to improve oncall experience and flexibility); cluster workload access (DNS, load balancers); use flatcar;
No due date•5/5 issues closedFirst GS CAPI release for Azure.
No due dateThird GS CAPI release for Azure with a migration path from GS clusters to CAPI clusters and upgrades. This is a release candidate only intended for use with test clusters.
No due date•2/2 issues closedSecond GS CAPI release for Azure with a migration path from GS clusters to CAPI clusters. This is beta quality and only intended for testing. There is no migration path from this release.
No due date•2/4 issues closedInitial Giant Swarm Cluster API (CAPI) release for Azure with feature alignment between Giant Swarm clusters and Cluster API clusters. This is alpha quality and only intended for testing. There is no migration path to or from this release. We should have a decision on all features part of our Giant Swarm clusters. Such a decision could be: - already implemented; - will be implemented within this milestone; - will be implemented at a later point in time (which milestone, TBD); - optional feature (not on the critical path; might be implemented if we have customers using it); - dropped feature (we don't want to support it anymore; migration path might be needed if we have customers using it); What should be part of this milestone? - feature alignment (see above); - cluster creation; - cluster deletion; - cluster access; - cluster monitoring (metrics & dashboards) - cluster alerting, with the option to disable it per cluster (also, useful for our existing clusters to improve oncall experience and flexibility); - cluster workload access (DNS, load balancers); - use flatcar;
No due date•1/1 issues closedThird GS CAPI release for AWS with a migration path from GS clusters to CAPI clusters and upgrades. This is a release candidate only intended for use with test clusters.
No due date•1/2 issues closedFirst GS CAPI release for AWS.
No due dateSecond GS CAPI release for AWS with a migration path from GS clusters to CAPI clusters. This is beta quality and only intended for testing. There is no migration path from this release.
No due date•3/4 issues closedInitial Giant Swarm Cluster API (CAPI) release for AWS with feature alignment between Giant Swarm clusters and Cluster API clusters. This is alpha quality and only intended for testing. There is no migration path to or from this release. We should have a decision on all features part of our Giant Swarm clusters. Such a decision could be: - already implemented; - will be implemented within this milestone; - will be implemented at a later point in time (which milestone, TBD); - optional feature (not on the critical path; might be implemented if we have customers using it); - dropped feature (we don't want to support it anymore; migration path might be needed if we have customers using it); What should be part of this milestone? - feature alignment (see above); - cluster creation; - cluster deletion; - cluster access; - cluster monitoring (metrics & dashboards) - cluster alerting, with the option to disable it per cluster (also, useful for our existing clusters to improve oncall experience and flexibility); - cluster workload access (DNS, load balancers); - use flatcar;
No due date•1/2 issues closed