jiebi/CodeConvo huggingface dataset:
Change:
}, } <ins> fqinSecret := &corev1.Secret{ ObjectMeta: metaObj, Data: map[string][]byte{ testServerFQIN + "." + userKey:     []byte(testUser), testServerFQIN + "." + passwordKey: []byte(testPassword), }, } </ins> emptySecret := &corev1.Secret{ ObjectMeta: metaObj, Data:       map[string][]byte{},

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: kube-controller-manager is unable to locate the credentials of the vCenter host, even though they are defined and cased identically to the hostname in the cloud-provider-config. What you expected to happen: vCenter hostname should not be case-sensitive, or should be documented that it is. It should successfully locate credentials from the manager How to reproduce it (as minimally and precisely as possible): to an upper-case name kube-controller-manager daemon to update the secret to provision storage with the "thin" storage class will stay suck in pending Anything else we need to know?: Log Messages: ` This appears to be induced by the way the vCenter server name is calculated when the secret containing the credentials is parsed[]. The credentialKey is converted to lower case and is then parsed to lookup the server name. Environment: Kubernetes version (use ): v1.14 Cloud provider or hardware configuration: vSphere OS (e.g: ): Unknown Kernel (e.g. ): Unknown Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area/provider/vmware
/area provider/vmware
Change:
return errStr + buf.String() } <del> // check if a Pod is controlled by a Replication Controller in the List func hasReplicationControllersForPod(rcs *api.ReplicationControllerList, pod api.Pod) bool { for _, rc := range rcs.Items { selector := labels.SelectorFromSet(rc.Spec.Selector) if selector.Matches(labels.Set(pod.ObjectMeta.Labels)) { return true } } return false } </del> // WaitForPodsSuccess waits till all labels matching the given selector enter // the Success state. The caller is expected to only invoke this method once the // pods have been created.

Discussion:
The logic to account for all pods being ready is incorrectly counting some pods as being controlled by a replication controller. This is causing the 1.3-1.5 upgrade tests to fail. See https://k8s- as an example. Since , the pre-flight checks fail and the rest of the tests never run. I think this was exposed by which changed some things from ReplicationControllers to Deployments. There's a pod being created by a deployment that also matches the selector of a replication controller, and is therefore being incorrectly counted by cc
Change:
return links, nil } <ins> // GetMountRefs : empty implementation here since there is no place to query all mount points on Windows </ins> func (mounter *Mounter) GetMountRefs(pathname string) ([]string, error) { if _, err := os.Stat(normalizeWindowsPath(pathname)); os.IsNotExist(err) { return []string{}, nil } else if err != nil { return nil, err } <del> refs, err := getAllParentLinks(normalizeWindowsPath(pathname)) if err != nil { return nil, err } return refs, nil </del> <ins> return []string{pathname}, nil </ins> } // Note that on windows, it always returns 0. We actually don't set FSGroup on

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?: /kind bug /sig windows What happened: After creating pods having PersistentVolumeClaims and deleting them, the logs are getting filled with errors regarding failing to unmount the volume [1]. Additionally, tests requiring PVCs will hang several minutes while waiting the PV to unmount [2]. [1] [2] What you expected to happen: There shouldn't be any issues while unmounting the volume, the tests shouldn't have to wait several minutes waiting for the volume to be unmounted. How to reproduce it (as minimally and precisely as possible): pod requiring PVC. the pod. logs for error messages regarding the volume not being able to be unmounted. Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.2 Cloud provider or hardware configuration: Azure, acs-engine v0.21.2 (: ) OS (e.g. from /etc/os-release): Windows Server 1803 Kernel (e.g. ): Install tools: Others:
/sig azure /assign
what's your PVC type? is it azure disk?
thanks for reporting. I have identified that this is a regression introduced by UnmountDevice common code mainly for linux: the root cause is is not well implemented Error code is like following: I have a different implementation for func on windows wich could fix this issue, will file a PR tomorrow.
Change:
return nil } <del> func convert_v1_StatusCause_To_api_StatusCause(in *StatusCause, out *api.StatusCause, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*StatusCause))(in) } out.Type = api.CauseType(in.Type) out.Message = in.Message out.Field = in.Field return nil } func convert_api_StatusCause_To_v1_StatusCause(in *api.StatusCause, out *StatusCause, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*api.StatusCause))(in) } out.Type = CauseType(in.Type) out.Message = in.Message out.Field = in.Field return nil } func convert_v1_StatusDetails_To_api_StatusDetails(in *StatusDetails, out *api.StatusDetails, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*StatusDetails))(in) } out.ID = in.ID out.Kind = in.Kind if in.Causes != nil { out.Causes = make([]api.StatusCause, len(in.Causes)) for i := range in.Causes { if err := convert_v1_StatusCause_To_api_StatusCause(&in.Causes[i], &out.Causes[i], s); err != nil { return err } } } else { out.Causes = nil } out.RetryAfterSeconds = in.RetryAfterSeconds return nil } func convert_api_StatusDetails_To_v1_StatusDetails(in *api.StatusDetails, out *StatusDetails, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*api.StatusDetails))(in) } out.ID = in.ID out.Kind = in.Kind if in.Causes != nil { out.Causes = make([]StatusCause, len(in.Causes)) for i := range in.Causes { if err := convert_api_StatusCause_To_v1_StatusCause(&in.Causes[i], &out.Causes[i], s); err != nil { return err } } } else { out.Causes = nil } out.RetryAfterSeconds = in.RetryAfterSeconds return nil } </del> func convert_v1_TCPSocketAction_To_api_TCPSocketAction(in *TCPSocketAction, out *api.TCPSocketAction, s conversion.Scope) error { if defaulting, found := s.DefaultingInterface(reflect.TypeOf(*in)); found { defaulting.(func(*TCPSocketAction))(in)

Discussion:
When accessing a non existing entity (example - namespace), the message specifies the requested field as 'id', but it should be 'name'. Example (see the details section) { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "namespaces "staging" not found", "reason": "NotFound", "details": { "id": "staging", "kind": "namespaces" }, "code": 404 }
Yes. We should rename "id" to "name" in StatusDetails: Not sure if we can change v1beta3 API now. cc
You can add a new field and fill in both, and MAYBE remove ID in v1 , Nikhil Jindal wrote:
I suggest we fix it at most in v1 only. This is an annoying wart, but we could just fix the description string for now.
If trivial, we should fix v1.
Change:
"STANDARD_M32LS":         32, "STANDARD_M32MS":         32, "STANDARD_M32TS":         32, <ins> "STANDARD_M416-208MS_V2": 64, "STANDARD_M416-208S_V2":  64, </ins> "STANDARD_M416MS_V2":     64, "STANDARD_M416S_V2":      64, "STANDARD_M64-16MS":      64,

Discussion:
<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:
Change:
var err error wait.ExponentialBackoff(backoff, func() (bool, error) { err = webhookFn() if ctx.Err() != nil { // we timed out or were cancelled, we should not retry return true, err } <del> // these errors indicate a transient error that should be retried. if net.IsConnectionReset(err) || apierrors.IsInternalError(err) || apierrors.IsTimeout(err) || apierrors.IsTooManyRequests(err) { return false, nil } // if the error sends the Retry-After header, we respect it as an explicit confirmation we should retry. if _, shouldRetry := apierrors.SuggestsClientDelay(err); shouldRetry { </del> <ins> if shouldRetry(err) { </ins> return false, nil } if err != nil {

Discussion:
What would you like to be : The api server should retry sending audit events to configured webhook sinks regardless of the type of HTTP error code it might receive from the webhooks. Why is this needed: While some components may live with failed data transmissions, this is a particularly sensitive topic for the audit area. The API server audit mechanisms must ensure that no other reasonable option exists before dropping an audit event that may be the only trace of malicious behavior in the cluster. It seems that the current implementation may be improved further in this direction. Currently, when the API server is configured for non-blocking sending of audit events to a webhook audit sink backend, it will retry up to 5 times with exponential backoff, should there be an error in communicating with the webhook, as implemented . However, not all errors will trigger a retry. Some are considered transient and yield retry. Others simply stop the retry cycle. For example, it retries on receiving HTTP code , but not on receiving . The list of error codes that will yield a retry is actually quite small - three HTTP errors and one network error. Any other error will not trigger a retry and the audit events will be lost. The code comments explain that the retry will consider only recoverable failures, which may make sense in other cases, but as far as sending audit events to an audit backend webhook is concerned, it is not sufficient policy. A more robust approach would be to consider any error and give the backend service a chance to recover instead of relying on the error codes semantics and the webhook implementations interpretation of it. That is more inline with having the transmission of audit events as top priority. /sig auth /sig api-machinery
Change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/component-base/config:go_default_library", ], )

Discussion:
What would you like to be : Actually disable scheduler plugins according to the disabled list in the scheduler's component config. The semantics are defined here: Part of /sig scheduling /priority important-soon /assign
The following semantics seems vague, and I think we should reach consensus on some cases when disabled plugins are involved. Suppose we have two default plugins, and , the runs before , here are the cases we could meet with the scheduling framework, plugins which run after all the default plugins plugins which should run ahead of the plugins plugin which should run ahead of all the plugins -enable default or custom plugin should return errors
Do you have any other cases not mentioned here?
Those cases sound right, I don't have others.
Is this actually what we want? I don't think so. The comment needs rewording.
I plan to revisit the comments after
Change:
framework.ExpectNoError(err, "failed to wait for pod1 running status") l.pods = append(l.pods, pod1) <del> // Create the second pod, which will fail scheduling because the ReadWriteOncePod PVC is already in use. </del> <ins> // Create the second pod, which will preempt the first pod because it's using the // ReadWriteOncePod PVC and has higher priority. </ins> pod2, err := e2epod.MakeSecPod(&podConfig) framework.ExpectNoError(err, "failed to create spec for pod2") <ins> pod2.Spec.PriorityClassName = l.priorityClass.Name </ins> _, err = l.cs.CoreV1().Pods(pod2.Namespace).Create(ctx, pod2, metav1.CreateOptions{}) framework.ExpectNoError(err, "failed to create pod2") <del> err = e2epod.WaitForPodNameUnschedulableInNamespace(ctx, l.cs, pod2.Name, pod2.Namespace) framework.ExpectNoError(err, "failed to wait for pod2 unschedulable status") </del> l.pods = append(l.pods, pod2) <del> // Delete the first pod and observe the second pod can now start. err = e2epod.DeletePodWithWait(ctx, l.cs, pod1) framework.ExpectNoError(err, "failed to delete pod1") </del> <ins> // Wait for the first pod to be preempted and the second pod to start. err = e2epod.WaitForPodNotFoundInNamespace(ctx, l.cs, pod1.Name, pod1.Namespace, f.Timeouts.PodStart) framework.ExpectNoError(err, "failed to wait for pod1 to be preempted") </ins> err = e2epod.WaitTimeoutForPodRunningInNamespace(ctx, l.cs, pod2.Name, pod2.Namespace, f.Timeouts.PodStart) framework.ExpectNoError(err, "failed to wait for pod2 running status") <ins> // Recreate the first pod, which will fail to schedule because the second pod // is using the ReadWriteOncePod PVC and has higher priority. _, err = l.cs.CoreV1().Pods(pod1.Namespace).Create(ctx, pod1, metav1.CreateOptions{}) framework.ExpectNoError(err, "failed to create pod1") err = e2epod.WaitForPodNameUnschedulableInNamespace(ctx, l.cs, pod1.Name, pod1.Namespace) framework.ExpectNoError(err, "failed to wait for pod1 unschedulable status") // Delete the second pod with higher priority and observe the first pod can now start. err = e2epod.DeletePodWithWait(ctx, l.cs, pod2) framework.ExpectNoError(err, "failed to delete pod2") err = e2epod.WaitTimeoutForPodRunningInNamespace(ctx, l.cs, pod1.Name, pod1.Namespace, f.Timeouts.PodStart) framework.ExpectNoError(err, "failed to wait for pod1 running status") </ins> }) ginkgo.It("should block a second pod from using an in-use ReadWriteOncePod volume on the same node", func(ctx context.Context) {

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 storage /sig scheduling
Change:
source "${KUBE_ROOT}/test/cmd/storage.sh" source "${KUBE_ROOT}/test/cmd/template-output.sh" source "${KUBE_ROOT}/test/cmd/version.sh" <ins> source "${KUBE_ROOT}/test/cmd/wait.sh" </ins> ETCD_HOST=${ETCD_HOST:-127.0.0.1}

Discussion:
We should consider updating the command to wait on all resources for a given kind. For example: would wait for every pod in the current namespace to be deleted. /sig cli cc
Interestingly, the error text implies that this is already supported: Yet when you try to use it, it declares Would really like the wait functionality given some much needed TLC. Still no way to determine what conditions are supported for various resources (eg. I can say and it just waits for the timeout like that resource might actually potato at some point).
I'm looking into adding the --all flag to wait, sounds like a nice feature to have :)
Change:
}, }, { name:        "container_cpu_usage_seconds_total", <del> help:        "Cumulative cpu time consumed per cpu in seconds.", </del> <ins> help:        "Cumulative cpu time consumed in seconds.", </ins> valueType:   prometheus.CounterValue, extraLabels: []string{"cpu"}, getValues: func(s *info.ContainerStats) metricValues { <ins> if len(s.Cpu.Usage.PerCpu) == 0 { if s.Cpu.Usage.Total > 0 { return metricValues{{ value:  float64(s.Cpu.Usage.Total) / float64(time.Second), labels: []string{"total"}, }} } } </ins> values := make(metricValues, 0, len(s.Cpu.Usage.PerCpu)) for i, value := range s.Cpu.Usage.PerCpu { if value > 0 {

Discussion:
/kind feature This is the once-per-release cut of a new cAdvisor release, which corresponds to the next kubernetes release. cAdvisor v0.29 corresponds to kubernetes v1.10. /sig node /priority important-soon
self-reminder to add per-cpu stats to ignore metrics when vendoring. reminder to add a release notice that one of the container labels fields is being removed.
/kind bug turns out most of the changes are bug-fixes
please mark this issue as approved-for-milestone, since it certainly seems to be, and it's now code slush. Thanks!
Change:
ginkgo.BeforeEach(func(ctx context.Context) { ginkgo.By("Wait for node to be ready") <del> gomega.Eventually(ctx, func(ctx context.Context) error { _, err := e2enode.TotalReady(ctx, f.ClientSet) if err != nil { return err } return nil }, time.Minute, time.Second).Should(gomega.Equal(1), "one node should be ready") </del> <ins> gomega.Eventually(ctx, e2enode.TotalReady). WithArguments(f.ClientSet). WithTimeout(time.Minute). Should(gomega.BeEquivalentTo(1)) </ins> // Before we run the device plugin test, we need to ensure // that the cluster is in a clean state and there are no

Discussion:
ci-crio-cgroupv1-node-e2e-flaky [It] [sig-node] Device Plugin [NodeFeature:DevicePlugin] [Serial] DevicePlugin [Serial] [Disruptive] Keeps device plugin assignments across node reboots (no pod restart, no device plugin re-registration) [Flaky] Since Under evaluation. cc /sig node
/triage accepted /priority important-soon
Tests are green again:
Change:
"//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", "//vendor/github.com/emicklei/go-restful:go_default_library", "//vendor/github.com/go-openapi/spec:go_default_library", <ins> "//vendor/k8s.io/kube-openapi/pkg/aggregator:go_default_library", </ins> "//vendor/k8s.io/kube-openapi/pkg/builder:go_default_library", "//vendor/k8s.io/kube-openapi/pkg/common:go_default_library", "//vendor/k8s.io/kube-openapi/pkg/util:go_default_library",

Discussion:
What happened: Created a CRD with a group/version/kind that defines a CustomResourceDefinition type overlapping with the in-tree kubernetes type (WARNING: do not create this CRD on a cluster you care about, see ) Note that two definitions for the group/version/kind appear in openapi: What you expected to happen: published openapi only includes the in-tree type, which has precedence /cc /area custom-resources /priority important-soon /sig api-machinery
/cc
haven't looked into the code yet. I'd expect the naming controller / apiextensions server to prevent conflicting CR GVK, but they are unaware of builtin API groups
CRD handling is isolated to the apiextensions server... it does not have information about all other built-in and aggregated APIs
mentioned something he was working on to make the aggregation layer honor APIService priorities (so that later definitions would not be included if something had already defined a GVK) edit: possibly
a naive idea is to reserve k8s groups in a hard code way that sounds good the CRD in defines a but the kubectl results are about . Did I miss something?
oops... fixed. I started with an API type under but the issue only surfaces for specific APIs (due to the generated definition name colliding for some types)
that wouldn't address duplicate GVKs from aggregated APIs
Three kinds of openapi paths/definitions that we want to prevent CRDs from overwriting: CRD API the spec aggregation in apiextensions-apiserver allows overwriting. I will send a fix native APIs well protected. The spec aggregation in kube-aggregator: 1) ignores duplicated paths and renames duplicated definitions; 2) treats kube-apiserver with than apiextensions-apiserver APIs the spec aggregation in kube-aggregator allows overwriting. The spec aggregation in kube-aggregator treats aggregated APIs with than apiextensions-apiserver. I'm thinking about giving apiextensions-apiserver the lowest priority, but then the problem is aggregated APIs can potentially overwrite the CRD API Note that none of the above prevents CRDs from adding new subpaths to existing APIs. E.g. a CRD can add a path to the CRD API, or to a aggregated API if it didn't have one
Change:
t.Errorf("3: %v: diff: %vnCodec: %#v", name, diff.ObjectReflectDiff(object, obj3), codec) return } <ins> // do structure-preserving fuzzing of the deep-copied object. If it shares anything with the original, // the deep-copy was actually only a shallow copy. Then original and obj3 will be different after fuzzing. // NOTE: we use the encoding+decoding here as an alternative, guaranteed deep-copy to compare against. ValueFuzz(object) if !apiequality.Semantic.DeepEqual(original, obj3) { t.Errorf("0: %v: fuzzing a copy altered the original, diff: %v", name, diff.ObjectReflectDiff(original, object)) return } </ins> } // dataAsString returns the given byte array as a string; handles detecting

Discussion:
The apimachinery roundtripping test does not ensure that deep copies work. We need to provide a deep copy test that makes sure we don't end up with shallow copies.
I looked into gofuzz some days ago and noticed that it does not support value-only fuzzing that preserves object structure (= does not change pointer values). So we need something clever, maybe reflection based here. Any other idea?
Change:
- apiGroups: - "" resources: <del> - endpoints verbs: - create - apiGroups: - "" resourceNames: - kube-scheduler resources: - endpoints verbs: - get - update - apiGroups: - "" resources: </del> - nodes verbs: - get

Discussion:
Not , but removed: Looking at this comment: this should be removed once the migration to lease in leader-election was done. Can this be removed already? I mean, the following 2 lines: Security folks internally were asking if we could get rid of this upstream if it is not needed anymore (if this "migration to lease in leader-election" was fully done)
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 sig-scheduling
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig sig-scheduling 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 scheduling
/cc
/assign
Support for endpoints and configmap based leader election has been removed with this PR: Validation to error out leader elections configuration for resource lock type other than "lease" has been implemented in With this, it looks safe to remove the two lines mentioned in this issue.
Change:
o.WaitForDeletion = true o.GracePeriod = 1 } <ins> } else if o.ForceDeletion { fmt.Fprintf(o.ErrOut, "warning: --force is ignored because --grace-period is not 0.n") </ins> } return nil }

Discussion:
IMO it's surprising that does not force delete a resource. only takes effect when . The description of reads this: We should make it more clear what does and even print warnings when is specified without .
Changing the meaning of force to actually break cluster consistency be default could lead to data loss, which is why we haven’t changed it so far. agree we should print more info and clarfiy