└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | # KAPI - kubernetes CRDs for CF APIs
 2 | 
 3 | Hi. This is a proof-of-concept/spike to see what it would look like to
 4 | replicate the CF v3 APIs with Kubernetes CRDs.
 5 | 
 6 | # (Potential) Goals
 7 | 
 8 | - See whether we can support existing CF APIs on top of CRDs
 9 | - See whether we can use Eirini as a control loop from "Kapi" CRDs to k8s
10 | - See whether we can implement an org/space style model with RBAC
11 | - Experiment with whether it's better to do a CLI using k8s apis or with a wrapper around CRDs
12 | - Determine what an "MVP" would look like for this to avoid boiling the ocean
13 | 
14 | # Non-Goals
15 | 
16 | - Actual production code. This is a dirty rotten spike.
17 | 
18 | # What might success look like?
19 | 
20 | - end-to-end cf v3-push via cli (potentially wrapping kubectl, against CAPI api wrapper around CRDs), resulting in working statefulsets (probably via eirini)
21 | 
22 | # How does/would KAPI differ from Knative/StatefulSets/Deployments
23 | 
24 | KAPI apis are *PaaS* APIs. This means they are high-level (packages, droplets,
25 | builds, apps, processes, services, bindings) and do not talk about "containers", 
26 | "images" etc (other than permitting an optional "image" package/droplet type). 
27 | 
28 | Under the covers the KAPI APIs may end up being mapped to containers or statefulsets
29 | or knative kservices etc but this should happen in the Operator (eirini), rather
30 | than being exposed in the KAPI CRDs.
31 | 


--------------------------------------------------------------------------------