jiebi/CodeConvo huggingface dataset:
Change:
What would you like to be : Currently, does not have unit test coverage. Unless there's a strong reason not to, we'd like public facing functions to have unit test coverage. Why is this needed: There's a fairly small chance of GetAddressAndDialer being modified, and thus breaking, in the future without this test coverage. However, it should be relatively straightforward to add the test coverage, and could make a good first issue for a new contributor. There's also the benefit that it helps keep the test coverage in pkg/kubelet high :) And we never know, it might help catch a bug some day :) Extra note I think this ticket could be a great candidate for someone who is new to contributing to sig-node/k8s. I'd prefer to please give first dibs for picking this up to any folks who are currently underrepresented in the k8s community. Please reach out to on k8s Slack (or post directly in #sig-node and tag me) if you're interested, and I'll assign you the issue. I'm happy to mentor and be helpful in whatever way I can :)
/sig node
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
/assign
Hi let's me solve it
Sounds like a plan! Can you please tag and myself for the review?
Hi, I've already created a pr which , please help me complete the review, thanks

Discussion:
assert.Equal(t, result, test.expectSocket, "Unexpected result from IsUnixDomainSocket: %v for %s", result, test.label) } } <ins> func TestGetAddressAndDialer(t *testing.T) { tests := []struct { endpoint     string expectError  bool expectedAddr string }{ { endpoint:     "unix:///tmp/s1.sock", expectError:  false, expectedAddr: "/tmp/s1.sock", }, { endpoint:     "unix:///tmp/f6.sock", expectError:  false, expectedAddr: "/tmp/f6.sock", }, { endpoint:    "tcp://localhost:9090", expectError: true, }, { // The misspelling is intentional to make it error endpoint:    "htta://free-test.com", expectError: true, }, { endpoint:    "https://www.youtube.com/", expectError: true, }, { endpoint:    "http://www.baidu.com/", expectError: true, }, } for _, test := range tests { // just test addr and err addr, _, err := GetAddressAndDialer(test.endpoint) if test.expectError { assert.NotNil(t, err, "expected error during parsing %s", test.endpoint) continue } assert.Nil(t, err, "expected no error during parsing %s", test.endpoint) assert.Equal(t, test.expectedAddr, addr) } } </ins>
Change:
<!-- 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: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority critical-urgent /sig network
thought you might have some insight here?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
will try to check later, but would be great if someone can verify this is not a duplicate of
looks like it might be, any idea why this would have just started now on the 1.19 branch?
seems the job started to run networking tests on friday :thinking:

Discussion:
{ Name:    "client-container", Image:   "gcr.io/google_containers/mounttest:0.6", <del> Command: []string{"/mt", "--break_on_expected_content=false", "--retry_time=10", "--file_content_in_loop=" + filePath}, </del> <ins> Command: []string{"/mt", "--break_on_expected_content=false", "--retry_time=120", "--file_content_in_loop=" + filePath}, </ins> VolumeMounts: []api.VolumeMount{ { Name:      "podinfo",
Change:
<!-- 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: When starting pods with AFS volumes, there is an initial delay of five seconds until the pod is transitioning from the "Scheduled" state. The reason for this is that currently the volume mounting happens inside a wait.Poll which will initially wait a specified interval (currently 5 seconds) before execution. Event log for comparison with and without AFS volume attached (seconds since event): 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign /priority important-soon /sig cloud-provider /area provider/azure
see

Discussion:
newDevicePath := "" <del> err = wait.Poll(1*time.Second, timeout, func() (bool, error) { </del> <ins> err = wait.PollImmediate(1*time.Second, timeout, func() (bool, error) { </ins> if newDevicePath, err = findDiskByLun(int(lun), io, exec); err != nil { return false, fmt.Errorf("azureDisk - WaitForAttach ticker failed node (%s) disk (%s) lun(%v) err(%s)", nodeName, diskName, lun, err) }

} mountComplete := false <del> err = wait.Poll(5*time.Second, 10*time.Minute, func() (bool, error) { </del> <ins> err = wait.PollImmediate(1*time.Second, 2*time.Minute, func() (bool, error) { </ins> err := b.mounter.MountSensitive(source, dir, "cifs", mountOptions, sensitiveMountOptions) mountComplete = true return true, err
Change:
<!-- 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: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: I believe this started with Any thoughts /cc /priority important-soon /milestone v1.19 /sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: /priority important-soon /milestone v1.19 /sig network </details
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved

Discussion:
ready kubernetes %v in-addr.arpa ip6.arpa { pods insecure <del> upstream </del> fallthrough in-addr.arpa ip6.arpa ttl 30 }
Change:
What happened: After creating Kubernetes service on a Kubernetes cluster built on Azure IaaS (not AKS), nodes which are not master nodes but are also not worker nodes and which are labeled with are included in the backend pool for the load balancer. What you expected to happen: All nodes labeled with should be excluded from the load balancer's backend pool. How to reproduce it (as minimally and precisely as possible): Create a node with a type other than and label it with Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.10", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-05-20T14:00:52Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.10", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-05-20T13:51:56Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Azure OS (e.g: ): CentOS Linux release 7.8.2003 (Core) Kernel (e.g. ): Linux master- 3.10.0-1127.8.2.el7.x8664 SMP Tue May 12 16:57:42 UTC 2020 x8664 x8664 x8664 GNU/Linux Install tools: Custom terraform stack Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/priority important-soon /sig cloud-provider /area provider/azure
/priority critical-urgent

Discussion:
if ss.excludeMasterNodesFromStandardLB() && isMasterNode(node) { continue } <ins> if ss.ShouldNodeExcludedFromLoadBalancer(node) { klog.V(4).Infof("Excluding unmanaged/external-resource-group node %q", node.Name) continue } </ins> // in this scenario the vmSetName is an empty string and the name of vmss should be obtained from the provider IDs of nodes resourceGroupName, vmssName, err := getVmssAndResourceGroupNameByVMProviderID(node.Spec.ProviderID) if err != nil {
Change:
<!-- 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: A NetworkPolicy to allow egress to all Pods should use the term "destination" instead of "source" while example: What you expected to happen: should instead be kubectl describe networkpolicy net-document Name: net-document Namespace: default Created on: 2020-07-15 18:16:46 -0700 PDT Labels: <noneAnnotations: {"apiVersion":"","kind":"NetworkPolicy","metadata":{"annotations":{},"name":"net-document","namespace":"default"},"spe... Spec: PodSelector: app=test-document Allowing ingress traffic: To Port: <any(traffic allowed to all ports) From: <any(traffic not restricted by source) Allowing egress traffic: To Port: 80/TCP To: <any(traffic not restricted by destination) Policy Types: Egress, Ingress `` How to reproduce it (as minimally and precisely as possible): Create a allow-all egress NetworkPolicy and do
/sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-network 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 network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/sig cli As this is something specific from kubectl :)
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cli 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
/assign
/remove-triage unresolved

Discussion:
} } if len(nper.To) == 0 { <del> w.Write(LEVEL_0, "%s%sn", initialIndent, "To: <any> (traffic not restricted by source)") </del> <ins> w.Write(LEVEL_0, "%s%sn", initialIndent, "To: <any> (traffic not restricted by destination)") </ins> } else { for _, to := range nper.To { w.Write(LEVEL_0, "%s%sn", initialIndent, "To:")

Except: 192.168.3.0/24, 192.168.4.0/24 ---------- To Port: <any> (traffic allowed to all ports) <del> To: <any> (traffic not restricted by source) </del> <ins> To: <any> (traffic not restricted by destination) </ins> Policy Types: Ingress, Egress `
Change:
<!-- 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: If I have the a psp with apparmor annotations: and I deploy a windows pod it gets blocked: What you expected to happen: Apparmor check is ignored for windows pods How to reproduce it (as minimally and precisely as possible): see above Anything else we need to know?: Should be fixed/documented with work around as per Environment: Kubernetes version (use ): kubectl version Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-06-26T19:51:26Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): windows/unbuntu Kernel (e.g. ): Install tools: aks-engine Network plugin and version (if this is a network-related bug): Others:
/sig windows
/assign I can fix it, it may take some time
I don't actually see anything in that suggests we should ignore windows nodes for apparmor. Can you link to it?
That issue doesn't have guidance explicitly, was more about the need for someone to look into it. I did some investigation with outcomes on the comment and the spread sheet has each PSP detailed with what applies to windows as of now:

Discussion:
"net/url" "os" "path" <ins> sysruntime "runtime" </ins> "sort" "strings" "sync"

opt(klet) } <del> klet.appArmorValidator = apparmor.NewValidator(containerRuntime) klet.softAdmitHandlers.AddPodAdmitHandler(lifecycle.NewAppArmorAdmitHandler(klet.appArmorValidator)) </del> <ins> if sysruntime.GOOS == "linux" { // AppArmor is a Linux kernel security module and it does not support other operating systems. klet.appArmorValidator = apparmor.NewValidator(containerRuntime) klet.softAdmitHandlers.AddPodAdmitHandler(lifecycle.NewAppArmorAdmitHandler(klet.appArmorValidator)) } </ins> klet.softAdmitHandlers.AddPodAdmitHandler(lifecycle.NewNoNewPrivsAdmitHandler(klet.containerRuntime)) klet.softAdmitHandlers.AddPodAdmitHandler(lifecycle.NewProcMountAdmitHandler(klet.containerRuntime))
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Kubemark controller should only use nodes for its template that are hollow nodes, rather than any node. Why is this needed: I want to perf-test the cluster autoscaler using clusters the contain real and hollow nodes. The original integration between cluster autoscaler and kubemark assumed multiple clusters, but I would like to enable using a single cluster for simplicity. I.e. a single node group with kubemark pods and many node groups of hollow kubemark nodes.
/sig node /sig autoscaling These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/remove-sig node /remove-sig autoscaling /sig scalability

Discussion:
} func (kubemarkCluster *kubemarkCluster) getHollowNodeName() (string, error) { <del> nodes, err := kubemarkCluster.nodeLister.List(labels.Everything()) </del> <ins> selector, _ := labels.Parse(nodeGroupLabel) nodes, err := kubemarkCluster.nodeLister.List(selector) </ins> if err != nil { return "", err }
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In the Kubernetes documentation about it says: Based on , if I'm understanding correctly, this is somewhat misleading. It appears that what Kubernetes actually does is issue a command to each container, and it's Docker itself that decides what signal is send to pid 1 in the container. By default (as of 2020 Jul) it sends SIGTERM, but this can be configured during image build with the Dockerfile command, or at runtime with . The documentation would be altered to read (something like): It might also be the case that when Kubernetes "forcefully kill[s]" a pod, it uses rather than issuing a SIGKILL itself; if so, the relevant documentation should be updated to describe what Kubernetes actually does. Why is this needed: It would more accurately describe what happens during the pod termination process. For background: I spent a couple of hours trying to figure out why my container was receiving SIGQUIT instead of SIGTERM. Because the Kubernetes documentation said "a TERM signal is sent to the main process in each Docker container" and not "Kubernetes runs ", it didn't occur to me to look within Docker's documentation for ways in which the signal might be changed. I was unaware of until I stumbled across a which mentioned it. It turned out that the base image I was using had in it. Thanks!
/sig Docs
I would like to add this comment only because of my frustration after I spent hours to find out why doesn't generate as it was documented. Of course it happened because of in Dockerfile. Unfortunately it was totally not clear and almost impossible to find. Actually on custom () made this troubleshooting possible.

Discussion:
<!-- END MUNGE: UNVERSIONED_WARNING --> <del> This file has moved to: http://kubernetes.github.io/docs/user-guide/overview/ </del> <ins> This file has moved to: http://kubernetes.github.io/docs/user-guide/ </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
Change:
<!-- 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 looking into what tests were enabled for and found that the following tests: are running 1.18. From the output of the tests (): and What you expected to happen: tests to be running against the latest code for 1.19 How to reproduce it (as minimally and precisely as possible): It looks to be caused by the setting: 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: /sig release /sig windows

Discussion:
node.Status.Conditions = append(node.Status.Conditions, *nodeOODCondition) } <del> // NOTE(aaronlevy): NodeReady condition needs to be the last in the list of node conditions. // This is due to an issue with version skewed kubelet and master components. // ref: https://github.com/kubernetes/kubernetes/issues/16961 </del> var newNodeReadyCondition api.NodeCondition var oldNodeReadyConditionStatus api.ConditionStatus if containerRuntimeUp && networkConfigured && containerRuntimeVersionRequirementMet {

} oldNodeUnschedulable = node.Spec.Unschedulable } <ins> // NOTE(aaronlevy): NodeReady condition needs to be the last in the list of node conditions. // This is due to an issue with version skewed kubelet and master components. // ref: https://github.com/kubernetes/kubernetes/issues/16961 // TODO: Remove the code after we drop support for v1.0 kubelets lastIndex := len(node.Status.Conditions) - 1 for i := range node.Status.Conditions { if node.Status.Conditions[i].Type == api.NodeReady && i < lastIndex { node.Status.Conditions[i], node.Status.Conditions[lastIndex] = node.Status.Conditions[lastIndex], node.Status.Conditions[i] break } } </ins> return nil }

Status: api.NodeStatus{ Conditions: []api.NodeCondition{ { <del> Type:               api.NodeOutOfDisk, </del> <ins> Type:               api.NodeReady, </ins> Status:             api.ConditionTrue, <del> Reason:             "KubeletOutOfDisk", Message:            "out of disk space", </del> <ins> Reason:             "KubeletReady", Message:            fmt.Sprintf("kubelet is posting ready status"), </ins> LastHeartbeatTime:  unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), }, { <del> Type:               api.NodeReady, </del> <ins> Type:               api.NodeOutOfDisk, </ins> Status:             api.ConditionTrue, <del> Reason:             "KubeletReady", Message:            fmt.Sprintf("kubelet is posting ready status"), </del> <ins> Reason:             "KubeletOutOfDisk", Message:            "out of disk space", </ins> LastHeartbeatTime:  unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: unversioned.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), },
Change:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /sig cluster-lifecycle /cc /priority critical-urgent /milestone v1.19
it seems like the cluster being brought up does not have the API (new in 1.19 and newly tested in conformance) enabled
Digging into this further now
/assign
So... The issue boils down to the way we are pulling in the k8s artifacts and the conformance test binary for this test: The installed kubernetes version is pulled in through the version marker, which is currently referencing an older build (from July 1st before the eventsv1 commit was merged). The test binary is built from the current state of master While we could target a different version marker file to get the version, I believe this issue should be resolved without any further intervention with once it is finished and merged.
This should be fixed in
Opened accompanying PRs for other Cluster API variants: capz: capa:
Thanks

Discussion:
import ( "encoding/json" "testing" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" </del> ) <ins> type FakeJSONBase struct { ID string } type FakePod struct { FakeJSONBase `json:",inline" yaml:",inline"` Labels       map[string]string Int          int Str          string } </ins> func TestMakeJSONString(t *testing.T) { <del> pod := api.Pod{ JSONBase: api.JSONBase{ID: "foo"}, </del> <ins> pod := FakePod{ FakeJSONBase: FakeJSONBase{ID: "foo"}, </ins> Labels: map[string]string{ "foo": "bar", "baz": "blah", }, <ins> Int: -6, Str: "a string", </ins> } body := MakeJSONString(pod)
Change:
The following comments are incomplete. For example, comments for "ResourceQuotaScopeTerminating" should be: Ref: /good-first-issue
/sig scheduling
/assign
Per ResourceQuota is within scope of api-machinery. /sig api-machinery /remove-sig scheduling
/assign
/unassign rakeshreddybandi
/remove-good-first-issue
Hi!! I'd like to help #investigate this problem I'm a beginner, so I'll make my best. Can you please help me point me in the right direction? What's the output today vs. how does the output should look like?
Oh I get it, the comments on top of the lines are not completely accurate on what the message displays, right? I think I got it
Yeah - But I've already opened a PR for this! - See the linked PR So this is already done, just waiting on final merge.
Great Dean, thanks for that!
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
/remove-lifecycle rotten

Discussion:
// These are valid values for resource quota spec const ( <del> // Match all pod objects where spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds >=0 </ins> ResourceQuotaScopeTerminating ResourceQuotaScope = "Terminating" <del> // Match all pod objects where !spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds is nil </ins> ResourceQuotaScopeNotTerminating ResourceQuotaScope = "NotTerminating" // Match all pod objects that have best effort quality of service ResourceQuotaScopeBestEffort ResourceQuotaScope = "BestEffort"

type ResourceQuotaScope string const ( <del> // Match all pod objects where spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds >=0 </ins> ResourceQuotaScopeTerminating ResourceQuotaScope = "Terminating" <del> // Match all pod objects where !spec.activeDeadlineSeconds </del> <ins> // Match all pod objects where spec.activeDeadlineSeconds is nil </ins> ResourceQuotaScopeNotTerminating ResourceQuotaScope = "NotTerminating" // Match all pod objects that have best effort quality of service ResourceQuotaScopeBestEffort ResourceQuotaScope = "BestEffort"