jiebi/CodeConvo huggingface dataset:
Change:
mergedConfig = &restclient.Config{} mergo.Merge(mergedConfig, promptedConfig) mergo.Merge(mergedConfig, previouslyMergedConfig) <ins> config.promptedCredentials.username = mergedConfig.Username config.promptedCredentials.password = mergedConfig.Password </ins> } return mergedConfig, nil

Discussion:
When I want to use basic-auth, kubectl will display the password I entered: I think it is more sensible to hide the password?
And it seems that kubectl request for username/password twice...
I'll take this. There is a library here: That appears to do the trick, but we need some refactoring so that it can read from an arbitrary reader to fit our usecase.
This was fixed by but I didn't close this issue. Closing it now.
Change:
"io" "net" "path" <ins> "regexp" </ins> "sort" "strconv" "strings"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : AWS release [Local Zones] (). One user enable local zones, using us-west-2 as an example, there's AZ and AWS right now uses method here to infer to region. This won't work for local zone region. Why is this needed: Update to cover this case
/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. ‍
/area provider/aws
Change:
"kubeproxy_iptables_ct_state_invalid_dropped_packets_total", "packets dropped by iptables to work around conntrack problems", nil, nil, metrics.ALPHA, "") <del> IPTablesCTStateInvalidDroppedNFAcctCounter   = "ct_state_invalid_dropped_pkts" iptablesCTStateInvalidDroppedMetricCollector = newNFAcctMetricCollector(IPTablesCTStateInvalidDroppedNFAcctCounter, iptablesCTStateInvalidDroppedPacketsDescription) </del> <ins> IPTablesCTStateInvalidDroppedNFAcctCounter = "ct_state_invalid_dropped_pkts" </ins> // IPTablesRestoreFailuresTotal is the number of iptables restore failures that the proxy has // seen.

Discussion:
The module now logs two errors during module initialization. Simply loading the module will cause two errors to be printed to stderr if the code is not run as root, or is run on a node without nfacct support. This is due to being used when creating Prometheus metrics during module variable initialization, which calls if the nfacct client cannot be initialized. This regression was introduced by: K3s ships all the various Kubernetes components bundled in a single multicall binary, which means that our now logs these errors when it is run as a non-root user. No error logs on module init cc <details</detailsn/a n/a n/a n/a n/a area/proxy sig/network
/sig network
/triage accepted /assign
I was about to fix this, this initialization happens in the unit tests as well .
thanks for the quick response! Do you think you'll have a patch that we could use temporarily for k3s until v1.31.1 is out? We were considering just removing the call for our initial 1.31 release, unless you have a better suggestion.
can you confirm is fine?
Change:
name = name[1:] } parts := strings.Split(name, "--") <del> if len(parts) > 0 { containerName = unescapeDash(parts[0]) </del> <ins> if len(parts) == 0 || parts[0] != containerNamePrefix { return </ins> } if len(parts) > 1 { <del> manifestId = unescapeDash(parts[1]) </del> <ins> containerName = unescapeDash(parts[1]) } if len(parts) > 2 { manifestId = unescapeDash(parts[2]) </ins> } return }

Discussion:
release-master-blocking Conformance-GCE-master-kubetest2Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance] ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test 07-11 15:51 EEST No response /sig cloud-provider cc
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
I remember some timeout has changed with ginkgo2 and something moved from 24hours to 1 hours, or something like that, is it possible that this is the problem here, in this job?
The Grinko timeout change could also be the root problem with this job:
hmm, we have to revisit the flags
hmm, this seems correct
that was a good observations, seems that job is failing because gathering the logs takes too much time !
there is no timeout set in the kubetest2 command here (not sure if this would be the place to set a timeout)
it seems kubetest has to be migrated to ginkgov2 it should use this as basis I'm on vacation this week, can somebody take over and open the issue and patch kubetest2?
looks like this file needs to get updated: add line 72:
oh, you already commented this :D
I will have a look later
Related: umbrella issue:
last testgrid run passed :)
Change:
return firewall, nil } <del> // If the node tags to be used for this cluster have been predefined in the // provider config, just use them. Otherwise, grab all tags from all relevant // instances: </del> <ins> // ComputeHostTags grabs all tags from all instances being added to the pool. </ins> // * The longest tag that is a prefix of the instance name is used <del> // * If any instance has a prefix tag, all instances must // * If no instances have a prefix tag, no tags are used </del> <ins> // * If any instance has no matching prefix tag, return error // Invoking this method to get host tags is risky since it depends on the format // of the host names in the cluster. Only use it as a fallback if gce.nodeTags // is unspecified </ins> func (gce *GCECloud) computeHostTags(hosts []*gceInstance) ([]string, error) { <del> if len(gce.nodeTags) > 0 { return gce.nodeTags, nil } </del> // TODO: We could store the tags in gceInstance, so we could have already fetched it hostNamesByZone := make(map[string][]string) for _, host := range hosts {

Discussion:
In some custom setup cases the prefix-matching logic for GCE load-balancers can break and end up creating a firewall rule with no tags. We should instead refuse to create the rule. In fact, if we find it, we should probably delete the rule, but that's maybe too aggressive. Looking at the logic, if we return error in the tag-selection, we'll abort the whole load-balancer creation, which is unfortunate, but not TERRIBLE. We could just silently not create the firewall but not return error, which will just retry over and over.
/cc
Are you active on this? may have some starter-project bandwidth to help.
Not active. It would indeed be a good starter project :)
Change:
--no-headers=false: When using the default output, don't print headers. -o, --output="": Output format. One of: json|yaml|template|templatefile. --output-version="": Output the formatted object with the given version (default api-version). <del> -t, --template="": Template string or path to template file to use when -o=template or -o=templatefile. </del> <ins> -t, --template="": Template string or path to template file to use when -o=template or -o=templatefile.  The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview] </ins> Global Flags: --alsologtostderr=false: log to standard error as well as files

Discussion:
periodic-conformance-main-k8s-main Kubernetes e2e suite.SynchronizedBeforeSuite 07/17 23:52PDT We saw a similar issue in , which was fixed by upgrading the control plane OS from Ubuntu 18.04 to 22.04. /sig cluster-lifecycle
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 /cc
/sig node It seems to be related to SWAP.
There is a bug in containerd that is fixed in v1.6.14. The test here is using v1.6.8. Kubernetes v1.27 supported containerd versions: 1.7.0+, 1.6.15+
/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
Still failing after is merged. Have we tried bumping the control plane OS image to ubuntu 22.04, like ?
Nevermind, the latest testgrid job might have been triggered before the PR was merged. I am observing this and will close this once I see the job passes.
Containerd version is already v1.6.21 in 's log There maybe still other problems.
can fix a similar failure in .
/close The failure of the swap is fixed by . The current failure is a flake that is mentioned in
Closing this issue. <detailsIn response to : /close The current failure is a flake that is mentioned in 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:
[Service] # ExecStartPre=/usr/bin/wget -N -P /opt/bin https://storage.googleapis.com/k8s/kube-register <del> ExecStartPre=/usr/bin/wget -N -O /opt/bin/kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.3/kube-register-0.0.3-linux-amd64 </del> <ins> ExecStartPre=/usr/bin/curl -L -o /opt/bin/kube-register -z /opt/bin/kube-register https://github.com/kelseyhightower/kube-register/releases/download/v0.0.3/kube-register-0.0.3-linux-amd64 </ins> ExecStartPre=/usr/bin/chmod +x /opt/bin/kube-register ExecStart=/opt/bin/kube-register  --metadata=role=node 

Discussion:
Minor issues with 1) The examples rely on cloud vendor specific variables ($private_ipv4 ) 2) The wget command for kube-register always re-downloads
Change:
":(glob)${root}"/'**/zz_generated.conversion.go'  | xargs -0 rm -f <del> local inputs=() </del> <ins> local input_args=() </ins> for arg in "${input_pkgs[@]}"; do <del> inputs+=("--input-dirs" "$arg") </del> <ins> input_args+=("--input-dirs" "$arg") done local extra_peer_args=() for arg in "${extra_peers[@]:+"${extra_peers[@]}"}"; do extra_peer_args+=("--extra-peer-dirs" "$arg") </ins> done "${gobin}/conversion-gen"  -v "${v}"  -O zz_generated.conversion  --go-header-file "${boilerplate}"  --output-base "${out_base}"  <del> "${inputs[@]}" </del> <ins> "${extra_peer_args[@]:+"${extra_peer_args[@]}"}"  "${input_args[@]}" </ins> fi }

Discussion:
Earlier it was possible to pass flag to while calling script. Now with the new script, is called under which doesnot support any other flags apart from , and . As it can be seen here there is no option to pass flag to conversion-gen Earlier in the script, it was considering all the inputs passed flag is supported by under the hood, but the function in script is not allowing the flag.
/cc
/sig api-machinery
/assign for code generation /triage accepted
/assign
Can you explain why you need this flag? What I found in k/k was that we don't actually need it at all.
You know what, my memory was faulty. We do use it (until I fix that, which is in a development branch, not merged). But we don't use it in any of the "submodule" configs.
A lot of the "magic" behind the conversion logic is very brittle. Can you help me understand where / how this impacts you?
I whipped up a quick patch but have not tested much:
We are using the flag several places in our script On removal of the flag, the autoConvert functions in. files has the error : Althoug I can see the function is already present at . But there is also a comment like Hence, I think there is a need for the in order to use this pkg.
I see. The component-base is something I didn't account for. If you apply the above patch, does the new argument to work for you?
Above patch throws an error for the cases when flag is not passed to function. Instead I followed this approach :
I'd rather not accumulate into a string - can you tell me what error it throws? Note, mine wants Also - is the argument here a dir (e.g. /home/me/src/foo/bar) or a pkg (e.g. ) ? I think it's actually a pkg, right?
You implementation throws error for the cases when we don't specify the option while calling , as shown below: For such cases I am getting following error
It seems to be an old-bash problem. Try this one?
Yes this is working fine.
OK. I'll prep a PR soon.
Thank you
Change:
tpVal, ok := node.Labels[c.topologyKey] if !ok { klog.V(5).Infof("node '%s' doesn't have required label '%s'", node.Name, tpKey) <del> return migration.PredicateResultToFrameworkStatus([]predicates.PredicateFailureReason{predicates.ErrTopologySpreadConstraintsNotMatch}, nil) </del> <ins> return framework.NewStatus(framework.Unschedulable, ErrReasonConstraintsNotMatch) </ins> } selfMatchNum := int32(0)

Discussion:
Part of /priority important-soon See example /sig scheduling /kind cleanup
/help
/assign
/remove-help
Change:
}}, allowed: true, }, <ins> { name: "new supported sysctls: net.ipv4.tcp_fin_timeout", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_fin_timeout", Value: "60"}}, }, }}, allowed: true, }, { name: "new supported sysctls: net.ipv4.tcp_keepalive_intvl", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_keepalive_intvl", Value: "75"}}, }, }}, allowed: true, }, { name: "new supported sysctls: net.ipv4.tcp_keepalive_probes", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_keepalive_probes", Value: "9"}}, }, }}, allowed: true, }, </ins> } for _, tc := range tests {

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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 node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
// don't wait due to limited number of clients, but backoff after the default number of steps return retry.RetryOnConflict(retry.DefaultRetry, func() error { set.Status = *status <del> _, updateErr := ssu.client.Apps().StatefulSets(set.Namespace).UpdateStatus(set) </del> <ins> _, updateErr := ssu.client.AppsV1beta1().StatefulSets(set.Namespace).UpdateStatus(set) </ins> if updateErr == nil { return nil }

Discussion:
The statefulset controller and controller history implementations should be migrated off of the Apps client (deprecated) and onto the AppsV1BetaClient. Currently there is no user facing issue caused by the use of the deprecated resource, but we should maintain good code hygiene.
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 .
/assign kow3ns
/assign kow3ns
/cc
/assign
Change:
func (c *FakeEvents) PatchWithEventNamespace(event *v1.Event, data []byte) (*v1.Event, error) { // TODO: Should be configurable to support additional patch strategies. pt := types.StrategicMergePatchType <del> action := core.NewRootPatchAction(eventsResource, event.Name, pt, data) </del> <ins> var action core.PatchActionImpl </ins> if c.ns != "" { action = core.NewPatchAction(eventsResource, c.ns, event.Name, pt, data) <ins> } else { action = core.NewPatchAction(eventsResource, event.GetNamespace(), event.Name, pt, data) </ins> } obj, err := c.Fake.Invokes(action, event) if obj == nil {

Discussion:
Opening this issue based on what I ran into on with namespace as follows While unit testing the controller, we create a fake client and setup the controller to run using the client. This ends up creating a having the namespace set to When the call eventually reaches The action gets associated with a namespace only if the object has a namespace associated with it. Which in this will be Which will result in the error in to manage the event like does. In case if the namespace is set to Above is a test case that can easily simulate the issue in question. Referring back to the test under PR NA <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted 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:
}) func cleanTest(f *framework.Framework, block bool) { <ins> // delete the APIService first to avoid causing discovery errors aggrclient := f.AggregatorClient _ = aggrclient.ApiregistrationV1beta1().APIServices().Delete("v1alpha1.wardle.k8s.io", nil) </ins> namespace := "sample-system" client := f.ClientSet _ = client.ExtensionsV1beta1().Deployments(namespace).Delete("sample-apiserver", nil)

Discussion:
Seen in https://k8s- Aug 26 09:35:45.074: Couldn't delete ns: "e2e-tests-containers-9cscj": an error on the server ("missing route (service "sample-api" not found)") has prevented the request from succeeding (get ) (&errors.StatusError{ErrStatus:v1.Status{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ListMeta:v1.ListMeta{SelfLink:"", ResourceVersion:""}, Status:"Failure", Message:"an error on the server ("missing route (service "sample-api" not found)") has prevented the request from succeeding (get )", Reason:"InternalError", Details:(*v1.StatusDetails)(0xc4217a4900), Code:500}})
https://k8s-
Change:
NFSconfig = VolumeTestConfig{ namespace:   api.NamespaceDefault, prefix:      "nfs", <del> serverImage: "gcr.io/google_containers/volume-nfs:0.7", </del> <ins> serverImage: "gcr.io/google_containers/volume-nfs:0.6", </ins> serverPorts: []int{2049}, serverArgs:  []string{"-G", "777", "/exports"}, }

Discussion:
Context: NodeSwap feature gate was recently . Currently, as per , swap is only supported with cgroup v2 - cgroup v1 is no longer supported. For this reason, we decided to fail kubelet if NodeSwap feature gate is enabled and the node runs with cgroup v1. This would help prevent any surprises for the user by failing as soon as possible. This effort is being implemented in this PR: The problem: Currently, swap jobs are running with cgroup v1. Swap tests were in a way that they first check on which environment they're being run (e.g. which cgroup version? is NodeSwap FG enabled? Which swapBehavior is defined? etc) and then expect the right behavior to take place. With v1, the tests expect the containers to be defined without swap access. While the tests pass, they are much less valuable, since all they check is that swap is disabled for v1 workloads. The tests would be much more valuable if they would run with v2, therefore actually ensure that proper swap limitations are configured. In addition, is dependent on these changes, since as of now the jobs immediately fail with this PR since kubelet fails on an environment with cgroup v1 and swap enabled. What needs to change: [x] CRI-O swap related jobs should be defined to run with cgroup v2 (e.g. ) [x] containerd swap related jobs should be defined to run with cgroup v2 (e.g. ). Future work: In the future, we might consider introducing more jobs to check swap. Ideally, both and would be tested, perhaps by periodic jobs.
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 node
/sig testing
/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
Change:
fs.StringVar(&s.HostnameOverride, "hostname-override", s.HostnameOverride, "If non-empty, will use this string as identification instead of the actual hostname.") fs.BoolVar(&s.ForceUserspaceProxy, "legacy-userspace-proxy", true, "Use the legacy userspace proxy (instead of the pure iptables proxy).") fs.DurationVar(&s.SyncPeriod, "iptables-sync-period", 5*time.Second, "How often iptables rules are refreshed (e.g. '5s', '1m', '2h22m').  Must be greater than 0.") <ins> fs.BoolVar(&s.MasqueradeAll, "masquerade-all", false, "If using the pure iptables proxy, SNAT everything") </ins> } // Run runs the specified ProxyServer.  This should never exit.

Discussion:
Related to . As a safety mesure, it could be very useful to actually include a flag to proxy to MASQUERADE everything (acting very close to a userspace proxy). I think it's not very hard to do and a very good way to diagnose or even fallback in case of problem (I'm thinking about vxlan cases). Something like "--snat-clients" or "--snat-pods" could be appropriate.
/cc
Looking at the current code: It looks like we SNAT almost everything already now? Would adding a set-mark rule (behind the flag of course) at line 548 be sufficient? Deprecated Public IPs, Loadbalancer IPs, and NodePorts all appear to be marked for SNAT already (also endpoint loopback traffic).
I think that is the flag, yeah. , Benjamin Elder wrote:
Ok, I'll push out a PR for that in a moment. I should be able to take care of that and the cleanup flag (PR out but needs some more work) today. On Aug 20, 2015 2:12 PM, "Tim Hockin" wrote: