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

updata: allow specifying a start time for waves #927

Merged
merged 1 commit into from
May 15, 2020

Conversation

tjkirch
Copy link
Contributor

@tjkirch tjkirch commented May 14, 2020

Previously, wave start times would always be relative to when you ran updata,
meaning you'd have to hold off on running updata until you were ready to start
a release process. This lets you (optionally) pick any start time for the
start of the waves, and the given start_after offsets will be relative to that
time.

To keep the code and the deployment process simple, this also requires
specifying relative offsets in wave definition files, rather than absolute
times; we only used relative offsets anyway so that the files were reusable and
it was easier to understand the delays between waves, but this codifies that
behavior.


This caused pain in the 0.3.3 release, requiring rework and a changed deployment plan, so I wanted to fix it before the next release.

Testing done:

Start with no waves:

$ jq '.updates[].waves' manifest.json
{}

Add waves with no start-at argument, as we have before:

$ cargo run --bin updata -- set-waves manifest.json --arch x86_64 --version 0.3.3 --variant aws-k8s-1.15 --wave-file ../waves/accelerated-waves.toml

We see the waves are relative to when I ran the command, as before.

$ jq '.updates[].waves' manifest.json
{
  "0": "2020-05-14T23:06:11.364246960Z",
  "61": "2020-05-15T02:06:11.364246960Z",
  "245": "2020-05-15T06:06:11.364246960Z",
  "1024": "2020-05-15T22:06:11.364246960Z"
}

$ date -u
Thu May 14 22:06:18 UTC 2020

Now run with a start-at next month, and we see the waves start next month as expected:

$ cargo run --bin updata -- set-waves manifest.json --arch x86_64 --version 0.3.3 --variant aws-k8s-1.15 --wave-file ../waves/accelerated-waves.toml --start-at '2020-06-01T00:00:00Z'

$ jq '.updates[].waves' manifest.json
{
  "0": "2020-06-01T01:00:00Z",
  "61": "2020-06-01T04:00:00Z",
  "245": "2020-06-01T08:00:00Z",
  "1024": "2020-06-02T00:00:00Z"
}

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

Previously, wave start times would always be relative to when you ran updata,
meaning you'd have to hold off on running updata until you were ready to start
a release process.  This lets you (optionally) pick any start time for the
start of the waves, and the given start_after offsets will be relative to that
time.

To keep the code and the deployment process simple, this also requires
specifying relative offsets in wave definition files, rather than absolute
times; we only used relative offsets anyway so that the files were reusable and
it was easier to understand the delays between waves, but this codifies that
behavior.
@tjkirch tjkirch requested review from zmrow and sam-aws May 14, 2020 22:17
Copy link
Contributor

@zmrow zmrow left a comment

Choose a reason for hiding this comment

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

🎧

Nice and clean. :)

@tjkirch tjkirch merged commit db32a93 into bottlerocket-os:develop May 15, 2020
@tjkirch tjkirch deleted the set-wave-relative branch May 15, 2020 17:44
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.

3 participants