Update Provisioner example with ability to trigger dynamic provider change #513
Conversation
…e used to detect changes to scripts.
aws-ts-ec2-provisioners/index.ts
Outdated
| host: server.publicIp, | ||
| username: "ec2-user", | ||
| privateKey, | ||
| privateKeyPassphrase, | ||
| privateKeyPassphrase, | ||
| changeToken: getFileHash("myapp.conf"), |
There was a problem hiding this comment.
Some indentation appears to be off here?
There was a problem hiding this comment.
Yeah my editor was set to use Tabs for this repo for some reason. I have fixed it now.
| * A string value to control the replacement of the provisioner during each update. | ||
| * Provide a stable value if you do not need the provisioner to run each time you run an update. | ||
| */ | ||
| changeToken: string; |
There was a problem hiding this comment.
I feel like this doesn't quite belong on the ConnectionArgs - and might make more sense as a property on CopyFile args and RemoteExec args? In terraform, this is often called keepers - perhaps use that terminology (I've never found any terminology I particularly like for this).
Note that for the specific case of changing when the file contents change - it might be nice to actually have a first class hash property. Doing just that might be sufficient here?
Though looking at your original example - perhaps the reason you did it the way you did was to trigger both of these to re-run - which would not be possible with my suggestion above due to the lack of pulumi/pulumi#838.
Feel free to keep this as is - but perhaps consider keepers as the name?
As for doc comment here - the inconsistency is a little jarring - perhaps add comments on all properties? And either adopt the same // style, or update all existing doc comments to /** */ style?
There was a problem hiding this comment.
I feel like this doesn't quite belong on the ConnectionArgs - and might make more sense as a property on CopyFile args and RemoteExec args?
Yeah I agree -- it was a little hacky to put it with the ConnectionArgs, to be honest. I moved it to be a property of those component resources, as well as the provisioner dynamic resource's "state" input as well.
Though looking at your original example - perhaps the reason you did it the way you did was to trigger both of these to re-run
Yes, that's correct. The user can control which one they would like to re-run every time the file(s) content changes.
Feel free to keep this as is - but perhaps consider keepers as the name?
I don't like the name keepers, so I left the name changeToken, but can change it if you insist on using keepers.
aws-ts-ec2-provisioners/util.ts
Outdated
| * Calculates a hash for all of the files under the scripts directory. | ||
| */ | ||
| export function getFileHash(filename: string): string { | ||
| const data = fs.readFileSync(path.join(__dirname, filename), {encoding: "utf8"}); |
There was a problem hiding this comment.
FWIW - I think the current interpretation of src: is relative to cwd, not to the __dirname.
There was a problem hiding this comment.
I am not sure I understand this comment?
… the componentresources.
|
@lukehoban it seems I neglected this PR for quite a while. Could you please take another look when you get a chance? I updated it based on your feedback. |
|
@praneetloke is this something you can add to the python provisioners as well? :) |
|
I will go ahead and merge this. The failure is unrelated to the changes in this sample. It was a GCP test failure. All other tests passed. For posterity, here's the test that failed: |
I'll try to add something there as well, but likely won't get to it soon. Is that ok? |
…hange (#513) * Add a user-settable changeToken property to ConnectionArgs that can be used to detect changes to scripts. * Add the changeToken property to the input args of the provisioner and the componentresources.
This PR updates the provisioner example with a new property in the
ConnectionArgsinterface that allows a user to provide a value, which can trigger a replacement should the value change. An ideal source of values is a hash calculated from the file itself. As the file changes, the dynamic provider will re-run the related steps, i.e. copy/execute. Without this change, updating the user-defined conf or script that the provisioner copies will never be re-executed after the first time.