Can me make the image version a const? I think it's fine to have the server version compiled into the operator controller to ensure compatibility but it should be easy to upgrade when we want to release a new version

I can update this.

This is where I think the complexity is for managing the grpc server as part of the controller. The porter config that this uses HAS to be the porter config that the installations used when running so that means it needs to use the porter config for the namespace. We put the restriction in the only allow a single porter config per namespace instead of a porter config to be defined for every installation. The operator sets up a default config if one doesn't exist. This service should be using the porter config that's applied to the namespace, either the default one or the user provided one. It also has to track if that PorterConfig ever changes and then reload with the new config so that it can hit the backing stores where the installations actually live.

Btw @schristoff we should add support for moving porter storage data from one backend to another. This will "just work" for secrets as long as the secrets are managed externally for the new store like they should be but for storage backend AFAIK there's no way to move from one DB to another if that changes in the porter config and we should definitely support that!

The porter config that this uses HAS to be the porter config that the installations used when running so that means it needs to use the porter config for the namespace. We put the restriction in the only allow a single porter config per namespace instead of a porter config to be defined for every installation. The operator sets up a default config if one doesn't exist. This service should be using the porter config that's applied to the namespace, either the default one or the user provided one. It also has to track if that PorterConfig ever changes

That means we can't do this implementation because this is trying to install the grpc server before we even do an installation. If the installation needs to happen to success to then create a deployment/configmap/service to get the Porter config in the namespace, (that resource isn't created until something makes it get created) then we will have to do that after the first installation. Relying on the default Porter config at runtime seems a little tricky as that default is making assumption around the installation resource process.

What I can do is move this to be done once at setup during the first installation and dynamically create the configmap that will map to the porter config by the installation we have in the namespace once the installation is complete.

This is really interesting because of how the Porter config gets resolved for an AgentAction:

We probably need to create a "default" grpc server in the operator namespace then have namespace specific servers IF a PorterConfig is specified for that namespace BUT not for the system..... This just feels gross.... But the resolvePorterConfig should be able to handle checking if a grpc server exists that will be able to handle the AgentAction based on the PorterConfig that is selected to run that AgentAction

This is already defined in controllers/installation_controller.go