jiebi/CodeConvo huggingface dataset:
Change:
cmd.SetStdin(bytes.NewBuffer(data)) b, err := cmd.CombinedOutput() if err != nil { <del> return fmt.Errorf("%v (%s)", err, b) </del> <ins> pErr, ok := parseRestoreError(string(b)) if ok { return pErr } return fmt.Errorf("%w: %s", err, b) </ins> } return nil }

Discussion:
my k8s cluster version is 1.17.x this cluster has 10 master only 2 nodes get problem. it make my svc sometime can usesometime can timeout what can i do can resolve this problem ? this 2 node's svc is nodeportType
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
you can increase kube-proxy verbosity adding flag and you should get more information about the cause of the error Kubernetes 1.17 is EOL, so you should upgrade to 1.19 at least
/sig network
hello bromy cluster is use kubeadm init .so what should i do .i know this is use configmap but in this i can not found how edit this configmap is availableabout upgrade this cluster .this time is impossible
about stack. i only get this log.
To increase the verbosity on kube-proxy on a kubeadm deployment you can do and wait until pods are restarted. Despite that, if there is a bug, it will not be backported to 1.17, so you have to go to a supported version first
I swear we code to dump the ruleset when this happens, but I don't see it any more.
I'm going to re-purpose this as a feature :)
Hi, I would like to pick this up. Can someone give me some code pointers on where to start?
Let me know if I can help in anyway.
/assign
I'd start with - It's worth thinking about the cleanest solution here, but maybe something like: When you get an error from exec, parse the error for and if it matches, return a . Then let the callers check for a by interface assertion, extract the Line(), extract their input's data at -3 and +3 from that line and log it. E.g. You'll proably want a helper func to do that, which could live in that same iptables package. And a test.
/assign
hi everyone! Is anyone doing this?

I am willing to do this
at least I didn't see any PR from , in case of collision please sync between both to avoid duplicate efforts
hi did you work on it?
Hi apologies I was busy with some other work. You must please continue.
thanks
/assign
I'm working on this now, but I'm stuck in here, I got the line, and then how I extract at -3 and +3 from that line?
you may need to write a helper function to extract them from the logs. my 2 cents.. here is my version for reference. you could add some tests, to cover the boundary conditions. to play around :)
Change:
}, { cfg: &kubeadmapi.MasterConfiguration{ <del> Networking:        kubeadmapi.Networking{PodSubnet: "bar"}, </del> <ins> Networking:        kubeadmapi.Networking{PodSubnet: "10.0.1.15/16"}, </ins> CertificatesDir:   testCertsDir, KubernetesVersion: "v1.7.0", },

Discussion:
/kind bug What happened: Currently, if the user sets the cidr with --pod-network-cidr with kubeadm, the kube-controller-manager is passed the cidr with the --cluster-cidr arg. --node-cidr-mask-size is not passed to the kube-controller-manager and the controller-manager used the default value of 24 The default value of 24 if good for IPv4, but for IPv6 the controller-manager throws an error because the node-cidr-mask-size is incorrect. What you expected to happen: The user should be able to specify the node-cidr-mask-size for IPv6 How to reproduce it (as minimally and precisely as possible): Use Kubeadm specify an IPv6 address with --pod-network-cidr. with a subnet greater than 24. For example kubeadm init --pod-network-cidr=2001:101::0/64 Anything else we need to know?: Environment: IPv6 Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /area kubeadm
/assign rpothier
Change:
expectedIptablesChains: netlinktest.ExpectedIptablesChain{ string(KubeNodePortChain): {{ JumpChain: string(KubeMarkMasqChain), MatchSet: kubeNodePortSetUDP, <ins> }, { JumpChain: "ACCEPT", MatchSet: kubeHealthCheckNodePortSet, </ins> }}, string(kubeServicesChain): {{ <ins> JumpChain: string(KubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { </ins> JumpChain: string(KubeNodePortChain), MatchSet: "", <ins> }, { JumpChain: "ACCEPT", MatchSet: kubeClusterIPSet, </ins> }}, }, },

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 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 network /assign
/triage accepted
Change:
// Map node's condition to Taints. var taints []v1.Taint for _, condition := range node.Status.Conditions { <del> if taint, found := nodeConditionToTaintKeyStatusMap[condition.Type]; found { if condition.Status == taint.noScheduleStatus { </del> <ins> if taintMap, found := nodeConditionToTaintKeyStatusMap[condition.Type]; found { if taintKey, found := taintMap[condition.Status]; found { </ins> taints = append(taints, v1.Taint{ <del> Key:    taint.taintKey, </del> <ins> Key:    taintKey, </ins> Effect: v1.TaintEffectNoSchedule, }) }

Discussion:
In autoscaling tests, we verify that when a node suddenly disappears from the cluster, Cluster Autoscaler will add another one to replace it. With TaintNodesByCondition (enabled by default in ), this is now failing: https://k8s- Every time a node disappears, a subset of pods become NodeLost and aren't rescheduled on a new node. /cc /sig node
I can work on this.
just got merged. Let's check result of autoscaling testings tomorrow: https://k8s-
latest autoscaling testing is green. I think we can close this issue.
Thanks for fixing this!
Change:
if [[ "${NUM_NODES}" -gt "500" ]]; then typha_count=5 fi <ins> if [[ "${NETWORK_POLICY_PROVIDER:-}" != "calico" ]]; then # We're not configured to use Calico, so don't start any Typhas. typha_count=0 fi </ins> echo "${typha_count}" }

Discussion:
Example: https://k8s- cc - Maybe related to /sig network /area platform/gke /kind bug /priority failing-test
/assign
/assign
I guess DaemonSet's behave differently the deployments wrt to scheduling. So in the DaemonSet case we return no nodes to run on since no labels match. In the deployment case (Typha) we want to run at least one thing and cannot so it sits in pending. Maybe the default for typha should be replicas 0? And then we can set the replicas at runtime?
Actually maybe leave it as is for now but in the e2e test maybe we just set it to 0?
Discussed with I think the right fix is . We should return typhacount=0 if NETWORKPOLICY_PROVIDER is not set to .
The tests are still failing with the same error: https://k8s-
I think the problem is here: if [[ "${NETWORKPOLICYPROVIDER:-}" == "calico" ]]; then setup-addon-manifests "addons" "calico-policy-controller" ..... sed -i -e "s I think we need to set that count to CALICOTYPHAREPLICAS_ regardless of provider
/reopen
ping ...
working on the fix that suggested in PR Tests are currently failing but haven't gotten to the bottom of it yet.
This is fixed now.
Change:
"k8s.io/kubernetes/pkg/util/mount" "k8s.io/kubernetes/pkg/volume" volumeutil "k8s.io/kubernetes/pkg/volume/util" <ins> utilexec "k8s.io/utils/exec" </ins> ) const (

Discussion:
What happened: In order to communicate with the target, the iscsi plugin creates a new iface. If for some reason an iface with the same name already exists in the node, this command will re-create it and no error will be reported. However, if the iface already exists and is being used by a session, this command will fail and report the error code 15 (). That's because it can't re-create the iface while it's in use by a session. What you expected to happen: The plugin could go ahead and use the existing iface instead of failing. How to reproduce it (as minimally and precisely as possible): pod1 pod2 Here, will re-use the session/iface from the step above. pod1 At this point, k8s will try to delete the session/iface used by pv1. However, it'll fail because the session is currently in use by pv2. pod1 Here the pod's status will be stuck at : Templates used: Anything else we need to know?: problem happens when a custom initiator is used, and it was reported to me that it's necessary in some set-ups in order to "restrict access to LUNs of the storage". to reproduce manually (assuming there's a session using the iface): /sig storage /CC
/assign
is this related to cc
If iface is reused, wouldn't it try to delete it once last volume (from kubelet perspective) is detached?
No
Change:
// Proxier implements ProxyProvider var _ proxy.ProxyProvider = &Proxier{} <ins> // ParseExcludedCIDRs parses the input strings and returns net.IPNet // The validation has been done earlier so the error condition will never happen under normal conditions func ParseExcludedCIDRs(excludeCIDRStrs []string) []*net.IPNet { var cidrExclusions []*net.IPNet for _, excludedCIDR := range excludeCIDRStrs { _, n, err := net.ParseCIDR(excludedCIDR) if err == nil { cidrExclusions = append(cidrExclusions, n) } } return cidrExclusions } </ins> // NewProxier returns a new Proxier given an iptables and ipvs Interface instance. // Because of the iptables and ipvs logic, it is assumed that there is only a single Proxier active on a machine. // An error will be returned if it fails to update or acquire the initial lock.

Discussion:
What would you like to be : Change excludeCIDRs from []string to []*IPNet in Proxier and perform the parsing at construction of Proxier. Why is this needed: This was proposed by over comments in Pr This improves the performance of isIPInExcludeCIDRs since the cost of parsing becomes one time.
/sig network /kind cleanup
/remove-kind feature
/triage unresolved I am a bot run by ‍
ping
Change:
TypeMeta     `json:",inline"` Labels       map[string]string `json:"labels,omitempty" description:"map of string keys and values that can be used to organize and categorize pods; may match selectors of replication controllers and services"` DesiredState PodState          `json:"desiredState,omitempty" description:"specification of the desired state of the pod"` <del> CurrentState PodState          `json:"currentState,omitempty" description:"current state of the pod"` </del> <ins> CurrentState PodState          `json:"currentState,omitempty" description:"current state of the pod; populated by the system, read-only"` </ins> // NodeSelector is a selector which must be true for the pod to fit on a node NodeSelector map[string]string `json:"nodeSelector,omitempty" description:"selector which must match a node's labels for the pod to be scheduled on that node"` }

Discussion:
Right now we have haphazard comments regarding which fields are read-only/output-only, and many, such as aren't documented at all. Swagger 2.0 actually supports a property tag, but we're using Swagger 1.2, which does not, officially. The official meaning doesn't match what we want, though. fields must not be included in a PUT, which would be painful for clients. We could simply document our convention, however. We should tag fields as readonly. Maybe we could have go-restful automatically add a comment to the description in that case.
/cc
Are there any known obstacles with upgrading to 2.0?
go-restful (the framework that we are using to generate swagger-spec) does not support 2.0 yet:
Disclaimer: for the doc-fix it day, I will be adding the read-only information into the description. This partially resolves this issue, but not entirely. I will unassign myself after description is done.
Note: users can set the node status when creating a node. This is a bug and should be fixed. After fixing that bug, the corresponding description should be updated.
Change:
unsyncedServices   bool                   // whether the services should NOT be synced configMap          *v1.ConfigMap          // an optional ConfigMap to pull from secret             *v1.Secret             // an optional Secret to pull from <ins> podIPs             []string               // the pod IPs </ins> expectedEnvs       []kubecontainer.EnvVar // a set of expected environment vars expectedError      bool                   // does the test fail expectedEvent      string                 // does the test emit an event

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --In a dual-stack cluster with IPv4 as default family (first kubelet IP), a container is created with a env var set to . When the container is running, properly contains the IPv4 But at runtime, this env var (used in container args) is expanded to the pod IPv6 instead of the IPv4. When using , it should always return the value actually exposed as and not something else. Kubernetes version:Cloud provider or hardware configuration: Bare metal cluster OS (e.g: ): Ubuntu 20.04 Kernel (e.g. ): Linux 5.8.0-59-generic 66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x8664 x8664 x86_64 GNU/Linux Network plugin and version (if this is a network-related bug): cilium 1.10 Others: CRI-O 1.21 + crun.
Note: I have a configuration that matches the ones that had IP ordering issue before was fixed. So it may be related.
/sig network
Just a guess, but I wonder if it may be caused by
That's it. The fix from properly sort IP when computing the Pod status, but the sorted IPs are then replaced by computed IPs as this log shows.
/triage accepted Thanks for the detailed report
/assign
Change:
cmdutil.AddApplyAnnotationFlags(cmd) cmdutil.AddValidateFlags(cmd) <ins> cmdutil.AddDryRunFlag(cmd) </ins> cmd.Flags().StringVar(&o.IngressClass, "class", o.IngressClass, "Ingress Class to be used") cmd.Flags().StringArrayVar(&o.Rules, "rule", o.Rules, "Rule in format host/path=service:port[,tls=secretname]. Paths containing the leading character '*' are considered pathType=Prefix. tls argument is optional.") cmd.Flags().StringVar(&o.DefaultBackend, "default-backend", o.DefaultBackend, "Default service for backend, in format of svcname:port")

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: kubectl create ingress panics because there is no cmdutil.AddDryRunFlag What you expected to happen: Command to work How to reproduce it (as minimally and precisely as possible): Compile the upstream, run ` Anything else we need to know?: Environment: Kubernetes version (use ): upstream/dev /sig cli /kind bug /priority critical-urgent
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
Change:
} v, err := conversion.EnforcePtr(listPtr) if err != nil || v.Kind() != reflect.Slice { <del> panic("need ptr to slice") </del> <ins> return fmt.Errorf("need ptr to slice: %v", err) </ins> } key = path.Join(s.pathPrefix, key)

Discussion:
Remove panic in , please return error instead following .
/sig api-machinery /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 : /sig api-machinery /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
Please also add some log if returns error
/remove-kind bug /kind cleanup
Change:
} func (obj InfoObject) Live() (map[string]interface{}, error) { <del> if obj.Info.Object == nil { </del> <ins> if obj.Remote == nil { </ins> return nil, nil // Object doesn't exist on cluster. } <del> data, err := runtime.Encode(obj.Encoder, obj.Info.Object) if err != nil { return nil, err } return obj.toMap(data) </del> <ins> return obj.Remote.UnstructuredContent(), nil </ins> } func (obj InfoObject) Merged() (map[string]interface{}, error) {

Discussion:
/kind bug /sig cli /area kubectl Hello. This is my first interaction with the Kubernetes community, so please forgive me if i have left out any crucial details, or if, perhaps, this is PEBKAC after all! I am keen to have a working feature, as described in and I am running K8s v1.9.3 and realise that this feature is in alpha, but i thought i would ask anyway. We're not on v1.9.4 yet, but the changelog doesn't mention the feature. What you expected to happen: I have some services deployed to Kubernetes with YAML files, that has been working reliably. We always use to deploy things. When a service is already deployed, and i make a minor change in the config file, for example the service port, i expect to see that in the diff. Instead, gives no output and exits with a . How to reproduce it (as minimally and precisely as possible): Consider the file : I make sure that it is correctly running on the cluster: Great, looking good. Now, i change the value to use Docker image tag and save. Now, i run: The stderr/stdout output is empty, and the exit code is . Anything else we need to know?: Environment: Kubernetes version: Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-09T21:50:44Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I have this same issue - if I change, say, to in my , running returns empty. If I try tweaking the version I'm diffing (which I don't understand) - e.g. - then I see a bunch of differences, but not actually the change I was expecting in the number of replicas.
I'll take this. Sorry for the inconvenience.
Change:
legacyregistry.MustRegister(zoneSize) legacyregistry.MustRegister(unhealthyNodes) legacyregistry.MustRegister(evictionsNumber) <ins> legacyregistry.MustRegister(evictionsTotal) </ins> }) }

Discussion:
I would like to propose the graduation of the metric from alpha to stable. The metric has been stable for 2 years now.
/sig api-machinery /sig instrumentation
I am willing to do all StabilityLevels from alpha to stable? Is that right?
/assign
- The request is to have the stability level for the metric graduate to stable. If there are other metrics you want to do at the same time that's a bonus, but not part of the request in this issue.
/sig node /remove-sig api-machinery /cc
To be promoted to stable, the metrics would need to be renamed from to in order to follow Prometheus best practices as well as sig-instrumentation naming guidelines.
/cc
/assign
/triage accepted
Change:
"k8s.io/apimachinery/pkg/labels" "k8s.io/client-go/util/workqueue" "k8s.io/klog" <del> "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates" </del> pluginhelper "k8s.io/kubernetes/pkg/scheduler/framework/plugins/helper" <del> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/migration" </del> framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" "k8s.io/kubernetes/pkg/scheduler/nodeinfo" schedulernodeinfo "k8s.io/kubernetes/pkg/scheduler/nodeinfo"

Discussion:
Part of /priority important-soon See example /sig scheduling /kind cleanup
/help
/assign
/remove-help
Change:
CapRWX                 Capability = "RWX"                 // support ReadWriteMany access modes CapControllerExpansion Capability = "controllerExpansion" // support volume expansion for controller CapNodeExpansion       Capability = "nodeExpansion"       // support volume expansion for node <del> CapVolumeLimits                   = "volumeLimits"        // support volume limits (can be *very* slow) </del> <ins> CapVolumeLimits        Capability = "volumeLimits"        // support volume limits (can be *very* slow) CapSingleNodeVolume    Capability = "singleNodeVolume"    // support volume that can run on single node (like hostpath) </ins> ) // DriverInfo represents static information about a TestDriver.

Discussion:
What happened: When we run csi hostpath driver e2e tests on a multi-node cluster some tests failed because they assume that volumes are node independent but this is not the case for some drivers like hostpath. Related PR; What you expected to happen: Skip the tests that assume volumes are node independent for the drivers that don't support node independent volumes. /sig storage /assign
Change:
}, timeout: 1 * time.Second, <del> expectedErr: wait.ErrWaitTimeout.Error(), </del> <ins> expectedErr: "timed out waiting for the condition on theresource/name-foo", </ins> validateActions: func(t *testing.T, actions []clienttesting.Action) { if len(actions) != 2 { t.Fatal(spew.Sdump(actions))

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : let's say I run If the deployment is comes up in time it tells me which deployment is up, but if it times out it doesn't tell me on which deployment/resource. Could it be Why is this needed: That would make it easier to use, and the information provided is the same irregardless on whether the condition is met or not
/sig cli
Sounds reasonable for me, i can take care of this one if someone from owners will approve it as a feature.
/assign Zyqsempai
GitHub didn't allow me to assign the following users: Zyqsempai. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Zyqsempai 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 result == resourceVersion, nil } <del> return wait.Poll(10*time.Millisecond, 100*time.Millisecond, ready) </del> <ins> return wait.Poll(10*time.Millisecond, util.ForeverTestTimeout, ready) </ins> } func TestListFromMemory(t *testing.T) {

Discussion:
fwiw, the time outs are way to short (100ms) please use util.ForeverTestTimeout instead.
Yes - it seems to be cause by too short timeouts. Sent out for review.