jiebi/CodeConvo huggingface dataset:
Change:
return CreatePausePod(cs, InitPausePod(&conf)) } <ins> // CreatePVC creates a PersistentVolumeClaim with the given config and returns // its pointer and error status. func CreatePVC(cs clientset.Interface, pvc *v1.PersistentVolumeClaim) (*v1.PersistentVolumeClaim, error) { return cs.CoreV1().PersistentVolumeClaims(pvc.Namespace).Create(context.TODO(), pvc, metav1.CreateOptions{}) } // CreatePV creates a PersistentVolume with the given config and returns its // pointer and error status. func CreatePV(cs clientset.Interface, pv *v1.PersistentVolume) (*v1.PersistentVolume, error) { return cs.CoreV1().PersistentVolumes().Create(context.TODO(), pv, metav1.CreateOptions{}) } </ins> // RunPausePod creates a pod with "Pause" image and the given config and waits // until it is scheduled. It returns its pointer and error status. func RunPausePod(cs clientset.Interface, pod *v1.Pod) (*v1.Pod, error) {

Discussion:
We need an integration test for the scheduler enforcement of the alpha feature. This is required for beta graduation; we need to collect signal on the current behavior before we can proceed. See this comment for context:
/sig storage /sig scheduler
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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig storage /sig scheduler 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
/sig scheduling
Change:
StabilityLevel: metrics.ALPHA, }, []string{"queue", "event"}) <ins> PermitWaitDuration = metrics.NewHistogramVec( &metrics.HistogramOpts{ Subsystem:      SchedulerSubsystem, Name:           "permit_wait_duration_seconds", Help:           "Duration of waiting in RunPermitPlugins.", Buckets:        metrics.ExponentialBuckets(0.001, 2, 15), StabilityLevel: metrics.ALPHA, }, []string{"result"}) </ins> metricsList = []metrics.Registerable{ scheduleAttempts, SchedulingLatency,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : metric name Description -- -- permitwaitduration_seconds Duration of permit extension point finishes waiting. Why is this needed: In permit extension point, if the status is "Wait", we block until the pod is scheduled or timeout: Blocking is an important behavior that we should monitor. /sig scheduling
/assign
Change:
diskName, err := createPDWithRetry() framework.ExpectNoError(err, "Error creating PD") numContainers := 4 <del> host0Pod := testPDPod([]string{diskName}, host0Name, false /* readOnly */, numContainers) </del> <ins> var host0Pod *api.Pod </ins> defer func() { By("cleaning up PD-RW test environment") // Teardown pods, PD. Ignore errors. // Teardown should do nothing unless test failed. <del> podClient.Delete(host0Pod.Name, api.NewDeleteOptions(0)) </del> <ins> if host0Pod != nil { podClient.Delete(host0Pod.Name, api.NewDeleteOptions(0)) } </ins> detachAndDeletePDs(diskName, []string{host0Name}) }()

Discussion:
PR moved some PD tests to flaky to resolve issue (and duplicate ). These tests started failing due to PR . is working on a patch to de-flake the tests. This issue is to track the fix and should be closed when: PD tests have been deflaked (verify by running the "" e2e tests back to back for a couple of hours to verify the issue is fixed). flaky label has been removed from the "" tests that were marked flaky in CC
how to watch the submit queue and find if the flake is gone?
I don't know. is there any way can verify whether test is no longer flaky?
I'm not sure what the publicly accessible link for test history is. I took a look for you: Pod Disks should schedule a pod w/ a RW PD shared between multiple containers, write to PD, delete pod, verify contents, and repeat in rapid succession Failed 3 times in the last 30 runs. Stability: 90 % Pod Disks should schedule a pod w/two RW PDs both mounted to one container, write to PD, verify contents, delete pod, recreate pod, verify contents, and repeat in rapid succession Failed 1 times in the last 30 runs. Stability: 96 % I have a PR pending that enables the new attach/detach controller and I was able to run the tests back to back overnight without any failures. So once that gets merged, we can take a look at moving these tests back.
Something in PD attach/detach affects also 'Dynamic provisioning' e2e test, a PD is still attached to a node ~15 minutes after appropriate pod was deleted and thus deleter can't delete it. From controller log:
please take a look at https://k8s-
thanks so at least one of the flake has a different error than "container not found" In one, the error is
^^ the above seems like a possible bug in exec
^
The error to me indicates that the original container is no longer around as exec can't find the ipc namespace fd. Are we sure the container that we are trying to join is still around?
my memory is rusty but did you have an idea to randomize the container id in this pd test?
see the info here:
Close we will track this with
Change:
} podCounts[label]++ } numServicePods := len(nsServicePods) result := []schedulerapi.HostPriority{} //score int - scale of 0-maxPriority

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Kubernetes version (use ): master What happened: The functionality is hidden in a large function, and not explicit, testable. What you expected to happen: The logic of should read more clearly, with tests for individual filters.
has a PR for this .
Few more things include removing limits in entries like
yeah, im not sure why the thing is there, after all they are just appending to the slice and the limit wont have an effect , from what i can tell, will it? probably good idea to remove unless im missing something.
Its part of part of PR too.
Change:
claims, err := tc.client.ResourceV1alpha2().ResourceClaims("").List(tc.ctx, metav1.ListOptions{}) require.NoError(t, err, "list claims") for _, claim := range claims.Items { <ins> claim := claim </ins> objects = append(objects, &claim) } schedulings, err := tc.client.ResourceV1alpha2().PodSchedulingContexts("").List(tc.ctx, metav1.ListOptions{}) require.NoError(t, err, "list pod scheduling") for _, scheduling := range schedulings.Items { <ins> scheduling := scheduling </ins> objects = append(objects, &scheduling) }

Discussion:
Apply this patch: Then run: This fails with: Test should pass. See above. If there are N objects in claims.Items, then this loop for _, claim := range claims.Items { objects = append(objects, &claim) } is appending the same pointer N times, pointing at the final item in the list. Adding fixes that mistake, but then it makes the test fail. Something else about the test is buggy, but the bug was being masked by this bug. In the repro case I to the loop a few lines down, just for good measure, but that one is not causing a problem. The line by itself causes the test failure. HEAD N/A N/A N/A N/A N/A
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 scheduling /priority important-soon /cc Thanks for finding this and the detailed report
/assign
Can you help to fix this?
If we don't here from soonish, then I'll fix it myself.
Sorry, I've been busy with an office accident this week, if you want fix it, please take it
/assign
/unassign
Change:
] }, { <del> "path": "/api/v1/namespaces/{namespace}/componentstatuses", </del> <ins> "path": "/api/v1/componentstatuses", </ins> "description": "API at /api/v1", "operations": [ {

Discussion:
The selflink provided in the api response for component statuses (/api/v1/componentstatuses) is broken. For example: /api/v1/namespaces/componentstatuses/controller-manager (as specified in the response of /api/v1/componentstatuses), will return: { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } while: /api/v1/namespaces/default/componentstatuses/controller-manager, will return the data. In addition, and this is asked for better understanding, are the component statuses namespace scoped? as far as I understood etcd, the scheduler and the controller manager were shared across the kubernetes cluster. If they aren't namespace scoped, what is the logic behind specifing a namespace in these api requests (as shown in ): /api/v1/namespaces/{namespace}/componentstatuses /api/v1/namespaces/{namespace}/componentstatuses/{name} If they are in fact namespace scoped, would you be kind and share an explanation/link to a documentation page?
I agree that it doesn't make a lot of sense for this to be namespaced given what's in it at the moment. Given what I'd like it to contain, the namespace might make more sense in the future. The self link is super broken right now, though, probably due to lack of actual namespace. there's probably a bug in the go-restful setup code for this. Can you take a look at some point? Also it might be worth mentioning that this will probably change in the near future, is working on a replacement.
The whole /componentstatus API is just broken. It needs rewriting.
Change:
}, } <del> for _, test := range tests { imageMap := createImageExistenceMap(test.nodes) if !reflect.DeepEqual(test.expected, imageMap) { t.Errorf("expected: %#v, got: %#v", test.expected, imageMap) } </del> <ins> for i, test := range tests { t.Run(fmt.Sprintf("case_%d", i), func(t *testing.T) { imageMap := createImageExistenceMap(test.nodes) if !reflect.DeepEqual(test.expected, imageMap) { t.Errorf("expected: %#v, got: %#v", test.expected, imageMap) } }) </ins> } }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign
Change:
validSeccomp := validPSP() validSeccomp.Annotations = map[string]string{ seccomp.DefaultProfileAnnotationKey:  "docker/default", <del> seccomp.AllowedProfilesAnnotationKey: "docker/default,unconfined,localhost/foo", </del> <ins> seccomp.AllowedProfilesAnnotationKey: "docker/default,unconfined,localhost/foo,*", </ins> } validDefaultAllowPrivilegeEscalation := validPSP()

Discussion:
It should be possible to create a PodSecurityPolicy with zero restrictions. This was the intent with the (a.k.a. "AllowAny") allowed seccomp profile, but it is rejected during the validation phase. /kind bug
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/auth: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
} } <ins> sort.Slice(volumesToReportInUse, func(i, j int) bool { return string(volumesToReportInUse[i]) < string(volumesToReportInUse[j]) }) </ins> return volumesToReportInUse }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is not sent in a stable sort order. this makes node status patch requests larger than needed, and makes debugging nodes harder than necessary. What you expected to happen: stable sort of volumesInUse How to reproduce it (as minimally and precisely as possible): always Anything else we need to know?: nope Environment: n/a
/sig node
- this is a good getting started item.
I've already submitted a PR in . PTAL. Thanks.
Change:
flags.StringVar(&TestContext.RepoRoot, "repo-root", "../../", "Root directory of kubernetes repository, for finding test files.") flags.StringVar(&TestContext.Provider, "provider", "", "The name of the Kubernetes provider (gce, gke, local, skeleton (the fallback if not set), etc.)") flags.StringVar(&TestContext.Tooling, "tooling", "", "The tooling in use (kops, gke, etc.)") <del> flags.StringVar(&TestContext.KubectlPath, "kubectl-path", "kubectl", "The kubectl binary to use. For development, you might use 'cluster/kubectl.sh' here.") </del> flags.StringVar(&TestContext.OutputDir, "e2e-output-dir", "/tmp", "Output directory for interesting/useful test data, like performance data, benchmarks, and other metrics.") flags.StringVar(&TestContext.Prefix, "prefix", "e2e", "A prefix to be added to cloud resources created during testing.") flags.StringVar(&TestContext.MasterOSDistro, "master-os-distro", "debian", "The OS distribution of cluster master (debian, ubuntu, gci, coreos, or custom).")

Discussion:
Which jobs are failing: ci-kubernetes-node-kubelet-orphans Which test(s) are failing: [sig-storage] EmptyDir volumes pod should support shared volumes between containers Since when has it been failing: Testgrid link: Reason for failure:
/sig testing
/assign
Thank for comment
Tests are now passing, /close
Closing this issue. <detailsIn response to : Tests are now passing, 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:
return err } } <ins> for _, memberId := range pool.MemberIDs { err = members.Delete(lb.network, memberId).ExtractErr() if err != nil && !isNotFound(err) { return err } } </ins> err = pools.Delete(lb.network, pool.ID).ExtractErr() if err != nil && !isNotFound(err) { return err

Discussion:
I am using openstack as the cloud provider, and the error could be reproduced like this: It looks so far so good, but after restarting the control plane.
logs from kube-controller-manager:
When checking the function here: I doubt that the process about deleting a vip, the deletion order expressed there is: get the vip. delete the vip. disassociate monitor. delete monitor. delete pool. why don't we check the members of the pool, and delete them before we delete the pool?
Hrm, that error message looks like it's generated only when a vip refers to the pool: (and from the URL I can see you're using lbaas v1) If it isn't too difficult, could you manually create a vip+pool+member and confirm exactly what conditions produce that error? (I'm afraid I only easily have access to lbaasv2 setups atm) Another possibility is that we didn't wait long enough after deleting the vip, etc before attempting to delete the pool.
Thanks for your attention, I already fixed it by removing the members, and the issue was gone after that. :) as far as I know, before all the references are removed, the pool would not be able to delete, so either the vip refers to it or the member refers to it. I do not have a deployment of LBaaS v2, but by reading the code, I am pretty sure that it deletes the member before deleting the pool as well. checking here:
Meh, if it works, then I'm good with that. LGTM.
Change:
case ok && cache.assumedPods[key]: if currState.pod.Spec.NodeName != pod.Spec.NodeName { // The pod was added to a different node than it was assumed to. <del> glog.Warningf("Pod %v assumed to a different node than added to.", key) </del> <ins> glog.Warningf("Pod %v was assumed to be on %v but got added to %v", key, pod.Spec.NodeName, currState.pod.Spec.NodeName) </ins> // Clean this up. cache.removePod(currState.pod) cache.addPod(pod)

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.
Change:
apiVersion: v1 kind: Pod metadata: <del> name: l7-lb-controller-v0.7.1 </del> <ins> name: l7-lb-controller-v0.8.0 </ins> namespace: kube-system labels: k8s-app: glbc <del> version: v0.7.1 </del> <ins> version: v0.8.0 </ins> kubernetes.io/cluster-service: "true" kubernetes.io/name: "GLBC" spec: terminationGracePeriodSeconds: 600 hostNetwork: true containers: <del> - image: gcr.io/google_containers/glbc:0.7.1 </del> <ins> - image: gcr.io/google_containers/glbc:0.8.0 </ins> livenessProbe: httpGet: path: /healthz

Discussion:
0 picks up a godep update with an int overflow fix to the upstream workqueue package. This bug tracks cherrypicking the version bump into 1.4.1.
closed via
Change:
if ok { t.Fatalf("expected result channel to be closed") } <del> case <-time.After(1 * time.Millisecond): </del> <ins> case <-time.After(1 * time.Second): </ins> t.Fatalf("watch should have closed channel: %#v", watching) }

Discussion:
From: https://travis- a test failure on a PR that documentation, so no failure expected. E0813 16:12:46. ] unknown action: update E0813 16:12:46. ] unexpected nil node: &etcd.Response{Action:"set", Node:(etcd.Node)(nil), PrevNode:(etcd.Node)(nil), EtcdIndex:0x0, RaftIndex:0x0, RaftTerm:0x0} E0813 16:12:46. ] failure to decode api object: 'foobar' from &etcd.Response{Action:"set", Node:(etcd.Node)(0xc2100d4720), PrevNode:(etcd.Node)(nil), EtcdIndex:0x0, RaftIndex:0x0, RaftTerm:0x0} &etcd.Node{Key:"", Value:"foobar", Dir:false, Expiration:(time.Time)(nil), TTL:0, Nodes:etcd.Nodes(nil), ModifiedIndex:0x0, CreatedIndex:0x0} E0813 16:12:46. ] etcd.Watch stopped unexpectedly: Injected error ("/some/key") E0813 16:12:46. ]

watch was unable to retrieve the current index for the provided key: 101: () --- FAIL: TestWatchFromOtherError (0.00 seconds) returning /some/key: &{ <nil<nil0 0 0} &etcd.EtcdError{ErrorCode:101, Message:"", Cause:"", Index:0x2} watch should have closed channel: &tools.etcdWatcher{encoding:(_conversion.Scheme)(0xc21001fa50), versioner:(api.jsonBaseResourceVersioner)(0xc586f0), transform:(tools.TransformFunc)(nil), list:false, filter:(tools.FilterFunc)(nil), etcdIncoming:(chan etcd.Response)(0xc2100bf240), etcdStop:(chan bool)(0xc2100bf2a0), etcdCallEnded:(chan struct {})(0xc2100bf300), outgoing:(chan watch.Event)(0xc2100bf360), userStop:(chan struct {})(0xc2100bf3c0), stopped:false, stopLock:sync.Mutex{state:0, sema:0x0}, emit:(func(watch.Event))(0x457940)} FAIL FAIL 0.474s ok 1.179s coverage: 83.6% of statements ok 1.286s coverage: 92.9% of statements ok 1.165s coverage: 84.4% of statements ok 1.283s coverage: 100.0% of statements The command "./hack/test-" exited with 123.
Change:
// If the -exist option is specified, ipset ignores the error otherwise raised when // the same set (setname and create parameters are identical) already exists. func (runner *runner) AddEntry(entry string, set *IPSet, ignoreExistErr bool) error { <del> args := []string{"add", set.Name, entry, "comment", set.Comment} </del> <ins> args := []string{"add", set.Name, entry} </ins> if ignoreExistErr { args = append(args, "-exist") }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig network /area kube-proxy /area ipvs /assign I'll send a fixing pull request tomorrow. What happened: On centos 7.2 with ipset 6.29, kube-proxy in ipvs mode failed to create ipset sets. After some dig, it turns out to be problem of ipset on centos/rh. See I tried ipset 6.29 on ubuntu, it's OK. But when I tried ipset 6.29 on centos, I got errors: What you expected to happen: Since the problematic ipset versions have very large installation base, we could remove ipset commet, or remove ipset commet with problematic ipset version. The problematic ipset also says it support comment by --help. The problem could be detected by a test run of "ipset create foo hash:ip comment". How to reproduce it (as minimally and precisely as possible): Create some service in kubernetes, run kube-proxy with ipvs mode on Centos 7.x node. Anything else we need to know?: Environment: Kubernetes version (use ): commit (actually all commits after ) Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS Linux release 7.2.1511 (Core) Kernel (e.g. ): Linux VM34centos 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others: ipset v6.29, protocol version: 6
could you test it before commit , that's ok?
, yes, I did. It's OK. But I think the we don't need to revert the iptables comments.
if ipset package not installed, will set module or match-set option in rule be weird and now seems not.
Change:
"k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/sets" <del> "k8s.io/apimachinery/pkg/util/validation/field" </del> "k8s.io/client-go/tools/record" <del> "k8s.io/kubernetes/pkg/api" k8s_api_v1 "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/api/validation" </del> kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/kubelet/events" kubetypes "k8s.io/kubernetes/pkg/kubelet/types"

Discussion:
To read a pod manifest file from disk (or from the http source), kubelet execute the following code to Decode a on-disk v1 pod manifest to an internal pod object (the defaults are applied in this process). Validate the internal pod. Convert the internal pod back to a v1 pod. The downstream pod cache (which gets v1 pods from different sources) performs similar operations: Convert the v1 pod to an internal pod. Validate the internal pod. One of two conversion/validation should be removed, and some of them should be simplified.
/cc for suggestions on defaulting and conversion.
If no one is working on this, I will take it.
Change:
// TODO: return a ListerWatcher interface instead? func (factory *ConfigFactory) createAssignedPodLW() *cache.ListWatch { return cache.NewListWatchFromClient(factory.Client, "pods", api.NamespaceAll, <del> parseSelectorOrDie(getHostFieldLabel(factory.Client.APIVersion())+"!=")) </del> <ins> parseSelectorOrDie(client.PodHost+"!=")) </ins> } // createMinionLW returns a cache.ListWatch that gets all changes to minions.

Discussion:
My broke it for v1beta3, then fixed it for v1beta3 and broke it for v1beta1. I'm working on a fix.
Honestly I'm very surprised that more people aren't complaining-- integration test logs are full of noise because of this.
Exact text of error log is "Failed to watch *api.Node: field label not supported: "
cc