Bug 1841057: Skip the initial upload delay

[martinkunc]

If the operator is started for the first time, or if it is not degraded, it will upload the collected data immediately after they are collected.

This is removing the original initial jitter delay between periods. Consequent runs will still be jittered. The 15 seconds detection of data to send is still there even for initial run, so the data should arrive in 15 seconds after they are collected (few seconds).

[openshift-ci-robot]

@martinkunc: This pull request references Bugzilla bug 1841057, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target release (4.5.0) matches configured target release for branch (4.5.0)
• bug is in the state NEW, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1841057: Skip the initial upload delay

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.

[martinkunc]

@iNecas Would you please have some time to look at this PR ? Thank you..

[tisnik]

It looks ok, thank you!

[tisnik]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: martinkunc, tisnik

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [martinkunc,tisnik]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@martinkunc: All pull requests linked via external trackers have merged: openshift/insights-operator#117. Bugzilla bug 1841057 has been moved to the MODIFIED state.

In response to this:

Bug 1841057: Skip the initial upload delay

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.

[martinkunc]

/cherrypick release-4.4

[openshift-cherrypick-robot]

@martinkunc: new pull request created: #118

In response to this:

/cherrypick release-4.4

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.

[martinkunc]

/cherrypick release-4.3

[openshift-cherrypick-robot]

@martinkunc: new pull request created: #120

In response to this:

/cherrypick release-4.3

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.

[openshift-cherrypick-robot]

@martinkunc: new pull request created: #121

In response to this:

/cherrypick release-4.2

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.

[smarterclayton]

The reason we did this was so that if the operator went into a crashloop it would not overwhelm the upstream server. How will you mitigate that now after this change went in?

[martinkunc]

The reason we did this was so that if the operator went into a crashloop it would not overwhelm the upstream server. How will you mitigate that now after this change went in?

@smarterclayton I was hoping that skipping fast upload on Operator's degrated status would be enough. Are you suggesting that I should add detection for POD status as well ? I was thinking about something like this:

pod, _  := gatherKubeClient.CoreV1().Pods(os.Getenv("POD_NAMESPACE")).Get(os.Getenv("POD_NAME"))
allHealthy := true
for _, c := range pod.Status.ContainerStatuses {
	allHealthy = allHealthy && c.RestartCount == 0
}
if allHealthy // fast upload

Do you think it would be better ?

Also I found that I should turn off the consequent fast upload after first successfull upload, rather that based only on non initial call of updateStatus, because Gathering might not be finished for larger clusters at time when updateStatus is called next time.

[martinkunc]

@smarterclayton I realized that Restarts can be something good as well. Would there be a better way, maybe checking LastTerminationState?=State.ExitCode != 0
Would it be good enough ?

[martinkunc]

Trying to address the better status check in #132

[martinkunc]

/cherrypick release-4.4

[openshift-cherrypick-robot]

@martinkunc: failed to push cherry-picked changes in GitHub: pushing failed, output: "To https://github.com/openshift-cherrypick-robot/insights-operator\n ! [rejected] cherry-pick-117-to-release-4.4 -> cherry-pick-117-to-release-4.4 (non-fast-forward)\nerror: failed to push some refs to 'https://openshift-cherrypick-robot:CENSORED@github.com/openshift-cherrypick-robot/insights-operator'\nhint: Updates were rejected because the tip of your current branch is behind\nhint: its remote counterpart. Integrate the remote changes (e.g.\nhint: 'git pull ...') before pushing again.\nhint: See the 'Note about fast-forwards' in 'git push --help' for details.\n", error: exit status 1

In response to this:

/cherrypick release-4.4

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.