Add ForceNew to layout_type dashboard attribute

[zippolyte]

Add ForceNew to layout_type dashboard attribute so that users can change the layout type of a dashboard.
Note that changing the type only is not sufficient, a layout property need to be added/removed to/from all the widgets in that dashboard depending on the change. Also a few widgets might be available in one type and not the other, which is another thing to lookout for when changing the layout type

fixes #772

[therve]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matt-miller-ddog]

We don't support changing a dashboard's layout type; our API will reject these payloads even if our Terraform provider doesn't.

[zippolyte]

That's the thing, it won't try to update the dashboard, it will just delete the old one, and create a new one from scratch

[nmuesch]

LGTM, minor question/note about the alert id, but other than that this seems 💯

[therve]

You need to keep the same resource name in your update, otherwise terraform ends doing a delete/create and you don't test forceNew

[zippolyte]

🤦

[zippolyte]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matt-miller-ddog]

I get the idea behind ForceNew now, but I'm still worried about approving. The issue is with widgets' layout blocks. Traditionally they're screenboard-only, and our API will force users to add/remove them when changing layout types. But the Multi-Size Layout project uses layout in timeboard widgets as well, using the same structure but for different purposes and with different expected values. That means that for orgs with MSL enabled, the API will allow users to switch from free to ordered (or the other way, once MSL goes GA and makes its way into TF) and produce a corrupt / bad-looking board.

(But if we don't do this PR, TF users may end up renaming their resources with new types to accomplish the same thing in a hackier way, which leaves us in the same situation. I'll think this over for now.)

[matt-miller-ddog]

Clarification: if Terraform is able to detect and prevent using layout on TBs + not using layout on SBs and prevent the API calls appropriately, this should be fine; if we're counting on the API to do it then this will become an issue once we start rolling out MSL.

[therve]

Clarification: if Terraform is able to detect and prevent using layout on TBs + not using layout on SBs and prevent the API calls appropriately, this should be fine; if we're counting on the API to do it then this will become an issue once we start rolling out MSL.

I suppose terraform could do that, but I'd rather not add more logic if we can avoid it. I'm not exactly sure how it's related to the issue at hand?

IIUC, right now you can either specify ordered, and no layout, or free, and layout everything. If you try to change the type, the API fails. In the future, with MSL, you can specify layout in ordered? And thus the API will allow changing the type? If that's the case, I agree we probably shouldn't merge this.

[matt-miller-ddog]

IIUC, right now you can either specify ordered, and no layout, or free, and layout everything. If you try to change the type, the API fails. In the future, with MSL, you can specify layout in ordered? And thus the API will allow changing the type? If that's the case, I agree we probably shouldn't merge this.

The API still won't allow Dashboard.update to change board types even with MSL (meaning that we'd still need ForceNew to do it); but other than that your statement is accurate, and TB payloads will have layout in them to manage MSL layout. As it stands now, the API won't be able to tell the difference between a SB layout vs an MSL TB layout and will allow users to change their resources' layout types without also forcing them to fix their layout values.

I'd classify this as "a future dashboards backend bug that will apply to TF users once MSL is rolled out" (and not merging this reduces its severity but also interferes with this layout_type edit bugfix) so I'll see if dashboards-backend is willing to address this.

At any rate, this future MSL bug will be present for TF users with MSL enabled regardless of whether this PR is merged or not, so I'm willing to approve this PR to fix the existing bug report. I'll raise awareness of this situation so that hopefully we can dodge the future MSL layout bug before it happens.