jiebi/CodeConvo huggingface dataset:
Code change:
} <ins> func TestValidatePersistentVolumeSourceUpdate(t *testing.T) { validVolume := testVolume("foo", "", api.PersistentVolumeSpec{ Capacity: api.ResourceList{ api.ResourceName(api.ResourceStorage): resource.MustParse("1G"), }, AccessModes: []api.PersistentVolumeAccessMode{api.ReadWriteOnce}, PersistentVolumeSource: api.PersistentVolumeSource{ HostPath: &api.HostPathVolumeSource{ Path: "/foo", Type: newHostPathType(string(api.HostPathDirectory)), }, }, StorageClassName: "valid", }) validPvSourceNoUpdate := validVolume.DeepCopy() invalidPvSourceUpdateType := validVolume.DeepCopy() invalidPvSourceUpdateType.Spec.PersistentVolumeSource = api.PersistentVolumeSource{ FlexVolume: &api.FlexVolumeSource{ Driver: "kubernetes.io/blue", FSType: "ext4", }, } invalidPvSourceUpdateDeep := validVolume.DeepCopy() invalidPvSourceUpdateDeep.Spec.PersistentVolumeSource = api.PersistentVolumeSource{ HostPath: &api.HostPathVolumeSource{ Path: "/updated", Type: newHostPathType(string(api.HostPathDirectory)), }, } scenarios := map[string]struct { isExpectedFailure bool oldVolume         *api.PersistentVolume newVolume         *api.PersistentVolume }{ "condition-no-update": { isExpectedFailure: false, oldVolume:         validVolume, newVolume:         validPvSourceNoUpdate, }, "condition-update-source-type": { isExpectedFailure: true, oldVolume:         validVolume, newVolume:         invalidPvSourceUpdateType, }, "condition-update-source-deep": { isExpectedFailure: true, oldVolume:         validVolume, newVolume:         invalidPvSourceUpdateDeep, }, } for name, scenario := range scenarios { errs := ValidatePersistentVolumeUpdate(scenario.newVolume, scenario.oldVolume) if len(errs) == 0 && scenario.isExpectedFailure { t.Errorf("Unexpected success for scenario: %s", name) } if len(errs) > 0 && !scenario.isExpectedFailure { t.Errorf("Unexpected failure for scenario: %s - %+v", name, errs) } } } </ins> func TestValidateLocalVolumes(t *testing.T) { scenarios := map[string]struct { isExpectedFailure bool

Related discussion:
text: /kind bug Right now we do not validate PV updates so admin can update at any time. Kubernetes has no facility to reflect this update - it won't magically re-mount an existing volume to e.g. a different NFS server. IMO the PersistentVolumeSource to be read-only and set to stone once created.
/assign
I think it is a good idea to make the VolumeSource read-only but I am afraid ship has sailed in v1 and existing code/tooling that relies on the ability to modify PVs will break as a result of this change.
- do you have any advice on how we should proceed on fixing this issue?
Code change:
func TestSetDefaultDaemonSetSpec(t *testing.T) { defaultLabels := map[string]string{"foo": "bar"} period := int64(v1.DefaultTerminationGracePeriodSeconds) <del> enableServiceLinks := v1.DefaultEnableServiceLinks </del> defaultTemplate := v1.PodTemplateSpec{ Spec: v1.PodSpec{ DNSPolicy:                     v1.DNSClusterFirst,

Related discussion:
text: <!-- 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 The change in a new field () to the Pod spec that is set to true by default. This is causing problems for DaemonSets in some situations. DaemonSets are using ControllerRevisions to keep track of previous configurations and each revision will contain among other things the Pod spec for the DaemonSet. If a DaemonSet is created with the enableServiceLinks property is set to true, the ControllerRevision will also contain this field. If the cluster is rolled back to a previous version of kubernetes, the DeamonSet struct does not have this field and so the ControllerRevision and the DaemonSet will no longer match. This leads to a new ControllerRevision being created and a rolling update of all pods in the DaemonSet. Would it be a better solution to rename the field to and enable service links whenever the field is not set? This would fix the problem with the DaemonSets unless the field is explicitly set before the rollback. This is causing the master upgrade tests to fail as reported in /sig apps /cc /cc /cc
I guess the change in podSpec and the defaulting will break all the workload resources as they are based on comparing the template's podSpec. ~Is the new value defaulted to true also for the DaemonSet's podSpec template? If not, controller might go hot loop like with mutating admission controllers.~ I don't like us making such changes to v1 podSpec. The other way around seems more sensible. /cc
Why is this a bad thing? We will continue to add fields to podSpec - the issue isn't the defaulting (this would happen regardless of which way it defaulted), it's that the controller can't really be version aware. The new value would default to true in the daemonset as well.
I'm not sure that a rollback requiring daemonsets to recreate is a bug. I think that's potentially "the best possible thing that we can do in that case".
/cc SIG Release blocking dashboard with upgrade test failures - https://k8s-
So the problem isn't the fact that a field has been . It the way in which the field was .
Code change:
func TestSetDefaultDaemonSetSpec(t *testing.T) { defaultLabels := map[string]string{"foo": "bar"} period := int64(v1.DefaultTerminationGracePeriodSeconds) <del> enableServiceLinks := v1.DefaultEnableServiceLinks </del> defaultTemplate := v1.PodTemplateSpec{ Spec: v1.PodSpec{ DNSPolicy:                     v1.DNSClusterFirst,

Related discussion:
text: enableServiceLinks is bool pointer that defaults to true. To be backward compatible it should be something like where the new default behavior is to assume that service links are enabled, and the field should be set on an opt out basis to disable the service links. compatiblity As it is if you create a new DaemonSet and then roll back cluster to a prior version, or if you have a failover in a HA setup, you can trigger a simultaneous rolling restart of all DaemonSets you created even though you didn't explicitly configure (and may not even be aware of) the new feature. If we respect backward compatibility and make the feature explicitly opt-out (that is the semantics we are going for here in either ca So the problem isn't the fact that a field has been . It the way in which the field was . enableServiceLinks is bool pointer that defaults to true. To be backward compatible it should be something like where the new default behavior is to assume that service links are enabled, and the field should be set on an opt out basis to disable the service links. compatiblity As it is if you create a new DaemonSet and then roll back cluster to a prior version, or if you have a failover in a HA setup, you can trigger a simultaneous rolling restart of all DaemonSets you created even though you didn't explicitly configure (and may not even be aware of) the new feature. If we respect backward compatibility and make the feature explicitly opt-out (that is the semantics we are going for here in either case), you won't trigger the rolling restart on rollback or controller manager failoverse), you won't trigger the rolling restart on rollback or controller manager failover unless you explicitly opt out of the behavior. I don't see why the former behavior is more desirable than the latter.
For background/context, the choice between enable/disable was initially discussed here:
Are you saying that the issue is that default value is not the same as the Go "zero value" ? The concept of zero value is interesting but it forces APIs to bend into unnatural shapes to respect it. Since forever Kubernetes has explicitly said that we have version-specific default values which ARE NOT governed by zero values, but instead are governed by the API version. It is safe to assume that if a field is documented as having a default in a version, you can rely on that field being populated with that default, with a few exceptions.
Code change:
func TestSetDefaultDaemonSetSpec(t *testing.T) { defaultLabels := map[string]string{"foo": "bar"} period := int64(v1.DefaultTerminationGracePeriodSeconds) <del> enableServiceLinks := v1.DefaultEnableServiceLinks </del> defaultTemplate := v1.PodTemplateSpec{ Spec: v1.PodSpec{ DNSPolicy:                     v1.DNSClusterFirst,

Related discussion:
text: We generally ask for boolean fields to be "in the affirmative direction", as in this case. Now, we could revisit this. It would be a significant change in direction, but it's not impossible. But I don't think that solves your problem in general -- if this field were optional string, with a default value of "Hello there", you would be in the same boat right?
So the underlying issue is that we are defaulting into the PodSpec which gets adopted into all of the PodTemplateSpecs of every object. That sort of defaults the users declared intent. Why not just default the value into the Pod itself . Is the intention really to default this in all Templates or to make it optional in the Template and default it in the Pod itself?
/milestone v1.13
I can't speak to the ideology of whether to default the field in all PodSpecs or just the Pod, but your suggestion makes sense to me. I'm not sure of the past reasoning for adding other defaulted fields, most recently SchedulerName in Jan. 2017 (), to all PodSpecs instead of just to the Pod object. Did we not have these same tests in place then? This would effectively be saying we should never add new defaulted fields to PodSpec. If this is the plan, I can create a PR for the fix and I'll add a big warning comment to SetDefaults_PodSpec.
As an example of where we don't default the template we have a CronJob that embeds JobTemplate, we never default that template, only an actual Job gets defaulting. I agree with that not defaulting any templates does make sense.
Agree to only default this in pods. Agree to adding the comment. Most important defaulting happens in pods to keep higher level pod specs simpler. We may need to raise the general pattern in a discussion with api review in general, since this is a change from previous strategy, but the previous strategy was not explicitly chosen (to my recollection at least)
Hi all do we have an agreed path forward for fixing this issue in 1.13? if so can we have an ETA for the fix to land? the release team would like for the tests to get passing in the blocking suites in an effort to unmask any other failures that might show up once these are fixed.
Code change:
func TestSetDefaultDaemonSetSpec(t *testing.T) { defaultLabels := map[string]string{"foo": "bar"} period := int64(v1.DefaultTerminationGracePeriodSeconds) <del> enableServiceLinks := v1.DefaultEnableServiceLinks </del> defaultTemplate := v1.PodTemplateSpec{ Spec: v1.PodSpec{ DNSPolicy:                     v1.DNSClusterFirst,

Related discussion:
text: /assign
We have a PR with a fix that will hopefully merge today or tomorrow. I will keep an eye on the dashboard to make sure it fixes the failing daemonset tests.
Thanks Can we link the PR here plz. /cc
Reopening, because of the auto-close. Tests are not passing yet. /reopen
Reopening this issue. <detailsIn response to : Reopening, because of the auto-close. Tests are not passing yet. 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
PR that should (hopefully) close this issue is here:
DaemonSet tests passed on run 1842, seems to have been fixed: https://k8s- if it doesn't pop up again - /close
Closing this issue. <detailsIn response to : DaemonSet tests passed on run 1842, seems to have been fixed: https://k8s- 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
Code change:
return done, nil }) <del> if pollErr == wait.ErrWaitTimeout { </del> <ins> if pollErr != nil { </ins> t.Fatalf("failed to get the expected healthz status of OK for check: %s, error: %v, debug inner error: %v", checkName, pollErr, restErr) } }

Related discussion:
text: {Failed === RUN TestKMSv2Healthz --- FAIL: TestKMSv2Healthz (167.38s) also shown in " TestKMSv2Healthz": 1, Not sure No response No response /sig auth
/assign /triage accepted Use for poll interval Change the poll timeout to 5m Update the poll error check (check if not nil)
Code change:
// Find out delta size expansionSize := (newSize.Value() - oldSize.Value()) <del> expansionSizeGB := int(volume.RoundUpSize(expansionSize, 1024*1024*1024)) </del> <ins> expansionSizeGB := int(volume.RoundUpSize(expansionSize, 1000*1000*1000)) </ins> // Make volume expansion request volumeExpandReq := &gapi.VolumeExpandRequest{Size: expansionSizeGB}

Related discussion:
text: Glusterfs+Heketi use GB units for expanding volume. Using GiB incorrectly leads to expanding the volume to smaller size than user requested. /sig storage cc
Code change:
return oauth2.NewClient(oauth2.NoContext, tokenSource), nil } <ins> func (manager *GCEServiceManager) CreateDisk( project string, zone string, disk *compute.Disk) (*compute.Operation, error) { return manager.gce.service.Disks.Insert(project, zone, disk).Do() } func (manager *GCEServiceManager) GetDisk( project string, zone string, diskName string) (*compute.Disk, error) { return manager.gce.service.Disks.Get(project, zone, diskName).Do() } func (manager *GCEServiceManager) DeleteDisk( project string, zone string, diskName string) (*compute.Operation, error) { return manager.gce.service.Disks.Delete(project, zone, diskName).Do() } func (manager *GCEServiceManager) WaitForZoneOp(op *compute.Operation, zone string, mc *metricContext) error { return manager.gce.waitForZoneOp(op, zone, mc) } </ins>

Related discussion:
text: Unit tests are needed for the GCE cloud provider disk interface.
Assigned to
/assign
GitHub didn't allow me to assign the following users: verult. Note that only can be assigned.. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. I understand the commands that are listed . </details
Code change:
go_test( name = "go_default_test", <del> srcs = ["gce_test.go"], </del> <ins> srcs = [ "gce_disks_test.go", "gce_test.go", ], </ins> library = ":go_default_library", tags = ["automanaged"], <ins> deps = [ "//pkg/cloudprovider:go_default_library", "//vendor/google.golang.org/api/compute/v1:go_default_library", "//vendor/google.golang.org/api/googleapi:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", ], </ins> ) filegroup(

Related discussion:
text: Unit tests are needed for the GCE cloud provider disk interface.
Assigned to
/assign
GitHub didn't allow me to assign the following users: verult. Note that only can be assigned.. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. I understand the commands that are listed . </details
Code change:
- mountPath: /registration name: registration-dir - name: hostpath <del> image: quay.io/k8scsi/hostpathplugin:v1.2.0-rc3 </del> <ins> image: quay.io/k8scsi/hostpathplugin:v1.2.0-rc4 </ins> args: - "--v=5" - "--endpoint=$(CSI_ENDPOINT)"

Related discussion:
text: What happened: The vresion of the hostpathplugin specified in the kubernetes e2e tests had a bug in cloning causing storageclass compare checks to always fail. As a result e2e tests could not pass for cloning in kubernetes. What you expected to happen: The version referencedin e2e tests should have a working hostpathplugin image to enable e2e testing of clone functinoality. How to reproduce it (as minimally and precisely as possible): Attempt to run the e2e cloning test: without modifying the hostpathplugin image version, test will fail due to storageClass mismatch even when set properly in the test. Anything else we need to know?: Fix in hostpathplugin is available in hostpathplugin:v1.2.0-rc4 There's also a required update to the provisioner side-car which has been submitted here:
/sig storage /assign
Code change:
AllowExpandedDNSConfig:                            utilfeature.DefaultFeatureGate.Enabled(features.ExpandedDNSConfig) || haveSameExpandedDNSConfig(podSpec, oldPodSpec), AllowInvalidLabelValueInSelector:                  false, AllowInvalidTopologySpreadConstraintLabelSelector: false, <ins> AllowMutableNodeSelectorAndNodeAffinity:           utilfeature.DefaultFeatureGate.Enabled(features.PodSchedulingReadiness), </ins> } if oldPodSpec != nil {

Related discussion:
text: See for context. This issue is creating to track work on the API validation changes. Validation relaxation of certain fields in the pod spec to allow for mutable scheduling directives.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig scheduling
Docs PR:
Code change:
"pod", klog.KObj(ps.pod)) continue } <del> if now.After(*ps.deadline) { </del> <ins> if cache.ttl != 0 && now.After(*ps.deadline) { </ins> klog.InfoS("Pod expired", "pod", klog.KObj(ps.pod)) if err := cache.removePod(ps.pod); err != nil { klog.ErrorS(err, "ExpirePod failed", "pod", klog.KObj(ps.pod))

Related discussion:
text: The scheduler has a for the bind operation to succeed; if we don't get a response within 30s, the in-memory assignment of pod to node in the . A race condition will happen in the follow case: 1 is assigned to a node, scheduler cache is updated with the assignment, bind operation issued to apiserver. the apiserver is under huge pressure, bind takes more than 30s, scheduler expires the cached pod-to-node assignment. eventually succeeds, but because the apiserver is under huge pressure, the pod update with the node name takes a long time to propagate to the scheduler. the pod update took a long time to propagate and the cache entry expired, the scheduler is not aware that the assignment actually happened, and so it had no problem assigning a second pod to the same node that would otherwise not fit if the scheduler was aware that the first pod was eventually assigned to the node. On the scheduler side, what we need to do is make the 30s longer for large clusters, and ideally adaptable to cluster state. /sig scheduling No race conditions. Create a large scale cluster. No response <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
IIRC, the 30s timeout only starts running after we receive a 200 response for the binding. But yes, if it takes longer than 30s to receive the update, we would invalidate the cache. I don't know if there is particular reason to invalidate the cache at all. I suppose it was meant to guard against missing Pod deletion events. We need to improve that regardless. I would be in favor of dropping the timeout altogether.
ok, so the deadline is effectively for receiving the update. Perhaps making it longer, like 15min, is good first step before completely removing it just so we can easily revert in case something else goes wrong.
I sent to increase the timeout to 15min.
Code change:
"pod", klog.KObj(ps.pod)) continue } <del> if now.After(*ps.deadline) { </del> <ins> if cache.ttl != 0 && now.After(*ps.deadline) { </ins> klog.InfoS("Pod expired", "pod", klog.KObj(ps.pod)) if err := cache.removePod(ps.pod); err != nil { klog.ErrorS(err, "ExpirePod failed", "pod", klog.KObj(ps.pod))

Related discussion:
text: We should backport this.
We should double check the history, but I think that in the past we were: asynchronously sending bind request updating the cache before sending the request and then the timeout was actually protecting us from the binding request actually not succeeding. So I agree with Aldo - that we should double check if this timeout is at all needed currently.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
We are probably good to remove this timeout altogether at this point. /remove-lifecycle stale
/good-first-issue
I see this issue was labeled as "good first issue" and I would like to start working on it!