Add v0.27.0 release notes

[imiric]

No description provided.

[codecov-commenter]

Codecov Report

Merging #1507 into master will increase coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1507      +/-   ##
==========================================
+ Coverage   77.18%   77.21%   +0.03%     
==========================================
  Files         162      162              
  Lines       13172    13172              
==========================================
+ Hits        10167    10171       +4     
+ Misses       2485     2481       -4     
  Partials      520      520              

Impacted Files	Coverage Δ
stats/cloud/collector.go	79.04% <0.00%> (+0.59%)	⬆️
js/runner.go	83.73% <0.00%> (+0.69%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dc31776...357b718. Read the comment docs.

[mstoykov]

LGTM, some more issues should be linked and I have small nitpicks on the wording here and there

[mstoykov]

This is probably ... a bug ? (or to keep it the same as before 1007), but the externally-controlled executor does call gracefulStop if it's pausing vus ...
cc @na--

[imiric]

I'll fallback to @na-- on how to reword this, as I just copied it from 1007.

[na--]

hmm it's a bit tricky - the externally-controlled executor doesn't have gracefulStop as an option... but it's true that when you pause it, it calls the vuHandle.gracefulStop() method. This was done to preserve the logic of how "pausing" worked in the old k6, which didn't interrupt any running iterations, it just stopped k6 from making new iterations, i.e. what gracefulStop does: https://github.com/loadimpact/k6/blob/459da79ef51b37e5eaba4575c9065d9e592e5c49/core/local/local.go#L234-L250

so, I think the sentence here is technically correct... also, I think this whole paragraph should be more prominent, i.e. moved somewhere on top of the breaking changes, in second place perhaps?

[imiric]

I moved this higher up, but maybe we should explain why the externally-controlled executor doesn't have the option? We mention it here and it the new docs, but it's never explained.

Since it's technically still using vuHandle.gracefulStop() it would make sense to be able to define this value in the config too. Avoiding special cases is always good if possible. :)

[na--]

Calling vuHandle.gracefulStop() is very much not the same thing as the gracefulStop option. It just means "don't start more iterations with this VU", whereas the option the gracefulStop option implies "don't start new iterations and call hardStop after this period, if an iteration was still running".

And yes, if there's a sufficiently high demand for it, we could probably implement support for the gracefulStop option in the externally-controlled executor as well. As to why we haven't, it's because of a couple of reasons:

• the externally controlled executor is pretty much the least important executor of them all, for now, it exists mostly because of keeping some backwards compatibility and because it might be useful to a small number of people
• users of the externally-controlled executor can achieve exactly the same result pretty easily with just the k6 REST API, if they want to - instead of directly setting the running VUs to 0, you can first run k6 pause, wait 30 seconds (or however long you want to give VUs to finish gracefully), and then set the active VUs to 0 - hey, presto, you have gracefulStop 😄

Though you are right, that second fact is probably worth mentioning in the docs, though probably not in the release notes

[mstoykov]

Well, they can't have something like going down from 100 to 50 VUs gracefully ... but to be honest I don't like the externally-controlled executor and unless there is demand I am for not touching it :D

[na--]

Still haven't read this, just commenting on something that seems to be missing after remembering it and not finding it with Ctrl+F here 😅 We should mention that we've changed the default setupTimeout and teardownTimeout values to 60s (were 10s before) - #1356. This is also something we should update in https://k6.io/docs/using-k6/options#setup-timeout

[imiric]

@na-- That's a breaking change, right? I added it in 4df3093.

[na--]

hmm it's a bit tricky - the externally-controlled executor doesn't have gracefulStop as an option... but it's true that when you pause it, it calls the vuHandle.gracefulStop() method. This was done to preserve the logic of how "pausing" worked in the old k6, which didn't interrupt any running iterations, it just stopped k6 from making new iterations, i.e. what gracefulStop does: https://github.com/loadimpact/k6/blob/459da79ef51b37e5eaba4575c9065d9e592e5c49/core/local/local.go#L234-L250

so, I think the sentence here is technically correct... also, I think this whole paragraph should be more prominent, i.e. moved somewhere on top of the breaking changes, in second place perhaps?

[mstoykov]

LGTM, I am pretty sure we've missed something, so I will go through all the issues/PRs marked as 0.27.0 and try to see if we've missed something, it's probably good idea for all of us to do it, though :D

[na--]

LGTM besides the last few minor corrections I suggested inline. Also, please squash this when merging it in master 😄