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
We've started playing with using this provider to configure our fleet of Dell boxes but we've been surprised by how state is being handled here.
We had a few attributes that we wanted to set across our fleet at the BIOS level and for our IPMI but when we first added these resources and ran a plan, the plan showed a full creation of the resources and no diff. We then imported the resources for each of the boxes into state and could see the diffs for what we were setting as well as a bunch of attributes being set to null as a no-op where we hadn't defined them in code.
This seemed fair enough as a one off so we then applied out, saw that the diff was empty after that and then tweaked a single attribute and saw the diff in the plan as expected and didn't show a perpetual diff of undefined attributes being set to null.
However, when we added a new attribute to the resource and ran a plan the diff shows a single attribute being created without showing the diff from what that single attribute is already set to. This means we can't actually tell which boxes are being impacted by this change which is worrying when a BIOS change will immediately trigger a reboot of an unknown amount of boxes. It looks like it's comparing it to the nulls in the state rather than comparing to the refreshed state from the box so it can't show us a useful plan.
We can potentially work around this by removing everything from state and reimporting it all and then setting every single attribute in the Terraform code but this feels unnecessary and in our case will probably lead to a bunch of less important changes having to be applied out, causing reboots in the case of BIOS changes, or us having to make those things variable and defining them at every host configuration that we then for_each over.
It's been a while since I've done any provider work and I haven't looked too deeply into what's happening in this provider but I think the solution should be that the state should contain all of the settings and then you would use a SchemaDiffSuppressFunc to ignore anything that's not set in code from showing as being set to null. Is that something that the maintainers here would be interested in? I don't have a priority for this work but if you're happy for contributions along these lines then if this becomes a priority for my team then I could raise a PR for it if no one else has done it by then.
The text was updated successfully, but these errors were encountered:
We've started playing with using this provider to configure our fleet of Dell boxes but we've been surprised by how state is being handled here.
We had a few attributes that we wanted to set across our fleet at the BIOS level and for our IPMI but when we first added these resources and ran a plan, the plan showed a full creation of the resources and no diff. We then imported the resources for each of the boxes into state and could see the diffs for what we were setting as well as a bunch of attributes being set to null as a no-op where we hadn't defined them in code.
This seemed fair enough as a one off so we then applied out, saw that the diff was empty after that and then tweaked a single attribute and saw the diff in the plan as expected and didn't show a perpetual diff of undefined attributes being set to null.
However, when we added a new attribute to the resource and ran a plan the diff shows a single attribute being created without showing the diff from what that single attribute is already set to. This means we can't actually tell which boxes are being impacted by this change which is worrying when a BIOS change will immediately trigger a reboot of an unknown amount of boxes. It looks like it's comparing it to the nulls in the state rather than comparing to the refreshed state from the box so it can't show us a useful plan.
We can potentially work around this by removing everything from state and reimporting it all and then setting every single attribute in the Terraform code but this feels unnecessary and in our case will probably lead to a bunch of less important changes having to be applied out, causing reboots in the case of BIOS changes, or us having to make those things variable and defining them at every host configuration that we then
for_each
over.It's been a while since I've done any provider work and I haven't looked too deeply into what's happening in this provider but I think the solution should be that the state should contain all of the settings and then you would use a
SchemaDiffSuppressFunc
to ignore anything that's not set in code from showing as being set to null. Is that something that the maintainers here would be interested in? I don't have a priority for this work but if you're happy for contributions along these lines then if this becomes a priority for my team then I could raise a PR for it if no one else has done it by then.The text was updated successfully, but these errors were encountered: