The doc following projects has the theme of constraints.
Here's a simple example of how to constrain the output generated by a project. The platform team could add the constraint at projects/httpbin/constraints.cue and the development team is able to create directories via the projects/httpbin/components/OWNERS file, for example adding the projects/httpbin/components/backend/backend.cue component.
We're likely going to need to re-work the core BuildPlan definition to make
this ergonomic, for example adding one top level spec.resources field for
platform teams to constrain, but that can come later, the versioned api and
schema/core packages should make it pretty straight forward to do without
impacting users too badly. They should just need to bump from v1alpha3 to
v1alpha4 in the root schema.cue file of their repo, no other code changes
should be necessary. Hopefully.
diff --git a/components/namespaces/namespaces.cue b/components/namespaces/namespaces.cue
index a6cc0f2..0f6e4b0 100644
--- a/components/namespaces/namespaces.cue
+++ b/components/namespaces/namespaces.cue
@@ -3,7 +3,13 @@ package holos
let Objects = {
Name: "namespaces"
Resources: Namespace: #Namespaces
+ Resources: Jeff: jeff: metadata: name: "jeff"
}
// Produce a kubernetes objects build plan.
(#Kubernetes & Objects).BuildPlan
+
+// Constrain what can be managed from the project.
+#AllowedResources: Namespace: _
+
+spec: components: kubernetesObjectsList: [{apiObjectMap: #AllowedResources}]
The doc following projects has the theme of constraints.
Here's a simple example of how to constrain the output generated by a project. The platform team could add the constraint at
projects/httpbin/constraints.cue
and the development team is able to create directories via theprojects/httpbin/components/OWNERS
file, for example adding theprojects/httpbin/components/backend/backend.cue
component.We're likely going to need to re-work the core BuildPlan definition to make this ergonomic, for example adding one top level
spec.resources
field for platform teams to constrain, but that can come later, the versioned api and schema/core packages should make it pretty straight forward to do without impacting users too badly. They should just need to bump from v1alpha3 to v1alpha4 in the rootschema.cue
file of their repo, no other code changes should be necessary. Hopefully.This constraint results in: