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

Way to describe dependency/definition content from kubectl #16

Open
pigmej opened this issue Aug 16, 2016 · 4 comments
Open

Way to describe dependency/definition content from kubectl #16

pigmej opened this issue Aug 16, 2016 · 4 comments

Comments

@pigmej
Copy link
Contributor

pigmej commented Aug 16, 2016

Currently we can just get objects that were created using 3rd party resource. For better UX we should be able to describe them too.

This issue is not strictly bound to AppController itself, but it really improves UX of it.

It requires improvements in kubectl for 3rd party resources.

@bgrant0607
Copy link

Is there a reason why you chose to use ThirdPartyResource rather than annotations?

@pigmej
Copy link
Contributor Author

pigmej commented Sep 3, 2016

@bgrant0607 Initially we wanted to use annotations but then we discovered that 3rd party resources are better for us. The reason is simple, to separate deps from k8s object definitions. It allows to modify deps without touching k8s object definition. It adds some complexity obviously. The more complex scenario the more natural that separation is. It also makes unified UX for existing and new objects.

@nebril
Copy link
Contributor

nebril commented Sep 5, 2016

@bgrant0607 the problem with annotations is that it requires an object to annotate. If we created a pod, it would be too late to annotate it with it's dependencies, because it would already be created and running.

@pigmej
Copy link
Contributor Author

pigmej commented Feb 21, 2017

kubernetes/community#122

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

3 participants