Clear up status and role of state-into-spec field

[SammyGoogles]

Describe your question

Hello,

As GCP support is getting questions about the role, deployment, and security concerns involving the state-into-spec field, would it be possible to update documentation on the matter? I cannot add links for this request.

[jcanseco]

Yes, noted. We'll create an internal bug to improve the documentation.

For now, let me just outline the important points below to serve as pseudo-documentation until we can update our official docs:

1. cnrm.cloud.google.com/state-into-spec is an annotation that all resources (other than IAM policy resources) support.
2. You can set it to one of two values:
   • merge (Default): Tells KCC to update spec with fields not specified by the user, but defaulted by GCP. That is, merge the "desired" and "observed" states. This is the default and original KCC behavior.
   • absent: The opposite of merge. Useful for working around an issue with how list fields work in KCC.
3. Few resources today support absent. Our intent is to roll it out to all resources, but due to lack of capacity, we only roll it out on an as-need basis today.
4. state-into-spec is a step towards a direction where we want to take KCC in the long-term, which is to fully separate the desired and observed states (since we have seen a number of problems with the current design).

[diviner524]

Our public document on state-into-spec annotation is recently added.

Please take a look and share your feedbacks!

https://cloud.google.com/config-connector/docs/concepts/ignore-unspecified-fields

[derekperkins]

That's helpful, the immutable state-into-spec error has been very annoying and spamming our logs for over a year since it was added. Honestly the description in @jcanseco's comment is more useful than that page. There's a blink and you miss it reference to "merge" - "This annotation has a default value of merge if not specified", vs the clear explanation of the two valid values.