Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Definition for new Terraforming/Infrastructure/Fleet Management service #7

Open
1 task
davidffrench opened this issue Feb 9, 2022 · 0 comments
Open
1 task
Assignees

Comments

@davidffrench
Copy link
Contributor

davidffrench commented Feb 9, 2022

Context

Terraforming and infrastructure management is a common concern for all fleet managers that use a bin packed data plane deployment topology. A shared service would ensure consistency and reliability with data plane cluster fleet management and scaling.

The high-level idea for the API is to achieve:

  • Policy endpoint that allows API users to define the structure of their managed service dataplane cluster (e.g. what should be included in terraforming - addons, resources etc)
  • Capacity Pool endpoint which allows API users to likely define some restrictions around their capacity pool. Minimum, maximum clusters etc

These are rough ideas above about how this might work. As spikes are completed, this Epic should become more concrete.

User Narrative

Joe, a development lead from ProductA has been tasked with turning it into a managed service, running on a managed OpenShift offering. Joe knows that this new managed service will colocate separate customers service instances on the same managed OpenShift cluster.

Joe hears about the Infrastructure fleet manager, which suits this bin packed deployment topology perfectly. Joe creates a blueprint for his managed service and instantiates a fleet of clusters created using his blueprint in a specific cloud provider and region.

Job Stories

  • As a SaaS developer, I want to define the blueprint for my SaaSs data plane cluster, so the data plane fleet can be created in a consistent and reliable way.
  • As a Saas developer, I would prefer the blueprint to be cloud provider agnostic, so that I only have to define one blueprint for my data plane.
  • As a Saas developer, I want to define machinepools and node sizes within my blueprint, so that I can provision services on different node sizes.
  • As a SaaS developer, I want an observability stack and my custom observability resources included in each data plane cluster, so that the service instances can be managed by an SRE team.
  • As a SaaS developer, I want the ability to create a pool of my SaaSs data plane clusters from a defined blueprints version, so that I can start provisioning service instances
  • As a SaaS developer, I want the ability to update the blueprint for my SaaSs data plane cluster with versioning, so that I can update the blueprint used for cluster pools independently.
  • As a SaaS developer, I want to retrieve the clusters from my SaaSs data plane cluster pools, so that I can choose where to provision service instances.
  • When a given data plane cluster's available compute resources have fallen below a threshold, I want the number of nodes scaled in the cluster, so I can continue to provision service instances.
  • When a given data plane cluster has reached my defined maximum capacity, I want a new data plane cluster added to the cluster pool, so I can continue to provision service instances.

Analysis

(links to analysis docs containing architecture design work, requirements gathering, etc)

Task List

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

No branches or pull requests

2 participants