Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Milestones

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 closed
  • First GS CAPI release for Azure.

    No due date
  • Third 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 closed
  • Second 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 closed
  • Initial 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 closed
  • Third 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 closed
  • First GS CAPI release for AWS.

    No due date
  • Second 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 closed
  • Initial 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