jiebi/CodeConvo huggingface dataset:
Code change:
loc.Path += "/" } <del> // From pkg/genericapiserver/endpoints/handlers/proxy.go#ServeHTTP: // Redirect requests with an empty path to a location that ends with a '/' // This is essentially a hack for http://issue.k8s.io/4958. // Note: Keep this code after tryUpgrade to not break that flow. if len(loc.Path) == 0 { var queryPart string if len(req.URL.RawQuery) > 0 { queryPart = "?" + req.URL.RawQuery } w.Header().Set("Location", req.URL.Path+"/"+queryPart) w.WriteHeader(http.StatusMovedPermanently) </del> <ins> proxyRedirect := proxyRedirectsforRootPath(loc.Path, w, req) if proxyRedirect { </ins> return }

Related discussion:
text: What happened: As part of creating an e2e test for , it was found that the apiserver proxy server is processing a blank redirect for any for 21 endpoints across pods, services and nodes. For a pod, redirecting for any method other than GET or HEAD is a bug, you expected to happen: This is the current behaviour for the apiserver but with a minimal code change the redirect can apply to only the following endpoints; - - - How to reproduce it (as minimally and precisely as possible): Create any standard pod and service in the default namespace run in another terminal the response from running the following commands produces a can be replaced with other http verbs , , , , and which also produce 301 responses. Anything else we need to know?: networking /sig testing /sig architecture
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: - - - run in another terminal the response from running the following commands produces a testing /sig architecture 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
Does this issue and PR address your concerns about the apiserver proxy server doing a blanket direct of any http call to the root proxy endpoints?
commented on the associated PR, thanks
/remove-sig testing
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale Will be addressed late in 1.21
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
loc.Path += "/" } <del> // From pkg/genericapiserver/endpoints/handlers/proxy.go#ServeHTTP: // Redirect requests with an empty path to a location that ends with a '/' // This is essentially a hack for http://issue.k8s.io/4958. // Note: Keep this code after tryUpgrade to not break that flow. if len(loc.Path) == 0 { var queryPart string if len(req.URL.RawQuery) > 0 { queryPart = "?" + req.URL.RawQuery } w.Header().Set("Location", req.URL.Path+"/"+queryPart) w.WriteHeader(http.StatusMovedPermanently) </del> <ins> proxyRedirect := proxyRedirectsforRootPath(loc.Path, w, req) if proxyRedirect { </ins> return }

Related discussion:
text: 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 stale
/remove-lifecycle stale
Code change:
97099dccc8807e9159dc28f374a8f0602cab07e1 kube::util::go_install_from_commit  github.com/bazelbuild/bazel-gazelle/cmd/gazelle  <del> 39e8257565d3917c1674bf37d6538c10cdac2260 </del> <ins> a85b63b06c2e0c75931e57c4a1a18d4e566bb6f4 </ins> touch "${KUBE_ROOT}/vendor/BUILD"

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: What you expected to happen: I expected the update to run successfully. How to reproduce it (as minimally and precisely as possible): Checkout. . Anything else we need to know?: I get this in both master and release-1.9. I tested most carefully in release-1.9 (because I am working on a cherry-pick right now). In particular, I blew away the container and image I had used earlier for building. Before running I established this state: Then I ran --- which took a while but eventually completed. It left me this state: After that is when I ran the that is exhibited at the start of this issue. Environment: Kubernetes version (use ): Commit (current release-1.9) Cloud provider or hardware configuration: local VM OS (e.g. from /etc/os-release): Ubuntu 17.10 Kernel (e.g. ): Linux ubu17dev 4.13.0-21-generic -Ubuntu SMP Mon Dec 18 17:29:16 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others: Docker 17.12.0-ce
Ah, there's another bug for this, this is being fixed. (same issue, verify uses update internally)
Any workaround?
/reopen It looks like the 1.8 and 1.9 release branches are broken for the same reason, but the fix is a bit less trivial, since we can't just use the latest gazelle, since this would require a huge mass of changes to the BUILD files. (Luckily, 1.7 doesn't use gazelle, so it's unaffected.) Some additional background: gazelle doesn't vendor bazelbuild/buildtools, though it does have a bazel dependency on a particular version. As a result, is always grabbing the latest version of bazelbuild/buildtools, even with our hacks to check out an older version of gazelle. An additional complication for the 1.8 and 1.9 branches is that we're installing gazelle from bazelbuild/rulesgo instead of bazelbuild/bazel-gazelle.
Code change:
97099dccc8807e9159dc28f374a8f0602cab07e1 kube::util::go_install_from_commit  github.com/bazelbuild/bazel-gazelle/cmd/gazelle  <del> 39e8257565d3917c1674bf37d6538c10cdac2260 </del> <ins> a85b63b06c2e0c75931e57c4a1a18d4e566bb6f4 </ins> touch "${KUBE_ROOT}/vendor/BUILD"

Related discussion:
text: Various options under consideration to fix these release branches: vendor gazelle, similar to (but not a straight cherrypick, since versions are different) the bazelbuild/rulesgo repo somewhere (where?) and then explicitly vendor and older version of bazelbuild/buildtools, and then use that fork instead of the upstream fork the hack in to also check out a particular bazelbuild/buildtools revision (so hacky) Anyone have a better idea?
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen Fully vendor gazelle, similar to (but not a straight cherrypick, since versions are different) Clone the bazelbuild/rulesgo repo somewhere (where?) and then explicitly vendor and older version of bazelbuild/buildtools, and then use that fork instead of the upstream fork Extend the hack in to also check out a particular bazelbuild/buildtools revision (so hacky) 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 /reopen
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /assign /reopen 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
I think we should start with 2) to get things fixed and then solve 1) for the current branch and come back to the release branches if we think we still need that.
can you describe 1) and 2) here?
I ended up implementing option 3 in ; it wasn't quite as gross as I thought it'd be. LMK what you think.
1) and 2) from the bullets in
ahh, thanks.
many thanks... would the same fix work in release-1.7 and release-1.8? trying to get those in shape as well
PRs are out for 1.8 and 1.9. The same thing would work for 1.7 AFAIK Edit: see below, I am wrong WRT 1.7
1.7 is unaffected because it doesn't use gazelle.
Code change:
97099dccc8807e9159dc28f374a8f0602cab07e1 kube::util::go_install_from_commit  github.com/bazelbuild/bazel-gazelle/cmd/gazelle  <del> 39e8257565d3917c1674bf37d6538c10cdac2260 </del> <ins> a85b63b06c2e0c75931e57c4a1a18d4e566bb6f4 </ins> touch "${KUBE_ROOT}/vendor/BUILD"

Related discussion:
text: I just opened with the same hacky fix for 1.8. apologies for all these breakages. my technical debt caught up to me. :(
/close this should be fixed everywhere, for now.
Code change:
97099dccc8807e9159dc28f374a8f0602cab07e1 kube::util::go_install_from_commit  github.com/bazelbuild/bazel-gazelle/cmd/gazelle  <del> 39e8257565d3917c1674bf37d6538c10cdac2260 </del> <ins> a85b63b06c2e0c75931e57c4a1a18d4e566bb6f4 </ins> touch "${KUBE_ROOT}/vendor/BUILD"

Related discussion:
text: http://k8s- looks like something is indeed busted :- /priority failing-test /kind bug /status approved-for-milestone /sig testing cc /assign
/assign looks like Mike is working on the fix
Code change:
if [[ -n "${move_docker}" ]]; then # Move docker to e.g. /mnt <ins> # but only if it is a directory, not a symlink left over from a previous run </ins> if [[ -d /var/lib/docker ]]; then mv /var/lib/docker ${move_docker}/ fi mkdir -p ${move_docker}/docker <del> ln -s ${move_docker}/docker /var/lib/docker </del> <ins> # If /var/lib/docker doesn't exist (it will exist if it is already a symlink), # then symlink it to the ephemeral docker area if [[ ! -e /var/lib/docker ]]; then ln -s ${move_docker}/docker /var/lib/docker fi </ins> DOCKER_ROOT="${move_docker}/docker" DOCKER_OPTS="${DOCKER_OPTS:-} -g ${DOCKER_ROOT}" fi

Related discussion:
text: On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.
Code change:
create_storage_class fi <ins> if [[ "${FEATURE_GATES:-}" == "AllAlpha=true" || "${FEATURE_GATES:-}" =~ "CSIDriverRegistry=true" ]]; then create_csi_crd "csidriver" fi if [[ "${FEATURE_GATES:-}" == "AllAlpha=true" || "${FEATURE_GATES:-}" =~ "CSINodeInfo=true" ]]; then create_csi_crd "csinodeinfo" fi </ins> print_success if [[ "${ENABLE_DAEMON}" = false ]]; then

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : a new addon to addon manager "that automatically installs CSI CRDs if CSIDriverRegistry or CSINodeInfo feature gates are true". But this is either broken or this addon manager isn't active in a cluster brough up with: This should work automatically also for such local clusters. Why is this needed: The CSI E2E tests are now expecting that the cluster has the CRDs and fail when that isn't the case. /kind feature (or perhaps a bug, not sure) /cc
/assign
Is this expected to be installed in other clusters? A lot of clusters are not going to be using cluster/* scripts.
Code change:
Close() // DeleteNominatedPodIfExists deletes nominatedPod from internal cache DeleteNominatedPodIfExists(pod *v1.Pod) <ins> // NumUnschedulablePods returns the number of unschedulable pods exist in the SchedulingQueue. NumUnschedulablePods() int </ins> } // NewSchedulingQueue initializes a new scheduling queue. If pod priority is

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Today, the scheduler re-processes unschedulable nodes . Node updates are sent by Kubelet frequently (every 10 seconds) and often times they don't change any of the node properties that could potentially make them feasible. We should be smarter about these updates and move pods to the schedulable queue only when certain properties of nodes change that could make them feasible. These properties include node allocatable, node conditions, taints, labels, .... Why is this needed: Improves performance of the scheduler and avoids doing unnecessary attempts to schedule pods. This is particularly helpful when a cluster has a lot of unschedulable pods. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature This is not a feature really. It is performance optimization, but in the absence of such a label, I need to use "feature" here. /sig scheduling
I can help to fix it. /assign mlmhl
The main reason for this problem is / update their status too frequently and most of these updates are heartbeats without any meaningful change. Recently sig-node introduces a new to alleviate this problem. With this mechanism, kubelet will split heartbeat and node status updates into two independent operations, and reduce the frequency of status updates to once per 1 minute(or more). In the long run this mechanism can indeed alleviate our problems, but at present it does not help us much as this is still an alpha feature and the node status updates frequency is still a bit high(per 1 minute right now).
Maybe we can try comparing old and new nodes after stripping their heartbeat info, like this:
I think that had sent earlier is more efficient. However, that PR does not filter out . In Wei's code, the heartbeat time is removed correctly. I think we should fix this issue and resubmit that PR.
could you resubmit a PR to: disregard in conditions comparison: and (optionally) disregard timestamp in taints comparison:
Thanks for all your advice, a new PR is submitted: This PR does not include your second suggestion(disregard timestamp in taints comparison) as I'm not sure if can be changed when node updating.
Code change:
Close() // DeleteNominatedPodIfExists deletes nominatedPod from internal cache DeleteNominatedPodIfExists(pod *v1.Pod) <ins> // NumUnschedulablePods returns the number of unschedulable pods exist in the SchedulingQueue. NumUnschedulablePods() int </ins> } // NewSchedulingQueue initializes a new scheduling queue. If pod priority is

Related discussion:
text: If it can be changed, I will add this filter later, otherwise I think we can keep the current implementation to make the compare operation simpler and faster. What's more, just as I said in the PR's description, I'm not sure how much side effects this change has on scheduler's resource consumption, as it always copy node's conditions before comparison.
I am thinking whether we could move this logic(whether node became more schedulable) to kubelet, kubelet reports it through heartbeats.
Code change:
// BeforeEach gets a client and makes a namespace. func (f *Framework) BeforeEach() { <ins> f.beforeEachStarted = true </ins> // The fact that we need this feels like a bug in ginkgo. // https://github.com/onsi/ginkgo/issues/222 f.cleanupHandle = AddCleanupAction(f.AfterEach)

Related discussion:
text: What happened: When running external CSI Driver tests with the Kubernetes E2E: We seem to be getting the following error. From initial investigation it looks like this happens in the during check but only when the test is being skipped. Hunch is that maybe since the test is skipped some resources are never created or they are cleaned up already and they are nil when the is called and expecting them. Kind of low priority since it doesn't make any tests actually fail. /cc /sig storage
see
I think should address this
Code change:
} if shareName == "" { <del> // File share name has a length limit of 63, and it cannot contain two consecutive '-'s. </del> <ins> // File share name has a length limit of 63, it cannot contain two consecutive '-'s, and all letters must be lower case. </ins> name := util.GenerateVolumeName(a.options.ClusterName, a.options.PVName, 63) shareName = strings.Replace(name, "--", "-", -1) <ins> shareName = strings.ToLower(shareName) </ins> } if resourceGroup == "" {

Related discussion:
text: <!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-e2e-aks-engine-azure-file pull-kubernetes-e2e-azure-file-windows AzureFile CSI Driver End-to-End Tests: Dynamic Provisioning should create a volume on demand with mount options [] [] [Windows] AzureFile CSI Driver End-to-End Tests: Dynamic Provisioning should create multiple PV objects, bind to PVCs and attach all to different pods on the same node [] [] [Windows] AzureFile CSI Driver End-to-End Tests: Dynamic Provisioning should create a volume on demand and mount it as readOnly in a pod [] [] [Windows] If the randomly generated kubetest resource group has capital letters, the share name will contain invalid characters and fail provisioning. links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
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
Code change:
func TestUpdateDisruptedPods(t *testing.T) { dc, ps := newFakeDisruptionController() <del> dc.recheckQueue = workqueue.NewNamedDelayingQueue("pdb-queue") </del> <ins> dc.recheckQueue = workqueue.NewNamedDelayingQueue("pdb_queue") </ins> pdb, pdbName := newMinAvailablePodDisruptionBudget(t, intstr.FromInt(1)) currentTime := time.Now() pdb.Status.DisruptedPods = map[string]metav1.Time{

Related discussion:
text: What happened: From : What you expected to happen: Metrics should register successfully. How to reproduce it (as minimally and precisely as possible): Run kubernetes-integration test 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 add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Code change:
// // alpha: v1.4 // MyFeature() bool <del> // owner @smarterclayton // alpha: v1.16 // beta:  v1.19 // // Enable legacy behavior to vary cluster functionality on the node-role.kubernetes.io labels. On by default (legacy), will be turned off in 1.18. // Original copy from k8s.io/kubernetes/pkg/features/kube_features.go LegacyNodeRoleBehavior featuregate.Feature = "LegacyNodeRoleBehavior" // owner @brendandburns // alpha: v1.9 // beta:  v1.19 // ga:  v1.21 // // Enable nodes to exclude themselves from service load balancers // Original copy from k8s.io/kubernetes/pkg/features/kube_features.go ServiceNodeExclusion featuregate.Feature = "ServiceNodeExclusion" </del> // owner: @khenidak // alpha: v1.15 //

Related discussion:
text: What is missing? Based on SIG call it's probably "tests" but I am not sure. Could use some investigation and followup - how do we get it to GA? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
This one seems not a good first one, I'll take this to myself and start bothering people in Slack to check what's missing, mostly as I've seen this is also related to cloud providers :)
I think this one originally. According to the KEP in This should have went GA in v.19 and be removed in v1.20. Given it's still marked beta, at the very least we should mark it GA in v1.20 and remove it in v1.21. anything I'm missing here?
yeap. Honest question, changing a Feature Gate to GA process is only changing the related line in and also putting a comment that this goes to GA? If so, probably this one can also be a good first issue and we can open a future issue for the removal in v1.21 once v1.20 ships. I think this will also need to be changed in the in v1.21 right? If is ok with that, I would like then to mark this as a good first issue to turn the feature GA in v1.20 :)
Well, taking a look into how secure is to move to GA: In the KEP there are some considerations about removing the IsMasterNode function, which seems to be already dealt in commit E2E tests needs to be also checked about usage of IsMasterNode(), which I could not find anymore and also seems to be removed from the same commit above. About the same Kep, it's directly related to other Feature Gate: ` So what I think that needs to be done: Promote LegacyNodeRoleBehavior to GA and Default it to false as proposed in the Kep -I'll open another issue just for this According to the LegacyNodeRoleBehavior should be removed in v1.19 but according to the Kep in v1.21, so let's stick with v1.21? ServiceNodeExclusion - Should be moved to GA, already defaulted to true. This issue is going to deal ONLY with this.
Code change:
// // alpha: v1.4 // MyFeature() bool <del> // owner @smarterclayton // alpha: v1.16 // beta:  v1.19 // // Enable legacy behavior to vary cluster functionality on the node-role.kubernetes.io labels. On by default (legacy), will be turned off in 1.18. // Original copy from k8s.io/kubernetes/pkg/features/kube_features.go LegacyNodeRoleBehavior featuregate.Feature = "LegacyNodeRoleBehavior" // owner @brendandburns // alpha: v1.9 // beta:  v1.19 // ga:  v1.21 // // Enable nodes to exclude themselves from service load balancers // Original copy from k8s.io/kubernetes/pkg/features/kube_features.go ServiceNodeExclusion featuregate.Feature = "ServiceNodeExclusion" </del> // owner: @khenidak // alpha: v1.15 //

Related discussion:
text: NodeDisruptionExclusion - Should be moved to GA, already defaulted to true. I'll open another issue for this I'm afraid of this having some sort of direct impact in cloud providers, do you want me to take this to the sig-cloudproviders meet? Otherwise can we move the above Feature Gates to GA, and schedule their removal for v1.21, wdyt?
Per deprecation lifecycle it seems that a feature needs 6 months or 2 releases (the longer one) in Beta before going to GA. So this actually seems to be the missing part before moving to GA. As the 3 FeatureGates are directed related, probably this issue should be: Move all of them to GA in v1.21 Default LegacyNodeRoleBehavior to false Sounds a good approach? I can keep this opened until we reach v1.21
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
/retitle Move Feature gate ServiceNodeExclusion to GA and LockToDefault
/triage accepted as this FG is scheduled to be moved to GA in v1.21, do you want to tackle on this?
fixed in /close
Closing this issue. <detailsIn response to : fixed in /close </details