Provide a mechanism to allow updates in certain time window

[gthao313]

users could have workload that cannot be interrupted during some periods of the day, so we provide a mechanism to prevent Bottlerocket nodes update on user customized time window.

Issue number:

Closes: #67

Description of changes:

Author: Tianhao Geng <tianhg@amazon.com>

Provide a mechanism to allow updates in certain update time window

Users could have workload that cannot be interrupted during some periods
of the day, so we provide a mechanism to allow Bottlerocket nodes updates
on user customized update time window. Beyond update time window,
bottlerocker update operator will prevent any updates.

Testing done:
Set up update time window and then confirm if brupop stops updating nodes except in-process node.

UPDATE_WINDOW_START=23:55:0
UPDATE_WINDOW_STOP=0:10:0

UPDATE_WINDOW_START=0:15:0
UPDATE_WINDOW_STOP=0:24:0

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.

[gthao313]

This PR has conflicts with #238. I'll solve the conflicts when #238 is merged.

[gthao313]

Push above:

1. Add a buffer 6 mins before time window coming - this can make sure that brupop completes in-process updates and doesn't have any actions when time window starts.
   2.Add a strategy to deal with if window start time later than end time - will recognize it as cross day period. like 11pm to 2am.
2. rename time window related env variable.
3. rebase

[jpmcb]

This looks good to me! Just a few doc nits

---

Testing:

Build the image from this pull request and deployed to a cluster with v1.9.1 nodes. I set the following parameters for the time window:

            - name: PREVENT_UPDATE_SINCE
              value: "19:0:0"
            - name: PREVENT_UPDATE_UNTIL
              value: "20:0:0"

Where the current utc time was 19:45 - I saw that the bottlerocketshadows were idel until just after 20:00 where the update occurred

---

On the discussion if pushing a currently updating BR node to completion if the time window is reached is a good idea or not, I don't have enough context to have a strong opinion. But, I think this behavior is fine for now and if we get user feedback that it's not what they want or expected, we can re-visit it 👍🏼

[webern]

Flipping this around might be easier to understand:

UPDATE_WINDOW_BEGIN
UPDATE_WINDOW_END

Or

UPDATE_WINDOW_START
UPDATE_WINDOW_STOP

[gthao313]

@webern you think it's better to rename or you think use update window logic instead of prevent window logic?

[webern]

It seems more cognitively intuitive to me since I am familiar with the idea of a "maintenance window", but not a "no maintenance window".

[gthao313]

I see, that's a good point!
I'd like to keep "no maintenance window" because actually this feature was asked by customers when we was implementing brupop 0.1.0. Customer wanted us to provide a feature which can prevent update on current time. Therefore, I implemented on this way.

I like maintenance window this idea, if you think it worths to do in this way, I can update it! thanks : )

[jpmcb]

Hmmm Matt brings up a good point: I'd be surprised if update windows were extremely wide leading to the need for "preventative, no maintenance" windows. My assumption is that most people running kubernetes clusters will have small windows of time when updates should be allowed.

So, that's a +1 from me for UPDATE_WINDOW_START and UPDATE_WINDOW_END

[gthao313]

Push above changes logic from prevent update time window to update time window - "maintenance window".

[jpmcb]

Deployed a nodegroup with bottlerocket version 1.9.0 and applied the update operator yamls with

            - name: UPDATE_WINDOW_START
              value: "17:0:0"
            - name: UPDATE_WINDOW_STOP
              value: "18:0:0"

where the current UTC was ~16:45. I watched the nodes in the background and saw them begin to update at 17:00. Great work!!!!! 👏🏼

[gthao313]

Push above Rebase and fix README according to Matt's comments.