Instead of removing this entirely, can we infer cody.enabled = completions.enabled and mark this old configuration as deprecated? This way when we upgrade an instance, Cody won't be momentarily disabled

This way when we upgrade an instance, Cody won't be momentarily disabled

How many customers are affected by this? And with "momentarily" you mean the time between "upgraded" and "admin added cody.enabled", right?

And with "momentarily" you mean the time between "upgraded" and "admin added cody.enabled", right?

Yep!

How many customers are affected by this?

This is pretty surprisingly high number for me but we have 32 Cloud customers with Cody enabled that may all be affected by this change:

$ mi2 instance list -expr 'Spec.Application.Cody?.Enabled == true' | jq length             
32

Should this be nested? e.g.

cody {
  enabled
  restrictUsersFeatureFlag
}

this could be convenient for grouping Cody-related config

I personally think top-level fields are easier to manage than nested ones and I'm also copying relatively recent additions to site-config like these:

https://github.com/sourcegraph/sourcegraph/blob/d3587f514877cf957a5c0a36494bcfc8125b550f/schema/site.schema.json#L644-L715

Because the case I want to optimize for is

{
  "cody.enabled": true
}

That seems much nicer to me (I know: hard arguments here) than:

{
  "cody": {
    "enabled": true
  }
}

(If we had a webform instead of a JSON editor and people wouldn't have to edit this manually, that's fine)

Fair enough, we have precedence for both :)

Potential downside I've seen is that sometimes customer's don't sort the keys alphabetically so in a large site config, at a glance it's easy to miss that some facet of a particular group of config is set/not set