You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 12, 2018. It is now read-only.
Changing the name, namespace or kind in the content causes the provider to get confused about the resource that it is tracking. The read operations will continue to use the old names, etc... as these are encoded in the id associated with the resource. The creation operations, however, will use a combination of the newer values encoded in the content and the older values encoded in the id.
Ultimately I think the name, namespace and kind should all be part of the terraform resource so that they can be ForceNew. This avoids all of these strange edge cases.
I have a proof of concept implementation here and can get it into an MR if there is interest. It will, however, potentially conflict with #21
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Changing the name, namespace or kind in the
content
causes the provider to get confused about the resource that it is tracking. The read operations will continue to use the old names, etc... as these are encoded in the id associated with the resource. The creation operations, however, will use a combination of the newer values encoded in thecontent
and the older values encoded in the id.Ultimately I think the name, namespace and kind should all be part of the terraform resource so that they can be
ForceNew
. This avoids all of these strange edge cases.I have a proof of concept implementation here and can get it into an MR if there is interest. It will, however, potentially conflict with #21
The text was updated successfully, but these errors were encountered: