Aleksei Sviridkin
bc400dff15
## What this PR does `hack/mariadb-first-boot-waits.bats` let two regressions of the wait budgets it guards pass green. This closes both. The change is test and doc only: no wait, op or chart value moves. A wait now has to clear its floor by a named `MBW_START_MARGIN` of 60s, not by one second. The wait's clock starts before the install's by the Application reconcile, the chart artifact fetch and the helm-controller queue. Nothing in the tree bounds those three, so the value is a policy choice and the header says so. It equals the headroom every current wait already carries (660 against a 600s floor), which is why no value has to change. A fixture pins 660 against 600 as passing and 659 and 601 as refused. The sizing guide in `docs/agents/e2e-testing.md` asked only for "strictly above" the floor, which the guard now rejects, so it now asks for a start margin and points at the constant instead of restating the number. The mongodb, rabbitmq and clickhouse walkthrough waits and their Chainsaw ops are now held to the same contract as mariadb, through one table with a row per suite. Each suite gets its own floor test and its own op test, so a regression turns only that suite's tests red. The floor comes from the api-server's install-timeout default, and each suite's ApplicationDefinition is checked for an override. The startup-probe half is computed only for mariadb, since the other three charts set no `startupProbe`. Each op must keep the remainder it had before its waits were raised, and that raise preserved it: 900s for mariadb and rabbitmq, 1200s for mongodb, 2700s for clickhouse. The remainder is taken over every HelmRelease wait the op reaches, the bucket wait included, so raising a wait together with its op keeps the remainder instead of turning the raise into slack. The mongodb target wait sits behind the `SKIP_RESTORE=1` its op passes, so it is not reached and is left out; the test turns red once the op stops passing it. The Chainsaw HR-Ready asserts of mongodb, rabbitmq and clickhouse (6m) stay out of scope. They sit under the floor by per-suite choice, and the header says so. Verification: - The file goes from 22 to 28 tests. Four mariadb-only tests are replaced by the eight per-suite ones: the example floor, the both-waits op slack, the check that both applications are waited on and the ApplicationDefinition override. Two fixture tests drive the per-suite floor and op checks through directory, suite-file and RD overrides. They cover each way of falling short that the live tree cannot produce, since every live wait sits at exactly 660 and every remainder at exactly its constant. That includes an RD that overrides or disables the install wait, and a startup budget large enough to bind over the install timeout. - `make bats-unit-mariadb-first-boot-waits` passes, and the same file passes under dash through `hack/cozytest.sh`, as CI runs it. - Mutations, each confirmed applied and each run test by test, because the runner stops at the first failure: - Any suite's database wait lowered to 601: only that suite's floor test fails. That includes the mongodb target wait the op never reaches. - Each op lowered back to its old value (30m, 30m, 30m, 60m): only that suite's op tests fail. For mariadb that is also the existing prefix-remainder test. - `SKIP_RESTORE=1` dropped from the mongodb op: only the mongodb op test fails. - Any suite's bucket wait raised to 660, or the rabbitmq one indented out of the flow: only that suite's op tests fail. Raising a bucket wait to 660 together with its op by 6m keeps all 28 tests green. - A third clickhouse wait added in a new file under `examples/backups/clickhouse/`: the clickhouse floor and op tests fail, because the waits are read from every script in the directory rather than from a listed subset. - Any suite's target wait renamed to wait on the source again, in mariadb and rabbitmq: only that suite's floor test fails. Dropping the distinct-release check, or its `sort -u`, fails only the floor fixture test. - Inside the helpers themselves, one mutation per branch of every new or changed helper, 37 in all: each turns its own fixture test red, or the live suite checks where the branch selects which waits are read at all. Two branches whose deletion changed no output were removed rather than pinned. - `MBW_START_MARGIN` set to 0: only the two fixture tests that encode the margin fail. Deleting the constant fails every test that reads it, as an unbound variable. - `hack/select-e2e.sh` selects no suite for this diff. Left for later: - The file name. `hack/mariadb-first-boot-waits.bats` now guards four suites. I kept the name because renaming it changes its make target and every reference to it, which belongs in a change of its own. - The SKIP_RESTORE stop works within one file. A suite whose waits span several scripts, as clickhouse's do, would still count the waits in later files if its op ever passed SKIP_RESTORE=1. That errs toward a false red, not a silent pass, and no such op exists today. - Measuring the margin. The delay from Application creation to the start of the install is measurable from CI reports and would turn the 60s policy value into a bound. That delay is not bounded anywhere today. Closes #4418 ### Screenshots Not a UI change. ### Downstream repositories - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: ### Release note ```release-note test(e2e): the wait-budget guard now requires a 60s margin over each floor and covers the mongodb, rabbitmq and clickhouse backup walkthroughs alongside mariadb. ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that HR-Ready waits should exceed both the app’s first-boot budget and the release install timeout, with a start margin for controller processing. * **Tests** * Expanded wait-budget and timeout validation across configured suites, including checks for missing or invalid settings, operation slack, restore-skip behavior, and bucket waits. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Cozystack
Cozystack is a free and open-source platform and framework for building clouds.
Cozystack is a CNCF Sandbox project that was originally built and sponsored by Ænix.
With Cozystack, you can transform a bunch of servers into an intelligent system with a simple REST API for spawning Kubernetes clusters, Database-as-a-Service, virtual machines, load balancers, HTTP caching services, and other services with ease.
Use Cozystack to build your own cloud or provide a cost-effective development environment.
Use-Cases
-
Using Cozystack to build a public cloud
You can use Cozystack as a backend for a public cloud -
Using Cozystack to build a private cloud
You can use Cozystack as a platform to build a private cloud powered by Infrastructure-as-Code approach -
Using Cozystack as a Kubernetes distribution
You can use Cozystack as a Kubernetes distribution for Bare Metal
Documentation
The documentation is located on the cozystack.io website.
Read the Getting Started section for a quick start.
If you encounter any difficulties, start with the troubleshooting guide and work your way through the process that we've outlined.
Versioning
Versioning adheres to the Semantic Versioning principles.
A full list of the available releases is available in the GitHub repository's Release section.
Contributions
Contributions are highly appreciated and very welcomed!
In case of bugs, please check if the issue has already been opened by checking the GitHub Issues section. If it isn't, you can open a new one. A detailed report will help us replicate it, assess it, and work on a fix.
You are welcome to take on the fix yourself. Commits are used to generate the changelog, and their author will be referenced in it.
If you have a concrete feature request, open an issue. For a cross-cutting or architectural change, open a design proposal in the community repo. For questions or early ideas, use GitHub Discussions. See CONTRIBUTING.md for the full routing.
Community
You are welcome to join us in #cozystack, on either CNCF Slack (get an invite) or Kubernetes Slack (get an invite), in our Telegram group, and at our community meetings. Add them to your Google Calendar or iCal for convenience.
Project documents
| Document | What it covers |
|---|---|
| Governance | How decisions are made and who makes them |
| Contributor Ladder | How to grow from contributor to maintainer |
| Maintainers | Who maintains the project |
| Code of Conduct | What we expect of each other |
| Security Policy | Reporting a vulnerability, and which releases get fixes |
| Adopters | Who runs Cozystack in production |
| Roadmap | Where the project is going |
License
Cozystack is licensed under Apache 2.0.
The code is provided as-is with no warranties.
Commercial Support
A list of companies providing commercial support for this project can be found on official site.