python-osism
Documentation
- SONiC ConfigDB validation — how
osism sonic validateis built, what it does not check, and the caveat that the vendored YANG models are a different SONiC flavour to the devices.
Running unit tests
Install development dependencies and run the full unit test suite:
pipenv install --dev
pipenv run pytest
Run a single test module:
pipenv run pytest tests/unit/test_smoke.py
Running integration tests
The integration tests in tests/integration/ exercise the Celery/Redis task
core (broker, queue routing, worker, result backend, Redis streams and locks)
end-to-end. They require a reachable Redis and start a Celery worker from the
same virtualenv; they are skipped automatically when Redis is not running.
docker run -d -p 6379:6379 redis:7-alpine
REDIS_HOST=localhost REDIS_DB=15 pipenv run pytest tests/integration
Warning: The suite mutates live state on the configured Redis. Most keys are per-run (UUID-based), but some are fixed global names on the selected
REDIS_DB: the task-lock test reads, writes and removesosism:task_lock, and the vault test removesansible_vault_password— which a real deployment cannot recover, since no other copy of it exists on the system. Always point the suite at a disposable Redis (such as the throwaway container above).To make that hard to get wrong, the suite refuses to run against
REDIS_DB=0, the database a deployment uses. SetREDIS_DBto a spare database as shown above, orOSISM_ALLOW_DEFAULT_REDIS_DB=1if the Redis itself is disposable.REDIS_DBmoves the direct client, the Celery broker and the result backend together.
Running the SONiC E2E golden test
The end-to-end test in tests/e2e/ provisions NetBox with a docker compose
stack, seeds it from the fixtures in tests/e2e/scenario/, generates the SONiC
config_db.json files and compares them against the goldens in
tests/e2e/golden/. Besides the development dependencies it needs docker with
the compose plugin, openssl, and a netbox-manager checkout for the seeding
CLI — a sibling directory by default, NETBOX_MANAGER_DIR otherwise.
pipenv install --dev
make sonic-e2e
A cold run takes roughly ten minutes, most of it starting NetBox. To iterate without paying that each time, bring the stack up separately and leave it running:
make sonic-e2e-up # start NetBox and leave it up; sonic-e2e reuses it
make sonic-e2e-down # stop it again and remove its volumes
After an intentional generator change, rewrite the goldens and review the diff before committing it. Regeneration deliberately refuses to run against a stack left over from an earlier run, because applying the fixtures over a populated database can produce goldens that CI — which always starts fresh — would not reproduce:
make sonic-e2e-down
make sonic-e2e-regen
How much of the generated config the golden set actually covers is reported separately, because nothing in CI reports it:
make sonic-e2e-coverage
That compares the config_db tables the generator can emit against the tables
that are non-empty in at least one golden, and names any that no golden covers.
It exits non-zero while that list is non-empty, so it is worth running after
adding a scenario to confirm the new tables landed. It gates nothing on its own
— the golden comparison above is the only check that fails a run.
tests/e2e/sonic_golden_test.sh documents the remaining environment overrides
(NETBOX_PORT, KEEP_STACK, SEED_PARALLEL and the regeneration escape
hatch).
Warning: Seeding applies every file under
tests/e2e/scenario/resources/, tracked or not, so a stray file there joins the fixture set — which either breaks the run or silently changes the goldens. Check that directory withgit status --ignoredbefore regenerating or debugging a mismatch.
Metadata
Release files for osism 0.20261019.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| osism-0.20261019.0.tar.gz | 1.0 MB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| osism-0.20261019.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 1.3 MB
Release files / osism-0.20261019.0.tar.gz
| Download URL | osism-0.20261019.0.tar.gz |
|---|---|
| Size | 1.0 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
1ffaafb2d26b56bba98ebdfabd88f8eb0d916f0f7ad7dd6b7df90117bff1ebe5
|
|
BLAKE2b-256 checksum How to use checksums |
b42bfd956f733701956573ddfca1905e0967e7d90b80974140dd827f0a1758ae
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Release files / osism-0.20261019.0-py3-none-any.whl
| Download URL | osism-0.20261019.0-py3-none-any.whl |
|---|---|
| Size | 308.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4a92f9f5cf55627afb0db3dec6e05a7506785682d50d152d721f5898c2bcfee9
|
|
BLAKE2b-256 checksum How to use checksums |
58e9a53102129fb36c644113c33b554e307af3da968c2abfa69b78a551c31ad9
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Security for osism 0.20261019.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
