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 28, 2024. It is now read-only.
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:
Because the properties of the application are fundamentally about the application, we add them as an attribute to the resource, and when we perform the create, we also do a second call to set the properties, if appropriate.
Because the properties are a separate web request, we could do them as a separate resource. This could be a resource specific to preferences of applications, or we could allow the user to specify path the properties are for much like
PUT /v3/preferences/
PUT /v3/namespaces/<namespace-id>/preferences
PUT /v3/namespaces/<namespace-id>/apps/<app-id>/preferences
PUT /v3/namespaces/<namespace-id>/apps/<app-id>/<program-type>/<program-id>/preferences
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.
The text was updated successfully, but these errors were encountered:
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 :)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: