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
Change restart flag to an restart policy enum in interfaces #217
Conversation
@krucod3: After all local modifications, I had an enum called |
Shall I add an comment out stest also? |
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.
All in all looks good, just a couple of small findings.
@krucod3: Since a restart of a workload is basically an update (delete + create), I would recommend that we rename the Restart stuff related to the retry mechanism inside the WorkloadControlLoop to "Retry" instead of "Restart". This prevents confusion (especially for the swdd chapters). |
tests/resources/configs/update_state_config_with_dependency_cycle.yaml
Outdated
Show resolved
Hide resolved
Co-authored-by: lingnoi <42992756+lingnoi@users.noreply.github.com>
We should not just update all configs to ALWAYS if the previous value was true. Workloads that go to succeeded will end up in a restart loop and this is not what we are targeting. |
Yes this is why I have carefully thought about the need for restart or not for each workload config or documentation snippet. And I have disabled the restart feature for all stests not testing the restart feature itself to prevent stests from failing because of the restart failure even if their intend tests a different feature. |
I think, utilizing the term "RestartPolicy" is more precise, as the term "Restart" alone could potentially be misunderstood in various contexts. |
I will do a commit in a few minutes. But I need to test all examples again after the changes. |
@krucod3: All changes for renaming "restart" into "RestartPolicy" are done (Manifest + Enum). The problem is since two builds in GH actions and on my local side the mkdocs build is failing It is failing on the main branch as well (see picture above). The mystique thing is that on @lingnoi WSL2 both main and this branch builds the documentation successfully. We have found out that it is the social plugin of mkdocs: If I comment out the social plugin then it works. However, after analyzing the python code of the social plugin it seems like it is trying to download the Roboto.zip of google fonts (this is happen when the documentation is built). The download does not return a valid zip file if you download it in a programmatic way (curl, python code of the function that loads the zip). It returns a javascript file. However, if you download the google fonts with the browser it returns a valid zip file. The issue was also mentioned in the past here: squidfunk/mkdocs-material#5628 (but with different setting) |
I can confirm, I can build and serve the documentation of this branch and also of main branch on my machine (WSL2). |
After removing the .cache folder, I'm able to reproduce the issue: |
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.
LGTM, now 👍
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.
LGTM 👍
Issues: #5, #212
Changes:
Definition of Done
The PR shall be merged only if all items mentioned in CONTRIBUTING.md have been followed. In case an item is not applicable as described, please provide a short explanation in the description.