Add integration tests for /cpu-config

[mattschlebusch]

Changes

Add integration tests to call the PUT /cpu-config API endpoint.

Reason

• Improves coverage and validates core end-to-end functionality of the API.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following
Developer Certificate of Origin and signing off your commits, please check
[CONTRIBUTING.md][3].

[kalyazin]

A general comment. Looks like this change implements tests similar to those we have under pytest: runs a Firecracker binary and executes some HTTP requests. Is there a reason to implement such tests in Rust instead by bringing new development dependencies? Is that merely because you had to convert static templates into json, and an interface for that is only available in Rust? Can we reuse existing json replicas of static templates from our repo?
I know @JonathanWoollett-Light has some ideas on migrating the integration test suite from Python to Rust, but I don't think there has been a conclusion yet.

[mattschlebusch]

A general comment. Looks like this change implements tests similar to those we have under pytest: runs a Firecracker binary and executes some HTTP requests. Is there a reason to implement such tests in Rust instead by bringing new development dependencies? Is that merely because you had to convert static templates into json, and an interface for that is only available in Rust? Can we reuse existing json replicas of static templates from our repo?
I know @JonathanWoollett-Light has some ideas on migrating the integration test suite from Python to Rust, but I don't think there has been a conclusion yet.

To summarize my intentions and approach here:

• Our Rust code-base has utility functions, like building testing data but also serialization and deserialization that is useful, but also benefits from being re-used in our test code wherever possible.
• Code coverage - While not applicable here yet, we could far more easily improve our coverage if we wired our integration tests using our Rust codebase.

[kalyazin]

Our Rust code-base has utility functions, like building testing data but also serialization and deserialization that is useful, but also benefits from being re-used in our test code wherever possible.

I would have to say that ser/des functionality is not required for this test since we can use json versions of the static templates from the repo directly. Please speak up if you have concerns with this approach.
Python test code can be reused in the same way as Rust. Is there a Rust-specific advantage?
I can also see bringing in tokio which is certainly something new to our code base.

Code coverage - While not applicable here yet, we could far more easily improve our coverage if we wired our integration tests using our Rust codebase.

While I agree that code coverage can be improved by counting in integration tests, I do not think that this is the right approach for raising coverage. Usually line/branch coverage is useful to measure how code is covered with unit tests. Adding coverage coming from integration tests makes it significantly harder to see what is covered by unit tests alone. Also since integration tests tend to touch many lines of code, we may have a false sense of good coverage. What we should be aiming for integration tests is functional coverage, meaning covering all real-world use cases. Line/branch coverage is much less relevant as it is impractical to write integration tests for many error conditions.

[pb8o]

Rather than doing an integration test in Rust, and then triggering it from pytest, why not just make it in pytest?

[mattschlebusch]

There is a similar thread with @kalyazin, but I will summarize my take:

• Easier debugging with Rust workspace dependency.
• Smaller (or no) reliance on Docker environment updates with changing/updating dependencies.
• Existing Rust code is tested more thoroughly.
• Improves possibilities of clearer code coverage reporting.

[mattschlebusch]

I would have to say that ser/des functionality is not required for this test since we can use json versions of the static templates from the repo directly. Please speak up if you have concerns with this approach.

It is not absolutely required, but it is a repeated use of the code and is certainly a benefit to repeatedly use code in different scenarios as a means of testing it. I used the JSON ser/deser as an example, but this would go for any other functions that could potentially be used in integration tests.

Python test code can be reused in the same way as Rust. Is there a Rust-specific advantage?

Python test code is only implemented exclusively for the purposes of running our tests. While the Rust code is used on critical performance paths and is developed as a consequence of a feature's development in any event. Our Rust specific advantage to my mind is that Firecracker is implemented in Rust itself, and therefore makes writing tests easier (because the code exists). We can also run tests directly if written in Rust's workspace, cargo test --test <test name> which is faster, doesn't require Docker environment manipulations when there are new dependencies or updates involved, and with reliance purely on the Rust workspace, this integrates more easily with IDEs, so debugging with breakpoints is much easier.

I can also see bringing in tokio which is certainly something new to our code base.

That is true. In this context, it's not strictly required though, it just makes testing in a multi-threaded context a bit easier. It is also only a dev dependency which I don't consider an issue. I stand to be corrected on that though.