jiebi/CodeConvo huggingface dataset:
Change:
package network import ( <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> networkingv1 "k8s.io/api/networking/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/intstr"

Discussion:
What happened: I wanted to run the e2e network policy tests with: and I noticed that all tests are failing (I actually don't know why nobody has noticed this before). Looking into the logs I saw the following errors: which are correct because the tests using as "client" which doesn't contain . What you expected to happen: The e2e tests for network policies should actually pass. How to reproduce it (as minimally and precisely as possible): Just run: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: kind OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig testing
With the current fix two tests are still failing: I will take a look and fix these failing tests too.
Seems to be an implementation error on the network plugin side (tested with weave latest and calico 3.6). I will investigate some time in the implementation details on the calico side. But this error/failures are no blocker for the PR from my perspective.

As far as I know the busybox image doesn't contain , only so I don't understand how the PR that changed from to has passed the CI What happened: What you expected to happen: 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: /kind bug cc
/sig network
NetworkPolicy tests are a and so don't get run by default. But I imagine at least some of the CI test environments implement NetworkPolicy (e2e-gce?) so probably we should fix that. So 2 fixes: Make the tests pass again; probably requires changing the test image from busybox to something else. I bet there are other tests in that they switched from wget to curl where they did remember to change the image (because the tests would have failed otherwise) so this should just be a matter of seeing what image they used there, and use it here too. Make at least one of the CI tests test NetworkPolicy /good-first-issue (at least the first part anyway)
/remove-good-first-issue /remove-help (after someone asked me about this, I realized that trying to run tests that don't get run by CI is kind of complicated...)
Change:
c.queue.Add(key) } <del> // ensureSetupManagedByAnnotation selects all EndpointSlices for a Service and // ensures they have LabelManagedBy set appropriately. This ensures that only // one controller or entity is trying to manage a given EndpointSlice. This // function provides backwards compatibility with the initial alpha release of // EndpointSlices that did not include these labels. // TODO(robscott): Remove this in time for v1.18. func (c *Controller) ensureSetupManagedByAnnotation(service *v1.Service) error { if managedBySetup, ok := service.Annotations[managedBySetupAnnotation]; ok && managedBySetup == managedBySetupCompleteValue { return nil } esLabelSelector := labels.Set(map[string]string{discovery.LabelServiceName: service.Name}).AsSelectorPreValidated() endpointSlices, err := c.endpointSliceLister.EndpointSlices(service.Namespace).List(esLabelSelector) if err != nil { c.eventRecorder.Eventf(service, v1.EventTypeWarning, "FailedToListEndpointSlices", "Error listing Endpoint Slices for Service %s/%s: %v", service.Namespace, service.Name, err) return err } for _, endpointSlice := range endpointSlices { if _, ok := endpointSlice.Labels[discovery.LabelManagedBy]; !ok { if endpointSlice.Labels == nil { endpointSlice.Labels = make(map[string]string) } endpointSlice.Labels[discovery.LabelManagedBy] = controllerName _, err = c.client.DiscoveryV1beta1().EndpointSlices(endpointSlice.Namespace).Update(endpointSlice) if err != nil { return err } } } if service.Annotations == nil { service.Annotations = make(map[string]string) } service.Annotations[managedBySetupAnnotation] = managedBySetupCompleteValue _, err = c.client.CoreV1().Services(service.Namespace).Update(service) return err } </del> func (c *Controller) addPod(obj interface{}) { pod := obj.(*v1.Pod) services, err := c.serviceSelectorCache.GetPodServiceMemberships(c.serviceLister, pod)

Discussion:
What happened: kube-controller-manager panic for What you expected to happen: no panic. How to reproduce it (as minimally and precisely as possible): No idea. I guess it's hard to reproduce. Anything else we need to know?: Found from here: 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: /assign cc Should we do something for v1.17? (v1.17 code freeze now, but still have the opportunity to fix) can be removed safely in v1.18, right?
/sig scheduling
Working on this in /sig network /priority critical-urgent /assign
Sorry, I didn't realize it. I should have a search before firing an issue. I recommend adding this issue to your PR. e.g. `
Updated, thanks!
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This seems to be writing to a cached (should be const) service. I think we need to DeepCopy() it before we mutate the Go type. does that sound right? Is this still our best state of the art?
yes, copy before change
we have a tool to catch this (the cache mutation detector), but it got disabled in our test runs two years ago (xref )
yes great catch - I was always convinced this is enabled...
Change:
SyncFrequency:      *syncFrequency, HTTPCheckFrequency: *httpCheckFrequency, } <del> my_kubelet.RunKubelet(*file, *manifest_url, *etcd_servers, *address, *port) </del> <ins> my_kubelet.RunKubelet(*file, *manifestUrl, *etcdServers, *address, *port) </ins> }

Discussion:
It would be great to have an easy way to run a kubernetes master/minion locally. Currently, it's not that easy to set up. We should have a convenient script to make it work.
The integration test binary is pretty close. It'd be pretty simple to glue in the kubelet to that binary. Brendan On Jun 10, 2014 2:53 PM, "Daniel Smith" wrote:
I'll take a look.
+1 for this -- especially in script form rather than a go executable.
what exactly do you mean by "script form"? Were you thinking of something like a version of cloudcfg that can be run without needing to have started up a daemon first?
Basically, what I had in mind, is a shell script that looks something like
Ah, ok. That's very similar to local-; the only difference is that everything is packaged into a single go binary. We probably will switch to using individual binaries for this when we start running our components inside docker containers.
The script just makes things more obvious how to run things for those who are looking to integrate them into non-GCE environments.
That's a good point. I'll look into this some more later.
Create a pad as follows: Name: non-persistent-redis Container image: redis Named-volum with name: cache-control Mount path: /data/redis It should launch in the pre-prod namespace and the volume MUST NOT be persistent. apiVersion: v1 kind: Pod metadata: name: non-persistent-redis namespace: pre-prod spec: containers: name: non-persistent-redis image: redis volumeMounts: name: cache-control mountPath: "/data/redis" volumes: name: cache-control emptyDir: {}

I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.

When I'm accessing persistentVolumes and persistentVolumeClaims, I'm getting nil instead of empty list of items, as happening in other entities when there are no items. { "kind": "PersistentVolumeList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/persistentvolumes", "resourceVersion": "" } }
Yes, this seems like a bug. I see an empty list when I access pods: And items is nil when I access persistent volumes:
Items shouldn't be tagged with omitempty:
cc
PersistentVolumeList and PersistentVolumeClaimList appear to be the only resource types with this problem.
Please see for fix.
Change:
deadline          int64 // cj status <del> ranPreviously bool stillActive   bool </del> <ins> ranPreviously              bool stillActive                bool jobPresentInCJActiveStatus bool </ins> jobCreationTime time.Time

Discussion:
in TestControllerV2SyncCronJob, there are many listing the properties that don't matter (like nil, false). and many constants F and T, which is unnecessary. As per 's request, We shouldn't be listing the properties that don't matter (like nil, false). And get rid of constants F and T check No response <details</details<detailsNone </details<details</details<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
/assign I would like to work on the optimization
It's not an optimization. It's just about readability.
/remove-kind bug /kind cleanup
/sig apps
Change:
svc.ObjectMeta.Annotations[key] = tier } <del> func clearNetworkTier(svc *v1.Service) { key := gcecloud.NetworkTierAnnotationKey if svc.ObjectMeta.Annotations == nil { return } delete(svc.ObjectMeta.Annotations, key) } </del> // TODO: add retries if this turns out to be flaky. func reserveRegionalAddress(cloud *gcecloud.Cloud, name string, netTier cloud.NetworkTier) (string, error) { Addr := &compute.Address{

Discussion:
ci-kubernetes-e2e-gci-gce-coredns ci-kubernetes-e2e-gci-gce-slow ci-kubernetes-e2e-gci-gce-ipvs Basically, all jobs that run the test :) [sig-network] Services [Slow] should be able to create and tear down a standard-tier load balancer 06-05
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 network it seems you reported failures in this test previously and seems a GCE feature dependent on the GCE controller, can you PTAL? cc
It has been so long that I entirely forgot what was the previous cause. From a quick look, the gce loadbalancer controller stuck on an address not found error (logs from ):
Full logs related to the problematic service : It reads like the controller thought the service desired tier network, where it actually wanted ? Would it be (purely based on the timing - don't see how that is related yet)
/assign Thanks It is indeed caused by . Pushed a PR to fix the e2e test.
Change:
package cmd import ( <ins> "encoding/json" "errors" </ins> "fmt" "io" <ins> "github.com/ghodss/yaml" </ins> "github.com/spf13/cobra" <ins> apimachineryversion "k8s.io/apimachinery/pkg/version" </ins> "k8s.io/kubernetes/pkg/kubectl/cmd/templates" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "k8s.io/kubernetes/pkg/util/i18n" "k8s.io/kubernetes/pkg/version" ) <ins> type Version struct { ClientVersion *apimachineryversion.Info `json:"clientVersion,omitempty" yaml:"clientVersion,omitempty"` ServerVersion *apimachineryversion.Info `json:"serverVersion,omitempty" yaml:"serverVersion,omitempty"` } </ins> var ( version_example = templates.Examples(` # Print the client and server versions for the current context

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): no What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "kubectl version", "kubectl version" json Is this a BUG REPORT or FEATURE REQUEST? (choose one): Feature request Kubernetes version (use ): $ kubectl version --client Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-12T05:22:15Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"} Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): MacOS 10.12.2 I find it difficult to parse the output of programmatically. I have to use a YAML parser to do it. I'd prefer to use JSON, or to be given just the string and asked to parse it with a regex. This is obviously a relatively low-priority request.
I wouldnt mind helping out on this, if there are no objections?
are you working on this? If not, I would like to work on it.
I plan to, but if i'll keep you posted if i get too delayed.
How can I direct message you?
didnt see this till now, felt bad i had not kept up on this so i decided to just push through it. If my email is not available in my profile, please let me know, otherwise AT gmail would be the best way to contact me.
Thanks!
Included below are some examples. Let me know what you think, my only concern is the the original output of included the key and then the object type which is a little strange. Note the output flag is optional so we don't break previous behavior and contract, which is now baked and part of e2e testing. here are the couple of samples:
Change:
} ) <ins> func TestNilOutMap(t *testing.T) { var fakeKubeconfigData = `apiVersion: v1 kind: Config clusters: - cluster: certificate-authority-data: UEhPTlkK server: https://1.1.1.1 name: production contexts: - context: cluster: production user: production name: production current-context: production users: - name: production user: auth-provider: name: gcp` _, _, err := clientcmdlatest.Codec.Decode([]byte(fakeKubeconfigData), nil, nil) if err != nil { t.Fatalf("unexpected error: %v", err) } } </ins> func TestNonExistentCommandLineFile(t *testing.T) { loadingRules := ClientConfigLoadingRules{ ExplicitPath: "bogus_file",

Discussion:
What happened: I have a test case: This behaves different with different client-go versions. With , the test passes. This is using in with in With , this test panics. This is using in with in Panic logs: Basically it its creating an object to decode into, and this object has some maps. These are set to nil, so when we try to populate them we get a panic. What you expected to happen: Behavior remains the same as previous release, or at least have some alternative that works here? How to reproduce it (as minimally and precisely as possible): I pasted the test above that reproduces this. This can be reproduced with a project with just that file, and a file with only client-go. Using go 1.13
/sig api-machinery
/assign
Change:
var _ Interface = new(Fake) <ins> func (c *Fake) Start() error { return nil } </ins> func (c *Fake) ContainerInfo(name string, req *cadvisorApi.ContainerInfoRequest) (*cadvisorApi.ContainerInfo, error) { return new(cadvisorApi.ContainerInfo), nil }

Discussion:
This is blocking (reboot test). In running a test that reboots all of the nodes and then runs the e2e tests, we saw a failure with the influxdb / heapster monitoring test: The heapster logs, from running (), shows a ton of the following kubelet errors for all containers (this one happens to be for skydns): The shows a bunch of 500 errors, such as: However, the apiserver thinks that all the pods are running ( gives this ) Docker thinks that the pods are running ( on that node gives this ) In summary: apiserver and docker think containers are running but kubelet can't find them this manifested in the influxdb / heapster monitoring e2e test after node reboot I've still got the cluster around if anyone would like to debug. +cc (helped me debug this (thanks!)) +cc (node) +cc (interested in getting in, which this is blocking)
Can I access your test nodes?
Is this an active problem? I'd check if the cAdvisor thinks the containers exist (it is the one returning the error). I'd then scan the logs to see if cAdvisor had any errors related to that container.
Unfortunately during debugging, I restart kubelet service on that node, the issue is gone. The problem could be cadvisor cannot get stats, but I couldn't find any cadvisor related error messages. How easy to reproduce the issue here? Next time we might access cadvisor's page to see if there is no such container information. Thanks!
(and Thanks for looking into this! I believe I can reproduce easily but I'll confirm. Where do I look for cAdvisor info? I don't see a log in or , and I don't see a cAdvisor container running?
cAdvisor is running as part of kubelet now. If you can reproduce the issue, could you please change kubelet's log level to 4 so that we have more cadvisor log here? Thanks!
Yes! How do I do that?

I can reproduce this by doing the following: After this, I got two failures: ... and I have another node with more of the same kubelet errors: (If I need to change the Kubelet log level at compile-time I can do that and repro on a new cluster; otherwise, I've got another cluster with the issue that can be introspected...)
There is a race between cadvisor initialization and docker. cadvisor failed to register docker factory, and bailed out. is going to make cadvisor more resilient to the issue of docker is not available, and have some retry logic. I am going to change kubelet initialization logic a little bit to make sure docker is running before we start cadvisor.
Awesome, thank you Dawn! Are there issues or PRs I can follow to know when this is unblocked?
is one of them. is working on the second.
Change:
) var ( <del> order = []string{"false", "true", "matches", "nopods", algorithmpredicates.MatchInterPodAffinityPred} </del> <ins> errPrioritize = fmt.Errorf("priority map encounters an error") order         = []string{"false", "true", "matches", "nopods", algorithmpredicates.MatchInterPodAffinityPred} </ins> ) func falsePredicate(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) {

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?: What happened: A failed Prioritize Map Function caused Scheduler break down. What you expected to happen: Pod remains Pending and describe pod will show errors of failed functions. How to reproduce it (as minimally and precisely as possible): It happens when some prioritize's map functions return with error. Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
As shown above, if priorityConfigs[i].Map(pod, meta, nodeInfo) returns with error, there will be no chance for results[i + 1] to initialize its value, thus causing panic when calling config.Reduce(pod, meta, nodeNameToInfo, results[i+1])
/sig scheduling
I opened a PR to initialize results with real host name instead of empty string.
Change:
PrintFlags  *genericclioptions.PrintFlags RecordFlags *genericclioptions.RecordFlags <del> DeleteFlags   *cmddelete.DeleteFlags </del> DeleteOptions *cmddelete.DeleteOptions DryRunStrategy cmdutil.DryRunStrategy

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/triage accepted
Change:
ADD https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz /root/kube/ # Copy the the cni-bin folder into /opt/cni/bin <del> COPY cni-bin /opt/cni/bin </del> <ins> COPY cni-bin/bin /opt/cni/bin </ins> # Copy overlay configuration to default directory COPY cni-conf /etc/cni/net.d

Discussion:
We should update cni binaries to containernetworking/cni and release binaries for all arches. I do not have push access to the repo, so I guess some googler have to do it.
Thanks. I have this on my plate.
Change:
format:     "{"ts":%f,"caller":"json/json_test.go:%d","msg":"test for duplicate keys","v":0,"akey":"avalue","akey":"anothervalue"}n", keysValues: []interface{}{"akey", "avalue", "akey", "anothervalue"}, }, <ins> { msg:        "test for NamespacedName argument", format:     "{"ts":%f,"caller":"json/json_test.go:%d","msg":"test for NamespacedName argument","v":0,"obj":{"Name":"kube-proxy","Namespace":"kube-system"}}n", keysValues: []interface{}{"obj", types.NamespacedName{Name: "kube-proxy", Namespace: "kube-system"}}, }, </ins> } for _, data := range testDataInfo {

Discussion:
should implement . This ensures that it's use as value in a key/value pair emits a struct and not the string. /ref
This depends on logr 1.2.0, which will be in /wg structure-logging /sig instrumentation
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : This depends on logr 1.2.0, which will be in /sig instrumentation 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
I'd like to work on this :) /assign
/wg structured-logging
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /lifecycle frozen
Change:
go_library( name = "go_default_library", srcs = [ <ins> "capabilities.go", </ins> "doc.go", <del> "mustrunas.go", </del> "types.go", ], importpath = "k8s.io/kubernetes/pkg/security/podsecuritypolicy/capabilities",

Discussion:
The name of this file is odd: The file context has nothing to do with Is this a BUG REPORT or FEATURE REQUEST?: /assign