jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/pkg/kubelet/eviction" testingclock "k8s.io/utils/clock/testing" <ins> "k8s.io/utils/pointer" </ins> ) func alwaysReady() bool { return true }

Discussion:
We should enhance the to verify that adding is unit-testable. We originally thought that this would only be possible with finalizers but there looks to be other options. We could follow examples from In podgc, if we discover an orphaned pod (pod on a missing node), we add a DisruptionCondition to the pod. We only test this behavior in the integration tests because we previously rely on finalizers to halt the deletion so we can avoid flaky tests.
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
/kind cleanup /sig apps
/good-first-issue /help
Will take a look /assign
/assign
/help
newbie question please, I couldn't find the file in the codebase or the PRs. Where can I read it?
Working on it now!
/assign
/assign
Has done very good work with this so I’m not sure we will be able to accept other PRs. We are waiting for an approval on the PR
is this issue still open
Is the issue still open or awaiting for the approval on the pr?
/remove help /remove good-first-issue
The issue is waiting for approval. I removed the tags to reflect that is is almost done.
Change:
"containers": [ { "name": "webserver", <del> "image": "gcr.io/google_containers/nettest:1.4", "imagePullPolicy": "Always", "args": [ "-service=nettest", "-port=8080", "-namespace=default", "-peers=2" </del> <ins> "image": "gcr.io/google_containers/nettest:1.1", "command": [ "-service=nettest" </ins> ], "ports": [ {

Discussion:
It's failing on both GCE and GKE-CI. It appears to have broken somewhere around build number 2509/2510 which includes a likely candidate PR (). /cc
I was about to debug this one. I'll take it.
Root cause is almost definitely one of these: Summary secrets example pod (details) the permissions on python files. (details) the implementation of DeepCopy to use reflection instead of Gob encode/decode. (details) networking test (details) back to executable. (details) protected docker processes (-900) (details) proxySocket out of to (details) Commit by Fix secrets example pod The file was modified Commit by Fixing the permissions on python files. The file was modified cluster/juju/charms/trusty/kubernetes- The file was modified cluster/juju/return-node- The file was modified cluster/juju/charms/trusty/kubernetes- Commit by Changing the implementation of DeepCopy to use reflection instead of Gob encode/decode. The file was The file was modified The file was modified Commit by Fix networking test The file was modified contrib/for-tests/network- The file was modified contrib/for-tests/network- The file was modified The file was modified contrib/for-tests/network-tester/Makefile Commit by Changing back to executable. The file was modified Commit by OOM protected docker processes (-900) The file was modified The file was modified The file was modified Commit by Move proxySocket out of to Moves proxySocket out of to new in proxy package in order to start separating proxy logic and implementation and make proxier more manageable to review. The file was modified The file was
Pretty sure it's commit , so rolling back now. cc .
The above rollback solved that immediate problem, but now the test, while proceeding healthily, is timing out. More debugging or optimization required: Networking should function for intra-pod communication ..... [irrelevant stuff deleted] ..... INFO: Proxy status call returned in 4.861944ms INFO: Attempt 35/60: test still running INFO: About to make a proxy status call Build timed out (after 90 minutes). Marking the build as aborted. Build timed out (after 90 minutes). Marking the build as failed. Ran 40 of 46 Specs in 5069.444 seconds FAIL!

-- 18 Passed 5 Skipped Build was aborted Recording test results
I'm not entirely sure why, but the test is running normally again, completing consistently in 13 seconds. Closing this issue for now. !
Change:
var ( // TODO: Deprecate gitMajor and gitMinor, use only gitVersion instead. gitMajor     string = "0"              // major version, always numeric <del> gitMinor     string = "4.2+"           // minor version, numeric possibly followed by "+" gitVersion   string = "v0.4.2-dev"     // version from git, output of $(git describe) </del> <ins> gitMinor     string = "4.3+"           // minor version, numeric possibly followed by "+" gitVersion   string = "v0.4.3-dev"     // version from git, output of $(git describe) </ins> gitCommit    string = ""               // sha1 from git, output of $(git rev-parse HEAD) gitTreeState string = "not a git tree" // state of git tree, either "clean" or "dirty" )

Discussion:
Failed: https://k8s- Run so broken it didn't make JUnit output!
Bootstrap?
Why did run this test? Please don't run large and enormous tests - this requires coordination w SREs etcd and may potentially break GCE.
/close hummm I just see the index is -1

Failed: https://k8s- Run so broken it didn't make JUnit output!
Sen what is the plan for migrating these to bootstrap?
isn't it a manual run test?
I guess I'll move it over with empty cron-string?
Why did run this test? Please don't run large and enormous tests - this requires coordination w SREs etcd and may potentially break GCE.
I don't think we've run these test ourselves, someone ran it and failed(10 days ago) thus this test failure occurred.
Change:
cmdArgs = append(cmdArgs, systemdRun, "--unit="+unitName, "--remain-after-exit", build.GetKubeletServerBin()) killCommand = exec.Command("sudo", "systemctl", "kill", unitName) restartCommand = exec.Command("sudo", "systemctl", "restart", unitName) <del> es.logFiles["kubelet.log"] = logFileData{ </del> <ins> e.logFiles["kubelet.log"] = logFileData{ </ins> journalctlCommand: []string{"-u", unitName}, } framework.TestContext.EvictionHard = adjustConfigForSystemd(framework.TestContext.EvictionHard)

Discussion:
In node e2e, we have the option to keep the services running after test for further debug. However, we set to for the services, which means that once the parent exits, they will receive and exit with the parent if they don't trap the signal. With this, option will never work. If we still need this feature, we should not set if is false. /cc
We still need this feature. It helps with debugging test failures by keeping all the daemons running upon failure. , Lantao Liu wrote:
Change:
} func (c *BlobDiskController) getAllStorageAccounts() (map[string]*storageAccountState, error) { <del> ctx, cancel := getContextWithCancel() </del> <ins> ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second) </ins> defer cancel() accountListResult, err := c.common.cloud.StorageAccountClient.ListByResourceGroup(ctx, c.common.resourceGroup) if err != nil {

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: A storageAccount API call blocks kubelet from becoming Ready when there isn't any outbound IP, 1. eventually (after 10mins), the kubelet registers again... there is a call to the ARM API done by which blocks for 10mins, before letting kubelet complete with its starting logic and making the node as details: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
return g.cache.UpdateNodeInfoSnapshot(g.nodeInfoSnapshot) } <ins> // GetPredicateMetadataProducer returns the predicate metadata producer. This is needed // for cluster autoscaler integration. func (g *genericScheduler) PredicateMetadataProducer() predicates.PredicateMetadataProducer { return g.predicateMetaProducer } </ins> // Schedule tries to schedule the given pod to one of the nodes in the node list. // If it succeeds, it will return the name of the node. // If it fails, it will return a FitError error with reasons.

Discussion:
/sig scheduling What would you like to be : Expose from constructed object. Why is this needed: Cluster Autoscaler is internally creating scheduler instance to perform predicates simulations. Up until now we used for bootstrapping scheduler. This allowed as to obtain the via (). We wanted to migrate to to simplify bootstrapping but now we cannot get the as it is not exposed via any public method/field of object. See WIP branch with migrated to () /sig scheduling
/assign
Change:
reflect.DeepEqual(s.EnableTCPReset, t.EnableTCPReset) && reflect.DeepEqual(s.DisableOutboundSnat, t.DisableOutboundSnat) <del> if wantLB { </del> <ins> if wantLB && s.IdleTimeoutInMinutes != nil && t.IdleTimeoutInMinutes != nil { </ins> return properties && reflect.DeepEqual(s.IdleTimeoutInMinutes, t.IdleTimeoutInMinutes) } return properties

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: Azure cloud provider is sending unexpected LoadBalancer update requests even if the LoadBalancer rules are already identical. The reason is GetIdleTimeout() returns nil when the annotation is not set While find rule doens't check whether it is nil or not. What you expected to happen: Azure cloud provider shouldn't send unexpected LoadBalancer updates. It is easily to get throttled if there're too many services running on the cluster. How to reproduce it (as minimally and precisely as possible): kubectl annotate service nginx testlabel=value Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /area provider/azure /assign
/sig cloud-provider
Change:
} // if groups are not specified, then we need to look them up differently depending on the type of user <del> // if they are specified, then they are the authority </del> <ins> // if they are specified, then they are the authority (including the inclusion of system:authenticated/system:unauthenticated groups) </ins> groupsSpecified := len(req.Header[authenticationapi.ImpersonateGroupHeader]) > 0 // make sure we're allowed to impersonate each thing we're requesting.  While we're iterating through, start building username

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): impersonate system:authenticated Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): Centos7 Kernel (e.g. ): Install tools: custom Others: Using RBAC What happened: Impersonating a user is not setting group which causes impersonate to fail What you expected to happen: If a user is in the tokens file they and they are impersonated the group should be for authz. How to reproduce it (as minimally and precisely as possible): sure group has cluster role a test user via token file a user with impersonate access submit a command via kubectl That request will fail with 403 response even though the user is in the group. Anything else we need to know: cc
We can probably be smart and put the authenticated group adder around the result of the impersonation filter. you see any issues with that?
We provide the group field to provide this kind of information. I'm not sure I would expect my request to the server about a particular user/group tuple to be evaluated for a different user/group tuple.
for impersonation, we already add groups when known (service accounts). doing so for the system:authenticated/system:unauthenticated groups makes sense to me
Only when the groups aren't specified, right? If memory serves, that's how we did it downstream where we can make group determination.
Change:
allowAnyProfile = true continue } <ins> // With the graduation of seccomp to GA we automatically convert // the deprecated seccomp profile annotation `docker/default` to // `runtime/default`. This means that we now have to automatically // allow `runtime/default` if a user specifies `docker/default` and // vice versa in a PSP. if p == v1.DeprecatedSeccompProfileDockerDefault || p == v1.SeccompProfileRuntimeDefault { allowedProfiles[v1.SeccompProfileRuntimeDefault] = true allowedProfiles[v1.DeprecatedSeccompProfileDockerDefault] = true } </ins> allowedProfiles[p] = true } }

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: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:
Change:
idMap := make(map[common.QuotaID]bool) for _, project := range list.projects { if project.data == path { <del> if id != project.id { </del> <ins> if id != common.BadQuotaID && id != project.id { </ins> return common.BadQuotaID, false, fmt.Errorf("attempt to reassign project ID for %s", path) } // Trying to reassign a directory to the project it's // already in.  Maybe this should be an error, but for // now treat it as an idempotent operation <del> return id, false, nil </del> <ins> return project.id, false, nil </ins> } idMap[project.id] = true }

Discussion:
I have kubernetes 1.24.7. I tried to use on formated volume. It works until first reboot. After reboot, I get messages: I expect that project quota can be assigned even after reboot. Use xfs for /var/lib/containerd with discard,quota,prjquota No response <details</details<detailsbaremetal </details<details</details<details</details<detailsrke2 </details<details</details
/sig node Can this be reproduced? Can this pod be recreated correctly if you force delete the pod?
/triage accepted
It can be reproduced. Pod is created if I remove . I can test force delete.
/assign we are looking into gate to understand if we need to keep it or deprecate it.
If I force delete pod, it does not start again:
/assign Let me check on the latest code with the fix
Change:
} // The default plugin is explicitly re-configured, update the default plugin accordingly. if customPlugin, ok := enabledCustomPlugins[defaultEnabledPlugin.Name]; ok { <del> klog.InfoS("Defaut plugin is explicitly re-configured and is overriding.", "plugin", defaultEnabledPlugin.Name) // update the default plugin in place to preserve order </del> <ins> klog.InfoS("Default plugin is explicitly re-configured; overriding", "plugin", defaultEnabledPlugin.Name) // Update the default plugin in place to preserve order. </ins> defaultEnabledPlugin = customPlugin.plugin <del> // kick the plugin from the enabled list of custom plugins customPluginSet.Enabled = append(customPluginSet.Enabled[:customPlugin.index], customPluginSet.Enabled[customPlugin.index+1:]...) </del> <ins> replacedPluginIndex.Insert(customPlugin.index) </ins> } enabledPlugins = append(enabledPlugins, defaultEnabledPlugin) } } <del> enabledPlugins = append(enabledPlugins, customPluginSet.Enabled...) </del> <ins> // Append all the custom plugins which haven't replaced any default plugins. // Note: duplicated custom plugins will still be appended here. // If so, the instantiation of scheduler framework will detect it and abort. for index, plugin := range customPluginSet.Enabled { if !replacedPluginIndex.Has(index) { enabledPlugins = append(enabledPlugins, plugin) } } </ins> return v1beta2.PluginSet{Enabled: enabledPlugins} }

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 --Recent commit: import an issue when multiple custom plugin configured in scheduler config file, and those plugins are default plugins too. It was manipulating slice with index, but the slice is updated while index is not, which will cause the index out of range, see the exceptions listed below, config file should be handled properly without such exception override multiple default plugin in scheduler's config file. Kubernetes version (use ): latest (1.22) Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign
/sig scheduling /triage accepted
Change:
l) local_binaries=true ;; <ins> o) env_os_distro=true ;; </ins> h) usage exit 0

Discussion:
During a manual upgrade test, described in , a kubelet failed to communicate via SSL to its master. This is currently blocking the 1.4 release. There is not a repro for this yet. The cluster was running 1.3, and was upgraded to 1.4 successfully, but upon downgrading to 1.3, the kubelets one one or more machines are not able to talk to the master. Current kubelet version is . (EDITED) The error when talking to the master is (lots like this): I think this means that the kubelet cannot verify the master's cert. I can't find the master's cert. Since there is not flag to kubelet to tell it where to find its config, I assume it is using the default location, which is . It seems wrong that clusters[0].cluster.certificate-authority-data is empty. That should have the cert for the master, right? I see this thing: but I don't understand what process generates , and if, presumably, from that template, why it isn't setting the env var CA_CERT.
in case this is related to kubelet bootstrap changes in 1.4.
Currently node is :
Correction. The node is running 1.4.0-beta.5
If the kubelet hasn't set the then it will not go through the bootstrap code path. Is the kubeconfig provided through the bootstrap flag or the kubeconfig flag?
Not set. For reference, args are:
Question: Could you please tell me why your nodes are running with GCI image at the first place? The test is starting with 1.3 release, which is using old debian-based containervm image, and I thought doesn't change the image at all (separate topic).
It does change to gci on gce with the default upgrade scripts, i brought this up on an email thread. I'm guessing something was dropped when we translated salt grains (containervm) to gci env vars.
What the default upgrade scripts you were referring to? I just double-checked with test cluster which was upgrade to 1.4 through , the node is stay with debian-based containervm, but Kubernetes version is bumped up to 1.4-beta.X
Ok, I am assigning this to to confirm.

If upgrade logic from 1.3 to 1.4 changes the underneath os, that is wrong. I strongly believe this is just a simple operational error.
My understanding is that ignores base images altogether. , Dawn Chen wrote:
Hmm
I've tried and the node image did get updated to GCI. Before upgrade to v1.4: After upgrade to v1.4: After downgrade to v1.3: /cc
helped me debug this. He found that the metadata for the instance did not include the CA_CERT in it. That seems wrong.
Renamed from "x509 failure for kubelet after upgrade test"
Yeah, that's the error you'd get if the proper ca isn't loaded.
Will we get this problem if we don't upgrade to GCI (i.e. we stay with CVM) in -N? I guess we can try it and find out.
Manual upgrades have been successful if we don't switch image types. , David Oppenheimer < :
re: If you don't change the underneath image during the upgrade, the issue shouldn't occur.
Change:
mkdir -p "${release_stage}/server" cp "${RELEASE_DIR}/kubernetes-salt.tar.gz" "${release_stage}/server/" <del> cp "${RELEASE_DIR}"/kubernetes-server-*.tar.gz "${release_stage}/server/" </del> cp "${RELEASE_DIR}/kubernetes-manifests.tar.gz" "${release_stage}/server/" <ins> cat <<EOF > "${release_stage}/server/README" Server binary tarballs are no longer included in the Kubernetes final tarball. Run cluster/get-kube-binaries.sh to download client and server binaries. EOF </ins> mkdir -p "${release_stage}/third_party" cp -R "${KUBE_ROOT}/third_party/htpasswd" "${release_stage}/third_party/htpasswd"

Discussion:
Either include non-arch specific stuff in every tar or break that out too. ref cc
interested in helping with this one?
Yes, I may help
OK, I did not actually understand what was in , apparently. Alternate proposal: [ ] update all references that need just server binaries to download the server tarball directly [ ] same for places that just need (related to ) [ ] remove all arch-specific binary artifacts from and replace with a script which downloads the client/server tarballs as necessary. The alternative option, including all of the non-arch-specific code and docs in an arch-specific starts to get very tricky, since we run into a large cross product of client x server platforms/archs.