Add simple set of goose loadtests

[JimFuller-RedHat]

Adds a standalone setset of goose loadtests.

To load trustify endpoints with 3 concurrent users.

> cargo run --bin loadtest -- --host http://localhost:8080 -u 3

To stop load test hit [ctl-C], which should generate aggregate statistics.

To load trustify endpoints against 10 concurrent users, generating an html report.

 cargo run --release -- --host http://localhost:8080  --report-file=report.html --no-reset-metrics -u 10

Note: will need advice as to how we want to login this robot user.

[ctron]

Note: will need advice as to how we want to login this robot user.

We do have some "well known" credentials for tests that we could leverage: https://github.com/trustification/trustify/blob/main/common/auth/src/devmode.rs

Also I think we might consider grouping top-level tests into some "tests" root folder. Which should include integration-tests as well.

[JimFuller-RedHat]

alas I am getting distracted elsewhere ... currently this will just work against unauthenticated endpoints - will leave this open for me to dig into OIDC login when I return from holidays or feel free to close/merge.

[helio-frota]

good to sync with @dejanb [?]

https://github.com/trustification/trustify/discussions/214

[helio-frota]

I'm +1 for this load this thanks for this @JimFuller-RedHat :+1: This is a diff category of perf tests.

[dejanb]

Great that we have some progress on this topic as I didn't manage to consider it any attention. I wanted to make us be able to deploy both trustification and trustify in production way in arm cluster, before tackling these, but that is still WIP.

@helio-frota @JimFuller-RedHat How does this stands in comparison to hyperfoil work? Can we load documents using it or is it expecting a running, preloaded instance? Can we run it in the cluster?

Anyways, great that things are moving.

[JimFuller-RedHat]

@dejanb thx for comment ... will try to outline here but we can jump over to chat anytime.

hyperfoil and goose heavily overlap in responsibilities ...hyperfoil is older, has more committers while goose is younger but seems to have more adoption, at least amongst rust crowd - not surprising as hf is java and goose is rust.

There are some advantages having a test (load or otherwise) framework be a different ecosystem then the system one is testing.

The other difference is writing tests as code versus declarative markup ... I like both approaches.

As for application of the loadtest - goose loadtest could be run against stage/uat (and maybe a non mutating variant against prod) ... in addition to adhoc tests running against local.

We do something similar (with python locust) on prodsec projects as a performance regression on live data. I am certain hyperfoil could be similarly used.

So the pros/cons might boil down to:

• rust versus java
• code tests versus declarative markup

Alternately, we might eschew the 'versus' type discussion and simply run both ... maybe this loadtest should live in the scale-testing repo and we just see what sticks ... I am happy for this PR to be closed (as hyperfoil is sufficient loadtest), to proceed or maybe we move this to scaling-tests.

[helio-frota]

and simply run both

+1

or maybe we move this to scaling-tests.

+1

Maybe good to move there, some heavy refactor can happen (already happened) and the test will make no much sense now.

Anyways, great that things are moving.

yeah I'm based on this idea, to move the things a bit but not the final conclusion :+1: yet so I'm +1 to have both tests there on the scaling-tests repo.

[dejanb]

@JimFuller-RedHat @helio-frota Great. Thanks for the inputs. I agree, let's explore options and learn more before we commit to one approach or decide to keep both running. I'm OK with continuing this here for now or moving it to scaling-tests, whatever works best for you at the moment.

[JimFuller-RedHat]

ok ! I am going to close this and re raise something on scale-testing repo