Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove spec file of failed services #6794
This is a third attempt at resolving this issue. I apologize to reviewers. The feedback on the previous two attempts, #6719 and #6730, have illuminated much better ways to address the problem. The new method is sufficiently different that I believe it warrants a new PR.
To recap there are two changes in behavior:
I am still trying to find a way to encapsulate these changes in our test suite, but I wanted to get this PR up for initial feedback.
@christophermaier this does not address your comment here in so far as adding an in memory representation of loaded but not running services. There are two reasons. First this new implementation did not benefit from it, and second, I tried several times, but always ran into rather ugly
The situation that occurs to me is existing installs that have spec files cannot be validated. If we've changed things such that a given spec file may have validated previously, I could see us getting into that scenario.
This is a great point! To make sure I am understanding. The scenario is, supervisor version 1 is able to successfully call
The old behavior would be that we end up in the weird state this PR fixes.
The new behavior would be that the service is automatically unloaded. Does that seem reasonable?
christophermaier left a comment
I think this makes sense for now, in that it makes failures explicit. If a new version of a service comes in that has missing binds, the current (i.e., before this PR) situation requires users to reload the service anyway, so removing the file doesn't really change that.
I can envision a future where we could do a bit more validation before trying to upgrade a service and if we detect an incompatibility, refuse to upgrade until the user can intervene... that would at least allow the service to continue operating in the meantime. I can also envision a future where operations like updating binds doesn't require a full unload and reload of a service... in that case, we might not want to delete the spec file, but that's speculating about code that doesn't exist yet. Some tests around the behavior introduced in this PR would help guard against that, though.
All that is far beyond this PR, of course.
I'm curious for @stevendanna's thoughts on this, as this could have impact on Automate (it should at least be on their radar).
There are a couple tweaks I'd like to see before merging, but overall, I like the approach taken here. The breakup of things into commits really helped the review, as well.