Quota Management

[spjmurray]

OpenStack will start off with some rather paltry quota defaults which will not allow anything at decent scale.

We absolutely must not just set them to -1, as if CAPO goes wild it will DoS the system and possibly affect other users.

We know requested cluster geometry when its crated or updated, so can tailor the quotas to suit. As such we need some APIs to allow this information to be set in the cloud identity by the Kubernetes service for starters.

As an aside, we need to allow a little wiggle room, as rolling upgrades and general failure management will add additional nodes in before removing old ones to maintain minimum capacity.

[spjmurray]

Note: this is almost definitely going to need some policies adding

[spjmurray]

Note: it's probably best for the API to say "service X needs N of flavor Y, ..." this fulfills a couple requirements:

• Doesn't make the management at the cluster layer too onerous beyond what's already available to the cluster definition
• Doesn't expose stuff that's unnecessary
• The eagle eyed of you will notice the service is important...
  • I can feel in my heart there will be a requirement that kubernetes and baremetal exist in the same "virtual cluster"
  • 2 ways to pull this off
  • keep them separate and wang an IPSEC s2s tunnel in there, which requires coordination of IP address ranges, is slow and error prone, but it does keep quotas separate
  • allow then to share an identity/physical network, thus treating them a bit like a VPC, but this does give rise to the problem of split brain, with services fighting over quotas