use current time for running daily release#3507
use current time for running daily release#3507istio-merge-robot merged 4 commits intoistio:masterfrom rkpagadala:master
Conversation
There was a problem hiding this comment.
that was some weird UTC / date mix is it not anymore? 8a pst is probably too late if it takes 1h+ to make let's keep it around 1am or maybe up to 4a but not later ?
There was a problem hiding this comment.
We are trying to align the release cut off time and pipeline schedule.
The idea is to have a new daily build in the morning PST. We can do 6:15am so we normally can get a daily release by 07:30-ish PST.
There was a problem hiding this comment.
@hklai and @rkpagadala when back and forth on this question. There will always be people submitting code at midnight who want it in the build and others that want the build available first thing in the morning so there is no right answers. If we had people in New York working on istio 8 AM would be 11 AM witch is quite late. However under the current green build system(runs every two hours) you need to get code in by 11 PM for it to be in the next days daily. Best that we atlest make sure all code from day -1 is part of the build. The key is to not keep changing it or everyone will be confused.
There was a problem hiding this comment.
right now it seems it changed to noon somehow which is close to the worst possible time
let's do the builds between 1a and 4a PST
There was a problem hiding this comment.
I think the execution_time problem made it a lot more confusing, when the build cut at 1am was labeled as one day before.
With that now fixed, I am fine with sticking with 1am. However, that practical means the release candidate cut off day is on 14th 1am PST.
I will amend the release process to make it clear.
There was a problem hiding this comment.
if you prefer to make it 11:59pm (23:59) so it stays 'end' of the 14th or 01:00a on the 15 it's all good/fine - up to you as long as it's clear and at night (and I don't mind 1a 14th either)
thanks!
There was a problem hiding this comment.
fun fact: we have to be careful to not pick 2a local time for instance that can get a) skipped, b) ran twice during daylight savings
|
/retest |
There was a problem hiding this comment.
Let's add a comment to explain the problem of execution_date.
There was a problem hiding this comment.
We are trying to align the release cut off time and pipeline schedule.
The idea is to have a new daily build in the morning PST. We can do 6:15am so we normally can get a daily release by 07:30-ish PST.
There was a problem hiding this comment.
I think the execution_time problem made it a lot more confusing, when the build cut at 1am was labeled as one day before.
With that now fixed, I am fine with sticking with 1am. However, that practical means the release candidate cut off day is on 14th 1am PST.
I will amend the release process to make it clear.
prow/OWNERS
Outdated
| - sebastienvas | ||
| - yutongz | ||
|
|
||
| - rkpagadala |
There was a problem hiding this comment.
please sort alphabetically, same below.
run daily at 1 am pst, tag daily releases
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ldemailly The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
/test all [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue. |
|
@rkpagadala: The following test failed, say
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
| config_settings['GCS_FULL_STAGING_PATH'] = '{}/{}'.format( | ||
| config_settings['GCS_STAGING_BUCKET'], gcs_path) | ||
| config_settings['ISTIO_REPO'] = 'https://github.com/{}/{}.git'.format( | ||
| config_settings['GITHUB_ORG'], config_settings['GITHUB_REPO']) |
There was a problem hiding this comment.
we removed extra space, what is remaining is intentional
| bash_command=gcr_tag_success, | ||
| dag=dag, | ||
| ) | ||
| # skip_grc = DummyOperator( |
There was a problem hiding this comment.
will followup in a different PR
|
sorry it merged already |
* WorkloadInstance gets correct clusterID * Workloads have a draining weight The amount of traffic is controlled by the draining weight which is a value from 0 to 100. The default is 0 which means no draining. When the weight is 100, no traffic will be sent to that endpoint.
No description provided.