jiebi/CodeConvo huggingface dataset:
Code change:
defer logs.FlushLogs() if err := command.Execute(); err != nil { <del> fmt.Fprintf(os.Stderr, "%vn", err) </del> os.Exit(1) } }

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: kubectl version --client=yes command is giving the following error message. Error message is repeated at the start and the end and also containing programming jargon Error: invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax What you expected to happen: The error message can be improved with one of the two variants invalid argument "yes" for "--client" flag Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). (or) Invalid argument "yes" for "--client" flag How to reproduce it (as minimally and precisely as possible): Run the command kubectl version --client=yes Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: AWS OS (e.g: ): Amazon Linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli
Hi Thanks for posting this issue! It turns out that this duplicate output has been in kubectl, and all the other cli cmds, since . This should be fixed by , and hopefully we can cherry pick it back to at least .
Code change:
} } <ins> // BindOverrideFlags is a convenience method to bind the specified flags to their associated variables func BindOverrideFlags(overrides *ConfigOverrides, flags *pflag.FlagSet, flagNames ConfigOverrideFlags) { BindAuthInfoFlags(&overrides.AuthInfo, flags, flagNames.AuthOverrideFlags) BindClusterFlags(&overrides.ClusterInfo, flags, flagNames.ClusterOverrideFlags) BindContextFlags(&overrides.Context, flags, flagNames.ContextOverrideFlags) flagNames.CurrentContext.BindStringFlag(flags, &overrides.CurrentContext) flagNames.Timeout.BindStringFlag(flags, &overrides.Timeout) } </ins> // BindAuthInfoFlags is a convenience method to bind the specified flags to their associated variables func BindAuthInfoFlags(authInfo *clientcmdapi.AuthInfo, flags *pflag.FlagSet, flagNames AuthOverrideFlags) { flagNames.ClientCertificate.BindStringFlag(flags, &authInfo.ClientCertificate)

Related discussion:
text: Found in openshift, but I'm pretty sure the codepaths are the same. That means the token is getting ignored and in-cluster config is being used in preference to flags.
Is a similar issue?
Yep, kind of regression.
Sigh.
Yes, most likely the same cause.
I'm on it.
Unit test :)
Probably will want to cherrypick this into 1.5.
WIP in
Code change:
<ins> apiVersion: v1beta3 kind: ResourceQuota metadata: name: quota spec: hard: cpu: "20" memory: 1Gi persistentvolumeclaims: "10" pods: "10" replicationcontrollers: "20" resourcequotas: "1" secrets: "10" services: "5" </ins>

Related discussion:
text: Resource quota example is missing readme. Was it once there and was accidentally deleted?
I wrote something up in Origin repo I need to repurpose for Kubernetes. Sent from my iPhone
Code change:
"github.com/golang/glog" "k8s.io/apimachinery/pkg/types" <del> "k8s.io/kubernetes/pkg/cloudprovider" </del> ) // AttachDisk attaches a vhd to vm

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: VirtualMachineScaleSetVM and VirtualMachine are different data structures (because of different API versions), so the disk attach operation seems duplicate between vm and vmss. That means although disk operations are in same logic, some duplication are still required now. They should use same api version in the future and should be merged into same code base, e.g. move sharing logic to Refer What you expected to happen: vmss and vm disk operations should share same code logic. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I have checked with currently we can’t merge, e.g. following two structs are different since they using different sdk-for-azure versions. While in the end when sdk-for-azure version is upgraded, above two versions should be same and at that time, we should merge functions like ‘AttachDisk’, ‘DetachDiskByName’, 'GetDiskLun', GetNextDiskLun, DisksAreAttached
Code change:
[[projects]] <del> name = "github.com/json-iterator/go" packages = ["."] revision = "ca39e5af3ece67bbcda3d0f4f56a8e24d9f2dad4" version = "1.1.3" [[projects]] </del> name = "github.com/modern-go/concurrent" packages = ["."] revision = "e0a39a4cb4216ea8db28e22a69f4ec25610d513a"

Related discussion:
text: is a library yet is is instead of release tag. Please consider vendoring by tag whenever possible. Thanks.
We vendored it that way because the commit that fixed a bug (which we needed to be fixed and vendored back in) was This was merged on June 13. The release 1.1.4 () was released on July 1. If we want to update it to 1.1.4, I believe it should be fine. Between the commit we have vendored right now and the latest release, there are only three commits: adds tests merges (?) the case-sensitive fix - I'm not really sure what this commit is doing. fixes renaming when naming strategy is set (looks fine). Also, there are also no licensing changes. opinions?
/sig api-machinery
+1 to what said, it was a fire drill and 1.11.0 release was in trouble. Though in hind sight, we should have opened a issue to track that. something better to do next time. cc
I'm indifferent to updating this. I'm okay with moving up if it doesn't break anything, or I'm fine with leaving things as is. We don't require deps to match semver. We can version out any commit in a deps tree, as we rely on our vendored copy.
It is always a good idea to match semver and it should be a default policy. Even if it doesn't matter to you, it should, because it is a best practice. Moreover downstream it matters much more as dependencies may be un-vendored in favour of tested re-usable packages.
/cc
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
Someone please take care of this or bot will eventually close this valid issue without action...
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 .
Code change:
[[projects]] <del> name = "github.com/json-iterator/go" packages = ["."] revision = "ca39e5af3ece67bbcda3d0f4f56a8e24d9f2dad4" version = "1.1.3" [[projects]] </del> name = "github.com/modern-go/concurrent" packages = ["."] revision = "e0a39a4cb4216ea8db28e22a69f4ec25610d513a"

Related discussion:
text: /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.
Code change:
# TODO: This timeout should really be lower, this is a *long* time to test one # package, however pkg/api/testing in particular will fail with a lower timeout # currently. We should attempt to lower this over time. <del> KUBE_TIMEOUT=${KUBE_TIMEOUT:--timeout=170s} </del> <ins> KUBE_TIMEOUT=${KUBE_TIMEOUT:--timeout=180s} </ins> KUBE_COVER=${KUBE_COVER:-n} # set to 'y' to enable coverage collection KUBE_COVERMODE=${KUBE_COVERMODE:-atomic} # The directory to save test coverage reports to, if generating them. If unset,

Related discussion:
text: /kind failing-test Not sure if flake. Gubernator is showing a big spike in failures that started 06/14 around 10:00 ~UTC~ PT. This seems to be when merged. Failed on my PR: /sig testing
/sig api-machinery
/cc
filed I'm hesistant to bump it all the way back to 240, if you follow back the original PR / issue trail I ran a number of iterations of testing and it really shouldn't take 240s. four minutes is ludicrous for unit testing one package.
there are 39 failures in the last day in from timeout :/ /priority critical-urgent
Did any timed-out run produce any logs?
we capture the test logs but itself doesn't appear to have any.
e.g. at random (from triage above) ="raw build-" I'm not sure this code emits any when it fails.
Likely it's timing out on some step, but I would have expected some logging from something related -- I was just going to look at the last thing logged and figure that something after that must be the culprit. Does that log capture stderr and stdout of the test invocations?
it should, e.g. see a different kind of failure with logs: we're running with json output formatting then through to junit, and prow will capture stdout/stderr of whatever is running within the job as build-
reopening to keep an eye on this.
sigh: 180s
it's doing better (all recent runs passed, looks like 3 flakes due to this since the PR merged this afternoon) but we may still want to bump it again
We're at 100% pass rate the past 3 hours but CI is not very active right now. still just 3 fails. If we have a similar rate tomorrow morning I'd opt for another small bump (maybe 180s -190s) to cover remaining limited flakes still over going all the way back to 4 minutes.
If we knew which sub test was slow when it is slow, that would possibly narrow it down to a haystack small enough to look for needles in.
dug into it locally, follow up in:
Fairly confident this is now fixed after
closing as fixed by
confirmed
example:
that run happened at the fix merged at
Code change:
case "$tree" in w/-text) # Only binary files have a size limit. <del> size="$(stat --printf=%s "$file")" </del> <ins> size="$(wc -c < "$file")" </ins> if [ "${size}" -gt "$maxsize" ] && ! kube::util::array_contains "$file" "${allowlist[@]}"; then echo    "$file is too large ($size bytes)"

Related discussion:
text: The script encounters an error when executed on Mac OS X because the option is not supported. The error message appears as follows: I expected the script to execute successfully. Execute the command on macOS. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing
/triage accepted
/priority backlog
Code change:
HostIP: "1.2.3.4", }, }, false}, <ins> {api.Node{ ObjectMeta: api.ObjectMeta{ Name:   "foo", Labels: map[string]string{"bar": "foo"}, }, Status: api.NodeStatus{ HostIP: "1.2.3.4", }, }, api.Node{ ObjectMeta: api.ObjectMeta{ Name:   "foo", Labels: map[string]string{"bar": "fooobaz"}, }, }, true}, </ins> } for _, test := range tests { errs := ValidateMinionUpdate(&test.oldMinion, &test.minion)

Related discussion:
text: Two problems: on node do not have namepace, but kubectl requires namespace. However, if explicitly set namespace to 'default', this will cause an error because we are updating not allowed field (only label update is allowed). is usually created by node controller, update node label with a file is tedious since user needs to create a file with id, resource.capacity, etc. can we make it easier?
It would make more sense to have a special global namespace than no namespace. We should make it easy in kubectl to update a single field or subset of fields, generally, for all objects. What this would do is GET, merge, and PUT.
I had a discussion with on IRC about namespace on node. We'd like to just use "" (empty string) as of now. As we are not supporting any namespace feature on node, it's less confusing if we can hide the concept for now. Thinking a little more, "" is the special global namespace. I'm going to update kubectl to not assume 'default' namespace on every resources. It works fine for pod, service, but not for node, external LB, etc.
There was some discussion about "" being (essentially) an alias to "default": is that dead? , Deyuan Deng wrote:
I've seen two versions of NamespaceALL ("") NamespaceAll is the default argument to specify on a context when you want to list or filter resources across An empty namespace is equivalent to the , but "default" is the canonical representation. Either means , or the definition conflicts - all namespace should include "default" namespace. Also, for things like Node, I'd really like a NamespaceNone.
- I think there is a confusion here because of a poor naming choice. is a constant intended to be used as a filter to LIST/WATCH across multiple namespaces. It is NOT intended to be the value that is set on a resource for persistence. The discussion was to update to which I think is still a good thing to do. I have held off doing that until after we embed the namespace as a path parameter in our URLs instead of a query parameter, which I plan to look at after the holidays. is a constant intended to be used as the namespace context of a request when it's not explicitly stated on a request URL.
Code change:
HostIP: "1.2.3.4", }, }, false}, <ins> {api.Node{ ObjectMeta: api.ObjectMeta{ Name:   "foo", Labels: map[string]string{"bar": "foo"}, }, Status: api.NodeStatus{ HostIP: "1.2.3.4", }, }, api.Node{ ObjectMeta: api.ObjectMeta{ Name:   "foo", Labels: map[string]string{"bar": "fooobaz"}, }, }, true}, </ins> } for _, test := range tests { errs := ValidateMinionUpdate(&test.oldMinion, &test.minion)

Related discussion:
text: Since create operations pull the namespace from the context during persistence, it is also the value intended to be persisted. This is referring to a request URL that does not specify a namespace. It is not referring to the persisted value in the database directly - although that is the value that gets pulled. I think a is a good thing to add AFTER we make the change to specify namespace as a path parameter instead of a query parameter, and we update/rename to something that clarifies that its a wild-card filter whose value is probably best represented as.
ok, sounds good. Thanks. Look forward to see api.NamespaceAll = "*" and api.NamespaceNone :)
Code change:
for _, l := range strings.Split(string(f.Lines), "n") { if strings.Contains(l, fmt.Sprintf("-A %v", chainName)) { newRule := Rule(map[string]string{}) <del> for _, arg := range []string{Destination, Source, DPort, Protocol, Jump, ToDest, Recent} { </del> <ins> for _, arg := range []string{Destination, Source, DPort, Protocol, Jump, ToDest, Recent, MatchSet} { </ins> tok := getToken(l, arg) if tok != "" { newRule[arg] = tok

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Service loadbalancer source range don't work in ipvs proxy mode. Which result in gci-gce-ipvs CI failed. http://k8s- How to reproduce it (as minimally and precisely as possible): In gce environment. a service with backend. service type to service util service external IP is specified. the service from pod inside and pod out of the . Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: gce OS (e.g. from /etc/os-release): ubuntu Kernel (e.g. ): Install tools: cluster/kube- Others:
/kind bug /sig network /label ipvs
/area ipvs
The test seems to be flaky now. Can you take a look please?
I don't know why, but I think this flaky have the similiar reason with other normal service-test cases, like Those flaky are pretty annoying, problem is, I have run those cases in my own environment many times, never fail... : ( But still, I'll do my best to find the reason.
Code change:
# machines) we have to talk directly to the container IP.  There is no one # strategy that works in all cases so we test to figure out which situation we # are in. <del> if kube::build::probe_address 127.0.0.1 ${mapped_port}; then </del> <ins> if kube::build::rsync_probe 127.0.0.1 ${mapped_port}; then </ins> KUBE_RSYNC_ADDR="127.0.0.1:${mapped_port}" <del> sleep 0.5 </del> return 0 <del> elif kube::build::probe_address "${container_ip}" ${KUBE_CONTAINER_RSYNC_PORT}; then </del> <ins> elif kube::build::rsync_probe "${container_ip}" ${KUBE_CONTAINER_RSYNC_PORT}; then </ins> KUBE_RSYNC_ADDR="${container_ip}:${KUBE_CONTAINER_RSYNC_PORT}" <del> sleep 0.5 </del> return 0 fi

Related discussion:
text: https://k8s-
I have a similar problem when I try to make release on my local desktop:
Related to .
Similar problem for :
Can you open a new issue for your problem with information about your set up. Mac/Linux? Docker version? etc.
Please add details to (to be opened) issue. I suspect that is a different issue.
New issue:
Code change:
<del> apiVersion: v1 kind: ReplicationController metadata: name: es-master labels: component: elasticsearch role: master spec: replicas: 1 template: metadata: labels: component: elasticsearch role: master spec: serviceAccount: elasticsearch containers: - name: es-master securityContext: capabilities: add: - IPC_LOCK image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4 env: - name: KUBERNETES_CA_CERTIFICATE_FILE value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: "CLUSTER_NAME" value: "myesdb" - name: NODE_MASTER value: "true" - name: NODE_DATA value: "false" - name: HTTP_ENABLE value: "false" ports: - containerPort: 9300 name: transport protocol: TCP volumeMounts: - mountPath: /data name: storage volumes: - name: storage emptyDir: {} </del>

Related discussion:
text: Presently, the elasticsearch example Kubernetes configurations target elasticsearch v1.7.1, which is quite old. As of this writing, the latest elasticsearch release is v5.6.2, with many deployment changes since then. Could the elasticsearch examples be updated to target the v5 series of elasticsearch? See for a more up to date reference configuration.
cc
hey it's been a long while since I last contributed to the docs. i can do it soon but i need pointers on how to properly do it.
hey, so we need to update the stuff under examples/elasticsearch/ *&repos=kubernetes So basically update the images, yaml files etc and test that everything works (and submit a PR)
/sig testing
Ah, so there's no documentation updates anymore. OK I'll take care of it, assign it to me.
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
GitHub didn't allow me to assign the following users: me. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign me 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 pires
/remove-lifecycle stale
it seems that the example moved to I am now reading that repo guidelines and will update this there. I'll also open a PR that cleans this folder in the current repo and closes this issue.
Code change:
allErrs = append(allErrs, field.Invalid(fldPath.Child("SyncPeriod"), config.MinSyncPeriod, fmt.Sprintf("must be greater than or equal to %s", fldPath.Child("MinSyncPeriod").String()))) } <ins> allErrs = append(allErrs, validateIPVSTimeout(config, fldPath)...) </ins> allErrs = append(allErrs, validateIPVSSchedulerMethod(kubeproxyconfig.IPVSSchedulerMethod(config.Scheduler), fldPath.Child("Scheduler"))...) allErrs = append(allErrs, validateIPVSExcludeCIDRs(config.ExcludeCIDRs, fldPath.Child("ExcludeCidrs"))...)

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: kube-proxy doesn't validate the configurable IPVS tcp, tcpfin and udp timeouts. For example, when kube-proxy starts with , it will always log a warning: . What you expected to happen: kube-proxy should validate --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout flag values at start. How to reproduce it (as minimally and precisely as possible): add flags to kube-proxy 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:
/sig network /area ipvs
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Code change:
import ( "errors" "fmt" <del> "k8s.io/klog" </del> "path" "strconv" "strings" <ins> "k8s.io/klog" </ins> ) // FindMultipathDeviceForDevice given a device name like /dev/sdx, find the devicemapper parent

Related discussion:
text: If one target in multipath volume gets down and a pod that uses the volume is deleted and quickly recreated (e.g. by a Deployment), the new pod never starts. How to reproduce it (as minimally and precisely as possible): Deployment with single replica with one multipath iSCSI volume one target (e.g. switch the machine off). Multipath will mark appropriate path as failed: the deployment pod. will quickly start a new pod for the Deployment. new pod will be (or ) forever, What happened: Kubelet tries to WaitForAttach / SetUp volume for the new pod. The volume is still attached. Kubelet goes through all targets and tries to find out if it's logged in or not. Eventually it tries to read of the failed path and that returns error: What you expected to happen: Kubelet assumes that the path is failed / not logged in and tries to recover it. If it fails it continues with multipath with 2 available devices and 1 failed one. IMO, simple instead of will do its job just fine. /assign /sig storage cc for iSCSI expertise
Fix:
Code change:
"net/http" "net/url" gpath "path" <ins> "strings" </ins> "time" "k8s.io/kubernetes/pkg/admission"

Related discussion:
text: Given a request with a Content-Type header set to , the server will respond with an error because it does not exactly match the existing strings. Some browsers (Firefox, see: ) will automatically add to a Content-Type header when making an XHR request.