jiebi/CodeConvo huggingface dataset:
Code change:
"//staging/src/k8s.io/cli-runtime/pkg/genericclioptions/resource:go_default_library", "//staging/src/k8s.io/client-go/dynamic:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/typed/batch/v1:go_default_library", <ins> "//staging/src/k8s.io/client-go/kubernetes/typed/batch/v1beta1:go_default_library", </ins> "//staging/src/k8s.io/client-go/kubernetes/typed/rbac/v1:go_default_library", "//vendor/github.com/spf13/cobra:go_default_library", "//vendor/k8s.io/klog:go_default_library",

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Why is this needed: Because of is not recommended to create cronjob (with flags) anymore. But there is no imperative command available for to create cronjob. /sig CLI <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
GitHub didn't allow me to assign the following users: Pingan2017. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign 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 wanna work on this. give me several days
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
Code change:
} func gRPCServerPodSpec(readinessProbe, livenessProbe *v1.Probe, containerName string) *v1.Pod { <del> etcdLocalhostAddress := "127.0.0.1" if framework.TestContext.ClusterIsIPv6() { etcdLocalhostAddress = "::1" } etcdURL := fmt.Sprintf("http://%s", net.JoinHostPort(etcdLocalhostAddress, "2379")) </del> return &v1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "test-grpc-" + string(uuid.NewUUID())}, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:  containerName, <del> Image: imageutils.GetE2EImage(imageutils.Etcd), </del> <ins> Image: imageutils.GetE2EImage(imageutils.Agnhost), </ins> Command: []string{ <del> "/usr/local/bin/etcd", "--listen-client-urls", "http://0.0.0.0:2379", //should listen on all addresses "--advertise-client-urls", etcdURL, </del> <ins> "/agnhost", "grpc-health-checking", </ins> }, <del> // 2380 is an automatic peer URL Ports:          []v1.ContainerPort{{ContainerPort: int32(2379)}, {ContainerPort: int32(2380)}}, </del> <ins> Ports:          []v1.ContainerPort{{ContainerPort: int32(5000)}, {ContainerPort: int32(8080)}}, </ins> LivenessProbe:  livenessProbe, ReadinessProbe: readinessProbe, },

Related discussion:
text: Also pass proper parameters to agnhost to enable gRPC endpoint, change ports, and run tests to ensure that this worked.
Thanks for your reply! Will let you know if I have more questions as I work
/assign
/assign
Code change:
expectedCondition       *batch.JobConditionType expectedConditionReason string }{ <ins> "backoffLimit 0 should have 1 pod active": { 1, 1, 0, true, []int32{0}, 1, 0, 0, nil, "", }, "backoffLimit 1 with restartCount 0 should have 1 pod active": { 1, 1, 1, true, []int32{0}, 1, 0, 0, nil, "", }, "backoffLimit 1 with restartCount 1 should have 0 pod active": { 1, 1, 1, true, []int32{1}, 0, 0, 1, &jobConditionFailed, "BackoffLimitExceeded", }, </ins> "too many job failures - single pod": { 1, 5, 2, true, []int32{2},

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: If you have a JobSpec and set with in 1.9.x, then the job will start a pod and never restart it regardless of success of failure. In 1.10.x, a job spec with and , k8s does not start any pods at all. We had to set in order to get the pod to run. The wording in the docs suggest that should only take effect when the pod is finished/or failed. It shouldn't cap starting the initial pod. How to reproduce it (as minimally and precisely as possible): Run the following job spec in 1.9.x and 1.10.x: Anything else we need to know?: The docs links this existing ticket saying is ineffective with , but the ticket talks about restarting too many times, not never starting a pod. Given this issue was slightly different, I originally did not think it was a backoffPolicy bug. Environment: Kubernetes version (use ): Tested on 1.9.7 and 1.10.6 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Fedora 28
/sig apps
We've been hit by this too, in v1.10.6. It seems to me that with the current behavior, a value of doesn't really make any semantic sense. I think the problem comes from the function in : called here: if is , then will end with .
Code change:
f.BindFlags(cmds.PersistentFlags()) f.BindExternalFlags(cmds.PersistentFlags()) <ins> cmds.SetHelpCommand(NewCmdHelp(f, out)) </ins> // From this point and forward we get warnings on flags that contain "_" separators cmds.SetGlobalNormalizationFunc(flag.WarnWordSepNormalizeFunc)

Related discussion:
text: It'd be similar to Linux , a command to search the man page files
Why not just make do a search if it doesn't have an exact match?
sounds good.
SGTM
- Can be useful in this issue
I will work on this issue, if nobody is already working on it ( is not working on it).
thanks!
I focused currently on a bit different stuff, sorry. So I will start/finish it later. If anyone want to take over this one, feel free for now.
Code change:
} // markAsDeleting sets the obj's DeletionGracePeriodSeconds to 0, and sets the <del> // DeletionTimestamp to "now". Finalizers are watching for such updates and will </del> <ins> // DeletionTimestamp to "now" if there is no existing deletionTimestamp or if the existing // deletionTimestamp is further in future. Finalizers are watching for such updates and will </ins> // finalize the object if their IDs are present in the object's Finalizers list. <del> func markAsDeleting(obj runtime.Object) (err error) { </del> <ins> func markAsDeleting(obj runtime.Object, now time.Time) (err error) { </ins> objectMeta, kerr := meta.Accessor(obj) if kerr != nil { return kerr } <del> now := metav1.NewTime(time.Now()) </del> // This handles Generation bump for resources that don't support graceful // deletion. For resources that support graceful deletion is handle in // pkg/api/rest/delete.go if objectMeta.GetDeletionTimestamp() == nil && objectMeta.GetGeneration() > 0 { objectMeta.SetGeneration(objectMeta.GetGeneration() + 1) } <del> objectMeta.SetDeletionTimestamp(&now) </del> <ins> existingDeletionTimestamp := objectMeta.GetDeletionTimestamp() if existingDeletionTimestamp == nil || existingDeletionTimestamp.After(now) { metaNow := metav1.NewTime(now) objectMeta.SetDeletionTimestamp(&metaNow) } </ins> var zero int64 = 0 objectMeta.SetDeletionGracePeriodSeconds(&zero) return nil

Related discussion:
text: What happened: a custom resource defintion a namespace a custom resource in the namespace with a finalizer attached the namespace custom resource in the namespace will get its deletionTimestamp field updated about every 8 seconds. What you expected to happen: The resource would have the deletionTimestamp set once then not be updated again. This becomes a hassle if a controller needs to perform an operation that takes longer than the update period as it will need to perform a read-modify-write with retry loop when removing the finalizer. How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE 1.11
/sig api-machinery
/area custom-resources deletionTimestamps should not update even if subsequent deletion requests are made
/assign
as this description: if object has pending finalizers, the deletionTimestamps should be updated. Do we need to change this logic ?
deletionTimestamp is supposed to be immutable: storage modifying that timestamp is unexpected, at least to me
we should at least ensure that this documentation is honored:
opened to do that
Code change:
</g> <g> <path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 934.594 747.007 C 928,762 804,738 797.63,754.926"/> <del> <polygon style="fill: #000000" points="939.171,749.02 938.62,737.853 930.017,744.994 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="939.171,749.02 938.62,737.853 930.017,744.994 "/> </del> <ins> <polygon style="fill: #000000" points="939.171,749.02 938.619,737.853 930.017,744.994 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="939.171,749.02 938.619,737.853 930.017,744.994 "/> </ins> <polygon style="fill: #000000" points="794.988,761.945 793.831,750.825 797.63,754.926 803.19,754.347 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="794.988,761.945 793.831,750.825 797.63,754.926 803.19,754.347 "/> </g> <g> <path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 974.333 745.616 C 998,776 1131,714 1154.77,755.585"/> <del> <polygon style="fill: #000000" points="978.277,742.543 968.188,737.727 970.388,748.689 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="978.277,742.543 968.188,737.727 970.388,748.689 "/> </del> <ins> <polygon style="fill: #000000" points="978.278,742.544 968.188,737.727 970.389,748.689 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="978.278,742.544 968.188,737.727 970.389,748.689 "/> </ins> <polygon style="fill: #000000" points="1158.49,762.097 1149.19,755.896 1154.77,755.585 1157.87,750.934 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="1158.49,762.097 1149.19,755.896 1154.77,755.585 1157.87,750.934 "/> </g>

Related discussion:
text: Architecture picture: says kubecfg is deprecated. The architecture picture should be updated to show kubectl instead of kubecfg.
ref /cc
Code change:
Verb:     "get", Resource: schema.GroupVersionResource{Resource: "resource"}, } <del> c.Invokes(action, nil) </del> <ins> if _, err = c.Invokes(action, nil); err != nil { return resultGroups, c.Resources, err } </ins> return resultGroups, c.Resources, nil }

Related discussion:
text: I'm writing a UT for the following function: The code branch where the server returns an error other than could not be tested using 's . This is because does not handle the error returned by and therefore could not return errors other than : Ref: Add a to so simulate errors other than . Run the following UT (should fail):
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
Same issue for some other methods of : -
I'll submit a PR shortly to address this issue. /assign
Code change:
} csiAttacher := attacher.(*csiAttacher) <del> go func(spec *volume.Spec, id, nodename string, fail bool) { </del> <ins> go func(spec *volume.Spec, nodename string, fail bool) { </ins> attachID, err := csiAttacher.Attach(spec, types.NodeName(nodename)) if fail != (err != nil) { t.Errorf("expecting no failure, but got err: %v", err) } <del> if attachID != id && !fail { t.Errorf("expecting attachID %v, got %v", id, attachID) </del> <ins> if attachID != "" { t.Errorf("expecting empty attachID, got %v", attachID) </ins> } <del> }(tc.spec, tc.attachID, tc.nodeName, tc.shouldFail) </del> <ins> }(tc.spec, tc.nodeName, tc.shouldFail) </ins> var status storage.VolumeAttachmentStatus if tc.injectAttacherError {

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!--What happened: Followup to In 1.15, we can merge this commit: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/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
/remove-lifecycle stale
Code change:
github.com/mitchellh/go-homedir => github.com/mitchellh/go-homedir v1.1.0 github.com/mitchellh/go-wordwrap => github.com/mitchellh/go-wordwrap v1.0.0 github.com/mitchellh/mapstructure => github.com/mitchellh/mapstructure v1.1.2 <del> github.com/moby/ipvs => github.com/moby/ipvs v1.0.0 </del> <ins> github.com/moby/ipvs => github.com/moby/ipvs v1.0.1 </ins> github.com/moby/term => github.com/moby/term v0.0.0-20200312100748-672ec06f55cd github.com/modern-go/concurrent => github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd github.com/modern-go/reflect2 => github.com/modern-go/reflect2 v1.0.1

Related discussion:
text: Hi, Since my upgrade to 1.18 version, I have errors in kube-proxy: I have ipv4/ipv6 dualstack enable. No problem with cluster and IPVS works despite errors. Do you have also this issue ? OS: RHEL7 Kubernetes version (use ):
/sig network
Related to cc
/cc
Taking one of the outputs it gives me the following addresses? can you share more details about your environment, Is it possible that the CoreDNS pod has the address ? what are your cluster-cidr and service-cidr? Indeed that new net.Utils change looks suspicious , a quick grep in the repo gives me some suspects, maybe the service/ipallocator? It's important to mention there were similar issues with IPVS before, interpreting IPv4 addresses as IPv6, has some experience with this kind of issues, maybe he can see something:) /cc
A bit tricky to trace since libnetwork/ipvs is moving around at the moment. Problem seems to be in; The "family" must be wrong. It is called from;
Please do a and attach the output.
Hi, Some informations: cluster-cidr and service-cidr: fd00:10:245:0:0:0:0:0/64,10.245.0.0/16 fd00:10:96:0:0:0:0:0/112,10.96.0.0/12 ipvsadm output:
Ref:
The commit in the ref above should be in v1.18.0 which is the version used in this issue. So the commit does not fix the problem.
Maybe something wrong around here Before , it looks like this: Now it looks like this: However is not initializedit is zero :(.
I do not get these faults. Has the netlink API changed? What kernel version are you using?
d.AddressFamily is supposed to be set from the "NetlinkRouteAttr" slice; It should definitely not be hard-coded to ipv4.
Made a trying to reproduce this in my environment but didn't got this error.
Code change:
github.com/mitchellh/go-homedir => github.com/mitchellh/go-homedir v1.1.0 github.com/mitchellh/go-wordwrap => github.com/mitchellh/go-wordwrap v1.0.0 github.com/mitchellh/mapstructure => github.com/mitchellh/mapstructure v1.1.2 <del> github.com/moby/ipvs => github.com/moby/ipvs v1.0.0 </del> <ins> github.com/moby/ipvs => github.com/moby/ipvs v1.0.1 </ins> github.com/moby/term => github.com/moby/term v0.0.0-20200312100748-672ec06f55cd github.com/modern-go/concurrent => github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd github.com/modern-go/reflect2 => github.com/modern-go/reflect2 v1.0.1

Related discussion:
text: I may try this on some older kernel like from CentOS 7 Added exactly the same IPVS configuration here: And when running this 'gist/program' pointing to the IPVS from the DNS (fd00:10:96::a port 53 UDP) got the expected result: Maybe trying to run this also in some other scenarios could clarify if this is something related to Netlink API changed between Kernels, something with the used library, etc.
After some study, I find that this issue most likely is caused by the low linux kernel version. I have reproduced this problem on . Accroding to the code, netlink will try to get attribute, but I find the kernel just does not support it :( This is the defined in (kernel 3.10) No attribute is defined! But in new kernel version, the is defined like : Obviously, the kernel has some attributes (IPVSDESTATTRADDRFAMILY, IPVSDESTATTRSTATS64...). That is why kube-proxy works well on systems with a higher version of the kernel. So we can address this issue by upgrading our linux kernel. Not sure which kernel version is the minimum requirement, maybe we should document something about this.
Here is the defined in :
Good finding. So, we can conclude that this really is kernel version dependent. It is hard to know what to do about it. We must check the family. I would propose that we make it work for ipv4 with some fallback and put a requirement on kernel version for ipv6-only/dual-stack. But the decision is others to make. /cc
/cc
The symbol in the kernel tree The for service family seems very old. Since the service must have the same family as the real-servers perhaps it can be used for compatibility with old kernels?
The commit that adds the symbol; Seem to go into linux-3.18
I did not know the minimum required for the kernel version, I was using the stable and official version of RHEL7. My kernel version is: Currently the max version in the repository is: According to the documentation (), I should switch to RHEL8 if I want a recent kernel :-
There is no minimum kernel version requirement afaik. So I think this must be fixed for ipv4-only clusters IMO.
Code change:
github.com/mitchellh/go-homedir => github.com/mitchellh/go-homedir v1.1.0 github.com/mitchellh/go-wordwrap => github.com/mitchellh/go-wordwrap v1.0.0 github.com/mitchellh/mapstructure => github.com/mitchellh/mapstructure v1.1.2 <del> github.com/moby/ipvs => github.com/moby/ipvs v1.0.0 </del> <ins> github.com/moby/ipvs => github.com/moby/ipvs v1.0.1 </ins> github.com/moby/term => github.com/moby/term v0.0.0-20200312100748-672ec06f55cd github.com/modern-go/concurrent => github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd github.com/modern-go/reflect2 => github.com/modern-go/reflect2 v1.0.1

Related discussion:
text: However ipv6-only and dual-stack are in "alpha" so a requirement on kernel version might be ok, but I can't say myself. A complication is that the problem is not in k8s itself but in a 3rd party lib.
ipv6-only is beta since 1.18 :smile:
/assign
I opened a PR to fix this in moby/ipvs If someone w/ a cluster on the older kernel version can test it that would be great, otherwise I will setup a cluster to validate this some time this week.
Instead of bootstraping a whole cluster right now (pretty busy here) I can use the Gist I've mentioned to check in a CentOS 7.1 if it faces the problem before and after the patch. At least to have some more test right now
with a small test, it worked fine. Environment: CentOS 7.1 - Kernel 3.10.0-229.el7.x86_64 + ipvsadm 1.2.1 Pre-loaded some IPv6 rules into ipvs: I've used code, searching for the following structure: I then call ` to get the IPVS object, and then try to fetch the destinations. The following are the results: Before patching the ipvs module: After patching the ipvs module (pinning to your repo/branch) Also I've made those tests with the structure but searching for TCP, and for kube-apiserver (that have only one destination) and it worked fine in all those scenarios. If wanted I can improve the gist to pass the parameters as command arguments instead of hardcoded (sorry, did this in a rush to test)
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Thanks just waiting on now
same issue,sloved by update kernel to 5.X
I didn't want to wait, I updated to kernel-lt in the version 4.4 . The problem is solved on my side :)
Thanks for confirming. We'll still try to get in since I'm sure other folks with older kernels will run into this issue.
/retitle parseIP error with IPVS proxy
upgrade your system kernel to 4.xx edition
FYI: just merged, need to run some validation & cut a new release (v1.0.1).
Code change:
github.com/mitchellh/go-homedir => github.com/mitchellh/go-homedir v1.1.0 github.com/mitchellh/go-wordwrap => github.com/mitchellh/go-wordwrap v1.0.0 github.com/mitchellh/mapstructure => github.com/mitchellh/mapstructure v1.1.2 <del> github.com/moby/ipvs => github.com/moby/ipvs v1.0.0 </del> <ins> github.com/moby/ipvs => github.com/moby/ipvs v1.0.1 </ins> github.com/moby/term => github.com/moby/term v0.0.0-20200312100748-672ec06f55cd github.com/modern-go/concurrent => github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd github.com/modern-go/reflect2 => github.com/modern-go/reflect2 v1.0.1

Related discussion:
text: FYI
/retitle DualStack / IPv6-only: parseIP error with IPVS proxy on CentOS 7
v1.18 cherry-pick
Hi, it seems that you're using v1.18.0 and this has been corrected in v1.18.3, can you please update and check? Tks
Code change:
calls:        []string{"inspect_image", "pull"}, err:          true, }, <del> "should pull private image using dockerauth if image doesn't exist": { injectImage:  true, imgNeedsAuth: true, injectErr:    libdocker.ImageNotFoundError{ID: "image_id"}, calls:        []string{"inspect_image", "pull"}, configJSON:   authJSON, err:          false, }, </del> } { t.Logf("TestCase: %q", desc) _, fakeDocker, _ := newTestDockerService()

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: We have a private registry configured (where all images including the sandbox one), are hosted. The registry credentials are being pulled by one of k8s credentials providers () With Kubernetes 1.7 sandbox image failed to be pulled with the following error message: Looks like with this only creds from docker config are being evaluated on the sandbox image pull What you expected to happen: Sandbox image pull should be attempted using credentials returned by not just the basic docker credential provider, but other credentials providers registered in the system. How to reproduce it (as minimally and precisely as possible): 1) Register private repo credentials with one of the k8s credential providers (we've tried with rancher). Configure the to use the image from the the private repo. 2) Make sure you are not logged in to this private repo on the kubelet host 3) Try to create a pod. Sandbox image pull will fail with an error mentioned above. Anything else we need to know?: Non-sandbox images from the same private repo were able to download correctly using private repo credentials provider. Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node Just tested the same use case against k8s 1.5.x, it worked fine there and sandbox image was pulled using the credentials passed by the credential provider, not from docker config file. So it might have regressed in 1.7.x (haven't tested it on 1.6, so can't tell for sure)
Confirmed a bug introduced in dockershim. Will file a PR to fix this.