Add application/environment to ServiceSpec generated from a Service #2988
Conversation
By not carrying this data over when generating a `ServiceSpec`, we would always internally be tracking services with _no_ application/environment set (because it defaults to `None`). However, all the spec files on disk did have this information. This, coupled with the fact that we watch our spec directory with very coarse event resolution (basically, if anything in the directory changes, go check *all* specs to figure out what needs to be restarted, etc.) means that anytime a new service was started or stopped (anything that caused a change in the spec directory!), we'd end up restarting services that had been started with application/environment set. Our internal representation had no such information, but the on-disk representation _did_ have it; that's a difference, so we restart! Fixes #2964 Signed-off-by: Christopher Maier <cmaier@chef.io>
|
Thanks for the pull request! Here is what will happen next:
Thank you for contributing! |
|
|
|
@thesentinels approve |
|
🤘 I am testing your branch against master before merging it. We do this to ensure that the master branch is never failing tests. |
|
|
Travis CI has
|
💔 Travis CI reports this PR failed to pass the test suite. The next step is to examine the job and figure out why. If it is transient, you can try re-triggering the Travis CI Job - if it passes, this PR will be automatically merged. If it is not transient, you should fix the issue and update this pull request, and issue |
, you can issue a
|
@thesentinels approve |
|
🤘 I am testing your branch against master before merging it. We do this to ensure that the master branch is never failing tests. |
|
|
|
💖 Travis CI reports this PR passed. It always makes me feel nice when humans approve of one anothers work. I'm merging this PR now. I just want you and the contributor to answer me one question:
|
thesentinels
deleted the
cm/2964-do-not-restart-all-the-things-with-app-env
branch
christophermaier
added
Focus:Supervisor
By not carrying this data over when generating a
ServiceSpec, wewould always internally be tracking services with no
application/environment set (because it defaults to
None). However,all the spec files on disk did have this information.
This, coupled with the fact that we watch our spec directory with very
coarse event resolution (basically, if anything in the directory
changes, go check all specs to figure out what needs to be
restarted, etc.) means that anytime a new service was started or
stopped (anything that caused a change in the spec directory!), we'd
end up restarting services that had been started with
application/environment set. Our internal representation had no such
information, but the on-disk representation did have it; that's a
difference, so we restart!
Fixes #2964
Signed-off-by: Christopher Maier cmaier@chef.io