Clarify user experience for re-deployment of Link with updated recipe template

[kachawla]

Scenarios that need more clarity -

• Existing connector re-deployed with new template path - should underlying resources be updated and previous resources deleted?
• Existing connector re-deployed with same template path - should we try to re-deploy the template or skip recipe deployment? (this scenario will be handled by clarity around versioning of templates, if a template with same version is provided again it will be ignored else re-deployed)
• Do we want to support modifications to a previously deployed resource through recipe template?

AB#4154

AB#10665

[rynowak]

👀 - glad these topics are coming up already

The big risk here is the cases that will result in an interruption of service when deployed ... or even worse data loss. Lots of cloud resource APIs will trigger an interruption of service when specific properties change. From what I've seen AWS document these pretty well, and Azure does not.

Attesting to the safety of a recipe wrt updates might have to be the responsibility of a recipe author. For example it's possible in Bicep to declare metadata on parameters or for the template as a whole. I still don't have a great read on how to surface this in the UX, but it's a start.

---

One technique that applies here is to start restrictive and then become more lax over time. If we block updates to connectors using recipes NOW, then we can add support for it globally, based on policy, or based on the safety of the recipe in the future.

I'm not sure if you were present when we discussed it last, but there's potentially a really large amount of complexity here. eg: "Operator updates a recipe definition to apply a brand new security setting, and then that update is rolled our gradually and safely". LT's feeling was that the basic version of Recipes could be ready basic (no support updates).

[rynowak]

@kachawla - do you think this is a dupe of #6372? Could we combine these items?

[kachawla]

@kachawla - do you think this is a dupe of #6372? Could we combine these items?

Yeah, you're right. All the scenarios here will be resolved by versioning. I can close this in favor of 6372.