Provide flexibility of installing calico in an existing namespace as oppose calico-system namespace

[tigera]

Provide flexibility of installing calico in an existing namespace as oppose calico-system namespace

[tmjd]

Some organizations require calico to be installed in an existing namespace.

You could pre-create the calico-system namespace and the operator will happily take ownership of that namespace.

It is general best practice to put components with separate responsibilities in their own namespace so it is a good idea to have a dedicated namespace for calico and the operator is a bit opinionated in that way, with that being said I'm not sure what the use case would be that a namespace other than calico-system would be needed. We've even taken care to build into the operator the ability for it to seamlessly migrate an older calico manifest installation which used the kube-system namespace to the operator based installation, I thought I would mention that incase you were concerned with migration from an older install.

Could you expand on what the use case is that you need the calico components in a different namespace?

[tmjd]

Without more details on the use case that makes this required I don't think we would move forward with a change like this so I'm closing this issue. If more details are added we can re-open the issue.

[scbunn]

with that being said I'm not sure what the use case would be that a namespace other than calico-system would be needed

We have targeted OPA/Gatekeeper polices and depend on namespaces having particular prefixes. For our particular use case it would be better to have the ability to install into kube-system then calico-system which does not match any of our known patterns

In general I think it's best to leave things like namespaces up to the end user to decide.