jiebi/CodeConvo huggingface dataset:
Code 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!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc:

Related discussion:
text: importpath = "k8s.io/kubernetes/pkg/windows/service", deps = select({ "@io_bazel_rules_go//go/platform:windows": [ <ins> "//staging/src/k8s.io/apiserver/pkg/server:go_default_library", </ins> "//vendor/golang.org/x/sys/windows:go_default_library", "//vendor/golang.org/x/sys/windows/svc:go_default_library", "//vendor/k8s.io/klog:go_default_library",
Code 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!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc:

Related discussion:
text: import ( "os" <ins> "time" "k8s.io/apiserver/pkg/server" </ins> "k8s.io/klog" "golang.org/x/sys/windows"
Code 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!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc:

Related discussion:
text: case svc.Interrogate: s <- c.CurrentStatus case svc.Stop, svc.Shutdown: <del> s <- svc.Status{State: svc.Stopped} // TODO: Stop the kubelet gracefully instead of killing the process os.Exit(0) </del> <ins> klog.Infof("Service stopping") // We need to translate this request into a signal that can be handled by the the signal handler // handling shutdowns normally (currently apiserver/pkg/server/signal.go). // If we do not do this, our main threads won't be notified of the upcoming shutdown. // Since Windows services do not use any console, we cannot simply generate a CTRL_BREAK_EVENT // but need a dedicated notification mechanism. graceful := server.RequestShutdown() // Free up the control handler and let us terminate as gracefully as possible. // If that takes too long, the service controller will kill the remaining threads. // As per https://docs.microsoft.com/en-us/windows/desktop/services/service-control-handler-function s <- svc.Status{State: svc.StopPending} // If we cannot exit gracefully, we really only can exit our process, so atleast the // service manager will think that we gracefully exited. At the time of writing this comment this is // needed for applications that do not use signals (e.g. kube-proxy) if !graceful { go func() { // Ensure the SCM was notified (The operation above (send to s) was received and communicated to the // service control manager - so it doesn't look like the service crashes) time.Sleep(1 * time.Second) os.Exit(0) }() } break Loop </ins> } } }
Code 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!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc:

Related discussion:
text: ) var onlyOneSignalHandler = make(chan struct{}) <ins> var shutdownHandler chan os.Signal </ins> // SetupSignalHandler registered for SIGTERM and SIGINT. A stop channel is returned // which is closed on one of these signals. If a second signal is caught, the program
Code 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!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc:

Related discussion:
text: func SetupSignalHandler() <-chan struct{} { close(onlyOneSignalHandler) // panics when called twice <ins> shutdownHandler = make(chan os.Signal, 2) </ins> stop := make(chan struct{}) <del> c := make(chan os.Signal, 2) signal.Notify(c, shutdownSignals...) </del> <ins> signal.Notify(shutdownHandler, shutdownSignals...) </ins> go func() { <del> <-c </del> <ins> <-shutdownHandler </ins> close(stop) <del> <-c </del> <ins> <-shutdownHandler </ins> os.Exit(1) // second signal. Exit directly. }() return stop } <ins> // RequestShutdown emulates a received event that is considered as shutdown signal (SIGTERM/SIGINT) // This returns whether a handler was notified func RequestShutdown() bool { if shutdownHandler != nil { select { case shutdownHandler <- shutdownSignals[0]: return true default: } } return false } </ins>
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: // BlockStorageOpts is used to talk to Cinder service type BlockStorageOpts struct { <del> BSVersion       string `gcfg:"bs-version"`        // overrides autodetection. v1 or v2. Defaults to auto TrustDevicePath bool   `gcfg:"trust-device-path"` // See Issue #33128 IgnoreVolumeAZ  bool   `gcfg:"ignore-volume-az"` </del> <ins> BSVersion             string `gcfg:"bs-version"`        // overrides autodetection. v1 or v2. Defaults to auto TrustDevicePath       bool   `gcfg:"trust-device-path"` // See Issue #33128 IgnoreVolumeAZ        bool   `gcfg:"ignore-volume-az"` NodeVolumeAttachLimit int    `gcfg:"node-volume-attach-limit"` // override volume attach limit for Cinder. Default is : 256 </ins> } // RouterOpts is used for Neutron routes
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: return &os, nil } <ins> // NewFakeOpenStackCloud creates and returns an instance of Openstack cloudprovider. // Mainly for use in tests that require instantiating Openstack without having // to go through cloudprovider interface. func NewFakeOpenStackCloud(cfg Config) (*OpenStack, error) { provider, err := openstack.NewClient(cfg.Global.AuthURL) if err != nil { return nil, err } emptyDuration := MyDuration{} if cfg.Metadata.RequestTimeout == emptyDuration { cfg.Metadata.RequestTimeout.Duration = time.Duration(defaultTimeOut) } provider.HTTPClient.Timeout = cfg.Metadata.RequestTimeout.Duration os := OpenStack{ provider:     provider, region:       cfg.Global.Region, lbOpts:       cfg.LoadBalancer, bsOpts:       cfg.BlockStorage, routeOpts:    cfg.Route, metadataOpts: cfg.Metadata, } return &os, nil } </ins> // Initialize passes a Kubernetes clientBuilder interface to the cloud provider func (os *OpenStack) Initialize(clientBuilder cloudprovider.ControllerClientBuilder, stop <-chan struct{}) { }
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: return os.bsOpts.TrustDevicePath } <ins> // NodeVolumeAttachLimit specifies number of cinder volumes that can be attached to this node. func (os *OpenStack) NodeVolumeAttachLimit() int { return os.bsOpts.NodeVolumeAttachLimit } </ins> // GetLabelsForVolume implements PVLabeler.GetLabelsForVolume func (os *OpenStack) GetLabelsForVolume(ctx context.Context, pv *v1.PersistentVolume) (map[string]string, error) { // Ignore if not Cinder.
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: ], embed = [":go_default_library"], deps = [ <ins> "//pkg/cloudprovider/providers/openstack:go_default_library", </ins> "//pkg/util/mount:go_default_library", "//pkg/volume:go_default_library", "//pkg/volume/testing:go_default_library", <ins> "//pkg/volume/util:go_default_library", </ins> "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library",
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: if cloud.ProviderName() != openstack.ProviderName { return nil, fmt.Errorf("Expected Openstack cloud, found %s", cloud.ProviderName()) } <ins> openstackCloud, ok := cloud.(*openstack.OpenStack) if ok && openstackCloud.NodeVolumeAttachLimit() > 0 { volumeLimits[util.CinderVolumeLimitKey] = int64(openstackCloud.NodeVolumeAttachLimit()) } </ins> return volumeLimits, nil }
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/types" utiltesting "k8s.io/client-go/util/testing" <ins> "k8s.io/kubernetes/pkg/cloudprovider/providers/openstack" </ins> "k8s.io/kubernetes/pkg/util/mount" "k8s.io/kubernetes/pkg/volume" volumetest "k8s.io/kubernetes/pkg/volume/testing" <ins> "k8s.io/kubernetes/pkg/volume/util" </ins> ) func TestCanSupport(t *testing.T) {
Code change:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect

Related discussion:
text: t.Errorf("Deleter() failed: %v", err) } } <ins> func TestGetVolumeLimit(t *testing.T) { tmpDir, err := utiltesting.MkTmpdir("cinderTest") if err != nil { t.Fatalf("can't make a temp dir: %v", err) } cloud, err := getOpenstackCloudProvider() if err != nil { t.Fatalf("can not instantiate openstack cloudprovider : %v", err) } defer os.RemoveAll(tmpDir) plugMgr := volume.VolumePluginMgr{} volumeHost := volumetest.NewFakeVolumeHostWithCloudProvider(tmpDir, nil, nil, cloud) plugMgr.InitPlugins(ProbeVolumePlugins(), nil /* prober */, volumeHost) plug, err := plugMgr.FindPluginByName("kubernetes.io/cinder") if err != nil { t.Fatalf("Can't find the plugin by name") } attachablePlugin, ok := plug.(volume.VolumePluginWithAttachLimits) if !ok { t.Fatalf("plugin %s is not of attachable type", plug.GetPluginName()) } limits, err := attachablePlugin.GetVolumeLimits() if err != nil { t.Errorf("error fetching limits : %v", err) } if len(limits) == 0 { t.Fatalf("expecting limit from openstack got none") } limit, _ := limits[util.CinderVolumeLimitKey] if limit != 10 { t.Fatalf("expected volume limit to be 10 got %d", limit) } } func getOpenstackCloudProvider() (*openstack.OpenStack, error) { cfg := getOpenstackConfig() return openstack.NewFakeOpenStackCloud(cfg) } func getOpenstackConfig() openstack.Config { cfg := openstack.Config{ Global: struct { AuthURL    string `gcfg:"auth-url"` Username   string UserID     string `gcfg:"user-id"` Password   string TenantID   string `gcfg:"tenant-id"` TenantName string `gcfg:"tenant-name"` TrustID    string `gcfg:"trust-id"` DomainID   string `gcfg:"domain-id"` DomainName string `gcfg:"domain-name"` Region     string CAFile     string `gcfg:"ca-file"` }{ Username:   "user", Password:   "pass", TenantID:   "foobar", DomainID:   "2a73b8f597c04551a0fdc8e95544be8a", DomainName: "local", AuthURL:    "http://auth.url", UserID:     "user", }, BlockStorage: openstack.BlockStorageOpts{ NodeVolumeAttachLimit: 10, }, } return cfg } </ins>
Code 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!--What happened: When running e2e conformance tests against a cluster using a public HTTPS endpoint for the apiserver, you get the following errors: What you expected to happen: The API server endpoint is so the e2e tests should use and connect on port instead of . How to reproduce it (as minimally and precisely as possible): Run e2e conformance tests against a cluster with the apiserver exposed on a public endpoint with a public CA. Anything else we need to know?: When looking at the code here: It looks like the tlsConfig is not correctly derived from the URL. Diving into I see that this uses deep down: And this seem to return unless the kubeconfig has a CA or other explicit TLS config configured: I believe if this check also checked the of the URL, then it would be correct: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig testing

Related discussion:
text: if err != nil { return nil, fmt.Errorf("Failed to create tls config: %v", err) } <del> if tlsConfig != nil { </del> <ins> if url.Scheme == "https" { </ins> url.Scheme = "wss" <del> if !strings.Contains(url.Host, ":") { url.Host += ":443" } </del> } else { url.Scheme = "ws" <del> if !strings.Contains(url.Host, ":") { url.Host += ":80" } </del> } headers, err := headersForConfig(config, url) if err != nil {
Code 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!--What happened: test/e2enode/perf tests are referring to adm only images, this need to be replaced with multi-arch fat manifest images. ref:
/assign /sig node

Related discussion:
text: imageutils.GetE2EImage(imageutils.Nonewprivs), imageutils.GetPauseImageName(), framework.GetGPUDevicePluginImage(), <del> "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is-amd64:1.0", "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep-amd64:1.0", </del> <ins> "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is:1.0", "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep:1.0", </ins> "gcr.io/kubernetes-e2e-test-images/node-perf/tf-wide-deep-amd64:1.0", )
Code 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!--What happened: test/e2enode/perf tests are referring to adm only images, this need to be replaced with multi-arch fat manifest images. ref:
/assign /sig node

Related discussion:
text: var containers []corev1.Container ctn := corev1.Container{ Name:  fmt.Sprintf("%s-ctn", w.Name()), <del> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep-amd64:1.0", </del> <ins> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-ep:1.0", </ins> Resources: corev1.ResourceRequirements{ Requests: corev1.ResourceList{ corev1.ResourceName(corev1.ResourceCPU):    resource.MustParse("15000m"),
Code 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!--What happened: test/e2enode/perf tests are referring to adm only images, this need to be replaced with multi-arch fat manifest images. ref:
/assign /sig node

Related discussion:
text: var containers []corev1.Container ctn := corev1.Container{ Name:  fmt.Sprintf("%s-ctn", w.Name()), <del> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is-amd64:1.0", </del> <ins> Image: "gcr.io/kubernetes-e2e-test-images/node-perf/npb-is:1.0", </ins> Resources: corev1.ResourceRequirements{ Requests: corev1.ResourceList{ corev1.ResourceName(corev1.ResourceCPU):    resource.MustParse("16000m"),