k6 icon indicating copy to clipboard operation
k6 copied to clipboard

Change config directory name from "loadimpact" to "k6"

Open MattDodsonEnglish opened this issue 2 years ago • 7 comments

Feature Description

Looking in my .config , I happened to notice the loadimpact directory. Inside that directory, there was a k6 directory, which had a config.json file with my API key.

Can the loadimpact part be removed? Users looking for their configs will be much more likely to look for k6. Besides, not everyone will associate k6 with loadimpact. As time goes on, this association will become weaker and weaker, too, as the official business name is now k6.

Suggested Solution (optional)

$XDG_CONFIG_HOME/k6/config.json

For example, ~/.config/loadimpact/k6/config.json ~/.config/k6/config.json

Appropriate default directory locations might be different on Mac and Windows.

MattDodsonEnglish avatar Apr 28 '22 09:04 MattDodsonEnglish

This will likely also mean that we need code to:

  1. copy the old config in the place of the new one if it doesn't exist. But print warning if it does
  2. delete the old, so we don't print warnings.

Hopefully with the latest changes to the cmd package this will need less hacks to implement :crossed_fingers:

mstoykov avatar Apr 28 '22 09:04 mstoykov

Yeah, not sure how we should handle old configs, but this should definitely be easier to implement and test nowadays :crossed_fingers:

We should probably look into how other grafana projects handle this, if they have similar config files in .config/grafana, so we can move ours to .config/grafana/k6? :thinking:

Personally, I am slightly against automatically moving .config/loadimpact during a k6 run command. Instead, I think we should:

  • support both .config/loadimpact and .config/grafana during k6 run, k6 cloud, etc., with .config/grafana being checked for and used first, and .config/loadimpact emitting a deprecation warning if it ends up being loaded
  • move the config files when k6 login is executed (and explain that in the deprecation warning :arrow_up: )

na-- avatar Apr 28 '22 09:04 na--

I realized that the docs will need to be updated in a few places if this change happens:

  • [ ] https://k6.io/docs/cloud/integrations/token/#authentication-with-a-config-file
  • [ ] https://k6.io/docs/using-k6/options/#config ( or /docs/using-k6/k6-options/reference#config )

MattDodsonEnglish avatar Jun 08 '22 08:06 MattDodsonEnglish

I would go with .config/k6

As far as I know, in the Grafana world, this pattern doesn't exist. Also, it looks easier to find for k6 users.

dgzlopes avatar May 03 '23 14:05 dgzlopes

+1 to I would go with .config/k6 for the same reasons Daniel mentions.

As for the deprecation warning, it would be good if it included instructions for updating (link to doc if not simple).

Sounds like for users using Grafana Cloud k6 - k6 login would be the proposed quick way to update. But how would this work for pure OSS users? What would they need to do?

markjmeier avatar May 03 '23 14:05 markjmeier

Sounds like for users using Grafana Cloud k6 - k6 login would be the proposed quick way to update. But how would this work for pure OSS users? What would they need to do?

k6 login should be the unique command that writes the config, right? If k6 run and k6 cloud both support the two file paths as Ned suggested then we don't need to differentiate the cases.

When the user runs for the first time with the new version they will see the warning, so they can:

  • if they are still using the influxdb/cloud output then they can re-run k6 login and the config will be migrated otherwise
  • if they are not using the output anymore then they could drop the config file to not see the warning again

The unique edge case I've found is if they are using a custom config that they want to keep but they are not using the output and they wouldn't log in again. In this case, they should migrate the config manually.

Having the migration on k6 run and k6 cloud could be easier but I agree with Ned that having this migration on the main commands is a risk not justified by the benefits (with the assumption in mind that the most used case will be to just log in again).

codebien avatar May 04 '23 08:05 codebien

Also of note is that we do print where the default config is being loaded from on help (cut to the important parts

$ k6 --help
...
  -c, --config string       JSON config file (default "/home/mstoykov/.config/loadimpact/k6/config.json")
...

mstoykov avatar May 09 '23 08:05 mstoykov