Allow Setting of Deployment Namespace

[daviddyball]

At the moment the agent requires that it exists in cloudability namespace and there is no way to override it.

Can you please make this not a constant value?

[housejester]

I'd love to hear more about your needs. There are a few reasons it currently needs to be in a specific namespace:

• There should only ever be one cloudability agent running in a cluster. Enforcing that gets more complicated if it is allowed to be configured to be in any namespace.
• Putting it in a specific namespace helps to ensure cluster-wide security policies for the agent and ensure the agent can only interact/write resources belonging to the cloudability namespace.
• It isn't intended to run in a namespace with non-agent pods running. Allowing a configurable namespace makes this less clear, and we'd want to at least warn if that is detected.
• Having it be possibly co-located in a namespace with other customer pods isn't something that users are keen on (from feedback, the agent should be as sandboxed as possible). Basically, setting the namespace to something other than cloudability will require a HIGH level of trust and review from the user. Which is probably acceptable if they are opting-in to that.

Given the additional ACL complexity in that case though (ie it would need to be dynamically generated), I'm not sure this would be a high priority unless we can understand your use case better.

Is it an environment where you are locked down to only a certain namespace you are allowed to deploy into? Or is there a namespace naming scheme/policy you are needing to adhere to? Or are you maybe using the agent pointing to your own collector (eg white labeling the agent)?

[daviddyball]

I know you guys do dynamic generation through your interface and pre-seed the customers access keys into the produced manifest and I'm not asking that you change that at all. I just want a way for the actual Go application to accept an override and not rely on a hard-coded value of cloudability.

Nothing would need to change with your template generation for people that don't want to customise it. The app could default to the namespace cloudability unless overridden on the command-line (e.g. --namespace=my-namespace). The issue is that, at the moment, there is no way for us to deploy it to where we want it. We don't have per-app namespaces. We have environment namespaces (e.g. staging, production) and we have an operations namespace that holds all operational deployments.

• There should only ever be one cloudability agent running in a cluster. Enforcing that gets more complicated if it is allowed to be configured to be in any namespace.

We have other services like instana-agent, filebeat and a few others that should only run once-per-cluster and we haven't run into any issues running them in our preferred namespace. We group all of our operational apps into a single namespace which allows easier management and roll-out.

• Having it be possibly co-located in a namespace with other customer pods isn't something that users are keen on (from feedback, the agent should be as sandboxed as possible). Basically, setting the namespace to something other than cloudability will require a HIGH level of trust and review from the user. Which is probably acceptable if they are opting-in to that.

I have no problem with the namespace defaulting to cloudability in the metrics-agent, but it'd be nice to have the option to say --namespace=<NAMESPACE> instead of it being hard-coded so that we can deploy it how we want. Right now it's just not possible.

Given the additional ACL complexity in that case though (ie it would need to be dynamically generated), I'm not sure this would be a high priority unless we can understand your use case better.

I'm not asking you to change the way you're currently doing things for your other customers... I'm just requesting that you make it configurable so that users who do want to customise their deployments can do so.