-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(RK-397) Check for module on disk before skipping implementation #1278
Conversation
@justinstoller I think I just want to make sure this is the right fix before updating the spec tests. |
@puppetlabs/puppetserver-maintainers I pinged Justin directly, but if anyone has opinions about this, would be great to hear. |
7aa1886
to
a5f053b
Compare
@@ -0,0 +1 @@ | |||
This only exists so the directory can be commited to git for testing purposes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
committed has two 't's ; P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the convention is also usually to call this file .gitkeep
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TIL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
about .gitkeep
, not my spelling deficiencies.
I don't love this approach. The average time per module that r10k was taking that was too much for the scale some people run at was only 40 ms. ie, We need to take significantly less that 40ms per module we're no-oping. Part of the design of IMO, a big part of the issue that instigated this is terrible error reporting in other areas of the product, and this is a bandaid. However, a single directory check is should be significantly less than 40ms and maybe this is the right time/value trade off. Let me run this change through our Puppetfile for scale testing and see how it performs. |
The ticket uses a module with the wrong tag as the reproducer. Do you know if that's the actual issue or is that a simplified reproducer? I'm wondering what proportion of issues users encounter installing modules end up failing prior to the module directory creation. |
I don't love the approach either, but I didn't see any other way to address the issue of "is this thing actually deployed or not?" Keeping some other state on disk seems just as bad, so I think our hand is really forced here. I think that since the I think the general problem is for anyone using |
Maybe one optimization that could be implemented is to do a single |
I finished my local testing and with a 1233 module Puppetfile an incremental no-op deploy goes from 1.9 seconds to 2.1 seconds. So, it's 10% slower but no where near the time frames we taking before incremental. |
Regarding the UX, I'm wondering if we keep some record of errors in the .r10k-deploy.json that we could reference from one run to the next to display failures on subsequent runs (or just try to fix them). Also, we maybe should update our docs that when users are concerned that there may have been failures that they may want to manually run r10k without the |
FWIW, I checked and don't find meaningful info to determine if there were errors in the |
I guess those last three comments were all a long way to say that I think this fix is a good value/time tradeoff to solve a specific usability issue. |
Prior to this change, the puppetfile module loader would check to see if the static version changed after an environment sync. However, if the static version failed to deploy, this check would prevent a deploy from re-attempting to deploy that static version. This results in deploys returning without error because it never re-attempts to deploy the invalid static version. This change just ensures that the install path for the module also exists before skipping, so we can be reasonably certain that what is installed on disk is the version r10k expects.
a5f053b
to
1ee9fe4
Compare
Prior to this change, the puppetfile module loader would check
to see if the static version changed after an environment sync.
However, if the static version failed to deploy, this check
would prevent a deploy from re-attempting to deploy that
static version. This results in deploys returning without
error because it never re-attempts to deploy the invalid static
version.
This change just ensures that the install path for the module
also exists before skipping, so we can be reasonably certain that
what is installed on disk is the version r10k expects.
Please add all notable changes to the "Unreleased" section of the CHANGELOG in the format: