Repository navigation
Conversation
0cbcd10 to
daacaa4
Compare
daacaa4 to
2cc2ddc
Compare
2cc2ddc to
1bbb149
Compare
1bbb149 to
de819c5
Compare
de819c5 to
ff8cf94
Compare
413624e to
707c7bd
Compare
707c7bd to
a5b3533
Compare
a5b3533 to
9708bb1
Compare
1b68f8d to
a451ed1
Compare
a451ed1 to
1f11eee
Compare
1f11eee to
2708fb7
Compare
2708fb7 to
9f67178
Compare
9f67178 to
d5eb8f7
Compare
d5eb8f7 to
5e3d908
Compare
5e3d908 to
fd2c5c1
Compare
fd2c5c1 to
a17a6ef
Compare
The harness needs a VM the daemon can discover and scale without libvirt. JSON files carry the snapshot, and set_thread_count records each target so tests can assert behavior. Signed-off-by: Leonardo Forchini <leonardo.forchini@nutanix.com>
Add a Python component test interface for the FakeBackend. It is able to read the JSON files used by the backend and provides utilities to modify the 'VM's as required by tests. AI-Generated: Most of it Signed-off-by: Leonardo Forchini <leonardo.forchini@nutanix.com>
tmakatos
left a comment
There was a problem hiding this comment.
I haven't looked at the methods of the FakeBacked class yet. How do you plan to create the tasks on /proc?
|
|
||
| //! File-backed backend for component tests. | ||
| //! | ||
| //! Instead of requiring a running QEMU instance, this backend manages |
There was a problem hiding this comment.
This reads like we still use QEMU except that we're not running it. I assume you mean that we use a backend that doesn't require QEMU at all. The fact that it's file-based is secondary.
|
|
||
| //! File-backed backend for component tests. | ||
| //! | ||
| //! Instead of requiring a running QEMU instance, this backend manages |
There was a problem hiding this comment.
Can you also add a paragraph how this backend behaves? E.g. whether you pre-configure some performance counter values that it will return when queried by the controller etc. I feel like test backend is a more suitable name, and it could be used as a n example backend as well, could you document this in the README?
| //! | ||
| //! Instead of requiring a running QEMU instance, this backend manages | ||
| //! state through JSON files in `state_dir`. This allows for the external | ||
| //! Python component testing harness to manipulate "VM"s as necessary. |
There was a problem hiding this comment.
You don't explain what happens after the harness has modified the files, does the backend blindly re-read everything when asked by the controller?
| continue; | ||
| }; | ||
| let Some(vm) = read_vm(&path, id) else { | ||
| continue; |
| for entry in entries.flatten() { | ||
| let path = entry.path(); | ||
| if path.extension().and_then(|ext| ext.to_str()) != Some("json") { | ||
| continue; |
There was a problem hiding this comment.
Are we expecting irrelevant files which we should ignore?
| #[async_trait] | ||
| impl InstanceClient for FakeClient { | ||
| async fn set_thread_count(&self, count: u32) -> Result<(), BackendClientError> { | ||
| let _guard = LockGuard::acquire(&lock_path_for(&self.vm_path))?; |
There was a problem hiding this comment.
Why not lock the VM json file? Or better the entire VM directory? This way we wouldn't need the read/write methods in impl VmFile?
| from harness.common import physical | ||
|
|
||
| DEFAULT_VM = "vm-a" | ||
| STATE_DIR = "/var/fake" |
There was a problem hiding this comment.
Shouldn't we use a directory in /tmp?
|
|
||
| DEFAULT_VM = "vm-a" | ||
| STATE_DIR = "/var/fake" | ||
| OWNERSHIP_FILE = "/run/io-thread-controller/vm-ownership.json" |
|
|
||
|
|
||
| class FakeBackend: | ||
| """JSON VM directory the ``fake`` backend discovers.""" |
There was a problem hiding this comment.
This class represents a directory?
| self, threads: int, util: float, io: int = 0, vcpu: int = 16 | ||
| ) -> None: | ||
| """Set the default VM's threads, utilisation, vCPU cap, and read I/O.""" | ||
| self.set_threads(threads) |
There was a problem hiding this comment.
Not sure we need those function separate if they're used only once, given how simple they are. Can you open code other such functions, if any?
The harness needs a VM the daemon can discover and scale without
libvirt. JSON files carry the snapshot, and set_thread_count records
each target so tests can assert behavior.
Signed-off-by: Leonardo Forchini leonardo.forchini@nutanix.com
Stack created with GitHub Stacks CLI • Give Feedback 💬