A suggestion to have a capsule cli tool would be cool.

Describe the feature

create a capsulectl cli tool to view, create, edit, delete tenants

@donhighmsft thanks for your interest in Capsule. May be we’re missing something but we do not see any reason for such cli. You can view, edit, create, and delete tenants by kubectl. One of the key guidelines for developing Capsule was to give the users a native Kubernetes experience while dealing with tenants. Unlike other solutions for multi tenancy in Kubernetes, with Capsule, you do not have to use custom binaries or plugins. Anyway, if we’re missing something, please let us know your thoughts.

@bsctl Makes Sense. I was thinking for many users who just want to add tenants, view tenants, change tenant resources only who are not kubernetes experts. Which many users may not be, just an option for the average it guys thats not devops experts. Say Alice for example who just want to onboard her team but new to kubernetes she just want to put resource limits on her tenants etc. Right now capsule is assuming that everyone is a high level kubernetes expert. I know many small startups and ISV's who need multi-tenancy in Kubernetes but don't know all the in and outs on Ingress Controllers etc

@donhighmsft good point of view. For such people we’re developing a nice UI based on the awesome Lens project https://github.com/clastix/capsule-lens-extension please have a look.

@bsctl that same UI can fuel the capsulectl same api calls etc. Use cobra, ffcli, kong, etc. I love Lens but for the average user can be overwhelming when I just want to onboard tenants and group many of my namespaces.

that same UI can fuel the capsulectl same api calls etc

Actually, capsule is baked just by the Custom Resource Definition: it means all the API calls are towards the Kubernetes Control Plane. We don't have the API aggregation in place, which would require a more cumbersome development effort, although providing more flexibility and additional subresources (as the default /status one).

I'm trying to step down from my deep understanding of Capsule and having some difficulties trying to find a real use-case of a possible capsulectl. One of the reasons we were thinking of it was the listing of the Tenant namespaces, solved in a smarter way thanks to capsule-proxy.

I just want to onboard tenants and group many of my namespaces

Are you referring to attach already created Namespaces to a Tenant? This could be interesting. Can you provide a sort of a real use-case as a user story?

@prometherion yes I'm talking about attached already created Namespaces to Tenant. Many customers will not be Kubernetes experts but maybe be in charge of creating Tenants, Namespaces, Resource Quotas, Resource Limits. They just want a tool see all of that quickly or add quickly. The cli should do one thing specific to Capsule.

Thanks for sharing these requirements but I'm not still understanding them properly.

As @bsctl said,m since Capsule is (ab)using underlying Kubernetes primitives, most of the actions can be performed using the Kubernetes tools, e.g.creating a Namespace as alice user (kubectl create namespace my-namespace --as alice --as-group capsule.clastix.io).

Many customers will not be Kubernetes experts but maybe be in charge of creating Tenants, Namespaces (...)

I'd say a strong requirement if you want to use Capsule as a Cluster Administrator is a deep and broad experience managing Kubernetes and its resources. Different story for the Tenant Owner since you just need to use the right credentials and issue kubectl create namespace.

(...) Resource Quotas, Resource Limits

There's the OpenAPI Specification for these, as well the scheme validation mechanism put in place by the API Server, but I think I'm getting your point, especially for the NetworkPolicy: these APIs could be cumbersome and hard to grok since they're the building blocks to establish a multi-tenancy in the Kubernetes cluster, and aren't idiomatic.

A possible solution that could be put in place to help with these struggles is a sort of template generator for the Tenant YAML, a CLI tool that asks for all the fields using a human discussion (sic) for the underlying objects needed for the multi-tenancy scenario.

An example could be the following:

1. What's the name of the Tenant you'd like to create? oil
2. Is it managed by a Group/User? y/n
3. Type the Group/User name: myorgname/alice
4. Should Network segregation put in place through NetworkPolicy resources? y/n
5. Define the first NetworkPolicy: should egress communication allowed to any CIDR? y/n
6. Define the first NetworkPolicy: should the egress communication blocked to specific CIDRs? y/n ...
7. Please, insert the path where to save the Capsule Tenant manifest: /opt/capsule/tenants/oil.yaml

Is it something you could think useful for Capsule newbies?

There's the OpenAPI Specification for these, as well the scheme validation mechanism put in place by the API Server, but I think I'm getting your point, especially for the NetworkPolicy: these APIs could be cumbersome and hard to grok since they're the building blocks to establish a multi-tenancy in the Kubernetes cluster, and aren't idiomatic.

Exactly what I was thinking as well @prometherion capsulectl cli to help the newcomers of capsule and kubernetes. Let me tell you a true story in the last 2 weeks, I must of talked to 5 Startups and ISV's who I mentioned Capsule and/or Proposed Capsule as an option over other tools like HNS, Virtual Clusters Loft, or Who Doesn't Need a full blown Rancher Cluster. Rancher has this functionality inside it, it's called Projects very useful for Multi-Tenant ISVs and Startups. This CLI would be awesome for those companies and would be a Quicker transition. If it becomes more adopted then create more functionality.

Start with the basics K.I.S.S method.

• yaml capsule generator/validator
• view current tenants
• check Networkpolices for the tenant
• check ingresses for the tenant

Thanks for all the useful insights, as I said, really appreciated it.

Although these features could be useful to onboard users with the Capsule domain logic, we are already focusing our energy on the Lens extensions that allows, using UI, to understand better all the moving parts involved.

I'm not saying we should not focus also on a CLI, but since we're understaffed from the maintainers' perspective, we have to cleverly select the area we have to work and improve: our backlog, although not yet public, is full of features and some of them are highly demanded by the early adopters, but definitely, we can try to schedule (or at least, document) this feature request.

@prometherion I understand thats what the community is for. I would love to help out in the future and contribute to the capsulectl efforts. We should just document what a MVP looks like.