All hooks should execute even if artifact does not need to be deployed about artifact-cookbook

[ivey]

I disagree about before_migrate ... I think it should only be run if we are migrating.

[ivey]

Do we need an after_extract to handle "Where do I put bundle install?"

[ivey]

Actually, I may disagree on the whole issue. We're having a problem where bundler is running every time in the before_migrate. My feeling is that this is a bug: if the deployed code hasn't changed, I don't want bundler running. Do you think that is a correct statement?

[reset]

@ivey I think you are right that before_migrate and after_migrate (if it existed) should only run on migrate.

We may not have enough hooks defined and that may be why you disagree on the whole issue. We should allow people to configure their application within the LWRP to have access to the folder structure and we want to make sure the configuration is valid even if the application doesn't need to be re-deployed.

Let's take the case where we change an attribute that affects a configuration file. If the application is already deployed then this would be missed since configuration is placed within the hooks we have implemented and those only fire if an application deploys.

[ivey]

Shouldn't that config file be in a template resource outside the artifact block? Or does it need to be inside for some reason? My feeling right now is that "Deploying an artifact" is the job of this cookbook, and if v1.2.3 of the artifact is deployed, and :force is not set, we shouldn't do anything. Configuration should happen regardless of the artifact state. Happy to be convinced otherwise though.

I agree about hooks, though. I'm working on a list of hooks we may want to add, plus the change to migration hooks to only run if migrating.

[ivey]

The simple solution would be to have some hooks that always run, some that only run if the artifact is being deployed, and let users pick the one that meets their needs.

[KAllan357]

I think one of the reasons for the templates in procs argument is the current idempotency check. The manifest file that is used is meant to ensure that the artifact is still in the state is was deployed in. Randomly deleting a file from the deployed directory should prompt a redeploy on the next chef run.

Similarly, adding a file into the deployment directory after deployment would cause the manifest check to fail. I'm not sure the correct path here, but I think the manifest checking is useful for ensuring that the artifact is still in the correct state.

I had some other thoughts on this that I wrote about in #26

[ivey]

Got it. Honestly, I didn't realize we did that. Makes sense.

I'll finish my hooks list and add it to this thread.

[ivey]

Here's what I am thinking. Adds a few redundant hooks, but I have always been bothered that you have to know symlink comes after extract and use before_symlink instead of after_extract, for example.

• check the manifest and save the result
• run before_deploy
• if deploy?
  • run before_extract / extract / run after_extract
  • run before_symlink / symlink / run after_symlink
• run configure
• if deploy? and migrate?
  • run before_migrate / migrate / run after_migrate
• if deploy? or manifest has changed so far (we changed configs)
  • run restart
• run after_deploy
• write the manifest

before_deploy and after_deploy would be catch-all for "do this inside the manifest write"

configure would be the preferred place to do templates, since you don't have to remember where in the process it comes.

This does add an extra manifest check to see if we should run restart.

[reset]

@ivey looks good to me. Is configure a hook as well or all configuration would occur in before_deploy?

[KAllan357]

I like this. Makes sense to me.