Comments (6)
One approach would be for us to reuse kola's provisioning/teardown bits, and have it write out the ssh connection information (as a ssh-config file e.g.) and then something higher level can reuse that to execute other test suites.
kola spawn
could possibly be adapted for this. I like the idea of writing out an ssh config file.
from coreos-assembler.
Oh I forgot to add...I had short discussions with @jlebon about finding a generic way for running these kinds of upstream tests via kola
. I'm not convinced about the usefulness of such an effort, since there don't seem to be a lot of projects that we work with that execute their tests the same way (i.e. Fedora STI).
from coreos-assembler.
Do we want/need these to be added to kola
? I'm not familiar with vmcheck
, if it's meant more to test rpm-ostree
it might make sense to just add a subset of native tests that target core functionality to make sure that what we have packaged in the image is functional rather than testing all of rpm-ostree
.
Here's some miscellaneous thoughts I've had on the subject of external tests in kola
that don't necessarily directly target any of your points:
Ideally I'd like to avoid adding more vendor bloat to mantle
for additional tests unless directly necessary.
Another thing for running non-native kola
tests is that we don't have a great way of discovering them and providing accurate information about the test (just stdout, stderr, and exit status). In the case of vmcheck
where there's a series of tests it would need it's own test runner that kola
just runs.
My personal opinion (if we want to add these into kola
) would learn more towards either building subsets of the tests natively (and dealing with the extra maintenance burden of duplicating existing relevant tests in golang) or some sort of hybrid where we accept that the tests will require a git clone
or some form of download (could just be pulling a container) to get the relevant test bits and the kola
test essentially handles creating the machine, downloading the relevant source bits it needs, and executing it in a simple way (ideally just executing a binary/script that will exit 0 or 1). In the latter case it might be worthwhile to add some sort of flag to enable/disable said tests.
Definitely open to hearing other alternatives.
cc @bgilbert for other opinions
from coreos-assembler.
We haven't generally had kola tests which wrap other test suites. We probably shouldn't build many tests of that kind, but it might make sense to do so in some cases. Pulling and running a container seems like the obvious way to implement them. I agree that vendoring tests directly into mantle doesn't seem great.
from coreos-assembler.
if it's meant more to test rpm-ostree it might make sense to just add a subset of native tests that target core functionality to make sure that what we have packaged in the image is functional rather than testing all of rpm-ostree.
Yeah, regardless we should probably at least have a basic invocation of e.g. rpm-ostree --status
.
One high level thing to keep in mind here is that since we now have two streams, that makes everything at least...four times more complicated =) Since we have to think about versioning a lot more.
Additional complexity here is that rpm-ostree is used by other projects in Fedora too.
So.....
One approach would be for us to reuse kola's provisioning/teardown bits, and have it write out the ssh connection information (as a ssh-config file e.g.) and then something higher level can reuse that to execute other test suites.
from coreos-assembler.
I think this is fixed by #1252
from coreos-assembler.
Related Issues (20)
- [4.15-9.2] legacy-oscontainer build killed due to unexpected EOF on ppc64le HOT 2
- How to build a PXE Image with Dockerfile layering HOT 1
- `coreos.unique.boot.failure` kola test fails on aarch64
- `coreos.ignition.failure` sometimes fails on RHCOS HOT 15
- Create disk failed due to incorrect option format on Fedora 39 HOT 1
- build-arch jobs failing with "Error: unmarshalling error into &errorhandling.ErrorModel"
- cosa build error: "cli: stat /var/tmp/mantle-qemu771203327/swtpm-sock: no such file or directory" HOT 4
- [RFE] kola should support to start previous build to do external tests HOT 4
- OSBuild without compression yields GRUB failures HOT 25
- what is the difference between dasd and metal4k on s390x? HOT 9
- Kola Custom Test HOT 10
- `buildextend-virtualbox` and `buildextend-vmware` improperly handle raw disks >=8GB HOT 6
- `kola testiso` tests should check for badness in console/journal output HOT 5
- rework iscsi tests architecture HOT 2
- osbuild should use a buildroot that matches the target system HOT 6
- kola qemuexec fails on PXE with `uefi-secure` qemu-firmware HOT 2
- cosa run should't expect an image when `--netboot` is present
- 4K UEFI PXE tests failing HOT 2
- Docs: Using the provided alias with `COREOS_ASSEMBLER_CONFIG_GIT` leave FS with dangling files HOT 2
- Check that there is console output / a login prompt to make sure getty works HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coreos-assembler.