RFC-0023: Add CRD and application config unification section

[jerm-dro]

Add a new section addressing how net-new CRD spec types relate to application config structures, motivated by Issue #3125.

Key additions:

• Problem statement covering configuration pipeline complexity, silent bugs from translation layers, documentation divergence, and testing limitations
• Options comparison table contrasting separate vs unified types
• Proposal recommending new CRDs use the same types as application configs, with VirtualMCPServer and MCPTelemetryConfig as examples

Updated for consistency:

• Added #3125 to Related Issues
• Added unified types goal to Goals section
• Updated Summary to mention unified CRD/config types
• Updated Implementation Plan to reflect unified types approach

[blkt]

concern: I don't think this is a good idea.

To give an example, in the Registry Server we support configuring database credentials via postgres password file (pgpass), and any user "manually" deploying the registry server via a plain Kubernetes Deployment has to provide the file with the correct content and mount it in the right place for it to work.

This is not the case for MCPRegistry CRD, where the User can put a reference to a Kubernetes Secret containing the passwords which are then used by the Operator to interpolate the content of the pgpass file which is then mounted transparently, preventing the user to mess with the Pod template spec.

I totally agree with making things more consistent across applications and fixing this at both the level of CRDs and application configs, but I don't think the two things should be exactly the same.

[jerm-dro]

Thanks for the review @blkt.

Let me make sure I understand your concern...

The CRD,MCPRegistry, has some field for referencing pg secrets:

type MCPRegistry struct {
    // PostgresSecret points to a secret containing the credentials to connect to postgres
    // the format is . . . and the secret's data will be mounted as a pgpass file for the
    // MCPRegistry server to consume.
    PostgresSecret SecretRef
}

and the server has some config which indicates where the file is mounted:

type Config struct {
   // PgPassFile is the file name for the pgpass.
   // These credentials are used to connect to postgres.
   PgPassFile string

   // ... other config fields 
}

Your concern is that you don't want to choose one or the other forms. You want to support both. Do I understand correctly?

To address that concern, I agree. I'm not proposing we choose one format over the other. Stepping back we have 3 types:

1. The type within the referenced k8s object. In your example, this is the secret.
2. The CRD which references object in 1. In your example, this MCPRegistry.
3. The server config which is populated by the operator. In the example above, this is Config.

With this PR, I'm trying to say when the operator reads 1 to transform it into a semantically equivalent type for 3, then those types should be the same. There are cases, like yours, where the types are not semantically equivalent and the operator is doing more than translation. Those cases should deviate from the pattern. The proposed Telemetry CRD is a good example that should follow the guidance here, because there's really no difference between 1 and 3.

If this sounds reasonable to you, I can update this PR to clarify when we should/should not use the same types.

[blkt]

I'm sorry I haven't seen the notification for this.
I'm OK if to share structs for shared config like OAuth, telemetry, and such. 👍

[blkt]

I'm sorry I haven't seen the notification for this.
I'm OK if to share structs for shared config like OAuth, telemetry, and such. 👍