jiebi/CodeConvo huggingface dataset:
Change:
for _, mountPoint := range mountPoints { const sysfsDevice = "sysfs" <del> if mountPoint.Device != sysfsDevice { </del> <ins> if mountPoint.Type != sysfsDevice { </ins> continue } // Check whether sysfs is 'rw'

Discussion:
On kubernetes 1.4.6 taken from releases. Using CentOS 7.2 Kubernetes worked with a 1.2 version. I just uninstalled and redo installation with 1.4.6. SELinux is disabled Everyhting seems to works (controller-manager, kubelet, and so on...) excepting kube-proxy that returns an error: "sysfs not mounted". API is responding (internally and externally), and I can see nodes The command that is launched by systemd is (--v=8 to get a maximum of information): But sysfs is mounted on /sys: I also tried to set /sys as writable (only to be sure, with chmod +x), and also tried to use userspace proxy mode. Note: 1.2.6 version was ok I think that the problem is that sysfs mount "none" as label, not "sysfs".
Note: I can now confirm that the problem comes from the "label". I did this: Then kube-proxy successfully started.
before setting . This logic was introduced in v1.3 by to workaround a known docker issue That's why "1.2.6 version was ok". Because sysfs is mounted as , kubeproxy couldn't find it then reported error. But why sysfs is mounted as ?
I installed kubernetes on a "scaleway" (a very nice cloud provider) VPS cluster. Their VPS uses a init file that mounts fs like that. I opened an issue on their github. But anyway you may mount "none" for tmpfs or any ramfs, sysfs, bugfs. What I think is that the mount listing function that is used in kube-proxy code tries to list the mount "source" but not the "type". For that kind of mountpoint you can use "none" as source.
the problem is here: You should check .Type and not .Device. "Device" is what I named "label" or "source" because I didn't remember the name ;) Sysfs can mount a "none" device as type "sysfs", so maybe you can change. See:
I'll do a PR
SGTM.
Change:
return false } <del> if _, hasExcludeBalancerLabel := node.Labels[LabelNodeRoleExcludeBalancer]; hasExcludeBalancerLabel { return false </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.ServiceNodeExclusion) { if _, hasExcludeBalancerLabel := node.Labels[LabelNodeRoleExcludeBalancer]; hasExcludeBalancerLabel { return false } </ins> } // If we have no info, don't accept

Discussion:
For various reasons (network topology, heterogenous nodes, etc) a user may want to control the addition of a node to a cloud load balancer. A specific issue with the Azure Container Instances connector which introduces a virtual node can be found here: The right way to do this is via a node annotation, e.g.
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
/reopen This is still a problem.. any word on when feature gate goes out of alpha?
Setup the enhancement tracking issue for this Still discussing with sig-network on how we want to move forward with this.
Change:
panic("Not implemented") } <ins> func (elb *FakeELB) AddTags(input *elb.AddTagsInput) (*elb.AddTagsOutput, error) { panic("Not implemented") } </ins> func (elb *FakeELB) RegisterInstancesWithLoadBalancer(*elb.RegisterInstancesWithLoadBalancerInput) (*elb.RegisterInstancesWithLoadBalancerOutput, error) { panic("Not implemented") }

Discussion:
BUG REPORT: /kind bug /sig aws What happened: Adding this annotation to an existing service: did not trigger an update on AWS ELB (no new tags). What you expected to happen: Expected to see those 2 new tags under the existing ELB: How to reproduce it (as minimally and precisely as possible): a service without annotation the annotation tags on AWS Anything else we need to know?: Creating a new service WITH the annotation will create the expected tags on AWS. Environment: Kubernetes version (use ): 1.7.9 Cloud provider or hardware configuration**: AWS OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie) Kernel (e.g. ): Linux ip-xxxxx 4.4.78-k8s SMP Fri Jul 28 01:28:39 UTC 2017 x86_64 GNU/Linux Install tools: Others: Using Kops
+1
+1
+1
+1
+1
I've done some work on a fix for this, will try and get a PR submitted later today.
Change:
objects = append(objects, template, pod) b.create(ctx, objects...) <del> // There's no way to be sure that the scheduler has checked the pod. // But if we sleep for a short while, it's likely and if there are any // bugs that prevent the scheduler from handling updates of the class, // those bugs should show up as test flakes. time.Sleep(time.Second) </del> <ins> framework.ExpectNoError(e2epod.WaitForPodNameUnschedulableInNamespace(ctx, f.ClientSet, pod.Name, pod.Namespace)) </ins> // Unblock the pod. class.SuitableNodes = nil

Discussion:
In Aldo pointed out that: Let's use that instead of sleeping. /sig node /triage accepted /priority long-term More robust test.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### What would you like to be ? Aldo pointed out that: There is. There should be a Schedulable condition set to false in the PodStatus. /triage accepted /priority long-term ### Why is this needed? 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
Change:
storage, _ := newStorage(t) emptyName := validController emptyName.Name = "" <del> emptySelector := validController emptySelector.Spec.Selector = map[string]string{} failureCases := []api.ReplicationController{emptyName, emptySelector} </del> <ins> failureCases := []api.ReplicationController{emptyName} </ins> for _, failureCase := range failureCases { c, err := storage.Create(ctx, &failureCase) if c != nil {

Discussion:
It doesn't make sense to define pod template with a set of labels that is strict subset of replicaSelector (or at least I can't find an use-case). For that reason I think that the labels in pod template part of replication controller should be optional and user should care about them only if he wants to define a superset of what replicaSelector already defines.
I've heard the same comments from a client. I think that it'd be more intuitive if we always specify pod labels in the template (so that we can copy&paste pod definition), and replicaSelector is optional (by default pod labels).
It would be reasonable for the selector to be a subset. I'm fine with intelligent defaulting but we need to be careful not to conflate the 2 concepts, which I think would increase the amount of confusion.
Setting RC selector from pod template labels SGTM. Any concerns It wouldn't have to work with separate templates, though it would be desirable if it did. It would be nice if we could add preconditions based on other objects (resource version of pod template in this case) to etcd transactions.
I think we agreed in another issue that defaulting the selector from the pod template labels is reasonable. No argument from me. One problem with pod templates is that we lose the strict relationship between selector and template, so if you change the template the RC needs to behave intelligently (I refuse to create more pods because the template selector doesn't match mine, etc)
We should do this, and we should default replicas to 1. We could also consider defaulting replication controller labels from pod template labels. That way, essentially the only thing that would need to be specified for a singleton RC would be the pod template.
I don't think we can default replicas to 1, since we can't tell the difference between an explicit zero and a default zero, and I think there are lots of reasonable cases where you want to set replicas == 0 on create. (esp. in the context of socket activation)
Responded on the PR: We can distinguish default from 0 if we make it a pointer.
Change:
gvr("storage.k8s.io", "v1beta1", "csistoragecapacities"): { Stub:             `{"metadata": {"name": "csc-12345-2"}, "storageClassName": "sc1"}`, ExpectedEtcdPath: "/registry/csistoragecapacities/" + namespace + "/csc-12345-2", <ins> ExpectedGVK:      gvkP("storage.k8s.io", "v1", "CSIStorageCapacity"), </ins> }, // --

Discussion:
The override in can be removed in Kubernetes v1.25 because then the oldest supported kube-apiserver for downgrades will be v1.24 which will understand the v1 format. Also need to adapt See and Code cleanup...
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
/sig storage
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:
cmd := fmt.Sprintf(`curl -s -o /dev/null -w "%%{http_code}" --connect-timeout 5 http://%s/healthz`, healthCheckNodePortAddr) out, err := e2eoutput.RunHostCmd(pausePod0.Namespace, pausePod0.Name, cmd) if err != nil { <del> return false, err </del> <ins> framework.Logf("unexpected error trying to connect to nodeport %d : %v", healthCheckNodePortAddr, err) return false, nil </ins> } expectedOut := "503" if out != expectedOut { <ins> framework.Logf("expected output: %s , got %s", expectedOut, out) </ins> return false, nil } return true, nil

Discussion:
pull-kubernetes-e2e-gce, assorted GCE jobs Seems to be elevated today No response No response_ /sig network
three instances:
/assign I've seen it too
/triage accepted
confirmed that it has been fixed !
Change:
containers: - image: gcr.io/google_containers/heapster_influxdb:v0.3 name: influxdb <ins> ports: - containerPort: 8083 hostPort: 8083 - containerPort: 8086 hostPort: 8086 </ins> - name: grafana image: gcr.io/google_containers/heapster_grafana:v0.6 env:

Discussion:
/sig gcp /sig cluster-life-cycle /kind flake /milestone v1.10 cc https://k8s- starting last night /assign can one of you verify?
/kind bug /priority important-soon
/priority critical-urgent /priority failing-test /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/assign according to , gonna move those jobs to us-central1-c instead
Change:
"testing" "time" <ins> "github.com/google/go-cmp/cmp" </ins> v1 "k8s.io/api/core/v1" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/types"

Discussion:
Events from node taint manager doesn't report involved object apiVersion: ! apiVersion is reported as other events. For example: ! a pod on node A (not master) off node A is reported, but without apiVersion in involvedObject. The apiVersion is not reported in The issue is still not fixed in master: ! <details</details<detailsIrrelevant </details<details</details<details</details<details</details<details</details
/sig node /sig apps
/assign In the latest version, the issue is confirmed
one suggestion you should wait for the corresponding SIG to triage the issue and accept it before sending PRs, the chances of your PR getting reviewed and approver are much higher
You are right sorry about that. It won’t happen again.
no no worries, it was a suggestion, is not that you did something wrong, but it is possible that your PR doesn't get reviews and you get frustrated
/remove-sig node please re-add if this is node-related issue
I think it is a node related issue. The root cause in taint manager.
/sig node
/assign /triage accepted
Change:
// CauseTypeFieldValueNotSupported is used to report valid (as per formatting rules) // values that can not be handled (e.g. an enumerated string). CauseTypeFieldValueNotSupported CauseType = "FieldValueNotSupported" <ins> // CauseTypeForbidden is used to report valid (as per formatting rules) // values which would be accepted under some conditions, but which are not // permitted by the current conditions (such as security policy).  See // Forbidden(). CauseTypeForbidden CauseType = "FieldValueForbidden" // CauseTypeTooLong is used to report that the given value is too long. // This is similar to ErrorTypeInvalid, but the error will not include the // too-long value.  See TooLong(). CauseTypeTooLong CauseType = "FieldValueTooLong" // CauseTypeTooMany is used to report "too many". This is used to // report that a given list has too many items. This is similar to FieldValueTooLong, // but the error indicates quantity instead of length. CauseTypeTooMany CauseType = "FieldValueTooMany" // CauseTypeInternal is used to report other errors that are not related // to user input.  See InternalError(). CauseTypeInternal CauseType = "InternalError" // CauseTypeTypeInvalid is for the value did not match the schema type for that field CauseTypeTypeInvalid CauseType = "FieldValueTypeInvalid" </ins> // CauseTypeUnexpectedServerResponse is used to report when the server responded to the client // without the expected return type. The presence of this cause indicates the error may be // due to an intervening proxy or the server software malfunctioning.

Discussion:
from: from: CauseType and field.ErrorType should be exactly mapped according to the comment of ErrorType, but currently this is not the case, metav1.CauseType is missing several values none No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Change:
if spec.Template.Spec.RestartPolicy != api.RestartPolicyAlways { allErrs = append(allErrs, field.NotSupported(fldPath.Child("template", "spec", "restartPolicy"), spec.Template.Spec.RestartPolicy, []string{string(api.RestartPolicyAlways)})) } <ins> if spec.Template.Spec.ActiveDeadlineSeconds != nil { allErrs = append(allErrs, field.Invalid(fldPath.Child("template", "spec", "activeDeadlineSeconds"), spec.Template.Spec.ActiveDeadlineSeconds, "must not be specified")) } </ins> allErrs = append(allErrs, apivalidation.ValidateNonnegativeField(int64(spec.MinReadySeconds), fldPath.Child("minReadySeconds"))...) allErrs = append(allErrs, apivalidation.ValidateNonnegativeField(int64(spec.TemplateGeneration), fldPath.Child("templateGeneration"))...)

Discussion:
setting activeDeadlineSeconds in deployment pod template, and seen new pods are continuously created after the older one dies. Is this excepted? if not we should forbidden this.
Yes, it is expected. Once a pod dies, the replica set controller will spawn a new one. activeDeadlineSeconds doesn't make any sense when used under a controller.
we may want to make it a validation error, but I don't feel strong.
Yes, we should not allow activeDeadlineSeconds for restartPolicy=Always pods generally.
What if I want a container to be restarted no matter what status it exits with, but to give up trying if it cannot even start up in seconds? So like this: Start a pod if it keeps constantly failing for seconds: stop it else (if it managed to start and not fail in those first seconds from creating): restart it everytime it fails or successfully finishes
then you want your own controller, RCs are designed for a simple use case: long-running apps. Have a look in , though keep in mind they are under a major redesign:
Sorta late to the party, but this behavior stops us from being able to use a Deployment to mitigate a production memory leak. Our application can handle a , but a leaves items in a pending state for our customers. Killing pods on a regular basis through kubernetes would allow us to induce known behavior of a graceful termination versus deploying new code to handle a timer before terminating. While I understand the intention of this feature, I feel that as a mitigation tool while my teams track down the memory leak, this would let my oncall rotation sleep easy.
Change:
nodeInfo: schedulercache.NewNodeInfo( newResourcePod(schedulercache.Resource{MilliCPU: 2, Memory: 2, StorageOverlay: 5})), fits: false, <del> test: "request exceeds allocatable", </del> <ins> test: "request exceeds allocatable overlay storage resource", reasons: []algorithm.PredicateFailureReason{ NewInsufficientResourceError(v1.ResourceStorageScratch, 18, 5, 20), }, }, { pod: newResourcePod(schedulercache.Resource{StorageOverlay: 18}), nodeInfo: schedulercache.NewNodeInfo( newResourcePod(schedulercache.Resource{MilliCPU: 2, Memory: 2, StorageOverlay: 5})), fits: false, test: "request exceeds allocatable overlay storage resource", </ins> reasons: []algorithm.PredicateFailureReason{ NewInsufficientResourceError(v1.ResourceStorageScratch, 18, 5, 20), },

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 Note: Please file issues for subcomponents under the appropriate repo What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): local isolation Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Bug Kubernetes version (use ): kubernetes HEAD Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: For local storage isolation, overlay resource predicates for pod with only overlay or scratch storage request doesn't work. What you expected to happen: If a pod requests only overlay or scratch storage, then local storage isolation feature should limit the pods. How to reproduce it (as minimally and precisely as possible): Run local cluster from master branch, and create following pods (against a machine with less overlay fs than 1024Gi). Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig storage
CC
Fix is ready:
Change:
`Username          jane.doe`, `UID               uniq-id`, `Groups            [students teachers]`, <del> `Extra: subjects   [math sports]`, </del> `Extra: skills     [reading learning]`, <ins> `Extra: subjects   [math sports]`, </ins> ``, }, },

Discussion:
Unit tests failed with , see TestWhoAmIRun/successtest None No response No response_ /sig cli
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
I think it was caused by
When we loop the golang Map, it's unordered.
I can work on this one.
Thanks.
/priority critical-urgent this is impacting CI,
Change:
storage, _, server := NewTestREST(t, nil, tc.enableDualStack) defer server.Terminate(t) <ins> if tc.isIPv6Primary { if storage.secondaryServiceIPs != nil { storage.serviceIPs, storage.secondaryServiceIPs = storage.secondaryServiceIPs, storage.serviceIPs } else { r, err := ipallocator.NewCIDRRange(makeIPNet6(t)) if err != nil { t.Fatalf("cannot create CIDR Range(primary) %v", err) } if tc.enableDualStack { storage.secondaryServiceIPs = storage.serviceIPs } storage.serviceIPs = r } } </ins> if tc.enableDualStack && storage.secondaryServiceIPs == nil { t.Errorf("storage must allocate secondary ServiceIPs allocator for dual stack") return

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍