Skip to content
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

release-24.2: roachtest: don't report VM preemptions on github #131091

Merged
merged 2 commits into from
Sep 23, 2024

Conversation

blathers-crl[bot]
Copy link

@blathers-crl blathers-crl bot commented Sep 20, 2024

Backport 2/2 commits from #130976 on behalf of @renatolabs.

/cc @cockroachdb/release


The new registry.NonReportableError can be used in situations where an error
happens in a test but we do not want to create (or update) a GitHub
issue for it. The mechanism introduced here can be used either in the
test runner, or in tests themselves. For now, they are only used when
a VM is preempted.

We have enabled spot VMs with a higher probability and backported this
behaviour to several release branches. It's not really useful or
actionable to have a GitHub issue for every preemption. Instead, this
kind of data is better analyzed at a higher level, on an analytical
database, using dashboards.

Epic: none

Release note: None


Release justification: test only changes.

`shouldPost` used to return `(bool, string)` but, in reality, the bool
value just encoded the whether the returned string was empty. Simplify
that function by returning a single value and having callers be
explicit about checking the skip reason.

Epic: none

Release note: None
`registry.NonReportableError` can be used in situations where an error
happens in a test but we do not want to create (or update) a GitHub
issue for it. The mechanism introduced here can be used either in the
test runner, or in tests themselves. For now, they are only used when
a VM is preempted.

We have enabled spot VMs with a higher probability and backported this
behaviour to several release branches. It's not really useful or
actionable to have a GitHub issue for every preemption. Instead, this
kind of data is better analyzed at a higher level, on an analytical
database, using dashboards.

Epic: none

Release note: None
@blathers-crl blathers-crl bot requested a review from a team as a code owner September 20, 2024 14:12
@blathers-crl blathers-crl bot force-pushed the blathers/backport-release-24.2-130976 branch from 350691b to ae19630 Compare September 20, 2024 14:12
@blathers-crl blathers-crl bot added blathers-backport This is a backport that Blathers created automatically. O-robot Originated from a bot. labels Sep 20, 2024
@blathers-crl blathers-crl bot requested review from DarrylWong, renatolabs, herkolategan, nameisbhaskar and vidit-bhat and removed request for a team September 20, 2024 14:12
Copy link
Author

blathers-crl bot commented Sep 20, 2024

Thanks for opening a backport.

Please check the backport criteria before merging:

  • Backports should only be created for serious
    issues
    or test-only changes.
  • Backports should not break backwards-compatibility.
  • Backports should change as little code as possible.
  • Backports should not change on-disk formats or node communication protocols.
  • Backports should not add new functionality (except as defined
    here).
  • Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
  • All backports must be reviewed by the owning areas TL. For more information as to how that review should be conducted, please consult the backport
    policy
    .
If your backport adds new functionality, please ensure that the following additional criteria are satisfied:
  • There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
  • The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
  • New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
  • The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
  • Your backport must be accompanied by a post to the appropriate Slack
    channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

@blathers-crl blathers-crl bot added the backport Label PR's that are backports to older release branches label Sep 20, 2024
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@srosenberg srosenberg self-requested a review September 20, 2024 22:36
@renatolabs
Copy link
Contributor

TFTR!

@renatolabs renatolabs merged commit d47234c into release-24.2 Sep 23, 2024
19 of 20 checks passed
@renatolabs renatolabs deleted the blathers/backport-release-24.2-130976 branch September 23, 2024 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport Label PR's that are backports to older release branches blathers-backport This is a backport that Blathers created automatically. O-robot Originated from a bot.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants