jiebi/CodeConvo huggingface dataset:
Change:
next_node=$(increment_ipv4 $next_node $node_subnet_count) done <del> CLUSTER_IP_RANGE="10.244.0.0/16" </del> <ins> CLUSTER_IP_RANGE="${KUBE_GCE_CLUSTER_CLASS_B:-10.244}.0.0/16" </ins> MINION_IP_RANGES=($(eval echo "${subnets[@]}")) MINION_SCOPES=("storage-ro" "compute-rw" "https://www.googleapis.com/auth/monitoring")

Discussion:
This is an offshoot of . cc Here's a log from a single showing that it's getting it's context screwed over by the other clusters coming up at the same time, even those its local environment never changed: Here's the relevant part of the new script: ( is in a separate commit and allows the override of on the GCE so that this script can work.)
I think this can be resolved by having kube- set the context by exporting KUBECONFIG, so a subsequent run doesn't overwrite it.
After some digging with it's a bit trickier than I thought. If we want to be able to run kube-up in parallel from the same branch/working directory, needs to create a separate kubeconfig for each run. But we also want kube-up to set config such that you can immediately run against the created cluster. Probably best to defer until is resolved.
cc And the script is sitting in
Change:
import ( "fmt" "os" <ins> "os/signal" </ins> "runtime" "runtime/pprof"

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: While investigating I've found that kubectl doesn't handle sigterm with profiling. This way, when profiling a long run command (as wait, drain, etc) and interrupting the command in the middle (ctrl-c, as an example) the profile file is not available. What you expected to happen: Profiling file exists if the command exists correctly or if the command is interrupted with ctrl-c How to reproduce it (as minimally and precisely as possible): Execute a long run command (as kubectl drain, kubectl wait) with --profile=cpu and then interrupt the command before it finishes the execution Anything else we need to know?: Because kubectl deals with errors with an util (cmdutil.CheckErr) that in some specific time exists with os.Exit(1), it's not possible yet to also profile programs that exits. Environment: Kubernetes version (use ): kubectl compiled from upstream Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04
/sig cli /assign
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:
if test.Response.Body == nil { test.Response.Body = ioutil.NopCloser(bytes.NewReader([]byte{})) } <del> body, err := ioutil.ReadAll(test.Response.Body) if err != nil { t.Errorf("failed to read body of response: %v", err) } response, created, err := r.transformResponse(test.Response, &http.Request{}, body) </del> <ins> result := r.transformResponse(test.Response, &http.Request{}) response, created, err := result.body, result.created, result.err </ins> hasErr := err != nil if hasErr != test.Error { t.Errorf("%d: unexpected error: %t %v", i, test.Error, err)

Discussion:
Storing r.req / r.resp internally (for use from DoRaw and Do) is probably not the right factoring. There should be a common method doRaw that returns request and body.
Change:
// Register regions, in particular for ECR credentials once.Do(func() { <del> RecognizeWellKnownRegions() </del> <ins> recognizeWellKnownRegions() </ins> }) return awsCloud, nil

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: From /kind cleanup What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cloud-provider /assign
Change:
} func NewFakeVolumeHost(rootDir string, kubeClient clientset.Interface, plugins []VolumePlugin) *fakeVolumeHost { <del> host := &fakeVolumeHost{rootDir: rootDir, kubeClient: kubeClient, cloud: nil} </del> <ins> return newFakeVolumeHost(rootDir, kubeClient, plugins, nil) } func NewFakeVolumeHostWithCloudProvider(rootDir string, kubeClient clientset.Interface, plugins []VolumePlugin, cloud cloudprovider.Interface) *fakeVolumeHost { return newFakeVolumeHost(rootDir, kubeClient, plugins, cloud) } func newFakeVolumeHost(rootDir string, kubeClient clientset.Interface, plugins []VolumePlugin, cloud cloudprovider.Interface) *fakeVolumeHost { host := &fakeVolumeHost{rootDir: rootDir, kubeClient: kubeClient, cloud: cloud} </ins> host.mounter = &mount.FakeMounter{} host.writer = &io.StdWriter{} host.pluginMgr.InitPlugins(plugins, host)

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? 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.): kubernetes, azure file, chinacloudapi Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- 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. --Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others: What happened: We try to mount azure file to pod, and get the following error That is because azure china's storage DNS suffix is rather than What you expected to happen: Kubernetes should provide some method to let user specify storage dns suffix, so we can use Azure file volume How to reproduce it (as minimally and precisely as possible): Any Azure cluster in china can reproduce it. Anything else we need to know: kubernetes has hard coded in shows a relative issue
could you help confirm this?
One possible way is configuring DNS suffix via annotations of PV. If thinks this way okay, I'd like to create a PR to fix it.
azure file was implemented without using resource group or azure cloud provider. The endpoint can be found at One fix is to use azure cloud provider and choose the file service endpoint from azure environment as I did in blob service . Let me know if you can help.
I'm not familiar with azure cloud provider and volume codes. I'd like to try to dig into it to see if I can fix as the way you suggested.
Change:
return cmdutil.AddSourceToErr(fmt.Sprintf("applying patch:n%snto:n%vnfor:", patchBytes, info), info.Source, err) } <del> if cmdutil.ShouldRecord(cmd, info) { if patch, patchType, err := cmdutil.ChangeResourcePatch(info, f.Command(cmd, true)); err == nil { if recordedObject, err := helper.Patch(info.Namespace, info.Name, patchType, patch); err != nil { glog.V(4).Infof("error recording reason: %v", err) } else { patchedObject = recordedObject } } } </del> info.Refresh(patchedObject, true) if uid, err := info.Mapping.UID(info.Object); err != nil {

Discussion:
What happened: What you expected to happen: DS history revision 2 should have change cause from the second command "kubectl apply -f ds-2.yaml --record", not the first /assign
Change:
"context" "errors" "fmt" <ins> "sync" </ins> "time" v1 "k8s.io/api/core/v1"

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: during phase from the plugin when the is updated: What you expected to happen: Not crash. How to reproduce it (as minimally and precisely as possible): I am suspecting that the issue is in the naive implementation of the 's method: Most likely the is cloned during filter phase, e.g. in the called during in the : ... and when is cloned during filtering, new mutex is created, but is not cloned properly, this mean that potentially there are two or more different mutexes protecting the same map from writes. Anything else we need to know?: I think potential solution is to have mutex in the or change the 's . Environment: Kubernetes version (use ): 1.19.0 Cloud provider or hardware configuration: not relevant OS (e.g: ): not relevant Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others: not relevant /sig scheduling
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 scheduling
It looks like relevant code is from and mutex per was considered intially. CC
IIUC, the may (edit: if the node has nominated pods) be duplicated in for every node before passing to extension point. So we cann't rely on 's lock to prevent the state from being modified concurrently. Am I right?
I may have given an incorrect analysis as VolumeBinding's plugin-specific state are always using the same pointer, sorry for the confusion. I removed the confusing comments. It's actually different from what was discussed in . Your and 's analysis make more sense to me.

For nodes that have nominated nodes (cloned CycleState) or not (original CycleState), the original mutex may not be able to protect the CycleState: I will take another look tomorrow.
can you please post the actual core dump, the description in the original comment doesn't seem complete. If the "concurrent map" fatal error is indeed happening at , then it means we are operating on two different CycleStates instances at the same time, which may happen when adding nominated pods () Using the CycleState lock to synchronize access to the plugin's state in the map is not proper, the plugin state itself should have its private lock, this is certainly a bug.
/cc
Change:
import ( "context" <del> "fmt" </del> "net/http" "net/url" "sync/atomic"

Discussion:
/kind bug What happened: kube-aggregrator returns 500 status code with message: unable to set dialer for wardle/api as rest transport is of type *transport.debuggingRoundTripper What you expected to happen: 500 status code should not returned How to reproduce it (as minimally and precisely as possible): kube-apiserver with flag: sample-apiserver as said. command and get the 500 status code: Environment: community master
/assign
/sig api-machinery
/cc
Change:
if !versFlag { allMountOptions = append(allMountOptions, fmt.Sprintf("%s=%s", vers, defaultVers)) } <ins> if !gidFlag && fsGroup != nil { allMountOptions = append(allMountOptions, fmt.Sprintf("%s=%d", gid, *fsGroup)) } </ins> return allMountOptions }

Discussion:
If I look at the code of azureFile plugin, it has fsGroup as an argument, but don't see its usage anywhere I also don't see anywhere explicitely stated that azureFile volume supports fsGroup.
/sig storage
For those landing here, a separate path to get the mount point to have the right permissions is to add this annotation to the PV metadata: This makes the plugin mount the volume in the Pod under those UID,GID. Obviously, this implies that one knows what those are for their workload in the container ...
If i create a PV like this, still mounted with the default root used into POD. StorageClass PV
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale cc Let's check whether works for azure file.
/sig azure
is another way to set groupid(gid) While according to this , we also need to support Here is the code about setting fsgroup from securityContext. I will enable this feature and do a test, it should be 3 lines of code. /assign
BTW, this is all for Linux(UserID, GroupID), is there an identical setting for Windows container?
No, setting user for volumes doesn't work on Windows. Only the rw/ro options are implemented.
According to my investigation, though I put the following code in azure file , it does not take effect. The reason is azure file(cifs) mount does not support gid setting after file system mount, by default would be 0(root) So in summary, set fsGroup code in azure file is useless, user could set gid by mountOptions in storage class, here is an Let me know if you hav any concern about this issue Update: Root cause is azure file(cifs) mount does not support gid setting after file system mount, while azure disk supports.
is this true, that cifs does not support guid setting?
Of course cifs support gid setting, see example: I mean cifs does not support second time gid setting, kind of differnet than azure disk.

Anyway, I am working on a PR to support if no gid setting in azure file storage class, while if both sets, only gid from storage class would be used.
while the code is quite different than just add below 3 lines of code, actually below does not work: I will show you the PR tomorrow.
Change:
if t.String() == "*extensions.ReplicaSet" || t.String() == "*extensions.ReplicaSetList" { return []string{"CONTAINER(S)", "IMAGE(S)", "SELECTOR"} } <ins> if t.String() == "*api.Node" || t.String() == "*api.NodeList" { return []string{"EXTERNAL-IP"} } </ins> } return nil }

Discussion:
Nice to have for nodePort service debugging, creating manual firewalls, hitting hostNetwork or hostPort pods etc. Currently I need to either -o yaml, --template, or switch to gcloud.
This should be quite easy, should be good for contribution.
I could take a look at this. What information exactly that is available in yaml output should be shown? This is example yaml from my node: There should be an additional address with type , right? Should all types be supported or only external when is used?
-o wide should just dump what we get from the api-server right? What changes should be in kubectl?
-o yaml dumps apiserver outout, -o wide appends useful information at the cost of overflowing 80 chars. I'm asking that -o wide does for nodes what it already does for pods. I currently have such a function in my bash rc: I use it pretty often. That's a signal that more people are probably doing the same.
thanks!
Change:
} go func() { <ins> mux := http.NewServeMux() </ins> if s.EnableProfiling { <del> http.HandleFunc("/debug/pprof/", pprof.Index) http.HandleFunc("/debug/pprof/profile", pprof.Profile) http.HandleFunc("/debug/pprof/symbol", pprof.Symbol) </del> <ins> mux.HandleFunc("/debug/pprof/", pprof.Index) mux.HandleFunc("/debug/pprof/profile", pprof.Profile) mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol) </ins> } <del> http.Handle("/metrics", prometheus.Handler()) http.ListenAndServe(net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), nil) </del> <ins> mux.Handle("/metrics", prometheus.Handler()) server := &http.Server{ Addr:    net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), Handler: mux, } glog.Fatal(server.ListenAndServe()) </ins> }() configFactory := factory.NewConfigFactory(kubeClient)

Discussion:
goroutine 11 [running]: net/http.(ServeMux).Handle(0xc20800a8a0, 0x9e9490, 0xd, 0x7f7d12f190a0, 0xb0e7c0) +0x244 net/http.(ServeMux).HandleFunc(0xc20800a8a0, 0x9e9490, 0xd, 0xb0e7c0) +0x6d net/http.HandleFunc(0x9e9490, 0xd, 0xb0e7c0) +0x48 ·001() +0x58 created by (*SchedulerServer).Run +0x1c7
cc
Change:
select { case <-stopCh: return nil <del> case <-r.initConnBackoffManager.Backoff().C(): </del> <ins> case <-r.backoffManager.Backoff().C(): </ins> continue } case apierrors.IsInternalError(err) && retry.ShouldRetry():

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
}, Spec: experimental.DeploymentSpec{ Replicas:       3, <del> Selector:       podLabels, </del> <ins> Selector:       deploymentPodLabels, </ins> UniqueLabelKey: "deployment.kubernetes.io/podTemplateHash", Template: &api.PodTemplateSpec{ ObjectMeta: api.ObjectMeta{ <del> Labels: podLabels, </del> <ins> Labels: deploymentPodLabels, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.
Change:
return nil, fmt.Errorf("metric %q not found", metricName) } <del> if metricFamily.GetMetric() == nil { return nil, fmt.Errorf("metric %q is empty", metricName) } </del> if len(metricFamily.GetMetric()) == 0 { return nil, fmt.Errorf("metric %q is empty", metricName) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : run got the below error message, We should provide the metric data for different extension points from the metric of "schedulerframeworkextensionpointdurationseconds" Why is this needed: Those metrics have been removed by this commit - Those metrics are deprecated cause it is suggested to use - , but simply remove those metrics definitely is not a nice way to address the issue. /sig scheduling
/triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /triage accept 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
/triage accepted
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-contributor-experience at . /lifecycle stale
/lifecycle stale
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
return nil } <del> func NewContainerManager(mountUtil mount.Interface, cadvisorInterface cadvisor.Interface, nodeConfig NodeConfig) (ContainerManager, error) { </del> <ins> func NewContainerManager(mountUtil mount.Interface, cadvisorInterface cadvisor.Interface, nodeConfig NodeConfig, failSwapOn bool) (ContainerManager, error) { </ins> return &containerManagerImpl{}, nil }

Discussion:
Failed: https://k8s- Run so broken it didn't make JUnit output!
Looks like .
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!

Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!
Should be fixed by
Failed: https://k8s- Run so broken it didn't make JUnit output!
Failed: https://k8s- Run so broken it didn't make JUnit output!