Provision shared instance of Central API cluster

[joshmue]

As a SCS contributor, I want to have access to an central API instance so that evaluate it and do testing against it.

435 discusses a long running community cluster for people to do testing with. Even though, sometimes, the discussion also was about using it for the central API approach, now it is meant for shared operation of some (testing) workloads.

This issue is concerned about setting up a shared Kubernetes cluster which implements multi tenancy and access to openstack resources, in order to test out these mechanics with other SCS contributor groups. These mechanisms would ultimately be intended for customer tenants in actual production environments.

Epic: #364

Definition of Ready:

• [ ] User Story is small enough to be finished within one sprint
• [ ] User Story is clear and understood by the whole team
• [ ] Acceptance criteria are defined
• [ ] Acceptance criteria are clear and understood by the whole team

Definition of Done:

• [ ] All acceptance criteria are met
• [ ] Changes have been reviewed
• [ ] CI tests have run successfully
• [ ] Documentation has been updated
• [ ] Release Notes have been updated

[joshmue]

The general direction on how to deploy such cluster is already discussed here: https://github.com/SovereignCloudStack/central-api/pull/3

IIRC: Basically the only thing that is blocking me here, is that it is not defined how the default automation should look like, nor where the line between CSP-specific automation and general automation is drawn.

Polar options:

1. Only define central-api characteristics; let CSP's make their own decisions how to integrate into their existing infrastructure; do not provide general automation at all
2. Leave little to no need for any CSP-specific automation; Almost everything should be covered by the opinionated general automation

Between these opposite options, there is some middle ground. Nevertheless, offloading as much work as possible from CSP's, potentially reducing duplicated efforts, should be the main driving factor, I guess.

IIRC, we once wanted to discuss that in a (SIG?) call. Right, @fkr?

We could also proceed with just a simple bootstrapping script with OpenStack API access for now.

[joshmue]

IIRC: Basically the only thing that is blocking me here, is that it is not defined how the default automation should look like, nor where the line between CSP-specific automation and general automation is drawn.

People present in the last SIG call did not have strong opinions in that regard. Consensus was to just go ahead with what works for now.