Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for a new architecture #595

Open
aguerra opened this issue Dec 27, 2018 · 1 comment
Open

Suggestion for a new architecture #595

aguerra opened this issue Dec 27, 2018 · 1 comment

Comments

@aguerra
Copy link
Contributor

aguerra commented Dec 27, 2018

Hi everyone, two cents from a former contributor. Keeping up with the kubernetes API (new features, breaking changes, etc) is unfeasible. We also end up duplicating a lot of kubectl code. One approach for teresa 2.0 might be: give kubectl to the developers and somehow implement access control
so each team can only change specific namespaces. Maybe RBAC, maybe an authorization backend, maybe some new k8s feature, etc. This way teresa can be a simple wrapper with sane defaults for kubectl, no more duplication, bumping client-go, etc. About the build process: forget about buildpacks, too complex and have the same problems of bumping, customizing, etc. Each team should be
responsible for creating Dockerfiles (we are in 2018!).That's it, good luck!

@yagonobre
Copy link
Contributor

Teresa can be a admission control/controller to enforce all restriction that teresa do today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants