jiebi/CodeConvo huggingface dataset:
Change:
// ExponentialBackoff repeats a condition check with exponential backoff. // <del> // It checks the condition up to Steps times, increasing the wait by multiplying // the previous duration by Factor. // // If Jitter is greater than zero, a random amount of each duration is added // (between duration and duration*(1+jitter)). // // If the condition never returns true, ErrWaitTimeout is returned. All other // errors terminate immediately. </del> <ins> // It repeatedly checks the condition and then sleeps, using `backoff.Step()` // to determine the length of the sleep and adjust Duration and Steps. // Stops and returns as soon as: // 1. the condition check returns true or an error, // 2. `backoff.Steps` checks of the condition have been done, or // 3. a sleep truncated by the cap on duration has been completed. // In case (1) the returned error is what the condition function returned. // In all other cases, ErrWaitTimeout is returned. </ins> func ExponentialBackoff(backoff Backoff, condition ConditionFunc) error { for backoff.Steps > 0 { if ok, err := condition(); err != nil || ok {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: While revising clients of I noticed that some comments there are misleading or confusing or incomplete. I am looking , which is in the latest commit in at the moment. The comment on the field named says it must be greater than or equal to zero. The comment does not call out any special meaning for zero. The method tolerates any value in the field, but treats zero irregularly (taking it to mean roughly the same thing as 1). The comments about all say that it is applied after , and give no other information. The method reveals that there is a broader and clearer thing to say. There is logic that determines the progression of values for , and at each step the jitter is to the returned value after the update (if any) to . The comment on says flatly that it is "The number of steps before duration stops changing". But this is not true; also stops changing once it hits . The comments on and should more clearly indicate that they are peers in determining when the increases in stop. The comment on says "The returned duration will never be greater than cap before jitter is applied", but this is not true in the method. When , is ignored. The comment on only says it is used to determine when to stop changing . The function interprets as a limit on the number of iterations (making its effect of limiting increases moot). The comment on the function says "It checks the condition up to Steps times" but this is not true. If the hits the earlier than that, the iteration is cut short.
/remove-sig architecture
Change:
authenticationv1 "k8s.io/api/authentication/v1" "k8s.io/apimachinery/pkg/util/clock" "k8s.io/apimachinery/pkg/util/wait" <del> corev1 "k8s.io/client-go/kubernetes/typed/core/v1" </del> <ins> clientset "k8s.io/client-go/kubernetes" </ins> ) const (

Discussion:
/kind bug /priority failing-test /priority important-critical /milestone v1.11 /assign cc All GKE jobs are failing in various release dashboards. Code freeze for 1.11 is a couple of hours away.
Common error appears to be:
Failures seem to align with when was merged. But nothing in that PR seems suspicious. Having verify. Bringing up my own cluster on head to try and get a live cluster.
I have a quick try to reproduce one of the failure test cases by gcloud container clusters create --addons=HttpLoadBalancing,HorizontalPodAutoscaling,KubernetesDashboard --machine-type=n1-standard-2 --image-type=gci --num-nodes=3 --cluster-version=1.11.0-beta.1.222+ test- The cluster isn't up. What I observed is the following: 1) kubelet on master is in crash-loop due to a panic No other master components could be up. 2) kubelet is in crashloop in node as well.
/sig node Looks like has a patch up at
/priority critical-urgent
/status approved-for-milestone
Waiting for new runs to verify the fix. Will reopen this issue if needed
/reopen Reopening this one until its actually verified to ensure it shows up in our tracking queries.
I see the GKE tests cleaning up in the . still doesn't seem to have the change (will have to wait for cutover?). The fix looks promising. Will wait for a couple more runs before I close
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Action Required: This issue has not been updated since Jun 6. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
all the GKE ones still look good /close
Change:
# See the License for the specific language governing permissions and # limitations under the License. <del> FROM busybox </del> <ins> FROM BASEIMAGE </ins> MAINTAINER Tim Hockin <thockin@google.com> ADD serve_hostname /serve_hostname <del> ADD serve_hostname.go /serve_hostname.go </del> EXPOSE 9376 ENTRYPOINT ["/serve_hostname"]

Discussion:
cross-build , Supported arch are: amd64(default) arm arm64 ppc64le PR is . This issue and PR() is an effort to achieve multiarch Kubernetes()
Done.
Change:
}, "webhook": { SchemaProps: spec.SchemaProps{ <del> Description: "webhook describes how to call the conversion webhook. Required when `strategy` is set to `Webhook`.", </del> <ins> Description: "webhook describes how to call the conversion webhook. Required when `strategy` is set to `"Webhook"`.", </ins> Ref:         ref("k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1.WebhookConversion"), }, },

Discussion:
Currently we have inconsistency in most of the API where the field name should be used in description so the generated docs match the API fields people actually set. A linter could be for checking To avoid confusing users
/good-first-issue
/triage accepted
/assign
Hey can you provide some more information for this issue
are you still working on this?
Hey feel free to take it. I am unassigning myself
/triage needs-information /remove-good-first-issue
/sig api-machinery
Change:
}, err: true, }, <ins> { name:    "Score plugin return score greater than MaxNodeScore", plugins: plugin1And2, input: PluginToNodeScores{ scorePlugin1: { { Name:  "node1", Score: MaxNodeScore + 1, }, { Name:  "node2", Score: 3, }, }, scorePlugin2: { { Name:  "node1", Score: MinNodeScore, }, { Name:  "node2", Score: 5, }, }, }, err: true, }, { name:    "Score plugin return score less than MinNodeScore", plugins: plugin1And2, input: PluginToNodeScores{ scorePlugin1: { { Name:  "node1", Score: MaxNodeScore, }, { Name:  "node2", Score: 3, }, }, scorePlugin2: { { Name:  "node1", Score: MinNodeScore - 1, }, { Name:  "node2", Score: 5, }, }, }, err: true, }, </ins> } for _, tt := range tests {

Discussion:
What would you like to be : a default normalize score function in the scheduling framework. the plugin and log an error when the normalizing phase returns an invalid range of scores. Why is this needed: Per discussion in , we should enforce the range of score returned by the scoring plugin. /sig scheduling /priority important-soon /assign
Change:
HardPodAffinitySymmetricWeight: pointer.Int32Ptr(1), HealthzBindAddress:             pointer.StringPtr("0.0.0.0:10251"), MetricsBindAddress:             pointer.StringPtr("0.0.0.0:10251"), <ins> DebuggingConfiguration: componentbaseconfig.DebuggingConfiguration{ EnableProfiling:           &enable, EnableContentionProfiling: &enable, }, </ins> LeaderElection: kubeschedulerconfigv1alpha1.KubeSchedulerLeaderElectionConfiguration{ LeaderElectionConfiguration: componentbaseconfig.LeaderElectionConfiguration{ LeaderElect:       pointer.BoolPtr(true),

Discussion:
What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help
Change:
assert.NoError(t, err) // Verify container log symlink deletion <ins> // symlink is also tentatively deleted at startup </ins> err = ds.RemoveContainer(id) assert.NoError(t, err) <del> assert.Equal(t, fakeOS.Removes, []string{kubeletContainerLogPath}) </del> <ins> assert.Equal(t, []string{kubeletContainerLogPath, kubeletContainerLogPath}, fakeOS.Removes) </ins> } // TestContainerCreationConflict tests the logic to work around docker container

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have a transient local disk mounted under /var/lib/docker in order to take advantage of faster IO on Azure VMs. This means that all that data is lost when a reboot occurs, but the rest of the data outside that mountpoint persists. After the reboot, the existing pods are relaunched, and kubelet is unable to create the log file symlinks because they already exist, but they are pointing to an invalid place, that container no longer exists. Here are the relevant log lines: The old symlinks are there: What you expected to happen: The correct symlinks should overwrite the old ones. How to reproduce it (as minimally and precisely as possible): Erase /var/lib/docker between reboots with existing pods. Anything else we need to know?: No. Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-30T17:46:00Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Azure VMs OS (e.g. from /etc/os-release): Container Linux by CoreOS 1409.6.0 (Ladybug) Kernel (e.g. ): Linux node-2-vm 4.11.9-coreos SMP Thu Jul 6 00:54:42 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list .

The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
I think this falls under
Reiterating the mentions to trigger a notification: <detailsIn response to : I think this falls under Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
} <ins> func TestNumberConversion(t *testing.T) { codec := api.Codecs.LegacyCodec(schema.GroupVersion{Version: "v1"}) currentVersionedObject := &v1.Service{ TypeMeta:   metav1.TypeMeta{Kind: "Service", APIVersion: "v1"}, ObjectMeta: metav1.ObjectMeta{Name: "test-service"}, Spec: v1.ServiceSpec{ Ports: []v1.ServicePort{ { Port:     80, Protocol: "TCP", NodePort: 31678, }, }, }, } versionedObjToUpdate := &v1.Service{} versionedObj := &v1.Service{} patchJS := []byte(`{"spec":{"ports":[{"port":80,"nodePort":31789}]}}`) _, _, err := strategicPatchObject(codec, currentVersionedObject, patchJS, versionedObjToUpdate, versionedObj) if err != nil { t.Fatal(err) } ports := versionedObjToUpdate.Spec.Ports if len(ports) != 1 || ports[0].Port != 80 || ports[0].NodePort != 31789 { t.Fatal(errors.New("Ports failed to merge because of number conversion issue")) } } </ins> func TestPatchResourceWithVersionConflict(t *testing.T) { namespace := "bar" name := "foo"

Discussion:
When patching, in the type decoded from ToUnstructured mismatch with the one decoded form json.Unmarshal for numbers. Example: port: 80 in original object has type int64 port: 80 in original object has type float64 This is the root cause of
Change:
# Base images - name: "k8s.gcr.io/debian-base: dependents" <del> version: buster-v1.2.0 </del> <ins> version: buster-v1.3.0 </ins> refPaths: - path: build/workspace.bzl match: tag =

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
} return nil } <ins> // Convert_Slice_string_To_v1_DeletionPropagation allows converting a URL query parameter propagationPolicy func Convert_Slice_string_To_v1_DeletionPropagation(input *[]string, out *DeletionPropagation, s conversion.Scope) error { if len(*input) > 0 { *out = DeletionPropagation((*input)[0]) } else { *out = "" } return nil } </ins>

Discussion:
makes API server accepts DeleteOptions as a query parameter, but APIserver cannot parse , which is a new field in 1.6. Probably it's a bug in the parameterCodec. cc
IMO this is not a 1.6 release blocker
does this apply to all DeleteOptions fields? does a 1.5 server handle the orphanDependents field sent by correctly?
No, is handled correctly by the apiserver built from head. And for , because our generated clients still encode DeleteOptions as body, so they are not affected.
- we can close this one right?
/sig api-machinery
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Why was this closed? I'm using a Kubernetes 1.9 cluster and this is still an issue. If I pass propagationPolicy as part of the query string (as per the documentation), I still receive the same error message. If I pass a DeleteOptions object with the propagationPolicy within, it works.
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
what documentation were you referring to? Is it the openapi doc? I don't know if we can just deprecate the support of query parameters for DELETE. I understand it's a breaking change, but it has been broken for a year.
Everything in delete needs to be moved to query parameters (unfortunately) as it is apparently non-standard to have a body in a delete request.

Chao Xu <:
/reopen
/remove-lifecycle rotten
cc
/assign
The DELETE operation states that propagationPolicy is a query parameter. Is correct that it's non-standard to have a body on a delete request.
GKE default version is still 1.9.7
Change:
WantedBy=multi-user.target EOF <del> # Delete docker0 to avoid interference </del> <ins> # Flush iptables nat table </ins> iptables -t nat -F || true <del> ip link set docker0 down || true brctl delbr docker0 || true </del> systemctl start kubelet.service }

Discussion:
On a cluster using GCI, I'm not able to create docker containers using the docker CLI. On further introspection, it looks like bridge is being deleted. I consider this a regression. K8s used to allow creating docker containers out of band and in-fact it is a feature that is taken into account as part of k8s node features. To further exacerbate this issue, exists on containervm. We need to match the behavior between GCI and container-vm and ideally stop deleting docker0 bridge. cc
During GCI start up, got deleted to avoid overlapping cidr with . ref:
there's no need to delete docker0 afaik. It was deleted on gci master to fix the "overlapping cidr" problem, i.e we were supplying to kubelet on GKE master, and this resulted in 2 bridges with the same cidr. At the time I'd suggested passing the correct cidr. Don't remember where this discussion ended. Note that containers on docker0 with/without cni are broken anyway, we used to start docker with --bridge=cbr0, so would result in an ip from cbr0. This is no longer the case. We use kubenet to put containers on cbr0, so will result in an ip from docker0, which is not connected to nanything else.
This shouldn't cause docker crashes? you should still be able to create containers, just no networking. And networking is broken through docker CLI anyway because of the cni issue mentioned, or are you observing something different?
will return error. Have to add
Since bridge has been deleted, docker run by default will fail unless one overrides the network ns to be host or none.
so what we're really losing is the ability to docker run then talk to others (external internet, other pods) without net=host on GCI. This is useful and we should fix it, as mentioned earlier we probably don't need to delete docker0. docker run + others talking to us is broken because of the cni change, and will be broken even with docker0 (IMO this is fine).
cc
Yeah. I'd prefer ignoring docker0 as long as it doesn't affect kubelet functionality. , Prashanth B wrote:
Vish pointed out that of docker dies, docker0 comes back.

Given that we should be consistent. Either force docker not to create a bridge at all, EVER, or just ignore docker0. We may even want to consider assigning --bip= 169.254.123.0/24 or something, so we can reliably use 172.* for clusters eventually. , Vish Kannan wrote:
Change:
local count="0" until [[ "$count" == "1" ]]; do local minions <del> minions=$("${KUBE_ROOT}/cluster/kubectl.sh" get nodes -o template -t '{{range.items}}{{.metadata.name}}:{{end}}' --api-version=v1) </del> <ins> minions=$("${KUBE_ROOT}/cluster/kubectl.sh" get nodes -o template --template '{{range.items}}{{.metadata.name}}:{{end}}' --api-version=v1) </ins> count=$(echo $minions | grep -c "${MINION_IPS[i]}") || { printf "." sleep 2

Discussion:
When running the Vagrant Cluster Provider with the following deprecated message is displayed (with some context): Proposed Fix: Simple, change -t to --template in at line 240.
Closing issue as fix was merged.
Change:
} // h.prepPod will be reused in cleanupDriver. pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(h.prepPod) <del> Expect(err).ToNot(HaveOccurred(), "while creating hostpath init pod") </del> <ins> Expect(err).ToNot(HaveOccurred(), "while creating hostPath init pod") </ins> err = framework.WaitForPodSuccessInNamespace(f.ClientSet, pod.Name, pod.Namespace) <del> Expect(err).ToNot(HaveOccurred(), "while waiting for hostpath init pod to succeed") </del> <ins> Expect(err).ToNot(HaveOccurred(), "while waiting for hostPath init pod to succeed") </ins> err = framework.DeletePodWithWait(f, f.ClientSet, pod) <del> Expect(err).ToNot(HaveOccurred(), "while deleting hostpath init pod") </del> <ins> Expect(err).ToNot(HaveOccurred(), "while deleting hostPath init pod") </ins> } <del> func (h *hostpathSymlinkDriver) DeleteVolume(volType testpatterns.TestVolType) { </del> <ins> func (h *hostPathSymlinkDriver) DeleteVolume(volType testpatterns.TestVolType) { </ins> f := h.driverInfo.Framework cmd := fmt.Sprintf("rm -rf %v&& rm -rf %v", h.targetPath, h.sourcePath) h.prepPod.Spec.Containers[0].Command = []string{"/bin/sh", "-ec", cmd} pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(h.prepPod) <del> Expect(err).ToNot(HaveOccurred(), "while creating hostpath teardown pod") </del> <ins> Expect(err).ToNot(HaveOccurred(), "while creating hostPath teardown pod") </ins> err = framework.WaitForPodSuccessInNamespace(f.ClientSet, pod.Name, pod.Namespace) <del> Expect(err).ToNot(HaveOccurred(), "while waiting for hostpath teardown pod to succeed") </del> <ins> Expect(err).ToNot(HaveOccurred(), "while waiting for hostPath teardown pod to succeed") </ins> err = framework.DeletePodWithWait(f, f.ClientSet, pod) <del> Expect(err).ToNot(HaveOccurred(), "while deleting hostpath teardown pod") </del> <ins> Expect(err).ToNot(HaveOccurred(), "while deleting hostPath teardown pod") </ins> } // emptydir

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: https://k8s- What happened: The skip check for hostpath doesn't seem to be working for these test cases
can you take a look?
Oh, disruptive tests are the tests that can't be tested locally in my environment due to I will take a look.
I found that above issue is not related, I should have been checked more carefully. Sorry for that.
I found out that this was just a driver name issue, so below will fix it: hostpath -hostPath hostpathSymlink -hostPathSymlink We might be better changing the skip logic later, to make it skip not by name in order to avoid this kind of bug, though. I will make a PR for above change, soon.
I made a PR above. Also, it might be a bit out of scope of this fix, but are drivers tested with containerized volume server, like nfs, ceph, etc..., safe to be tested with subpath disruptive tests? I'm worrying about the case that test pod and containerized volume server are deployed on the same node. In such a case, the same behaviour expected or do we need to avoid this kind of situation?