jiebi/CodeConvo huggingface dataset:
Code change:
"spec.hostPID", }, }, <del> { name: "reseting defaults for pre-v1.1 mirror pods", input: ` { "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"my-pod-name", "namespace":"my-pod-namespace", "annotations": { "kubernetes.io/config.mirror": "mirror" } }, "spec": { "containers":[{ "name":"a", "image":"my-container-image", "resources": { "limits": { "cpu": "100m" } } }] } } `, absentKeys: []string{ "spec.terminationGracePeriodSeconds", "spec.containers[0].resources.requests", }, }, { name: "preserving defaults for v1.1+ mirror pods", input: ` { "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"my-pod-name", "namespace":"my-pod-namespace", "annotations": { "kubernetes.io/config.mirror": "cbe924f710c7e26f7693d6a341bcfad0" } }, "spec": { "containers":[{ "name":"a", "image":"my-container-image", "resources": { "limits": { "cpu": "100m" } } }] } } `, expectedKeys: map[string]string{ "spec.terminationGracePeriodSeconds":    "30", "spec.containers[0].resources.requests": "map[cpu:100m]", }, }, </del> } validator := func(obj runtime.Object) field.ErrorList {

Related discussion:
text: We do have access to GKE nodes, and we don't do that. To obtain the permission to run script and sync a file requires more work from PM side. This is a API backward compatibility issue anyway. Given today's version management policy, we should handle such compatibility issue. I checked our default code: request diff was introduced by TerminationGracePeriodSeconds was introduced along with graceful termination support. There is no conversion for both fields There is no validation checking both fields today I think it is safe to disable such defaulting for mirror pods shouldn't cause any issue for 1.1 release. Sending PR shortly.
In order to not break the v1.1+ kubelet (which applies newer defaults), we should only skip defaulting for pods from pre-v1.1 kubelets. An easy way to do this is to reuse , which changes the mirror key annotation value from "mirror" to the hash of the pod manifest file. In short, if the key exists, it's a mirror pod. If the value is "mirror", it is sent by a pre-v1.1 kubelet. Otherwise, it's sent by a v1.1+ kubelet. Note that we will also need to maintain the special defaulting case for the future releases until we drop support for v1.0 nodes.
Just this morning, we discussed providing a script/tool to update static pod configs for people with large clusters. Why have we changed that plan? Any hack in apiserver is going to be confusing and fragile. For instance, a LimitRange installed for kube-system would defeat the hack. If we were to add a hack in apiserver, we'd need to remove it in 1.2.
we talked to and the conclusion was that node update may not be feasible as . I agree that any apiserver fix is hacky and fragile, but it seems the most viable option right now. We would need to carry this fix in apiserver as long as GKE supports v1.N master + v1.0 node, unless we can make updating the configs part of the cluster upgrade process.
Ah. These fields are problems because they existed in 1.0, but weren't used nor populated. Entirely new fields are silently dropped during decoding.
Code change:
"spec.hostPID", }, }, <del> { name: "reseting defaults for pre-v1.1 mirror pods", input: ` { "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"my-pod-name", "namespace":"my-pod-namespace", "annotations": { "kubernetes.io/config.mirror": "mirror" } }, "spec": { "containers":[{ "name":"a", "image":"my-container-image", "resources": { "limits": { "cpu": "100m" } } }] } } `, absentKeys: []string{ "spec.terminationGracePeriodSeconds", "spec.containers[0].resources.requests", }, }, { name: "preserving defaults for v1.1+ mirror pods", input: ` { "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"my-pod-name", "namespace":"my-pod-namespace", "annotations": { "kubernetes.io/config.mirror": "cbe924f710c7e26f7693d6a341bcfad0" } }, "spec": { "containers":[{ "name":"a", "image":"my-container-image", "resources": { "limits": { "cpu": "100m" } } }] } } `, expectedKeys: map[string]string{ "spec.terminationGracePeriodSeconds":    "30", "spec.containers[0].resources.requests": "map[cpu:100m]", }, }, </del> } validator := func(obj runtime.Object) field.ErrorList {

Related discussion:
text: We should cherrypick the solution into 1.0.7, since it appears there will be one.
That is, we should cherrypick into the 1.0 branch.
Ref.
If the hack is going to remain indefinitely, I'm not comfortable circumventing defaulting, conversion, and validation.
Just not performing the defaulting for these specific fields on just mirror pods seems safer.
In particular, I could easily imagine a new version of the pod API in 1.2 or 1.3, which will require defaulting and conversion to be applied, in general.
We'll be discussing this soon after 1.1 lands, I expect. My proposal would be for v1.N masters to support v1.N-1 and v1.N-2 (and maybe v1.N-3) nodes. That gives users 6-9 months to lag their nodes behind their masters. But it warrants much further discussion. This isn't a viable solution either, because we can't depend on users updating their nodes to the latest 1.0 rev. We expect arbitrary 1.0 nodes to work, including 1.0.6 all the way back to 1.0.1, per our current .
As Ike noted, cherrypicking into 1.0 kubelets is not feasible for solving this, because the whole reason for the problem is that people aren't updating their nodes. The conversion fix in is much preferable to the defaulting fix: it's less brittle, and components that need the defaulting (e.g. scheduler) will see the defaulting (because they run the conversion stack themselves), but on the wire the mirror pods from old kubelets will remain undefaulted.
I didn't say cherrypicking into 1.0 would solve the problem for everything. The behavior in 1.0 is pretty broken, even when not considering upgrade. We have a fix. We should cherrypick it into 1.0.
I don't see how different components would see different values for these fields, assuming they are all updated to the new code. As discussed offline, the scheduler and node controller need to handle cases of empty requests and pod termination for 1.0 kubelets, anyway, so I think the conversion approach is fine. Please put the explanation in code comments, though, not just in issue/PR comments.
Code change:
"spec.hostPID", }, }, <del> { name: "reseting defaults for pre-v1.1 mirror pods", input: ` { "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"my-pod-name", "namespace":"my-pod-namespace", "annotations": { "kubernetes.io/config.mirror": "mirror" } }, "spec": { "containers":[{ "name":"a", "image":"my-container-image", "resources": { "limits": { "cpu": "100m" } } }] } } `, absentKeys: []string{ "spec.terminationGracePeriodSeconds", "spec.containers[0].resources.requests", }, }, { name: "preserving defaults for v1.1+ mirror pods", input: ` { "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"my-pod-name", "namespace":"my-pod-namespace", "annotations": { "kubernetes.io/config.mirror": "cbe924f710c7e26f7693d6a341bcfad0" } }, "spec": { "containers":[{ "name":"a", "image":"my-container-image", "resources": { "limits": { "cpu": "100m" } } }] } } `, expectedKeys: map[string]string{ "spec.terminationGracePeriodSeconds":    "30", "spec.containers[0].resources.requests": "map[cpu:100m]", }, }, </del> } validator := func(obj runtime.Object) field.ErrorList {

Related discussion:
text: Adding new fields with new defaults is fine, just not changing the behavior of existing fields. course I do think kubelet is being a very inflexible client here, but we can't fix the stuff that's already out there.
+1 to both points. We should've patched kubelet sooner to avoid this, but it's out there and kubelet 1.0 remains a stubborn client. Sorry for that. thanks for coming up with the solution! Since both of you agreed on , I will change my PR acoordingly.
So that there is no misunderstanding that leads to future such problems: Whether fields are new or pre-existing, it is an invalid assumption that unset fields may not be changed, whether by defaulting or by some other process, such as admission control.
This issue will be considered fixed for 1.1 once is submitted. (I didn't read this thread carefully enough yet to know whether additional work is necessary before considering this whole issue closed.)
Update: has just been merged. Closing the issue.
Probably we should not close this issue until we do a cherrypick?
The change was cherrypicked, so closing this issue
Code change:
"k8s.io/client-go/restmapper" "k8s.io/client-go/tools/clientcmd" "k8s.io/client-go/util/homedir" <ins> utilpointer "k8s.io/utils/pointer" </ins> ) const (

Related discussion:
text: The discovery cache for kubectl is defaulted to 10 minutes: That means that every 10 minutes of using against a cluster, it runs API requests against all group versions, which can take quite some time on clusters with many operators installed (like , , , etc.). I previously wrote that shows that every 10 minutes a simple makes 170 API requests against a test cluster, vs 4 API requests when the cache exists. That results in significant productivity implications against such clusters. Here is a time comparison between a request that runs the discovery cache vs one that doesn't: The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers. This issue is raised to change the discovery cache default to 24 hours and also to make the discovery cache ttl configurable. Running the discovery cache every 10 minutes has a significant productivity impact on using on clusters with many CRDs as it is taking time to run these unnecessary requests. The discovery cache doesn't really have to run every 10 minutes, as CRDs don't change that often. A lot of unnecessary load is created on clients and servers.
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 cli
I would like to work on this issue.
/assign
Code change:
params+=" --advertise-address=${vm_external_ip}" params+=" --ssh-user=${PROXY_SSH_USER}" params+=" --ssh-keyfile=/etc/srv/sshproxy/.sshkeyfile" <del> else [ -n "${MASTER_ADVERTISE_ADDRESS:-}" ] </del> <ins> elif [ -n "${MASTER_ADVERTISE_ADDRESS:-}" ]; then </ins> params="${params} --advertise-address=${MASTER_ADVERTISE_ADDRESS}" fi

Related discussion:
text: This is for manual upgrade testing: I am running the script on the release-1.5 branch and the script has been running for a long time now (40mins) with no sign of completion. Has anyone experienced a similar issue or has been successfully able to run the upgrade script ? Command I ran: -M v1.5.0-beta.1 $ -M v1.5.0-beta.1 == Pre-Upgrade Node OS and Kubelet Versions == name: "kubernetes-master", osImage: "Google Container-VM Image", kubeletVersion: "v1.4.7-beta.0.2+-dirty" name: "kubernetes-minion-group-7593", osImage: "Debian GNU/Linux 7 (wheezy)", kubeletVersion: "v1.4.7-beta.0.2+-dirty" name: "kubernetes-minion-group-bigx", osImage: "Debian GNU/Linux 7 (wheezy)", kubeletVersion: "v1.4.7-beta.0.2+-dirty" name: "kubernetes-minion-group-q5uf", osImage: "Debian GNU/Linux 7 (wheezy)", kubeletVersion: "v1.4.7-beta.0.2+-dirty" Your active configuration is: [default] Project: rkouj-test1 Zone: us-central1-b INSTANCEGROUPS=kubernetes-minion-group NODENAMES=kubernetes-minion-group-7593 kubernetes-minion-group-bigx kubernetes-minion-group-q5uf == Upgrading master to ''. Do not interrupt, deleting master instance. == Trying to find master named 'kubernetes-master' Looking for address 'kubernetes-master-ip' Using master: kubernetes-master (external IP: 104.197.149.96) Deleted []. WARNING: You have selected a disk size of under [200GB]. This may result in poor I/O performance. For more information, see: Created [].
Code change:
params+=" --advertise-address=${vm_external_ip}" params+=" --ssh-user=${PROXY_SSH_USER}" params+=" --ssh-keyfile=/etc/srv/sshproxy/.sshkeyfile" <del> else [ -n "${MASTER_ADVERTISE_ADDRESS:-}" ] </del> <ins> elif [ -n "${MASTER_ADVERTISE_ADDRESS:-}" ]; then </ins> params="${params} --advertise-address=${MASTER_ADVERTISE_ADDRESS}" fi

Related discussion:
text: Once that finished, my master upgrade succeeded after being in a waiting state for a long time: The bad news is that is baked into the k8s release tar, so we'll need to cut a new beta with a fix before we can resume manual upgrade testing.
Thanks for the investigation, and ! I LGTMd the PR sent with the fix.
FYI this won't actually be fixed until this PR is in the 1.5 release branch and we cut a beta release. At that point we will update the instructions in to point to and should be working properly again.
Agreed; I'll take care of doing that once I see the anago announcement of the new beta.
Code change:
func TestEnsureSandboxImageExists(t *testing.T) { sandboxImage := "gcr.io/test/image" <del> registryHost := "https://gcr.io/" </del> authConfig := dockertypes.AuthConfig{Username: "user", Password: "pass"} <del> authB64 := base64.StdEncoding.EncodeToString([]byte(fmt.Sprintf("%s:%s", authConfig.Username, authConfig.Password))) authJSON := fmt.Sprintf("{"auths": {"%s": {"auth": "%s"} } }", registryHost, authB64) </del> for desc, test := range map[string]struct { injectImage  bool imgNeedsAuth bool

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?: What happened: We have a private registry configured (where all images including the sandbox one), are hosted. The registry credentials are being pulled by one of k8s credentials providers () With Kubernetes 1.7 sandbox image failed to be pulled with the following error message: Looks like with this only creds from docker config are being evaluated on the sandbox image pull What you expected to happen: Sandbox image pull should be attempted using credentials returned by not just the basic docker credential provider, but other credentials providers registered in the system. How to reproduce it (as minimally and precisely as possible): 1) Register private repo credentials with one of the k8s credential providers (we've tried with rancher). Configure the to use the image from the the private repo. 2) Make sure you are not logged in to this private repo on the kubelet host 3) Try to create a pod. Sandbox image pull will fail with an error mentioned above. Anything else we need to know?: Non-sandbox images from the same private repo were able to download correctly using private repo credentials provider. Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Ubuntu 16.04 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 node Just tested the same use case against k8s 1.5.x, it worked fine there and sandbox image was pulled using the credentials passed by the credential provider, not from docker config file. So it might have regressed in 1.7.x (haven't tested it on 1.6, so can't tell for sure)
Confirmed a bug introduced in dockershim. Will file a PR to fix this.
Code change:
func TestEnsureSandboxImageExists(t *testing.T) { sandboxImage := "gcr.io/test/image" <del> registryHost := "https://gcr.io/" </del> authConfig := dockertypes.AuthConfig{Username: "user", Password: "pass"} <del> authB64 := base64.StdEncoding.EncodeToString([]byte(fmt.Sprintf("%s:%s", authConfig.Username, authConfig.Password))) authJSON := fmt.Sprintf("{"auths": {"%s": {"auth": "%s"} } }", registryHost, authB64) </del> for desc, test := range map[string]struct { injectImage  bool imgNeedsAuth bool

Related discussion:
text: Could you also verify whether fixed your problem?
tested against your commits cherry-picked on top of 1.8 beta, the fix seems to work
thanks.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Code change:
pod:           getPod("foo", "", "", "10Mi", "100Mi"), expectedValue: "104857600", }, <ins> { fs: &v1.ResourceFieldSelector{ Resource: "limits.cpu", }, cName:         "init-foo", pod:           getPod("foo", "", "9", "", ""), expectedValue: "9", }, { fs: &v1.ResourceFieldSelector{ Resource: "requests.cpu", }, cName:         "init-foo", pod:           getPod("foo", "", "", "", ""), expectedValue: "0", }, { fs: &v1.ResourceFieldSelector{ Resource: "requests.cpu", }, cName:         "init-foo", pod:           getPod("foo", "8", "", "", ""), expectedValue: "8", }, { fs: &v1.ResourceFieldSelector{ Resource: "requests.cpu", }, cName:         "init-foo", pod:           getPod("foo", "100m", "", "", ""), expectedValue: "1", }, { fs: &v1.ResourceFieldSelector{ Resource: "requests.cpu", Divisor:  resource.MustParse("100m"), }, cName:         "init-foo", pod:           getPod("foo", "1200m", "", "", ""), expectedValue: "12", }, { fs: &v1.ResourceFieldSelector{ Resource: "requests.memory", }, cName:         "init-foo", pod:           getPod("foo", "", "", "100Mi", ""), expectedValue: "104857600", }, { fs: &v1.ResourceFieldSelector{ Resource: "requests.memory", Divisor:  resource.MustParse("1Mi"), }, cName:         "init-foo", pod:           getPod("foo", "", "", "100Mi", "1Gi"), expectedValue: "100", }, { fs: &v1.ResourceFieldSelector{ Resource: "limits.memory", }, cName:         "init-foo", pod:           getPod("foo", "", "", "10Mi", "100Mi"), expectedValue: "104857600", }, </ins> } as := assert.New(t) for idx, tc := range cases {

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When referencing init container's env value from its fields, kubelet complains What you expected to happen: Init container should be supported to get env values from its own fields, as to How to reproduce it (as minimally and precisely as possible): a pod with init container refering its fields value as env value kubectl create -f test-pod-1.yaml cannot be created pod events Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ):Kernel (e.g. ):Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
The err happens at this line , it seems that we should search for init containers as well
Code change:
if [[ -z "$(which go)" ]]; then kube::log::usage_from_stdin <<EOF Can't find 'go' in PATH, please fix and retry. See http://golang.org/doc/install for installation instructions. EOF exit 2 fi

Related discussion:
text: Example: I have a fixing PR ready, will send it in a moment.
/sig docs /assign closing because linked pr fixed this
/close
Code change:
return pod, podStats } <ins> func makePIDStats(nodeAvailablePIDs string, numberOfRunningProcesses string, podStats map[*v1.Pod]statsapi.PodStats) *statsapi.Summary { val := resource.MustParse(nodeAvailablePIDs) availablePIDs := int64(val.Value()) parsed := resource.MustParse(numberOfRunningProcesses) NumberOfRunningProcesses := int64(parsed.Value()) result := &statsapi.Summary{ Node: statsapi.NodeStats{ Rlimit: &statsapi.RlimitStats{ MaxPID:                &availablePIDs, NumOfRunningProcesses: &NumberOfRunningProcesses, }, }, Pods: []statsapi.PodStats{}, } for _, podStat := range podStats { result.Pods = append(result.Pods, podStat) } return result } </ins> func makeMemoryStats(nodeAvailableBytes string, podStats map[*v1.Pod]statsapi.PodStats) *statsapi.Summary { val := resource.MustParse(nodeAvailableBytes) availableBytes := uint64(val.Value())

Related discussion:
text: We should add a unit test to Eviction manager that accounts for PID Pressure. The test should cover similar cases as DiskPressure or MemoryPressure. 1) PIDPressure doesn't exist on node. 2) Force PidPressure on node We should include test cases for reclaming resources in terms of pressure and verifying differences between soft and hard eviction.
/sig node /kind feature /help
This request has been marked as needing help from a contributor. 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 : /sig node /kind feature /help </details
/triage accepted /priority important-longterm
/good-first-issue
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 : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
it looks like has requested to work on this.
/assign
Hi What do you mean by, "verifying differences between soft and hard eviction."?
It’s the same idea as what we do for disk, memory or inode pressure.