The current thinking is to use cupd for the server itself.
Then reserve cup as the name for a local CLI for interacting with an instance of cupd.
The following are some ideas for what this local CLI could support.
cup config
Much like kubectl config we could have some local configuration management.
For example, setting a local context.
Much like how kubectl has a cluster + namespace in its context, we could have a server + source + namespace context.
cup ctl
cup ctl could be considered much like kubectl. It would handle introspection into the resources available and access to the resources themseves. A reflection of the API servers capabilities for the command line.
cup ctl resources
cup ctl get flags
cup ctl list flipt.io/segments
cat resource.yaml | cup ctl put
cup build
This is a long way off idea :bulb:
cup could support packaging Controller implementations.
It could take a Resource Definition file and the identified target WASM binary and package them into an OCI image.
This image could be loaded into some kind of local store to be consumed directly by cup.
It could also be pushed to some target upstream OCI registry for distribution.
The current thinking is to use
cupdfor the server itself. Then reservecupas the name for a local CLI for interacting with an instance ofcupd.The following are some ideas for what this local CLI could support.
cup configMuch like
kubectl configwe could have some local configuration management. For example, setting a localcontext.Much like how
kubectlhas acluster+namespacein its context, we could have aserver+source+namespacecontext.cup ctlcup ctlcould be considered much likekubectl. It would handle introspection into the resources available and access to the resources themseves. A reflection of the API servers capabilities for the command line.cup ctl resourcescup ctl get flagscup ctl list flipt.io/segmentscat resource.yaml | cup ctl putcup buildThis is a long way off idea :bulb:
cupcould support packaging Controller implementations. It could take a Resource Definition file and the identified target WASM binary and package them into an OCI image. This image could be loaded into some kind of local store to be consumed directly by cup. It could also be pushed to some target upstream OCI registry for distribution.