jiebi/CodeConvo huggingface dataset:
Code change:
HOSTNAME_OVERRIDE=${HOSTNAME_OVERRIDE:-"127.0.0.1"} CLOUD_PROVIDER=${CLOUD_PROVIDER:-""} CLOUD_CONFIG=${CLOUD_CONFIG:-""} <del> FEATURE_GATES=${FEATURE_GATES:-"AllAlpha=true"} </del> <ins> FEATURE_GATES=${FEATURE_GATES:-"AllAlpha=false"} </ins> STORAGE_BACKEND=${STORAGE_BACKEND:-"etcd3"} # enable swagger ui ENABLE_SWAGGER_UI=${ENABLE_SWAGGER_UI:-false}

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): Environment: Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): RHE 7.2 Kernel (e.g. ): What happened: The node resource is empty when start local cluster by . What you expected to happen: There's one node in this local cluster. How to reproduce it (as minimally and precisely as possible):
Just check the script/code, it seems kubelet will not register until dynamic config is there ( enabled all alpha features by default).
I met same problem
What do you mean "dynamic config" ?
I think there's a PR that make kubelet can update configuration dynamically, similar to what we had done in scheduler. But did not find PR :(. I'm checking the code.
Should be this one: /cc /sig node
that shouldn't be the case. As long as you can get a client and a nodeName you should be able to register. What specific error are you seeing that suggests it's dynamic config? Also why does local-up-cluster enable all alpha features by default? That seems wrong to me.
Not sure why, but it really does:
I think this should be caused by /cc
, sorry for the disturbing :). Regarding all alpha features, I prefer to enable is by default: local-up-cluster is a kind of test environment for developer, enabling all alpha features maybe helpful to catch up potential feature interactions.
I would not expect all alpha features on by default in local up cluster
Neither would I. Developers, by default, shouldn't have to wonder if bugs are their fault or if they come from unstable alpha components. Users, by default, shouldn't have to deal with unstable alpha features either.
/ , got that; alpha components is unstable, do NOT cover everything for it.
met same problem
Code change:
<ins> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" kube::golang::setup_env "${KUBE_ROOT}/hack/build-go.sh" cmd/gendocs # Get the absolute path of the directory component of a file, i.e. the # absolute path of the dirname of $1. get_absolute_dirname() { echo "$(cd "$(dirname "$1")" && pwd)" } # Detect the OS name/arch so that we can find our binary case "$(uname -s)" in Darwin) host_os=darwin ;; Linux) host_os=linux ;; *) echo "Unsupported host OS.  Must be Linux or Mac OS X." >&2 exit 1 ;; esac case "$(uname -m)" in x86_64*) host_arch=amd64 ;; i?86_64*) host_arch=amd64 ;; amd64*) host_arch=amd64 ;; arm*) host_arch=arm ;; i?86*) host_arch=x86 ;; *) echo "Unsupported host arch. Must be x86_64, 386 or arm." >&2 exit 1 ;; esac # Find binary locations=( "${KUBE_ROOT}/_output/dockerized/bin/${host_os}/${host_arch}/gendocs" "${KUBE_ROOT}/_output/local/bin/${host_os}/${host_arch}/gendocs" "${KUBE_ROOT}/platforms/${host_os}/${host_arch}/gendocs" ) gendocs=$( (ls -t "${locations[@]}" 2>/dev/null || true) | head -1 ) if [[ ! -x "$gendocs" ]]; then { echo "It looks as if you don't have a compiled gendocs binary" echo echo "If you are running from a clone of the git repo, please run" echo "'./hack/build-go.sh cmd/gendocs'." } >&2 exit 1 fi KUBECTL_DOC="docs/kubectl.md" echo "diffing ${KUBECTL_DOC} against generated output from ${gendocs}" "${gendocs}" | diff "${KUBE_ROOT}/${KUBECTL_DOC}" - && echo "${KUBECTL_DOC} up to date." || { echo "${KUBECTL_DOC} is out of date. Please run ${gendocs} > ${KUBECTL_DOC}" exit 1 } </ins>

Related discussion:
text: Manually updated docs have a tendency to drift from actual implementation. It shouldn't be too hard to add a script to generate the markdown from a . We could then run the script manually or as a commit hook when changes are made to pkg/kubectl.
A big chunk of that is cut/paste from the help output anyway.. Brendan On Jan 9, 2015 4:20 PM, "Jeff Lowdermilk" wrote:
Why are we including the help output? Seems like cobra should do that, or we should just tell the user to ask for help if they want it.
It's useful to see generated markdown of help output for the full command tree, e.g. if you want to link to the syntax on irc or something. Anyway, this was quite easy to do, I'll have a PR shortly.
Code change:
Subsystem:         KubeletSubsystem, Name:              ConfigErrorKey, Help:              "This metric is true (1) if the node is experiencing a configuration-related error, false (0) otherwise.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, )

Related discussion:
text: This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
Reopened this issue. <detailsIn response to : /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
/cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Code change:
e := &Publisher{ client: cl, rootCA: rootCA, <del> queue:  workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "root-ca-cert-publisher"), </del> <ins> queue:  workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "root_ca_cert_publisher"), </ins> } if cl.CoreV1().RESTClient().GetRateLimiter() != nil { if err := metrics.RegisterMetricAndTrackRateLimiterUsage("root_ca_cert_publisher", cl.CoreV1().RESTClient().GetRateLimiter()); err != nil {

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:
Labels: testSvcLabels, }, Spec: v1.ServiceSpec{ <del> Type: "ClusterIP", </del> <ins> Type: "LoadBalancer", </ins> Ports: []v1.ServicePort{{ Name:       "http", Protocol:   v1.ProtocolTCP, Port:       int32(80), TargetPort: intstr.FromInt(80), }}, <ins> LoadBalancerClass: utilpointer.String("example.com/internal-vip"), </ins> }, } _, err = cs.CoreV1().Services(ns).Create(ctx, &testService, metav1.CreateOptions{})

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig network seems to be related.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/triage accepted
Code change:
// .. and other fields we don't care about.  Expand as necessary. } <del> // parseMetadataUUID reads JSON from OpenStack metadata server and parses </del> <ins> // parseMetadata reads JSON from OpenStack metadata server and parses </ins> // instance ID out of it. func parseMetadata(r io.Reader) (*Metadata, error) { var metadata Metadata

Related discussion:
text: According to the : "The scheduler bypasses any nodes that don't have any topologySpreadConstraints[].topologyKey present." However, the is:  "The scheduler bypasses any nodes that any don't have all topologySpreadConstraints[].topologyKey present." This is a bug as the implementation is not following . We expect the code implementation to align with the documentation's description. Read the documentation and the code. /sig scheduling of the on the branch, and of the on the branch <detailsNA </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
pr in case documentation is upheld
I dont't think the implementation of func is not as expected. Perhaps we can optimize the document a bit. /cc
I don't understand what the issue is trying to point out. -return true if the node has all required . -bypasses a node that don't have any topologySpreadConstraints[*].topologyKey. Nothing looks wrong?
I also think there is no problem with code logic. According to doc, if one node only have one label that equal to , this node should not be bypassed. This sentence may be ambiguous. In fact, a node with labels that match all should not be bypassed by scheduler.
So, where's the ambiguousness of the doc? Yes, and it matches the doc's explanation.
This is where there might be ambiguity. means that if node only have one matched label, this node will not be bypassed. But in fact the node labels must match all(not one of) topologySpreadConstraints[].topologyKey. Maybe I misunderstood it as well because English is not my native language. Ignore me if I'm wrong.
Okay, I got what you wanted to say. This is... an interesting English question.
Code change:
// .. and other fields we don't care about.  Expand as necessary. } <del> // parseMetadataUUID reads JSON from OpenStack metadata server and parses </del> <ins> // parseMetadata reads JSON from OpenStack metadata server and parses </ins> // instance ID out of it. func parseMetadata(r io.Reader) (*Metadata, error) { var metadata Metadata

Related discussion:
text: For example, the sentence "I don't have any of those books"; I'd interpret it as "I have no book; I don't have book-a, don't have book-b... don't have book-z". On the other hand, the sentence "If any of the following conditions are not true, the alert is triggered", I'd interpret it as "if condition-a and b is true, but condition-c isn't true, the alert is triggered". I interpreted the topology spread's doc like the second one; if any of topologySpreadConstraints[].topologyKey aren't in the Node's label, the node is bypassed. I'm not sure which interpretation is natural for the native speakers (looks like ChatGPT has the same interpretation as me though), but at least we can say it's ambiguous. I guess it'd be clearer if we rephrase it to, for example, "The scheduler bypasses any nodes that is missing at least of of the required topologySpreadConstraints[].topologyKey in its label.". Feel free to raise a PR. /remove-kind bug /kind documentation
I agree that the sentence is a little ambiguous. But this is not a bug in the code. The implementation matches the original intent of the design. I suggest opening a bug in /website so that SIG Docs can advise on better wording.
/close
Closing this issue. <detailsIn response to : /close 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
Thanks for your swift response! We chose to post this here because we were unsure about the expected behavior and wanted to hear developers' opinions. Now that we have clarity, so we will open a bug issue in the /website.
Code change:
return framework.RunKubectl("exec", fmt.Sprintf("--namespace=%s", pod.Namespace), pod.Name, "--", "/bin/sh", "-c", bashExec) } <ins> // VerifyExecInPodSucceed verifies bash cmd in target pod succeed func VerifyExecInPodSucceed(pod *v1.Pod, bashExec string) { _, err := PodExec(pod, bashExec) if err != nil { if err, ok := err.(uexec.CodeExitError); ok { exitCode := err.ExitStatus() Expect(err).NotTo(HaveOccurred(), "%q should succeed, but failed with exit code %d and error message %q", bashExec, exitCode, err) } else { Expect(err).NotTo(HaveOccurred(), "%q should succeed, but failed with error message %q", bashExec, err) } } } // VerifyExecInPodFail verifies bash cmd in target pod fail with certain exit code func VerifyExecInPodFail(pod *v1.Pod, bashExec string, exitCode int) { _, err := PodExec(pod, bashExec) if err != nil { if err, ok := err.(uexec.CodeExitError); ok { actualExitCode := err.ExitStatus() Expect(actualExitCode).To(Equal(exitCode), "%q should fail with exit code %d, but failed with exit code %d and error message %q", bashExec, exitCode, actualExitCode, err) } else { Expect(err).NotTo(HaveOccurred(), "%q should fail with exit code %d, but failed with error message %q", bashExec, exitCode, err) } } Expect(err).To(HaveOccurred(), "%q should fail with exit code %d, but exit without error", bashExec, exitCode) } </ins> // KubeletCommand performs `start`, `restart`, or `stop` on the kubelet running on the node of the target pod and waits // for the desired statues.. // - First issues the command via `systemctl`

Related discussion:
text: It would better to have e2e for iSCSI persistent volume. /sig storage
/assign
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
return result, nil } if resourceVersion < oldest { <del> return nil, errors.NewInternalError(fmt.Errorf("too old resource version: %d (%d)", resourceVersion, oldest)) </del> <ins> return nil, errors.NewGone(fmt.Sprintf("too old resource version: %d (%d)", resourceVersion, oldest)) </ins> } // Binary seatch the smallest index at which resourceVersion is not smaller than

Related discussion:
text: We sorta fixed this-- now it's a real status error, but we left the status code 500, so it still produces stack traces and potentially confuses clients. we should figure out the correct status code.
I think there is a lot more going on related to this in . Clients are re-listing after the error but not rewatching.
/sub
It turned out this was not causing job e2e flakes. Just sending 500s that were confusing. So lowering priority.
How about a NewBadRequest error?
that certainly sounds like an improvement.
Code change:
} if err := d.writeCachedFile(filename, liveResources); err != nil { <del> glog.V(3).Infof("failed to write cache to %v due to %v", filename, err) </del> <ins> glog.V(1).Infof("failed to write cache to %v due to %v", filename, err) </ins> } return liveResources, nil

Related discussion:
text: /kind bug What happened: kubectl became very slow, taking 30s to list pods etc. After going deep down the rabbit hole of debugging the controller components, I ran kubectl -v=8 which showed: What you expected to happen: Since caching is required for kubectl to respond in reasonable time and the issue isn't obvious, kubectl should at least print warnings in default log level. How to reproduce it (as minimally and precisely as possible): I got into the situation by running kubectl with sudo, but just chown'ing should be enough to reproduce this. Anything else we need to know?: Environment: kubectl v1.8.3
/sig cli
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 /lifecycle freeze
Code change:
cd /go/src/k8s.io/kubernetes # hack/verify-client-go.sh requires all dependencies exist in the GOPATH. <del> godep restore </del> <ins> # the retry helps avoid flakes while keeping total time bounded. godep restore || godep restore </ins> ./hack/install-etcd.sh make verify

Related discussion:
text: Seen in issue Logs from : At the very least, we should retry godep restore a couple times given the heavy network dependencies it has. The network dependencies are sorta necessary... but they change rarely so we could also do some clever caching of unmodified clones that we put in place ahead of time to dodge network traffic outside of new deps being . cc
We could probably do a single retry and avoid most flakes. Godep restore takes a long time though, so if we retry too many times we'll run into timeout issues (but maybe that's fine). See also , tools/godep
Actually, it looks like this is only being done for an excluded verify step (). We should not do this for an excluded step, and we should not do for every PR.
can you explain why staging/ needs to function?
verify- also runs :
eventually gets published to . IIRC, it needs because otherwise a later fails ().
If we can run the verify script in order, then we can run verify-staging-client- after verify-, then we can save one .
verify- exits out early if Godeps/ or vendor/ hasn't changed.
Hmm, ok. How often will fail?
I'm seeing ~.5% failure rate over the last few days, and averaging ~2 minutes for the godep restore. Do we have to check in _vendor for the staging client code at all?
We run to find all the dependencies of clients, including k8s packages, so _vendor is not the reason we need .
Code change:
computealpha "google.golang.org/api/compute/v0.alpha" computebeta "google.golang.org/api/compute/v0.beta" computev1 "google.golang.org/api/compute/v1" <ins> "k8s.io/kubernetes/pkg/cloudprovider" </ins> ) func TestReadConfigFile(t *testing.T) {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: As part of the initiative for external cloud providers (), we GetZoneByProviderID and GetZoneByNodeName. See for more details. The previous PR did not actually implement those methods for existing cloud providers in . These methods should be implemented by all cloud providers in the future. cc
Could someone add the label and the label for this issue please?
/sig cluster-lifecycle
/area cloudprovider
/assign wlan0
cc We need the following label - help-wanted and add it to the 1.8(?) milestone cc to implement it for their respective clouds.
I'll try to have a look by the end of the week.
Ok, I will take care of the Rackspace and OpenStack.
Thank you !
- Is there any listing where to see the already implemented cloud provider ?
No providers have this yet. Current PRs: Openstack: Rackspace: Please contribute if you have something ready :)
Sorry for the delay guys :)
Have you implemented them for gce?
Intending to work on it tonight, but if you have something I can work on azure
Yes, I have prepared for GCE.
Azure .
Cool, than you all! Any other providers we should implement this for in time for v1.8?
I'll take a look tomorrow to see if there's something left
Let's see which providers are left before closing this...
- I guess this one should be closed ?
If you say that all providers have this now, thanks, great!