jiebi/CodeConvo huggingface dataset:
Change:
stripped := []byte{} lines := bytes.Split(file, []byte("n")) for i, line := range lines { <del> if bytes.HasPrefix(bytes.TrimSpace(line), []byte("#")) { </del> <ins> trimline := bytes.TrimSpace(line) if bytes.HasPrefix(trimline, []byte("#")) && !bytes.HasPrefix(trimline, []byte("#!")) { </ins> continue } stripped = append(stripped, line...)

Discussion:
configmap, like edit configmap test, and make some error and write-save, will see below when the content after edited is invalid, should not remove data , thus mean expect content below configmap 2 edit configmap make invalid No response version kubeadm <details</details<details</details<details</details
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
/sig cli
PTAL
Hi, I am new to this project and would love to contribute. Can I work on this issue?
/sig cli
Change:
apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/wait" <ins> authauthenticator "k8s.io/apiserver/pkg/authentication/authenticator" </ins> "k8s.io/apiserver/pkg/authentication/group" "k8s.io/apiserver/pkg/authentication/request/bearertoken" <ins> authenticatorunion "k8s.io/apiserver/pkg/authentication/request/union" </ins> "k8s.io/apiserver/pkg/authentication/user" "k8s.io/apiserver/pkg/authorization/authorizer" "k8s.io/apiserver/pkg/authorization/authorizerfactory"

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig api-machinery
/assign I want to take a try
2 but actual 0 till timeout resource services, expected 2, actual 0 error waiting or ResourceQuota status: timed out waiting for the condition time later, actual state became 2 Seems polls a ResourceQuota status with timeout 10s may be not enough, we should enlarge it into 300s, that is poll for 300s timeout instead of 10s.
/triage accepted
Change:
<ins> /* Copyright 2022 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package fake import ( "context" v1 "k8s.io/api/core/v1" policy "k8s.io/api/policy/v1" meta_v1 "k8s.io/apimachinery/pkg/apis/meta/v1" "testing" ) func TestNewSimpleClientset(t *testing.T) { client := NewSimpleClientset() client.CoreV1().Pods("default").Create(context.Background(), &v1.Pod{ ObjectMeta: meta_v1.ObjectMeta{ Name:      "pod-1", Namespace: "default", }, }, meta_v1.CreateOptions{}) client.CoreV1().Pods("default").Create(context.Background(), &v1.Pod{ ObjectMeta: meta_v1.ObjectMeta{ Name:      "pod-2", Namespace: "default", }, }, meta_v1.CreateOptions{}) err := client.CoreV1().Pods("default").EvictV1(context.Background(), &policy.Eviction{ ObjectMeta: meta_v1.ObjectMeta{ Name: "pod-2", }, }) if err != nil { t.Errorf("TestNewSimpleClientset() res = %v", err.Error()) } pods, err := client.CoreV1().Pods("default").List(context.Background(), meta_v1.ListOptions{}) // err: item[0]: can't assign or convert v1beta1.Eviction into v1.Pod if err != nil { t.Errorf("TestNewSimpleClientset() res = %v", err.Error()) } else { t.Logf("TestNewSimpleClientset() res = %v", pods) } } </ins>

Discussion:
After I evicted an pod, I performed the operation of the full list instance, but found something that did not meet expectations After pods are evicted, non-evicted ones can be listed normally No response <details</detailsv1.20.0 <details</details<details</details<details</details<details</details<details</details
/sig node
/sig api-machinery /remove-sig node
/remove-sig api-machinery
/assign since you are tagged on the PR. Thanks! /triage accepted
/sig testing
If you have time, please help to look at this pr, thanks
this is a general issue with subresources that accept create requests of different object types than the parent resource see also:
Change:
package rbd import ( <ins> "encoding/json" </ins> "errors" "fmt" "math/rand"

Discussion:
etcd cluster backing apiserver died spontaneously, after restart apiserver pulled up the pods on different machines. Node storage was backed by ext4 over rbd, which became mounted on several nodes at once. That could have possibly led to data corruption. I guess that the proper way to mount rbd volume is to take a lock on it first, which will at least fail if it's locked somewhere else, requiring manual intervention, but not destroying data. The lock should be optional, in case a proper cluster fs is mounted over the rbd. In this case there was clearly no need for accessing the data from several pods so ext4 is deemed a proper fs.
, Vladimir Pouzanov < :
want to get some detail. How is your pod-to-rbd mapping like? Since rbd image is a block device, it can be used by one pod at a time. I am not sure if locking is a proper way to go - if the pod holds a lock but dies in the middle of mounting, the rbd image (or any other volume type) is then excluded from access. In such case, a high level coordination at apiserver is a better place to resolve this problem.
Here's my rc: I guess it's better to have a lock to be cleaned up manually rather than to have non-cluster fs to be mounted in several locations at once?
thanks, this pod looks good to me. what would cause multiple nodes run the same pod?
I don't know the exact reason of why kubelet didn't unmount the old fs, but after apiserver and scheduler were restarted pod got allocated on different node.
It is a scary thing to see etcd down, it is meant to be reliable...
Unfortunately I don't have long-term logging in test cluster so I have no idea why it actually died. but using kubedns as primary node resolver was clearly a bad idea, once it died, nodes stuck with no resolver at all.
your thought on HA?
Wrong Tim St. Clair?
- you HAVE to be ready to handle network partitions - the old node might still be alive and even using the volume, but the apiserver can't see the node, so it thinks it deletes the pod and starts it elsewhere. If RBD corrupts itslef in this case, it is not useful and we should strip it from the codebase.

, Huamin Chen wrote:
that makes sense. rbd doesn't corrupt itself. This is inconsistency happens when you have two pods mounting the same rbd image. How does GCE PD handle/prevent this case?
It doesn't allow more than one read-write attachment. Multiple read-only attachments is OK. Better to fail than to allow corruption. , Huamin Chen wrote:
That's neat. I have a lock fencing for rbd, testing now.
Change:
// Verify host, _, _ := net.SplitHostPort(dialAddr) <ins> if tlsConfig != nil && len(tlsConfig.ServerName) > 0 { host = tlsConfig.ServerName } </ins> if err := tlsConn.VerifyHostname(host); err != nil { tlsConn.Close() return nil, err

Discussion:
an APIService that routes to an external API server (e.g. service catalog) via a service in namespace a caBundle in the APIService the external API server with a certificate signed for Result: Normal API requests (get/put/post) work as expected Normal watch requests work as expected Upgrade requests (e.g. websocket watch requests) return a 500 error with text like cc
Change:
var internalLabelKeys []string = []string{containerTypeLabelKey, containerLogPathLabelKey, sandboxIDLabelKey} // NOTE: Anything passed to DockerService should be eventually handled in another way when we switch to running the shim as a different process. <del> func NewDockerService(client dockertools.DockerInterface, seccompProfileRoot string, podSandboxImage string, streamingConfig *streaming.Config, pluginSettings *NetworkPluginSettings, cgroupsName string) (DockerService, error) { </del> <ins> func NewDockerService(client dockertools.DockerInterface, seccompProfileRoot string, podSandboxImage string, streamingConfig *streaming.Config, pluginSettings *NetworkPluginSettings, cgroupsName string, kubeCgroupDriver string) (DockerService, error) { </ins> c := dockertools.NewInstrumentedDockerInterface(client) ds := &dockerService{ seccompProfileRoot: seccompProfileRoot,

Discussion:
Kubernetes version (use ): v1.5.0-alpha.1.2189+-dirty docker: 1.12.3 Environment: fedora24 docker-engine-1.12.3-1.fc24.x86_64 What happened: if docker Cgroup Driver=cgroupfs, and set --cgroup-driver=systemd in kubelet, then enable --experimental-cgroups-per-qos=true; The container cgroup some is not correct. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: 1) docker Cgroup Driver=cgroupfs and --cgroup-driver=cgroupfs in kubelet works well 2) docker Cgroup Driver=systemd and --cgroup-driver=systemd in kubelet works well
help check, thanks.
In Kubernetes 1.6, we can work to detect this case and return an error. IMHO its a configuration error to have docker running with a cgroupfs driver paired with the kubelet running the systemd cgroup driver. /cc
We can also document the compatibility matrix for now.
Change:
framework.RunIfContainerRuntimeIs("docker") }) <del> Context("when shared PID namespace is enabled", func() { It("processes in different containers of the same pod should be able to see each other", func() { // TODO(yguo0905): Change this test to run unless the runtime is // Docker and its version is <1.13. By("Check whether shared PID namespace is supported.") isEnabled, err := isSharedPIDNamespaceSupported() framework.ExpectNoError(err) if !isEnabled { framework.Skipf("Skipped because shared PID namespace is not supported by this docker version.") } By("Create a pod with two containers.") f.PodClient().CreateSync(&v1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "shared-pid-ns-test-pod"}, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:    "test-container-1", Image:   "busybox", Command: []string{"/bin/top"}, }, { Name:    "test-container-2", Image:   "busybox", Command: []string{"/bin/sleep"}, Args:    []string{"10000"}, }, }, }, }) By("Check if the process in one container is visible to the process in the other.") pid1 := f.ExecCommandInContainer("shared-pid-ns-test-pod", "test-container-1", "/bin/pidof", "top") pid2 := f.ExecCommandInContainer("shared-pid-ns-test-pod", "test-container-2", "/bin/pidof", "top") if pid1 != pid2 { framework.Failf("PIDs are not the same in different containers: test-container-1=%v, test-container-2=%v", pid1, pid2) } }) }) </del> Context("when live-restore is enabled [Serial] [Slow] [Disruptive]", func() { It("containers should not be disrupted when the daemon shuts down and restarts", func() { const (

Discussion:
Once the API for is finalized, add a node e2e test. /kind feature /assign /cc /sig node
We plan on adding this for 1.10
Change:
kube-up echo "... calling validate-cluster" >&2 <del> if [[ "${EXIT_ON_WEAK_ERROR}" == "true" ]]; then validate-cluster else validate-cluster validate_result="$?" if [[ ${validate_result} != "0" ]]; then if [[ "${validate_result}" == "1" ]]; then exit 1 elif [[ "${validate_result}" == "2" ]]; then echo "...ignoring non-fatal errors in validate-cluster" >&2 else echo "Got unknown validate result: ${validate_result}" fi </del> <ins> # Override errexit (validate-cluster) && validate_result="$?" || validate_result="$?" # We have two different failure modes from validate cluster: # - 1: fatal error - cluster won't be working correctly # - 2: weak error - something went wrong, but cluster probably will be working correctly # We always exit in case 1), but if EXIT_ON_WEAK_ERROR != true, then we don't fail on 2). if [[ "${validate_result}" == "1" ]]; then exit 1 elif [[ "${validate_result}" == "2" ]]; then if [[ "${EXIT_ON_WEAK_ERROR}" == "true" ]]; then exit 1; else echo "...ignoring non-fatal errors in validate-cluster" >&2 </ins> fi fi

Discussion:
Looks like this test is never able to succeed because service does not exist: /kind failing-test /sig instrumentation
possibly related to
/assign
/assign
/assign
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. 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
where did we get with this?
Looks like those tests didn't work for at least half a year and nobody cared... Should we delete this e2e test as well? If so I can help with that.
Yes, let's remove them. Would appreciate the help! /remove-lifecycle rotten
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. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Still failing: /remove-lifecycle stale
Change:
t.Errorf("Expect command executed %d times, but got %d", svcCount, fexec.CommandCalls) } } <ins> func TestIsIPv6String(t *testing.T) { testCases := []struct { ip         string expectIPv6 bool }{ { ip:         "127.0.0.1", expectIPv6: false, }, { ip:         "192.168.0.0", expectIPv6: false, }, { ip:         "1.2.3.4", expectIPv6: false, }, { ip:         "bad ip", expectIPv6: false, }, { ip:         "::1", expectIPv6: true, }, { ip:         "fd00::600d:f00d", expectIPv6: true, }, { ip:         "2001:db8::5", expectIPv6: true, }, } for i := range testCases { isIPv6 := IsIPv6String(testCases[i].ip) if isIPv6 != testCases[i].expectIPv6 { t.Errorf("[%d] Expect ipv6 %v, got %v", i+1, testCases[i].expectIPv6, isIPv6) } } } func TestIsIPv6(t *testing.T) { testCases := []struct { ip         net.IP expectIPv6 bool }{ { ip:         net.IPv4zero, expectIPv6: false, }, { ip:         net.IPv4bcast, expectIPv6: false, }, { ip:         net.ParseIP("127.0.0.1"), expectIPv6: false, }, { ip:         net.ParseIP("10.20.40.40"), expectIPv6: false, }, { ip:         net.ParseIP("172.17.3.0"), expectIPv6: false, }, { ip:         nil, expectIPv6: false, }, { ip:         net.IPv6loopback, expectIPv6: true, }, { ip:         net.IPv6zero, expectIPv6: true, }, { ip:         net.ParseIP("fd00::600d:f00d"), expectIPv6: true, }, { ip:         net.ParseIP("2001:db8::5"), expectIPv6: true, }, } for i := range testCases { isIPv6 := IsIPv6(testCases[i].ip) if isIPv6 != testCases[i].expectIPv6 { t.Errorf("[%d] Expect ipv6 %v, got %v", i+1, testCases[i].expectIPv6, isIPv6) } } } </ins>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: There is a bug in ipv6, see: What you expected to happen: The judgement logic should be: 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: /sig network /area ipv6
/assign cc
Change:
scaleSet    string vmList      []string nodeName    string <ins> location    string </ins> zone        string faultDomain int32 expected    string

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: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .
Change:
"syscall" "github.com/vishvananda/netlink" <ins> "github.com/vishvananda/netlink/nl" </ins> "github.com/appc/cni/libcni" "github.com/golang/glog"

Discussion:
I'm not sure where the defaults come from but they sometimes drop all packets causing container IPs to become unreachable. ARP fails. I'm not sure if this is related but I also noticed on this machine that the default pfifo qdisc drops all packets. pfifo is the default qdisc for an htb node so it's used in the unconfigured htb qdisc: This is because the default value for queue size is zero. On other machines I've seen the default value set to 1 packet and 1000 packets. When I set the limit explicitly the container becomes reachable again. The broken configuration is applied by kubelet to implement traffic shapping and there is no option to turn this off. This patch fixes the kubelet on broken machines by disabling traffic shapping: cc
does this happen with --configure-cbr0 and packet shaping too? The kubenet implementation just uses the existing kubernetes shaping code that --configure-cbr0 does.
It seems the *fifo qdiscs default their packet limit to the txquelen of the interface (man tc-pfifo). It also seems most virtual interface types (bridge, etc) set a dev-txqueuelen of 0. It further seems that relies on the default packet limit. I could swear this worked before with kubenet, and it must have worked with --configure-cbr0 when the code was originally . I'll check around to figure out what the default limit should be for interfaces that don't specify a tx queue length.
Note that to test with --configure-cbr0 you'd also need --reconcile-cidr.
Upstream CNI fix is here: and we'll also work around it in kubenet for now.
FWIW, the upstream CNI fix got merged for CNI 0.3.0
Change:
govc import.vmdk kube.vmdk ./kube/ ``` <del> Verify that the VMDK was correctly uploaded and expanded to 10GiB: </del> <ins> Verify that the VMDK was correctly uploaded and expanded to ~3GiB: </ins> ```sh govc datastore.ls ./kube/

Discussion:
When wgetting to this address during the installation process, this just fails silently. Turns out the issue is that if you take a raw and curl that address you get a TLS error. I've fixed it by changing to , but obviously that's more risky.
Related (filed after an email exchange around wget) I don't have easy access to the vSphere so I can't verify how it relates to my debian install.
Yes, that is exactly the error I was experiencing.
Does curl work? Or is it busted too?
Curl is not installed on the image by default. I'm building a new image based on Debian 7.7 where I pull in curl by default, so we can switch to using that everywhere (instead of an awkward mix of wget and curl).
Thanks for reporting this I hadn't seen this yet. I uploaded a new VMDK that includes curl and updated the deployment scripts to use curl. I verified that deployment works again for me.
I can confirm that this works now with latest build from master on ESX. Probably still won't work with v0.4.3 (even w new image) since the scripts still used wget back then.
We are probably going to fork for v0.5 soon. But I can backport if this trips folks up. sent from tiny keyboard On Nov 12, 2014 9:09 AM, "Ben Smith" wrote:
Change:
function config-ip-firewall { echo "Configuring IP firewall rules" <ins> # Do not consider loopback addresses as martian source or destination while # routing. This enables the use of 127/8 for local routing purposes. sysctl -w net.ipv4.conf.all.route_localnet=1 </ins> # The GCI image has host firewall which drop most inbound/forwarded packets. # We need to add rules to accept all TCP/UDP/ICMP packets. if iptables -L INPUT | grep "Chain INPUT (policy DROP)" > /dev/null; then

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Fluentd pod failed to become ready on master after upgrade from 1.8-HEAD. Logs from https://k8s- Multiple CIs are hitting this: https://k8s- https://k8s- https://k8s- Anything else we need to know?: From the timeline, possibly caused by the fluentd hostnetwork change:
https://k8s- has the same symptom as well. /sig instrumentation
Could you please take a look?
/unassign /assign
It doesn't seem like an upgrade issue actually. It happens exclusively on master and I see it happening just after regular cluster startup. In the prom-to-sd logs: Why is metadata server unaccessible from the master? Can it be related to the metadata-proxy?
Yeah I agree, edited the title. Sorry for the confusion.
This is definitely metadata proxy related. Are you still seeing this? I introduced a bug in that I fixed in
https://k8s- Same issue today. Again on master
Okay. My guess is that the metadata proxy isn't getting scheduled on the master for some reason. Looking ...
Hm. The master's shows that it's got the right node label and that a proxy is being scheduled:
Okay, I'm seeing the same thing on a newly-created HEAD cluster. Metadata-proxy is running and serving requests ... my next guess is that the iptables rules are messed up.
The iptables rules are fine:
cc
Note that we moved fluentd out of host network recently. Why do we want to do that?
Thanks, yup. We're trying to root cause; unclear if that's what caused it, or a change in the metadata proxy.
Thanks for debugging this! found that on master node is 0, which should be 1. I set it to 1, and it does fix the issue.
I've included the fix in
Thanks a lot for debugging! Could you please add to the PR description? Also, what about previous branches? Is it going to work on 1.7 and 1.8 branches, or we need to propagate your fix there?