Skip to content

Support to manage basic k6 resources #2129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 21 commits into from
May 6, 2025
Merged

Support to manage basic k6 resources #2129

merged 21 commits into from
May 6, 2025

Conversation

joanlopez
Copy link
Contributor

@joanlopez joanlopez commented Apr 14, 2025

It adds support for the following:

  • Resources:

    • Project
    • Project limits
    • Load test (w/ script)
    • Installation (k6 App)
  • Data sources:

    • Project
    • Project limits
    • Load test
    • Load tests (to query multiple load tests by project id)

Closes #2086

@joanlopez joanlopez requested review from Duologic and spinillos April 14, 2025 00:13
@joanlopez joanlopez self-assigned this Apr 14, 2025
@joanlopez joanlopez requested review from a team as code owners April 14, 2025 00:13
Copy link

In order to lower resource usage and have a faster runtime, PRs will not run Cloud tests automatically.
To do so, a Grafana Labs employee must trigger the cloud acceptance tests workflow manually.

@@ -4,6 +4,7 @@
/internal/resources/cloud/* @grafana/platform-monitoring @grafana/grafana-com-maintainers
/internal/resources/cloudprovider/* @grafana/platform-monitoring @grafana/middleware-apps
/internal/resources/connections/* @grafana/platform-monitoring @grafana/middleware-apps
/internal/resources/k6/* @grafana/platform-monitoring @grafana/k6-core
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like I don't have permission to add this team to the repository, can you help, please? 🙏🏻 cc/ @spinillos @Duologic

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also add: grafana/k6-backend, please?
This will likely be also co-owned by https://github.com/orgs/grafana/teams/k6-backend


Description: `
Sets up the k6 App on a Grafana Cloud instance and generates a token.
Once a Grafana Cloud stack is created, a user can either use this resource or go into the UI to install k6.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, why isn't this service part of the rergular Cloud Stack (via Stack State Service)? This pattern also exists for Synthetic Monitoring and we've notice it causes friction.

For example, someone already clicked the button in the UI and now tries to create it with Terraform as well, what happens then? Does the API return a token as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me invoke @d14c here, as I think he's the best candidate to answer to this one.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why isn't this service part of the rergular Cloud Stack (via Stack State Service)?

When the puguin was implemented SSS was not yet the service entirely responsible of provisioning the plugins, but neverthenless it seems good seperation to me that SSS is only responsible of the plugin provisioning /management (including jsonData nad secureJsonData) and the k6-cloud responsible of intitating the app state from k6-cloud perspective.

For example, someone already clicked the button in the UI and now tries to create it with Terraform as well, what happens then? Does the API return a token as well?

yes the initialization api is idempotent, if the app is already intialized it will return the master token.

{
category: "k6",
testCheck: func(t *testing.T, filename string) {
t.Skip() // TODO: Make all examples work
Copy link
Contributor Author

@joanlopez joanlopez Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All tests here are skipped, so I added the one for k6 examples but left it skipped as well, for now.

@Alex3k
Copy link

Alex3k commented Apr 25, 2025

@joanlopez - would this enable users to change the API used to api.staging.k6.io or does it hard code it to api.k6.io? I ask as we have a scenario internally where we use both

@joanlopez
Copy link
Contributor Author

@joanlopez - would this enable users to change the API used to api.staging.k6.io or does it hard code it to api.k6.io? I ask as we have a scenario internally where we use both

The k6 client, by default connects to api.k6.io, as you can see here. But, as you can also see here, the Terraform provider overwrites that configuration if either k6_url attribute or GRAFANA_K6_URL environment variable are provided.

@Alex3k
Copy link

Alex3k commented May 1, 2025

@joanlopez when this is released could we update https://docs.google.com/spreadsheets/d/1hBpYQpOq9MBlt1Fbf6A-JDsZmcf7y9BC-zk0hbJVCgo/edit?gid=0#gid=0 please? I wasn't sure if this is part of an official terraform provider release process or not but this sheet is proving incredibly useful in #terraform-provider

resource "grafana_k6_load_test" "test_load_test" {
project_id = grafana_k6_project.load_test_project.id
name = "Terraform Test Load Test"
script = <<-EOT
Copy link
Contributor

@fornfrey fornfrey May 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can script accept a .tar archive? If not, will the provider support multi-file test scripts in any other way?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a very good question @fornfrey. The short answer is: no.

The challenge here is that we don't have an easy and reproducible way to check for "changes" in the script if they use an archive. I've seen that, in case of creating a new load test with an archive, then the "script" can be retrieved from the API, but it returns some form of a UTF-8 representation of the contents of the archive, which looks similar to multipart, but doesn't make it easy to check for updates.

So, in this case, we should find an alternative way for doing so. For instance, the provider could define a couple of attributes, like script_file and script_file_hash, so it uses the hash of the local file to detect whenever the file pointed by the script_file attribute has changed. AFAIK that's the pattern that some providers use when dealing with files within Terraform modules.

That said, I'd suggest that, for now, we ship this initial support without, and to add that support in the next iteration.
So we unblock this initial release, users can test it, and give us feedback for that next iteration, beyond this specific "feature".

Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial concern was that we might need to change the scrip field schema to an object to support different types of scripts, but as you suggested, a separate field also solves this problem. I don't see a blocker here 👍

For instance, the provider could define a couple of attributes, like script_file and script_file_hash, so it uses the hash of the local file to detect whenever the file pointed by the script_file attribute has changed.

To clarify, will they be calculated internally in the provider based on script_file input rather than being requested from the user?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, will they be calculated internally in the provider based on script_file input rather than being requested from the user?

I'm not 100% sure how that's usually handled, but yes, I guess that could be an option. Alternatively, we may suggest users to use the filesha256 function.

@joanlopez joanlopez merged commit f09610a into main May 6, 2025
26 checks passed
@joanlopez joanlopez deleted the k6-support branch May 6, 2025 09:56
@joanlopez
Copy link
Contributor Author

joanlopez commented May 7, 2025

@joanlopez when this is released could we update https://docs.google.com/spreadsheets/d/1hBpYQpOq9MBlt1Fbf6A-JDsZmcf7y9BC-zk0hbJVCgo/edit?gid=0#gid=0 please? I wasn't sure if this is part of an official terraform provider release process or not but this sheet is proving incredibly useful in #terraform-provider

I don't know how frequently is this being updated, nor if it is up to date, but I have added the rows that correspond to resources/data sources added in this PR 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Creation of k6 resources ( project + role assignments)
6 participants