jiebi/CodeConvo huggingface dataset:
Change:
Follow up for the deprecation we did in 1.14:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /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 : /remove-lifecycle stale /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
/sig release
I am willing to take this, if it is available :)
go for it. All you need to do is remove and associated code -
I ended up getting hit with the removal of the --make-symlinks flag. I looked at the threads linked to the original PR, but I did not find the actual reason behind the removal. Do you recall was the reason behind removing that capability?
the original request was from

Discussion:
package main import ( <del> "errors" </del> goflag "flag" <del> "fmt" </del> "math/rand" "os" <del> "path" </del> "path/filepath" "time"

cloudController, } <del> makeSymlinksFlag := false </del> cmd := &cobra.Command{ Use:   "hyperkube", Short: "Request a new project", Run: func(cmd *cobra.Command, args []string) { <del> if len(args) != 0 || !makeSymlinksFlag { </del> <ins> if len(args) != 0 { </ins> cmd.Help() os.Exit(1) } <del> if err := makeSymlinks(os.Args[0], commandFns); err != nil { fmt.Fprintf(os.Stderr, "%vn", err.Error()) } </del> }, } <del> cmd.Flags().BoolVar(&makeSymlinksFlag, "make-symlinks", makeSymlinksFlag, "create a symlink for each server in current directory") cmd.Flags().MarkHidden("make-symlinks") // hide this flag from appearing in servers' usage output cmd.Flags().MarkDeprecated("make-symlinks", "This feature will be removed in a later release.") </del> for i := range commandFns { cmd.AddCommand(commandFns[i]())

return cmd, commandFns } <del> // makeSymlinks will create a symlink for each command in the local directory. func makeSymlinks(targetName string, commandFns []func() *cobra.Command) error { wd, err := os.Getwd() if err != nil { return err } var errs bool for _, commandFn := range commandFns { command := commandFn() link := path.Join(wd, command.Name()) err := os.Symlink(targetName, link) if err != nil { errs = true fmt.Println(err) } } if errs { return errors.New("Error creating one or more symlinks") } return nil } </del>
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 --What happened: kubectl describe pod xxx not show csi inline volume, it shows <unknow! What you expected to happen: show csi inline volume normally like this ! How to reproduce it (as minimally and precisely as possible): a pod with inline csi volume describe pod xxx not show csi inline volume Anything else we need to know?: Environment: Kubernetes version (use ): 1.14 beta2 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/assign
/sig cli

Discussion:
printFlockerVolumeSource(volume.VolumeSource.Flocker, w) case volume.VolumeSource.Projected != nil: printProjectedVolumeSource(volume.VolumeSource.Projected, w) <ins> case volume.VolumeSource.CSI != nil: printCSIVolumeSource(volume.VolumeSource.CSI, w) </ins> default: w.Write(LEVEL_1, "<unknown>n") }

flocker.DatasetName, flocker.DatasetUUID) } <ins> func printCSIVolumeSource(csi *corev1.CSIVolumeSource, w PrefixWriter) { var readOnly bool var fsType string if csi.ReadOnly != nil && *csi.ReadOnly { readOnly = true } if csi.FSType != nil { fsType = *csi.FSType } w.Write(LEVEL_2, "Type:tCSI (a Container Storage Interface (CSI) volume source)n"+ "    Driver:t%vn"+ "    FSType:t%vn"+ "    ReadOnly:t%vn", csi.Driver, fsType, readOnly) printCSIPersistentVolumeAttributesMultiline(w, "VolumeAttributes", csi.VolumeAttributes) } </ins> func printCSIPersistentVolumeSource(csi *corev1.CSIPersistentVolumeSource, w PrefixWriter) { w.Write(LEVEL_2, "Type:tCSI (a Container Storage Interface (CSI) volume source)n"+ "    Driver:t%vn"+
Change:
What happened: Set up an APIService object pointing to a service that does not service openapi What you expected to happen: Aggregation would attempt to aggregate, fail, and back off How to reproduce it (as minimally and precisely as possible): openapi aggregation logs continuously /sig api-machinery /cc
actually, this is happening without any external APIService objects registered as well
This is just too verbose logging. We have nothing better than polling of the delegation chain for changes. But the good thing is that with etags this should not be heavy on the CPU because nothing is recomputed (and if it is, it would be a bug).
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen </details
Kube-apiserver outputs the same log every second and takes up 10% more CPU than normal
cc
This problem has been fixed in some . Someone has covered up the problem. It makes it harder for us to find the CPU problem behind it. thanks.

Discussion:
return false } <del> klog.Infof("OpenAPI AggregationController: Processing item %s", key) </del> <ins> if aggregator.IsLocalAPIService(key.(string)) { // for local delegation targets that are aggregated once per second, log at // higher level to avoid flooding the log klog.V(5).Infof("OpenAPI AggregationController: Processing item %s", key) } else { klog.Infof("OpenAPI AggregationController: Processing item %s", key) } </ins> action, err := c.syncHandler(key.(string)) if err == nil {
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 --What happened: When I click the "1.14 What's New"and "(No, really, you MUST do this before you upgrade)" I found that it can not jump to the content. What you expected to happen: Click the "1.14 What's New" then I can jump to the "1.14 What's New"content. 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: ): Kernel (e.g. ): Install tools: Others:

Discussion:
- [Server Binaries](#server-binaries) - [Node Binaries](#node-binaries) - [Kubernetes v1.14 Release Notes](#kubernetes-v114-release-notes) <del> - [1.14 What’s New](#114-what’s-new) </del> <ins> - [1.14 What’s New](#114-whats-new) </ins> - [Known Issues](#known-issues) - [Urgent Upgrade Notes](#urgent-upgrade-notes) <del> - [(No, really, you MUST do this before you upgrade)](#no-really-you-must-do-this-before-you-upgrade) </del> <ins> - [(No, really, you MUST do this before you upgrade)](#no-really-you-must-read-this-before-you-upgrade) </ins> - [Deprecations](#deprecations) - [Removed and deprecated metrics](#removed-and-deprecated-metrics) - [Removed metrics](#removed-metrics)
Change:
What would you like to be : A comment in that includes the possible values of . I got the possible values from . The should contain the further explanation available in the linked code that explains what each condition type means. Why is this needed: Currently the output of is incomplete: It is important to include the values of because that's the value used to . It is not user-friendly to require users to guess the possible string values for condition or require them to read the code to deduce what the possible values are.
/sig cli
Please let me do it~
oops, I just notice your message. I already submitted a PR for this.
It's ok~

Discussion:
"type": "string" }, "type": { <del> "description": "Type is the type of the condition.", </del> <ins> "description": "Type is the type of the condition. Types include Established, NamesAccepted and Terminating.", </ins> "type": "string" } },

// CustomResourceDefinitionCondition contains details for the current condition of this pod. type CustomResourceDefinitionCondition struct { <del> // Type is the type of the condition. </del> <ins> // Type is the type of the condition. Types include Established, NamesAccepted and Terminating. </ins> Type CustomResourceDefinitionConditionType // Status is the status of the condition. // Can be True, False, Unknown.

// CustomResourceDefinitionCondition contains details for the current condition of this pod. message CustomResourceDefinitionCondition { <del> // Type is the type of the condition. </del> <ins> // Type is the type of the condition. Types include Established, NamesAccepted and Terminating. </ins> optional string type = 1; // Status is the status of the condition.

// CustomResourceDefinitionCondition contains details for the current condition of this pod. type CustomResourceDefinitionCondition struct { <del> // Type is the type of the condition. </del> <ins> // Type is the type of the condition. Types include Established, NamesAccepted and Terminating. </ins> Type CustomResourceDefinitionConditionType `json:"type" protobuf:"bytes,1,opt,name=type,casttype=CustomResourceDefinitionConditionType"` // Status is the status of the condition. // Can be True, False, Unknown.
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 --What happened: The windows kubelet does not set .status.nodeInfo.systemUUID on the node object. What you expected to happen: The windows kubelet sets the systemUUID from How to reproduce it (as minimally and precisely as possible): Start the windows kubelet and check for UUID: Anything else we need to know?: This will affect users running the out-of-tree vsphere CCM since that depends on the systemUUID, unlike the in-tree version. Also, looks like cAdvisor is the component responsible for providing the systemUUID so let me know if this issue needs to be moved to that repo. Environment: Kubernetes version (use ): Verified on 1.13.1 and 1.14 Cloud provider or hardware configuration: None OS (e.g: ): Windows Server 2019
/sig windows /sig vmware
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale

Discussion:
import ( "errors" <ins> "fmt" </ins> "os" <ins> "os/exec" </ins> "runtime" <ins> "strings" </ins> "sync" "time" "unsafe"

return nil, err } <ins> systemUUID, err := getSystemUUID() if err != nil { return nil, err } </ins> return &cadvisorapi.MachineInfo{ NumCores:       runtime.NumCPU(), MemoryCapacity: p.nodeInfo.memoryPhysicalCapacityBytes, MachineID:      hostname, <ins> SystemUUID:     systemUUID, </ins> }, nil }

return cpuUsageNanoCores } <ins> func getSystemUUID() (string, error) { result, err := exec.Command("wmic", "csproduct", "get", "UUID").Output() if err != nil { return "", err } fields := strings.Fields(string(result)) if len(fields) != 2 { return "", fmt.Errorf("received unexpected value retrieving vm uuid: %q", string(result)) } return fields[1], nil } </ins> func getPhysicallyInstalledSystemMemoryBytes() (uint64, error) { // We use GlobalMemoryStatusEx instead of GetPhysicallyInstalledSystemMemory // on Windows node for the following reasons:

NumCores:       4, MemoryCapacity: 1.6e+10, MachineID:      "somehostname", <ins> SystemUUID:     "E6C8AC43-582B-3575-4E1F-6DA170888906", </ins> }, nil }

assert.Equal(t, machineInfo, &cadvisorapi.MachineInfo{ NumCores:       4, MemoryCapacity: 1.6e+10, <del> MachineID:      "somehostname"}) </del> <ins> MachineID:      "somehostname", SystemUUID:     "E6C8AC43-582B-3575-4E1F-6DA170888906"}) </ins> } func TestWinVersionInfo(t *testing.T) {
Change:
The workaround in should be removed (but the test kept to prevent regressions) once we upgrade to go 1.12.2 and pick up /assign
Thanks Liggitt
/sig api-machinery
removed in

Discussion:
proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: h.Location.Scheme, Host: h.Location.Host}) proxy.Transport = h.Transport proxy.FlushInterval = h.FlushInterval <del> proxy.ServeHTTP(maybeWrapFlushHeadersWriter(w), newReq) } // maybeWrapFlushHeadersWriter wraps the given writer to force flushing headers prior to writing the response body. // if the given writer does not support http.Flusher, http.Hijacker, and http.CloseNotifier, the original writer is returned. // TODO(liggitt): drop this once https://github.com/golang/go/issues/31125 is fixed func maybeWrapFlushHeadersWriter(w http.ResponseWriter) http.ResponseWriter { flusher, isFlusher := w.(http.Flusher) hijacker, isHijacker := w.(http.Hijacker) closeNotifier, isCloseNotifier := w.(http.CloseNotifier) // flusher, hijacker, and closeNotifier are all used by the ReverseProxy implementation. // if the given writer can't support all three, return the original writer. if !isFlusher || !isHijacker || !isCloseNotifier { return w } return &flushHeadersWriter{w, flusher, hijacker, closeNotifier} } type flushHeadersWriter struct { http.ResponseWriter http.Flusher http.Hijacker http.CloseNotifier } func (w *flushHeadersWriter) WriteHeader(code int) { w.ResponseWriter.WriteHeader(code) w.Flusher.Flush() </del> <ins> proxy.ServeHTTP(w, newReq) </ins> } // tryUpgrade returns true if the request was handled.
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 --What happened: Unit tests are failing with the latest golang(1.12) What you expected to happen: Tests should pass without any fauilures. 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: ): Kernel (e.g. ): Install tools: Others:
/sig api-machinery

Discussion:
} pl, ok := obj.(*example.PodList) if !ok { <del> t.Fatalf("Expected PodList but got %t", pl) </del> <ins> t.Fatalf("Expected PodList but got %v", pl) </ins> } if len(pl.Items) != 3 { t.Errorf("Expected PodList of length 3 but got %d", len(pl.Items))

} limit1, ok := obj1.(*example.PodList) if !ok { <del> t.Fatalf("Expected PodList but got %t", limit1) </del> <ins> t.Fatalf("Expected PodList but got %v", limit1) </ins> } if len(limit1.Items) != 2 { t.Errorf("Expected PodList of length 2 but got %d", len(limit1.Items))

} limit2, ok := obj2.(*example.PodList) if !ok { <del> t.Fatalf("Expected PodList but got %t", limit2) </del> <ins> t.Fatalf("Expected PodList but got %v", limit2) </ins> } if limit2.Continue != "" { t.Errorf("Expected list not to have Continue, but got %s", limit1.Continue)
Change:
What would you like to be : Currently Mutex lock is acquired in for accessing different maps. Some functions only read map entry: We can utilize RWMutex where the above function acquires read lock. Why is this needed: For concurrent calls to IsFitPredicateRegistered / IsPriorityFunctionRegistered, read lock would lower contention.
/sig scheduling
functions getFitPredicateFunctions, getPriorityFunctionConfigs, ListRegisteredFitPredicates, ListRegisteredPriorityFunctions and GetAlgorithmProvider can also use read lock.
I happened to raise earlier today. Anyone can finish resting ones.
Good to know,
Thanks for raising this ! My PR covered and . Feel free to raise another PR to cover others.
Once is merged, I will send my PR thanks
it's merged now.

Discussion:
// IsFitPredicateRegistered is useful for testing providers. func IsFitPredicateRegistered(name string) bool { <del> schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() </del> <ins> schedulerFactoryMutex.RLock() defer schedulerFactoryMutex.RUnlock() </ins> _, ok := fitPredicateMap[name] return ok }

} func getFitPredicateFunctions(names sets.String, args PluginFactoryArgs) (map[string]predicates.FitPredicate, error) { <del> schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() </del> <ins> schedulerFactoryMutex.RLock() defer schedulerFactoryMutex.RUnlock() </ins> fitPredicates := map[string]predicates.FitPredicate{} for _, name := range names.List() {

} func getPriorityFunctionConfigs(names sets.String, args PluginFactoryArgs) ([]priorities.PriorityConfig, error) { <del> schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() </del> <ins> schedulerFactoryMutex.RLock() defer schedulerFactoryMutex.RUnlock() </ins> var configs []priorities.PriorityConfig for _, name := range names.List() {

// ListRegisteredFitPredicates returns the registered fit predicates. func ListRegisteredFitPredicates() []string { <del> schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() </del> <ins> schedulerFactoryMutex.RLock() defer schedulerFactoryMutex.RUnlock() </ins> var names []string for name := range fitPredicateMap {

// ListRegisteredPriorityFunctions returns the registered priority functions. func ListRegisteredPriorityFunctions() []string { <del> schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() </del> <ins> schedulerFactoryMutex.RLock() defer schedulerFactoryMutex.RUnlock() </ins> var names []string for name := range priorityFunctionMap {
Change:
What happened: The Portworx volume driver is accessing the storage parameters and also modifying it. This is a shared map object used by all PVCs being created at that time from the same StorageClass. This causes 2 issues: Portworx driver ends up saving annotations of one PVC into the parameters of another PVC as both CreateVolume calls use the same map. See controller manager crashes as 2 CreateVolume routines try to modify the same map. This is a big problem since the controller manager container crashes half way into creating a volume resulting in the volume being present in the backend portworx cluster but not bound in Kubernetes. What you expected to happen: CreateVolume call for one PVC should be completely isolated from another PVC How to reproduce it (as minimally and precisely as possible): Create a large number of PVCs using the Portworx volume driver using the same StorageClass. Anything else we need to know?: Environment: n/a Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: Kubernetes cluster with Portworx installed Others:
/sig storage
I'll take care of fixing this

Discussion:
} // Pass all parameters as volume labels for Portworx server-side processing <del> if len(p.options.Parameters) > 0 { spec.VolumeLabels = p.options.Parameters } else { </del> <ins> if spec.VolumeLabels == nil { </ins> spec.VolumeLabels = make(map[string]string, 0) } <ins> for k, v := range p.options.Parameters { spec.VolumeLabels[k] = v } </ins> // Update the requested size in the spec spec.Size = uint64(requestGiB * volumehelpers.GiB)
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 --What happened: The following unit test case is flakey What you expected to happen: Testcase should pass. How to reproduce it (as minimally and precisely as possible): Run the testcase for 20 times, you will see failures couple of times. Test failure history: https://k8s-
/sig cluster-lifecycle
/assign
This is happening because in when there is empty proxyIP we are not continuing the pool instead we are breaking which will exit from the loop and ignore the next element in the dictionary of stubDomainData dictionary where there is not guaranty of execution. To fix this issue should be replaced with continue

Discussion:
return "", errors.Wrap(err, "invalid format to parse for proxy") } if len(proxyIP) == 0 { <del> break </del> <ins> continue </ins> } pStanza := map[string]interface{}{}
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : It will be more convenient to include when . Why is this needed: Now, contributor need to run and both. If including when , it will be more convenient. /sig contributor-experience /kind feature /assign

Discussion:
update-generated-docs update-generated-swagger-docs update-openapi-spec <del> update-bazel" </del> <ins> update-bazel update-gofmt" </ins> for t in ${BASH_TARGETS}; do echo -e "${color_yellow}Running ${t}${color_norm}"
Change:
/cc
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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 windows These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by ‍

Discussion:
function export-windows-docker-event-log() { local -r node="${1}" <del> local -r powershell_cmd="powershell.exe -Command $log=$(Get-EventLog -LogName Application -Source Docker); Set-Content '${WINDOWS_LOGS_DIR}docker.log' $log.Message" </del> <ins> local -r powershell_cmd="powershell.exe -Command "$logs=$(Get-EventLog -LogName Application -Source Docker | Select-Object -Property TimeGenerated, EntryType, Message); $logs | Out-File -FilePath '${WINDOWS_LOGS_DIR}docker.log'"" </ins> # Retry up to 3 times to allow ssh keys to be properly propagated and # stored.
Change:
What would you like to be : Use read lock in ServeHTTP Why is this needed: Currently ServeHTTP (in ) takes the write lock: Since it only reads from h.hcs.services, holding read lock should suffice.
cc
/sig network
ping
looks good to me. Thanks!
Can you give /lgtm ?
ping

Discussion:
listener    Listener httpFactory HTTPServerFactory <del> lock     sync.Mutex </del> <ins> lock     sync.RWMutex </ins> services map[types.NamespacedName]*hcInstance }

var _ http.Handler = hcHandler{} func (h hcHandler) ServeHTTP(resp http.ResponseWriter, req *http.Request) { <del> h.hcs.lock.Lock() </del> <ins> h.hcs.lock.RLock() </ins> svc, ok := h.hcs.services[h.name] if !ok || svc == nil { <del> h.hcs.lock.Unlock() </del> <ins> h.hcs.lock.RUnlock() </ins> klog.Errorf("Received request for closed healthcheck %q", h.name.String()) return } count := svc.endpoints <del> h.hcs.lock.Unlock() </del> <ins> h.hcs.lock.RUnlock() </ins> resp.Header().Set("Content-Type", "application/json") if count == 0 {