[chg] avoid dealing with encoding and provide backwards compatibility #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
amazing, thanks a lot, as we use only kvm, is the most tested hypervisor, so we appreciate a lot your collaboration, and sorry for delay in merge |
|
No stress! Keep going with the great job! |
klingerko
pushed a commit
to klingerko/CAPEv2
that referenced
this pull request
Oct 14, 2021
initial CENTS setup
nbargnesi
added a commit
to nbargnesi/CAPEv2
that referenced
this pull request
Feb 9, 2023
Ideally key collisions across multiple configs could combine data, so multiple values could be generated across configs. For example, config kevoreilly#1 generates the following: {"cfg1": {"key": "value1"} While config kevoreilly#2 generates: {"cfg1": {"key": "value2"} And their combined config becomes: {"cfg1": {"key": ["value1", "value2"]}} The existing behavior is to let the last config win on key collisions, resulting instead in: {"cfg1": {"key": "value2"}} So reflect that in the new test coverage, and simplify the config update method by forwarding the cape_name.
nbargnesi
added a commit
to nbargnesi/CAPEv2
that referenced
this pull request
Feb 9, 2023
Ideally key collisions across multiple configs could combine data, so multiple values could be generated across configs. For example, config kevoreilly#1 generates the following: {"cfg1": {"key": "value1"} While config kevoreilly#2 generates: {"cfg1": {"key": "value2"} And their combined config becomes: {"cfg1": {"key": ["value1", "value2"]}} The existing behavior is to let the last config win on key collisions, resulting instead in: {"cfg1": {"key": "value2"}} So reflect that in the new test coverage, and simplify the config update method by forwarding the cape_name.
doomedraven
pushed a commit
that referenced
this pull request
Feb 9, 2023
…ial for data loss (#1357) * add config update test coverage, part 1 These tests are known to pass based on the current implementation of update_cape_configs. * add config update test coverage, part 2 This test is known to fail based on the current implementation of update_cape_configs. * run python-package workflow on all branches * simplify update_cape_configs and update tests Ideally key collisions across multiple configs could combine data, so multiple values could be generated across configs. For example, config #1 generates the following: {"cfg1": {"key": "value1"} While config #2 generates: {"cfg1": {"key": "value2"} And their combined config becomes: {"cfg1": {"key": ["value1", "value2"]}} The existing behavior is to let the last config win on key collisions, resulting instead in: {"cfg1": {"key": "value2"}} So reflect that in the new test coverage, and simplify the config update method by forwarding the cape_name. * log the potential for data loss * less ruff now * Revert "run python-package workflow on all branches" This reverts commit 4868ffa. * link test coverage to #1357 --------- Co-authored-by: Nick Bargnesi
enzok
pushed a commit
to enzok/CAPEv2
that referenced
this pull request
Apr 13, 2023
Merged
6 tasks
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While running CAPEv2 with virtualbox machinery, the system enters in a loop state. It seems no match is found for the detected VM state when checked against the predefined set (e.g. POWEROFF, ABORTED, etc.);
setting universal_newlines=Truereturns output as text instead of binary and it does the trick.