Did you build a list of all deprecated fields to grep for? Just curious how your script works. Can you share it in a branch or gist? It's fine if it's super-hacky, just want to get a better idea of what I should be trying to validate.

Deprecated fields in examples were updated by hand (I did build a list of deprecated fields via grep first). I can share the script I used for updating v2 messages/fields/types/enums to v3 ones though.

Gist with the script (pretty hacky!): https://gist.github.com/dmitri-d/e5957de963d7e51004f4fce2ba82a383

See my other comment about how this can be less manual in the future, but if there is anything we should commit for future use let's definitely do that.

@dmitri-d is there some place you grepped out a list of all the deprecated field names and then checked to see if any still exist in docs? I realize there could be many false positives, but this would give me confidence that we haven't missed any (dot-the-Is, cross-the-Ts).

For the new fragments that you wrote, did you verify they worked in some kind of test harness, e.g. that this load assignment would parse? It looks reasonable, but, would be reassuring to have some kind of machine check.

Long term we want #8837, but that's outside the scope of this PR; I'd be reassured if at least they were known to parse as valid at least once.

I did not, agree it would be a good idea.

Ping on this one. I think it would be good to at least verify one example of each kind of change you've made to ensure there isn't typo/subtle failure. What you could do is take https://github.com/envoyproxy/envoy/blob/master/configs/google_com_proxy.v2.yaml and copy+paste in fragments with some surrounding context, verify it can be loaded with envoy -c. I don't think we need anything beyond that.

Is this a tractable amount of work or is it going to be too crazy?

See my other comment about how this can be less manual in the future, but if there is anything we should commit for future use let's definitely do that.