jiebi/CodeConvo huggingface dataset:
Change:
Use apiserver extension(APIService) interface, impl its method to gracefully control resource deletion, when the field is nil, will lead to panic!! To first check if is nil, then get its value. Use apiserver extension(APIService) strategy, impl this function below will lead to panic: As the field is a int64 pointer, need to be careful when init the struct. 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 api-machinery
/triage accepted

Discussion:
type RESTGracefulDeleteStrategy interface { // CheckGracefulDelete should return true if the object can be gracefully deleted and set // any default values on the DeleteOptions. <ins> // NOTE: if return true, `options.GracePeriodSeconds` must be non-nil (nil will fail), // that's what tells the deletion how "graceful" to be. </ins> CheckGracefulDelete(ctx context.Context, obj runtime.Object, options *metav1.DeleteOptions) bool }

return false, true, nil } <ins> // `CheckGracefulDelete` will be implemented by specific strategy </ins> if !gracefulStrategy.CheckGracefulDelete(ctx, obj, options) { return false, false, nil } <ins> if options.GracePeriodSeconds == nil { return false, false, errors.NewInternalError(fmt.Errorf("options.GracePeriodSeconds should not be nil")) } </ins> now := metav1.NewTime(metav1.Now().Add(time.Second * time.Duration(*options.GracePeriodSeconds))) objectMeta.SetDeletionTimestamp(&now) objectMeta.SetDeletionGracePeriodSeconds(options.GracePeriodSeconds)

if objectMeta.GetGeneration() > 0 { objectMeta.SetGeneration(objectMeta.GetGeneration() + 1) } return true, false, nil }
Change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
/assign

Discussion:
import ( "fmt" "strings" <ins> "sync" </ins> "testing" "time"

syncNodeStatus := func() {} var shutdownChan chan bool <ins> var shutdownChanMut sync.Mutex </ins> var connChan = make(chan struct{}, 1) systemDbus = func() (dbusInhibiter, error) { defer func() { connChan <- struct{}{} }() <del> shutdownChan = make(chan bool) dbus := &fakeDbus{currentInhibitDelay: systemInhibitDelay, shutdownChan: shutdownChan, overrideSystemInhibitDelay: overrideSystemInhibitDelay} </del> <ins> ch := make(chan bool) shutdownChanMut.Lock() shutdownChan = ch shutdownChanMut.Unlock() dbus := &fakeDbus{currentInhibitDelay: systemInhibitDelay, shutdownChan: ch, overrideSystemInhibitDelay: overrideSystemInhibitDelay} </ins> return dbus, nil }

t.Errorf("unexpected error: %v", err) } <del> for i := 0; i != 5; i++ { </del> <ins> for i := 0; i != 3; i++ { </ins> select { case <-time.After(dbusReconnectPeriod * 5): t.Fatal("wait dbus connect timeout") case <-connChan: } <del> time.Sleep(time.Second) </del> <ins> shutdownChanMut.Lock() </ins> close(shutdownChan) <ins> shutdownChanMut.Unlock() </ins> } }
Change:
Is the sysctl namespaced? If so, can we include this in the set of "safe" sysctls? If we allow this, we would: add to permit in PodSecurity baseline profile cc So that containers can bind to low ports without needing to bake CAPNETBINDSERVICE into the files in the image doesn't help hostNetwork pods since they don't have their own namespace and you likely wouldn't want to change the system-wide sysctl also, pods that schedule to arbitrary nodes likely shouldn't start taking advantage of this until 2+ releases after it merges into the kubelet, because of potential node skew
/sig network security node auth
xref: for actually potentially setting this by default even.
/assign
Yes, it is network-namespaced and :+1: to adding it to safe list. From
/triage accepted

Discussion:
"net.ipv4.ip_local_port_range", "net.ipv4.tcp_syncookies", "net.ipv4.ping_group_range", <ins> "net.ipv4.ip_unprivileged_port_start", </ins> } }

"net.ipv4.ip_local_port_range", "net.ipv4.tcp_syncookies", "net.ipv4.ping_group_range", <ins> "net.ipv4.ip_unprivileged_port_start", </ins> ) )

// security context with no sysctls tweak(p, func(p *corev1.Pod) { p.Spec.SecurityContext.Sysctls = nil }), // sysctls with name="kernel.shm_rmid_forced" ,"net.ipv4.ip_local_port_range" <del> // "net.ipv4.tcp_syncookies", "net.ipv4.ping_group_range" </del> <ins> // "net.ipv4.tcp_syncookies", "net.ipv4.ping_group_range", // "net.ipv4.ip_unprivileged_port_start" </ins> tweak(p, func(p *corev1.Pod) { p.Spec.SecurityContext.Sysctls = []corev1.Sysctl{ {Name: "kernel.shm_rmid_forced", Value: "0"}, {Name: "net.ipv4.ip_local_port_range", Value: "1024 65535"}, {Name: "net.ipv4.tcp_syncookies", Value: "0"}, {Name: "net.ipv4.ping_group_range", Value: "1 0"}, <ins> {Name: "net.ipv4.ip_unprivileged_port_start", Value: "1024"}, </ins> } }), }

value: "0" - name: net.ipv4.ping_group_range value: 1 0 <ins> - name: net.ipv4.ip_unprivileged_port_start value: "1024" </ins>
Change:
--write-to-config flag in the scheduler writes to a file the default component config; however this config if passed back to the scheduler is not usable because it lists all default plugins as enabled without disabling them. To make the configuration usable as an input config while at the same time useful for debugging, the output should disable all plugins for each extension point using the "*" expression. /help /sig scheduling /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 : --write-to-config flag in the scheduler writes to a file the default component config; however this config if passed back to the scheduler is not usable because it lists all default plugins as enabled without disabling them. /help /sig scheduling /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
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

Discussion:
} cfg.Profiles = completedProfiles <ins> if len(fileName) > 0 { // Since the default component config lists all the default plugins as enabled // without disabling them, we must explicitly disable all the plugins for each // extension point using the "*" expression to ensure that the generated config // file is usable disabledPlugins := []config.Plugin{{Name: "*"}} for i := range cfg.Profiles { if cfg.Profiles[i].Plugins == nil { continue } cfg.Profiles[i].Plugins.QueueSort.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreFilter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Filter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PostFilter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreScore.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Score.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Reserve.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Permit.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreBind.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Bind.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PostBind.Disabled = disabledPlugins } } </ins> buf, err := encodeConfig(cfg) if err != nil { return err
Change:
When mounting an in-tree NFS share, reserved ports are used (this happened to be a filestore instance, so we can assume the server is configured sanely). gke-regular-default-pool--zgfs /home/mattcary # netstat -tp | grep nfs tcp 0 0 gke-regular-default:982 10.108.60.194:nfs ESTABLISHED - Note the connection is at port 982. This can conflict with other ports on the host, eg the metadata server in GKE. The right solution seems to be to restrict the sunrpc reserved port range. This only affects kube-up.
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

Discussion:
[Install] WantedBy=multi-user.target <ins> - path: /etc/modprobe.d/sunrpc.conf permissions: 0644 owner: root # The GKE metadata server uses ports 987-989, so the sunrpc range should be restricted to be below. content: | options sunrpc max_resvport=986 </ins> runcmd: - systemctl daemon-reload - systemctl enable kube-node-installation.service
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 --/kind bug /sig storage /area provider/azure Creation of a PVC that that uses a StorageClass with the in-tree provisioner and parameter fails. The above to work. an Azure cluster with CSI enabled StorageClass with the in-tree provisioner PVC and Deployment sure that external-provisioner fails with: Kubernetes version (use ): v1.21.1 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:
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 see that there is mismatch between the csi-translation lib and the docs in The csi-translation-lib is translating in-tree PV to CSI with uppercase ("Managed"), so this means that the docs (that state allowed values are with lowercase - "managed") are wrong. If we want to support the lowercase values, then the csi-translation logic needs to be adapted. /cc
/assign
would fix this issue, pls use kind as a workaround, thanks.
there is a quick fix in azure disk csi driver: , it would be merged in v1.5 version

Discussion:
} ``` <del> This time the selector for the service is `name=redis-slave`, because that identifies the pods running redis slaves. It may also be helpful to set labels on your service itself--as we've done here--to make it easy to locate them with the `kubecfg -l "label=value" list sevices` command. </del> <ins> This time the selector for the service is `name=redisslave`, because that identifies the pods running redis slaves. It may also be helpful to set labels on your service itself--as we've done here--to make it easy to locate them with the `kubecfg -l "label=value" list services` command. </ins> Now that you have created the service specification, create it in your cluster with the `kubecfg` CLI:
Change:
apiserverlongrunninggauge and apiserverregisterwatchers are kinda redundant . We discussed this in our SIG instrumentation meeting and while it's clear that apiserverlongrunninggauge, the name does not conform to instrumentation guidelines (it was created before those guidelines existed). What we want to do is deprecate both metrics and create a new one which actually does conform to our naming conventions probably something like . has volunteered to undertake this. /cc /sig instrumentation
/assign
GitHub didn't allow me to assign the following users: yan-lgtm. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
/triage accepted
Hello! Have you still working on this issue? I am new to the community, and can I try it?
Hey I the deprecate in If you want to add the new metric, feel free to do so.
Can I add the new metric? If I can, can you give me some advice about the new metric? Thank you~
/assign

Discussion:
) longRunningRequestGauge = compbasemetrics.NewGaugeVec( &compbasemetrics.GaugeOpts{ <del> Name:           "apiserver_longrunning_gauge", Help:           "Gauge of all active long-running apiserver requests broken out by verb, group, version, resource, scope and component. Not all requests are tracked this way.", StabilityLevel: compbasemetrics.ALPHA, </del> <ins> Name:              "apiserver_longrunning_gauge", Help:              "Gauge of all active long-running apiserver requests broken out by verb, group, version, resource, scope and component. Not all requests are tracked this way.", StabilityLevel:    compbasemetrics.ALPHA, DeprecatedVersion: "1.23.0", </ins> }, []string{"verb", "group", "version", "resource", "subresource", "scope", "component"}, )

// RegisteredWatchers is a number of currently registered watchers splitted by resource. RegisteredWatchers = compbasemetrics.NewGaugeVec( &compbasemetrics.GaugeOpts{ <del> Name:           "apiserver_registered_watchers", Help:           "Number of currently registered watchers for a given resources", StabilityLevel: compbasemetrics.ALPHA, </del> <ins> Name:              "apiserver_registered_watchers", Help:              "Number of currently registered watchers for a given resources", StabilityLevel:    compbasemetrics.ALPHA, DeprecatedVersion: "1.23.0", </ins> }, []string{"group", "version", "kind"}, )
Change:
We should drop the bit once in favor of a once gcp has a replacement. xref: /assign /milestone v1.24 /triage accepted /sig auth
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /lifecycle frozen
I'm in the release 1.24 bug triage shadow. Does this issue still target release 1.24? If yes, would you please update the kind and priority fields for us to track it better?
Yes, definitely targeting 1.24 /priority important-soon /kind cleanup deprecation
would you please link the PR that solves this issue and update the status?
There is none yet. Waiting on GKE folks.
addresses this issue.

Discussion:
var warnOnce sync.Once func newGCPAuthProvider(_ string, gcpConfig map[string]string, persister restclient.AuthProviderConfigPersister) (restclient.AuthProvider, error) { <del> // deprecated in v1.22, remove in v1.25 // this should be updated to use klog.Warningf in v1.24 to more actively warn consumers </del> warnOnce.Do(func() { <del> klog.V(1).Infof(`WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead. To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins`) </del> <ins> klog.Warningf(`WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead. To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke`) </ins> }) ts, err := tokenSource(isCmdTokenSource(gcpConfig), gcpConfig)
Change:
Replace the azure auth plugin deprecation with a in v1.24 xref: /assign /milestone v1.24 /triage accepted /sig auth
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /lifecycle frozen
/assign
/priority important-soon /kind cleanup deprecation

Discussion:
func newAzureAuthProvider(_ string, cfg map[string]string, persister restclient.AuthProviderConfigPersister) (restclient.AuthProvider, error) { // deprecated in v1.22, remove in v1.25 <del> // this should be updated to use klog.Warningf in v1.24 to more actively warn consumers </del> warnOnce.Do(func() { <del> klog.V(1).Infof(`WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.25+; use https://github.com/Azure/kubelogin instead. </del> <ins> klog.Warningf(`WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.25+; use https://github.com/Azure/kubelogin instead. </ins> To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins`) })
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 --the issue stays in the CleanScope function where all GET calls will end up with scope "namespace" and end up with verb "LIST" 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 /sig api-machinery
/triage accepted

Discussion:
// CleanScope returns the scope of the request. func CleanScope(requestInfo *request.RequestInfo) string { <del> if requestInfo.Namespace != "" { return "namespace" } </del> if requestInfo.Name != "" { return "resource" } <ins> if requestInfo.Namespace != "" { return "namespace" } </ins> if requestInfo.IsResourceRequest { return "cluster" }

"net/http" "net/url" "testing" <ins> "k8s.io/apiserver/pkg/endpoints/request" </ins> ) func TestCleanVerb(t *testing.T) {

}) } } <ins> func TestCleanScope(t *testing.T) { testCases := []struct { name          string requestInfo   *request.RequestInfo expectedScope string }{ { name:          "empty scope", requestInfo:   &request.RequestInfo{}, expectedScope: "", }, { name: "resource scope", requestInfo: &request.RequestInfo{ Name:              "my-resource", Namespace:         "my-namespace", IsResourceRequest: false, }, expectedScope: "resource", }, { name: "namespace scope", requestInfo: &request.RequestInfo{ Namespace:         "my-namespace", IsResourceRequest: false, }, expectedScope: "namespace", }, { name: "cluster scope", requestInfo: &request.RequestInfo{ Namespace:         "", IsResourceRequest: true, }, expectedScope: "cluster", }, } for _, test := range testCases { t.Run(test.name, func(t *testing.T) { if CleanScope(test.requestInfo) != test.expectedScope { t.Errorf("failed to clean scope: %v", test.requestInfo) } }) } } </ins>
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- ci-kubernetes-build-deprecated ci-kubernetes-build-deprecated-1-21 ci-kubernetes-build-1-20-deprecated ci-kubernetes-build-1-19-deprecated n/a - last good started at 2021-07-09 19:30:55 +0000 UTC - first bad started at 2021-07-09 21:14:51 +0000 TBD but likely related to the merge of or its followup PR's /sig testing /sig release /priority critical-urgent /area test /milestone v1.22 /assign
/triage accepted
Looks like maybe the needs to be moved to get picked up by whatever is invoking. Also, having a total lack of logs when bootstrap's default entrypoint fails is a fun failure mode. Ever more reason to stop using it (ref: )
should resolve, will hold open until we see successful job runs post-merge
/reopen I could have sworn I didn't use an auto-closing keyword...
Reopened this issue. <detailsIn response to : /reopen I could have sworn I didn't use an auto-closing keyword... 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
/close closing again, I see green runs for all of the affected builds:
Closing this issue. <detailsIn response to : /close closing again, I see green runs for all of the affected builds: 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

Discussion:
except zlib.error: # Don't fail if it's not gzipped. pass <del> data = data.decode('utf-8') </del> try: root = ET.fromstring(data)