Open ademariag opened 5 years ago
recorded gist of our conversation in faq: https://github.com/k14s/kapp/blob/develop/docs/faq.md#where-to-store-app-resources-ie-in-which-namespace
marking this as wontfix for now. may be we will circle back to this eventually.
I still think this is one of the only real shortcomings of kapp. It should have an option to manage the namespace and create and destroy it automatically. It should destroy it when the last app in the namespace is destroyed.
We also might need an annotation on the namespace as well and with the current setup I think you'd need to do that using kubectl.
related in a way: https://github.com/k14s/kapp/issues/112
Relevant slack thread here: https://kubernetes.slack.com/archives/CH8KCCKA5/p1563362345098000
On a newly created cluster, with only default namespaces, I am attempting to install a new application in the
demo
namespace.My workflow until now was to create a context pointing to the
demo
namespace and apply the resources. (i.e. DEMO_CONTEXT)Example namespace resource
Error
When applying a simple
namespace
usingkapp
pointing toDEMO_CONTEXT
, kapp fails with:Possible explanation
kapp
seems unable to handle a context pointing to a yet-to-be-created namespace. Possibly because if needs to store some state there?Workaround
using a context pointint to a different namespace, i.e.
default
, kapp is able to create the application successfullyUnfortunately, if after this bootstrap process we revert to using the original DEMO_CONTEXT,
kapp
finds a mismatch in the app ownershipThe only solution then becomes to force import the app
--dangerous-override-ownership-of-existing-resources