Skip to content

use current time for running daily release#3507

Merged
istio-merge-robot merged 4 commits intoistio:masterfrom
rkpagadala:master
Feb 19, 2018
Merged

use current time for running daily release#3507
istio-merge-robot merged 4 commits intoistio:masterfrom
rkpagadala:master

Conversation

@rkpagadala
Copy link
Copy Markdown
Contributor

No description provided.

@rkpagadala rkpagadala requested a review from a team February 15, 2018 01:51
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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 ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this was on request of @hklai

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Member

@ldemailly ldemailly Feb 17, 2018

Choose a reason for hiding this comment

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

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!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

@rkpagadala rkpagadala requested review from a team, hklai and sebastienvas February 15, 2018 18:23
@rkpagadala
Copy link
Copy Markdown
Contributor Author

/retest

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Let's add a comment to explain the problem of execution_date.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

please sort alphabetically, same below.

run daily at 1 am pst, tag daily releases
@ldemailly
Copy link
Copy Markdown
Member

/lgtm
btw please see #3609

@istio-merge-robot
Copy link
Copy Markdown

[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.

Details Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@istio-merge-robot
Copy link
Copy Markdown

/test all [submit-queue is verifying that this PR is safe to merge]

@istio-merge-robot
Copy link
Copy Markdown

Automatic merge from submit-queue.

@istio-merge-robot istio-merge-robot merged commit 7acfd1e into istio:master Feb 19, 2018
@istio-testing
Copy link
Copy Markdown
Collaborator

@rkpagadala: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
prow/istio-pilot-e2e.sh b7f21e3 link /test istio-pilot-e2e
Details

Instructions 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.

Copy link
Copy Markdown
Contributor

@hklai hklai left a comment

Choose a reason for hiding this comment

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

/lgtm

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'])
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

extra space intentional?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

we removed extra space, what is remaining is intentional

bash_command=gcr_tag_success,
dag=dag,
)
# skip_grc = DummyOperator(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Remove?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

will followup in a different PR

@ldemailly
Copy link
Copy Markdown
Member

sorry it merged already

PetrMc pushed a commit to PetrMc/istio-petrmc-upstream-fork that referenced this pull request Jan 14, 2026
* 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.
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.

8 participants