jiebi/CodeConvo huggingface dataset:
Code change:
maxUnavailable: 1, numUnavailable: 0, }, <ins> { name: "Two nodes with pods, MaxUnavailable in percents, pod terminating", Manager: func() *daemonSetsController { manager, _, _ := newTestController() addNodes(manager.nodeStore, 0, 2, nil) return manager }(), ds: func() *extensions.DaemonSet { ds := newDaemonSet("x") intStr := intstr.FromString("50%") ds.Spec.UpdateStrategy.RollingUpdate = &extensions.RollingUpdateDaemonSet{MaxUnavailable: &intStr} return ds }(), nodeToPods: func() map[string][]*v1.Pod { mapping := make(map[string][]*v1.Pod) pod0 := newPod("pod-0", "node-0", simpleDaemonSetLabel, nil) pod1 := newPod("pod-1", "node-1", simpleDaemonSetLabel, nil) now := metav1.Now() markPodReady(pod0) markPodReady(pod1) pod1.DeletionTimestamp = &now mapping["node-0"] = []*v1.Pod{pod0} mapping["node-1"] = []*v1.Pod{pod1} return mapping }(), maxUnavailable: 1, numUnavailable: 1, }, </ins> } for _, c := range cases {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The DaemonSet controller will schedule a pod on a node when the old pod is still in Terminating state. This breaks the expectation that only one pod will be running at a time per node. What you expected to happen: The DaemonSet controller should not let two pods running at the same time on the same node. How to reproduce it (as minimally and precisely as possible): Create a DaemonSet. Set terminationGracePeriodSeconds to be relatively long. Kill a pod. Watch a new pod start on the same node when the old pod is still terminating. Anything else we need to know?: Seems this behavior was introduced in Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig apps
/cc
cc
cc: I think the expected behavior is correct, the terminating pod could be performing an important step such as 'removing a lock' or 'cleanup' etc., we should allow that to gracefully die before creating a new one. IMHO we should revoke to old behavior, but why did we need this new behavior in the first place? That is not clear to me from the PR and Issue.
We don't currently guarantee at least or at most one scheduling for DaemonSet. Both behaviors are under consideration via issue and in the future work section of the . The reason for is to "Make sure that controllers are not adopting children that are marked for deletion" (). This is necessary for GC to work properly.
Well the behavior may be technically undefined, but can I request that in the future changes like this be mentioned in the release notes?
Yes, certainly.
Code change:
maxUnavailable: 1, numUnavailable: 0, }, <ins> { name: "Two nodes with pods, MaxUnavailable in percents, pod terminating", Manager: func() *daemonSetsController { manager, _, _ := newTestController() addNodes(manager.nodeStore, 0, 2, nil) return manager }(), ds: func() *extensions.DaemonSet { ds := newDaemonSet("x") intStr := intstr.FromString("50%") ds.Spec.UpdateStrategy.RollingUpdate = &extensions.RollingUpdateDaemonSet{MaxUnavailable: &intStr} return ds }(), nodeToPods: func() map[string][]*v1.Pod { mapping := make(map[string][]*v1.Pod) pod0 := newPod("pod-0", "node-0", simpleDaemonSetLabel, nil) pod1 := newPod("pod-1", "node-1", simpleDaemonSetLabel, nil) now := metav1.Now() markPodReady(pod0) markPodReady(pod1) pod1.DeletionTimestamp = &now mapping["node-0"] = []*v1.Pod{pod0} mapping["node-1"] = []*v1.Pod{pod1} return mapping }(), maxUnavailable: 1, numUnavailable: 1, }, </ins> } for _, c := range cases {

Related discussion:
text: Also "The DaemonSet controller should not let two pods running at the same time on the same node." is not necessarily the same thing as respecting termination prior to launching a new Pod. The former implies a more strict requirement than the latter. I think we should consider at least attempting to wait for a terminating Pod to be deleted prior to creating another Pod on the Node for same DaemonSet as default behavior.
will something like work then?
Code change:
func (options *ServerRunOptions) Validate() []error { var errors []error <ins> if errs := options.GenericServerRunOptions.Validate(); len(errs) > 0 { errors = append(errors, errs...) } </ins> if errs := options.Etcd.Validate(); len(errs) > 0 { errors = append(errors, errs...) }

Related discussion:
text: See I think it's the last file that has no validation in pkg . Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
Code change:
return false, fmt.Errorf("Spec does not reference a RBD volume type") } <ins> func getVolumeAccessModes(spec *volume.Spec) ([]v1.PersistentVolumeAccessMode, error) { // Only PersistentVolumeSpec has AccessModes if spec.PersistentVolume != nil { if spec.PersistentVolume.Spec.RBD != nil { return spec.PersistentVolume.Spec.AccessModes, nil } else { return nil, fmt.Errorf("Spec does not reference a RBD volume type") } } return nil, nil } </ins> func parsePodSecret(pod *v1.Pod, secretName string, kubeClient clientset.Interface) (string, error) { secret, err := volutil.GetSecretForPod(pod, secretName, kubeClient) if err != nil {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When use ceph as storageclass, i set accessModes: ReadOnlyMany, and create pods using the claim, only one pod would be running and the others on different nodes would get stuck on ContainerCreating. But if the pods are all on same node, it works fine. What you expected to happen: Pods on different nodes can mount ceph rbd volume. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): 3.10.0-327.18.2.el7.x86_64 Kernel (e.g. ): CentOS Linux release 7.2.1511 (Core) Install tools: kubeadm Others:
/sig storage
/assign
, how would this work? For example, how do you put the initial contents of the RBD volume on it if it is in the ReadOnlyMany access mode? How would you use this feature? As a cheap way of sharing files across a Kubernetes cluster? I'm just interested. -ben england
Do we really want to support ? I have the same questions as mentioned above. If we set the PVC AccessMode to , then the field in will need to be set true ? If so, for the first time, in , we will mount the device without formatting, is that intended ? We need to format the device manually before we use it ? /cc FYI: also there is an issue related to this:
We have this same problem for GCE PD, which supports ReadOnlyMany. You need to mount the volume first as RWO, in order to format the filesystem and populate it with data (mounting a read only volume with no data on it seems pointless). Then you have to fully unmount/detach it, and then you can deploy pods using it as ROX. Basically, you can dynamically provision it in RWO to format + populate data. But afterwards, you need to manually create a different PV/PVC for ROX
continuation
Code change:
k8sNodeRouteTag = "k8s-node-route" // AffinityTypeNone - no session affinity. <del> gceAffinityTypeNone = "None" </del> <ins> gceAffinityTypeNone = "NONE" </ins> // AffinityTypeClientIP - affinity based on Client IP. gceAffinityTypeClientIP = "CLIENT_IP" // AffinityTypeClientIPProto - affinity based on Client IP and port.

Related discussion:
text: Hi, I have a problem with my GCE cluster about LoadBalancer type Services It's creating a lot of unused static external IP on the google network of my project the cluster is running kubernetes v1.1.2. Tried restarting nodes, tried destroy/recreate of the entire cluster.
Seeing exactly the same issue at GKE since a few hours. First on a v1.0.7 cluster which I later upgraded to v1.1.2 to fix the problem but the issue is still there. Double checked my yaml config files but no changes from our side. Existing loadbalancers do work as before.
I dealt with this last night and a workaround was to add to the spec
Thx :+1:
We'll get this cherry picked into the two release branches once it's been verified at HEAD.
Code change:
grains: node_ip: $MASTER_IP master_ip: $MASTER_IP <ins> network_mode: openvswitch </ins> etcd_servers: $MASTER_IP cloud_provider: vagrant roles:

Related discussion:
text: The salt configs assume that anything under "os_family = RedHat" will use the ovs mechanisms that are only set up for vagrant. This means that we can't use Fedora on GCE.
I can clean this up today.
Code change:
} // Update updates the pet in the 'pet' pcb to match the pet in the 'expectedPet' pcb. <ins> // If the pod object of a pet which to be updated has been changed in server side, we // will get the actual value and set pet identity before retries. </ins> func (p *apiServerPetClient) Update(pet *pcb, expectedPet *pcb) (updateErr error) { <del> var getErr error </del> pc := podClient(p.c, pet.parent.Namespace) <del> pod, needsUpdate, err := copyPetID(pet, expectedPet) if err != nil || !needsUpdate { return err } glog.Infof("Resetting pet %v to match PetSet %v spec", pod.Name, pet.parent.Name) for i, p := 0, &pod; ; i++ { _, updateErr = pc.Update(p) </del> <ins> for i := 0; ; i++ { updatePod, needsUpdate, err := copyPetID(pet, expectedPet) if err != nil || !needsUpdate { return err } glog.Infof("Resetting pet %v/%v to match PetSet %v spec", pet.pod.Namespace, pet.pod.Name, pet.parent.Name) _, updateErr = pc.Update(&updatePod) </ins> if updateErr == nil || i >= updateRetries { return updateErr } <del> if p, getErr = pc.Get(pod.Name); getErr != nil { </del> <ins> getPod, getErr := pc.Get(updatePod.Name) if getErr != nil { </ins> return getErr } <ins> pet.pod = getPod </ins> } }

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Consider the following code, When previous update fails, Pet Set Controller will Get a new Pod which may don't contain the Pet identity information(see ). If so, we can't 100% update Pod with a given pet identity information. I think it's a bug and we should do between update retries?
Fixed.
Code change:
if err := validateHost(); err != nil { return &validator{validateHostErr: err} } <del> appArmorFS, err := getAppArmorFS() if err != nil { return &validator{ validateHostErr: fmt.Errorf("error finding AppArmor FS: %v", err), } } return &validator{ appArmorFS: appArmorFS, } </del> <ins> return &validator{} </ins> } type validator struct { validateHostErr error <del> appArmorFS      string </del> } func (v *validator) Validate(pod *v1.Pod) error {

Related discussion:
text: As mentioned the return value of is not being used any longer and the entire method can be removed. The usage of was removed in Now there is no need to have the function and store it's result at all. /sig node /kind cleanup /good-first-issue /help-wanted KEP xref:
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : As mentioned the return value of is not being used any longer and the entire method can be removed. /kind cleanup /good-first-issue /help-wanted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
/assign
I am having issues submitting the pull request. I removed that portion of the code under however this is my first time contributing and would like some help submitting this new updated version..
/assign
/assign
/assign
/assign
Code change:
apiVersion: apps/v1 kind: Deployment metadata: <del> name: event-exporter-v0.3.1 </del> <ins> name: event-exporter-v0.3.4 </ins> namespace: kube-system labels: k8s-app: event-exporter <del> version: v0.3.1 </del> <ins> version: v0.3.4 </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile spec:

Related discussion:
text: the following images are using old client-go that would not work correctly starting 1.22+ if those images use in-cluster config(mounted service account token) to talk to kube-apiserver: if the above images use in-cluster config, they should use client-go 1.14+. xref: /assign /cc /sig instrumentation /priority important-soon
/triage accepted
Code change:
SecurityContext:               &v1.PodSecurityContext{}, TerminationGracePeriodSeconds: &period, SchedulerName:                 api.DefaultSchedulerName, <del> EnableServiceLinks:            &enableServiceLinks, </del> }, } tests := []struct {

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:
SecurityContext:               &v1.PodSecurityContext{}, TerminationGracePeriodSeconds: &period, SchedulerName:                 api.DefaultSchedulerName, <del> EnableServiceLinks:            &enableServiceLinks, </del> }, } tests := []struct {

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:
SecurityContext:               &v1.PodSecurityContext{}, TerminationGracePeriodSeconds: &period, SchedulerName:                 api.DefaultSchedulerName, <del> EnableServiceLinks:            &enableServiceLinks, </del> }, } tests := []struct {

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:
SecurityContext:               &v1.PodSecurityContext{}, TerminationGracePeriodSeconds: &period, SchedulerName:                 api.DefaultSchedulerName, <del> EnableServiceLinks:            &enableServiceLinks, </del> }, } tests := []struct {

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:
import ( "fmt" "math/rand" <ins> "net/http" "net/http/httptest" "testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/testapi" "github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/master" "github.com/GoogleCloudPlatform/kubernetes/plugin/pkg/admission/admit" </ins> "github.com/coreos/go-etcd/etcd" "github.com/golang/glog"

Related discussion:
text: In 0.13.2, the apiserver has automatically exposed metrics about the process, like start time, memory usage, processor usage, etc. This stopped working sometime between then and when 0.14.0 was cut. They're still correctly exported from the kubelet, interestingly enough. An e2e or integration test is also needed to catch this if it happens again.