Issue1196 - Add default.inc entry point in configuration parsing - #1766
Issue1196 - Add default.inc entry point in configuration parsing#1766andreleblanc11 wants to merge 7 commits into
Conversation
Test Results379 tests 378 ✅ 1m 38s ⏱️ Results for commit eb57988. ♻️ This comment has been updated with latest results. |
|
Lots of flow tests are failing.. so that's a bad sign |
|
The flow tests are failing due to the Sarra C package being missing.. for some test cases. Seems unrelated to this PR. I ran the static flow test on a U22.04 VM and that passed without problems. |
There was a problem hiding this comment.
Went through the diff and traced the config through both sr_GlobalState and the worker startup path. I think this needs a few changes before it merges, here we goo:
default.inc only gets loaded by sr_GlobalState
The new include is parsed in sr_GlobalState._read_configs(), so sr3 show and declare see it. The process that actually starts a component builds its options through config.one_config() in instance.py, and that path doesn't load <component>/default.inc.
I reproduced this with retry_ttl 1h in subscribe/default.inc: the management-side options showed 3600, but the worker-side options left retry_ttl unset. Basically the config can look right in show and then run with different settings. Could we load this through the same path used by one_config() so management and runtime can't diverge? This one needs fixing before merge.
poll/default.inc loses the component context
The new parse_file(default.inc) call doesn't pass c. That changes how component-specific aliases are resolved. For example, destination in poll/default.inc became sendTo in my test; parsing the same file with "poll" sets pollUrl, which is the expected poll option. broker has the same kind of component-dependent mapping.
Can you pass the component into this parse call and add a test using a component-specific option?
Tests
The current tests prove _read_configs() sees the file, but they don't exercise the worker one_config() path where the first issue shows up. Can you add a runtime-side test as well?
They also write predictable /tmp/<component> paths and remove them afterward. That can race in parallel test runs or overwrite somebody's existing path. tmp_path would keep the test isolated.
Also, watch appears twice in the parameter list, while cpost and cpump aren't covered. If those are intentionally outside the feature, it would help to make that scope explicit; otherwise they should be included.
French docs
The French page still lists <component>.conf in the lookup order even though the paragraph below talks about <component>/default.inc. Can you update that list so both descriptions agree?
Flow tests
The current failed runs show /usr/bin/sr3_cpump installed and reporting a version before the failures. The MQTT failure is in the flakey-broker counts on Ubuntu 22/24, and the AMQP failure is the partitioned-flow check on Ubuntu 24. I don't think the missing-Sarra-C explanation matches those logs.
Can you rerun those flows or compare them against the same runs on development so we know whether they're pre-existing or caused by this branch?
Minor cleanup
git diff --check reports trailing whitespace in the new test, and the new test functions need the usual blank-line cleanup. This user-facing change also needs a CHANGES.rst entry.
… + pass component argument in parse_file
|
Thanks for that. I changed my entries so that the sarracenia instance as well as the sr command line invocation use both the same method. From a runtime perspective, the For a poll. The At the same time, Im running a sarra. The default.inc sarra settings aren't overriding the poll options. |
robjarawan
left a comment
There was a problem hiding this comment.
Thanks, the direct runtime setting and component-specific parsing issues from the first pass are fixed. The French lookup order is corrected and git diff --check is clean.
I reran the focused tests: 16 passed. The full unit suite also passed with 375 passed and 1 skipped.
I found three remaining points in the inline comments. CHANGES.rst is also still missing, and the new test block still has duplicated imports and two missing blank lines.
The full AMQP and MQTT flow workflows haven’t rerun against the current head because those workflows don’t trigger on synchronized commits. The base AMQP workflow also failed, but in different test cases, so it doesn’t establish that the branch failures were pre-existing. I’d still rerun them or provide a matching baseline before approval.
|
The github actions that have already failed are either,
|
|
Thanks, I went through the latest updates. So what I did was check the diff, your runtime evidence, and the CI state. The blockers from my first pass look fixed. Basically you now load I am holding approval on the items from my second review since they are still open. The tests only cover One new thing I found while reading the helper. On the flows, the maintenance runs are green on the PR, which is good. I still want a matching AMQP/MQTT baseline on the current head before approval, since the base failed in different cases and that does not prove pre-existing. Good progress. Once the |
This PR adds
An entry point to parse
<component>/default.incprior to parsing the configuration file.<component>/default.incto overridedefault.confand;default.conf+<component>/default.incI opted with
default.incinstead ofdefault.confbecause.confentry gets parsed and treated as a configuration file and;def default_configseemed like more work.default.incdoes the same job and doesn't need refactoring of the code to adapt.Add unit tests that test out this new entry point. Unit tests were manually ran on my VM + GitHub actions. Both passed.
Update documentation to reflect changes. Remove
<component>.confentry in documentation as I tested it and it doesn't work. I believe @reidsunderland confirmed this is a v2 specific feature.