jiebi/CodeConvo huggingface dataset:
Change:
t.Errorf("unexpected objects differerence after modifying status: %v", diff.ObjectDiff(statusVolumeAttachment, expectedVolumeAttachment)) } <del> // modifying spec should be dropped </del> <ins> // spec and metadata modifications should be dropped </ins> newVolumeAttachment := volumeAttachment.DeepCopy() newVolumeAttachment.Spec.NodeName = "valid-node-2" <ins> newVolumeAttachment.Labels = map[string]string{"foo": "bar"} newVolumeAttachment.Annotations = map[string]string{"foo": "baz"} newVolumeAttachment.OwnerReferences = []metav1.OwnerReference{ { APIVersion: "v1", Kind:       "Pod", Name:       "Foo", }, } </ins> StatusStrategy.PrepareForUpdate(ctx, newVolumeAttachment, volumeAttachment) if !apiequality.Semantic.DeepEqual(newVolumeAttachment, volumeAttachment) {

Discussion:
This came up as a follow up to Also rather than opening 5 different issues - we are going to use this github issue to track all follow up items mentioned here -
/sig storage
/assign /assign
: PR
and the rest is fixed in
Change:
"fmt" "path" "strings" <ins> "sync" </ins> "time" "github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2019-07-01/compute"

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: We found that cloud provider tries to attach a disk, it totally costs 121s in the end one minute(disk still in being detaching state), azure cloud provider tries to delete that disk and it succeeded 121s, attach disk operation succeeded and finally azure vm has attached one non-existing disk What you expected to happen: should not delete an azure disk when that disk is being attached How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The difficulty here is when a disk is being attached or detached, the disk state is still "unattached", would be the reason why delete disk at that time would succeed: Azure disk RP would have two options to fix this issue: a new disk state: , disk delete operation when disk is being attached or detached Otherwise on azure provider(client) side, we cannot know whether that disk is being attached or detached since the second delete disk operation is done after 1 min Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
cp "${KUBE_SERVER_BINARIES[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/server/bin/" <ins> # Include the client binaries here too as they are useful debugging tools. cp "${KUBE_CLIENT_BINARIES[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/server/bin/" </ins> local package_name="${RELEASE_DIR}/kubernetes-server-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." done

Discussion:
Currently the master VM specified by the Vagrantfile does not have the built kubecfg binary in the vagrant user's path. This request is to have this binary present on the host system and in the vagrant user's path so I can Vagrant ssh into the machine and do 'kubecfg list pods'.
I'm going to generalize this a little so that kubecfg is available in our general cluster install scripts. This should be easier as we move to binary installs.
Should be kubectl, not kubecfg, but otherwise is a good idea. etcd tools would be useful, too:
I'll take this on if no one else wants to do it. May take me a day or two to get to it.
Thinking out loud here... do we really want to encourage people to do admin and/or job runny stuff on their master?
I see it as a debugging tool.
Change:
path: ../_output/local/bin/logcheck.so description: structured logging checker original-url: k8s.io/logtools/logcheck <ins> forbidigo: analyze-types: true forbid: - p: ^managedfields.ExtractInto$ pkg: ^k8s.io/apimachinery/pkg/util/managedfields$ msg: should not be used because managedFields was removed - p: .Extract pkg: ^k8s.io/client-go/applyconfigurations/ msg: should not be used because managedFields was removed </ins> gocritic: staticcheck: checks:

Discussion:
Add a code static check for to report using server-side-apply extract With optimization of and , the will be removed in and , and maybe more of other components in the future, using Extract is problematic. It's safer to add this lint check.
/cc
/sig api-machinery
/sig scheduling /sig apps
/assign /triage accepted
Change:
} w.Write(LEVEL_1, "%stn", host) for _, path := range rules.HTTP.Paths { <del> w.Write(LEVEL_2, "t%s t%s (%s)n", path.Path, backendStringer(&path.Backend), i.describeBackend(ns, &path.Backend)) </del> <ins> w.Write(LEVEL_2, "t%s t%s (%s)n", path.Path, backendStringer(&path.Backend), i.describeBackend(ing.Namespace, &path.Backend)) </ins> } } if count == 0 {

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!--What happened: The issue is with the information provided for the rules, not about the default backend. Form the describe: Rules: Host Path Backends ---- ---- -------- hellonode hellonode:8080 (<none) the endpoint show none. and below is the ingress yaml file. apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hellonode spec: rules: host: hellonode http: paths: backend: serviceName: hellonode servicePort: 8080 What you expected to happen: it should show the service endpoint How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/area kubectl
/sig cli
Change:
key := strings.TrimSuffix(path.Base(url), ".txt") res, found := cases[key] if found { <del> if v.ErrorExpected { </del> <ins> if v.FetcherErrorExpected { </ins> return "error", errors.New("expected error") } return res.Content, nil

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: I was using kubeadm to generate cluster ca: The CA generation failed because of 502 bad gateway returned and the response body isn't empty when it's trying to fetch stable version from internet. In this case, the function returns error instead of falling back to local client version: is how kubeadm fetches stable version and is how the error is handled for . Should kubeadm always fall back to client version when there is any internet issue? Otherwise, this sounds defeat the purpose of fallback. /sig cluster-lifecycle What you expected to happen: kubeadm falls back to local client version when there is any internet issue. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.7 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
I'd like to take this issue. It would be better if you could give some directions. /assign
recreate the issue in kubernetes/kubeadm: /close
Closing this issue. <detailsIn response to : recreate the issue in kubernetes/kubeadm: 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
the fix will be removing the when failed to and add some unit test if I don't missing anything
Got it. Thanks.
Change:
# plugin by default. NETWORK_PLUGIN=${NETWORK_PLUGIN:-""} <del> # NETWORK_PLUGIN_PATH is the path to network plugin binary. NETWORK_PLUGIN_PATH=${NETWORK_PLUGIN_PATH:-""} </del> <ins> # CNI_CONF_DIR is the path to network plugin binaries. CNI_CONF_DIR=${CNI_CONF_DIR:-""} # CNI_BIN_DIR is the path to network plugin config files. CNI_BIN_DIR=${CNI_BIN_DIR:-""} </ins> # start_kubelet starts kubelet and redirect kubelet log to $LOG_DIR/kubelet.log. kubelet_log=kubelet.log

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.
Change:
return nil, nil } <del> // PodToleratesNodeTaints checks if a pod tolerations can tolerate the node taints func PodToleratesNodeTaints(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) { </del> <ins> // CheckNodeUnschedulablePredicate checks if a pod can be scheduled on a node with Unschedulable spec. func CheckNodeUnschedulablePredicate(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) { </ins> if nodeInfo == nil || nodeInfo.Node() == nil { return false, []algorithm.PredicateFailureReason{ErrNodeUnknownCondition}, nil }

Discussion:
DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by
Change:
<tbody> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">maxUnavailable</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding up. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td> <td class="tableblock halign-left valign-top"></td>

Discussion:
API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).
Change:
return stdout, stderr, err } <del> // WaitForStableCluster waits until all existing pods are scheduled and returns their amount. func WaitForStableCluster(c clientset.Interface, masterNodes sets.String) int { timeout := 10 * time.Minute startTime := time.Now() allPods, err := c.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{}) ExpectNoError(err) // API server returns also Pods that succeeded. We need to filter them out. currentPods := make([]v1.Pod, 0, len(allPods.Items)) for _, pod := range allPods.Items { if pod.Status.Phase != v1.PodSucceeded && pod.Status.Phase != v1.PodFailed { currentPods = append(currentPods, pod) } } allPods.Items = currentPods scheduledPods, currentlyNotScheduledPods := e2epod.GetPodsScheduled(masterNodes, allPods) for len(currentlyNotScheduledPods) != 0 { time.Sleep(2 * time.Second) allPods, err := c.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{}) ExpectNoError(err) scheduledPods, currentlyNotScheduledPods = e2epod.GetPodsScheduled(masterNodes, allPods) if startTime.Add(timeout).Before(time.Now()) { Failf("Timed out after %v waiting for stable cluster.", timeout) break } } return len(scheduledPods) } </del> // E2ETestNodePreparer implements testutils.TestNodePreparer interface, which is used // to create/modify Nodes before running a test. type E2ETestNodePreparer struct {

Discussion:
What would you like to be : is used at the beginning of some e2e scheduler tests to wait until the cluster is in a stable state. It currently waits until all existing pods are scheduled, but it should also wait until pods from previous tests are actually deleted. We can do this by assuming that pods should exist only in the kube-system namespace, and so WaitForStableCluster should wait until there are no pods in any other namespace. Why is this needed: /help /sig testing /sig scheduling
/milestone v1.17 /priority critical-urgent
/cc
I'll take this one, can't figure out how to get ci bot to assign to me...
/assign
/remove-help
Change:
cd ${TEMP_DIR} && sed -i.back "s|BASEIMAGE|${BASEIMAGE}|g" Dockerfile <del> docker buildx build  </del> <ins> DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build  </ins> --platform linux/${ARCH}  --load  --pull 

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: The overall job Since when has it been failing: Sometime between Jan 29 07:00 PST (commit ) and 16:13 PST (commit ) There are some runs that could not be scheduled on a node between these two runs, so it's not clear exactly when it started failing Testgrid link: https://k8s- Reason for failure: And then it spits out all the possible Docker options and commands. Anything else we need to know: Feels like it may be related to ? -- That was merged Jan 28 though, and there were successful runs between that and this run Spyglass example for failure: Contrast with Spyglass example for last success: /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
I confirm that I hit the same issue in a CI that builds kubernetes using
is removed in docker 20.10?
Looking into this /assign xref
xref /cc
Yeah docker buildx is not initialized within this job. Like mentioned, we probably broke other CI's too. I'm wondering if a init script would help us here, but I'm just trying to find out what the technical differences between the and are.
/assign
Change:
var _ http.Handler = hcHandler{} func (h hcHandler) ServeHTTP(resp http.ResponseWriter, req *http.Request) { <del> h.hcs.lock.Lock() </del> <ins> h.hcs.lock.RLock() </ins> svc, ok := h.hcs.services[h.name] if !ok || svc == nil { <del> h.hcs.lock.Unlock() </del> <ins> h.hcs.lock.RUnlock() </ins> klog.Errorf("Received request for closed healthcheck %q", h.name.String()) return } count := svc.endpoints <del> h.hcs.lock.Unlock() </del> <ins> h.hcs.lock.RUnlock() </ins> resp.Header().Set("Content-Type", "application/json") if count == 0 {

Discussion:
What would you like to be : Use read lock in ServeHTTP Why is this needed: Currently ServeHTTP (in ) takes the write lock: Since it only reads from h.hcs.services, holding read lock should suffice.
cc
/sig network
ping
looks good to me. Thanks!
Can you give /lgtm ?
ping
Change:
"k8s.io/kubernetes/pkg/client/restclient" "k8s.io/kubernetes/pkg/client/unversioned/remotecommand" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" <ins> "k8s.io/kubernetes/pkg/kubectl/resource" </ins> remotecommandserver "k8s.io/kubernetes/pkg/kubelet/server/remotecommand" "k8s.io/kubernetes/pkg/util/interrupt" "k8s.io/kubernetes/pkg/util/term"

Discussion:
I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.
Change:
#    shasum <tar> # 6. Update this file with new tar version and new hash <del> {% set etcd_version="v0.4.6" %} </del> <ins> {% set etcd_version="v2.0.0" %} </ins> {% set etcd_tar_url="https://storage.googleapis.com/kubernetes-release/etcd/etcd-%s-linux-amd64.tar.gz" | format(etcd_version)  %} <del> {% set etcd_tar_hash="sha1=5db514e30b9f340eda00671230d5136855ae14d7" %} </del> <ins> {% set etcd_tar_hash="sha1=b3cd41d1748bf882a58a98c9585fd5849b943811" %} </ins> etcd-tar: archive:

Discussion:
writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:
Change:
// The number of old ReplicaSets to retain to allow rollback. // This is a pointer to distinguish between explicit zero and not specified. <del> // Defaults to 2. </del> <ins> // Defaults to 10. </ins> // +optional optional int32 revisionHistoryLimit = 6;

Discussion:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps