Open jrstarke opened 2 years ago
Hi @jrstarke, we already have cdap_namespace_preferences resource so I would suggest adding a similar cdap_application_preferences resource if you can't reuse the existing namespace one.
I would caution against adding multiple API calls in a single resource create func. If one call succeeds but another fails you can enter some weird state which can be hard to correct because terraform does not support "partial" state (last I checked a year or so ago).
Also I may be remembering incorrectly but data fusion may create applications with some default preferences already set, so you may want to check if calling the API will override preferences. If it does then we will need to keep track of the existing preferences in the resource or document that the user needs to manually set them again in the call.
When I checked the properties on a newly created application today, it returned an empty json object {}
so I think that this one should be pretty safe.
Thanks for your advise :)
If your application uses Runtime Arguments and Macros to make it reusable between environments, then when you go to Runtime Arguments in the Data Fusion webapp, these are actually stored as properties for the application.
I'm looking to implement this functionality, but I'm unsure which design is better. I see two big alternatives:
Rather than using paths, we could use these as optional arguments, and depending on which ones are set, we decide which path to use.
While 2 is more extensible over all, it's definitely more complex. I wouldn't personally benefit from the complexity, and I'm not sure anyone else would, so my preference would be to add properties as an attribute of the application.