jiebi/CodeConvo huggingface dataset:
Change:
p:             &ExecOptions{}, args:          []string{"foo", "cmd"}, argsLenAtDash: -1, <del> expectedPod:   "foo", </del> <ins> expectedPod:   execPod(), </ins> expectedArgs:  []string{"cmd"}, name:          "cmd, w/o flags", }, { p:             &ExecOptions{}, <ins> args:          []string{"pod/foo", "cmd"}, argsLenAtDash: -1, expectedPod:   execPod(), expectedArgs:  []string{"cmd"}, name:          "pod with 'pod/' prefix, cmd, w/o flags", }, { p:             &ExecOptions{}, </ins> args:          []string{"foo", "cmd"}, argsLenAtDash: 1, <del> expectedPod:   "foo", </del> <ins> expectedPod:   execPod(), </ins> expectedArgs:  []string{"cmd"}, name:          "cmd, cmd is behind dash", },

Discussion:
I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.
Change:
if diskManager.volumeOptions.SCSIControllerType == "" { diskManager.volumeOptions.SCSIControllerType = vclib.LSILogicControllerType } <del> // Create virtual disk diskFormat := vclib.DiskFormatValidType[diskManager.volumeOptions.DiskFormat] // Create a virtual disk manager vdm := object.NewVirtualDiskManager(datastore.Client()) </del> <ins> // Check for existing VMDK before attempting create. Because a name collision // is unlikely, "VMDK already exists" is likely from a previous attempt to // create this volume. if dsPath := vclib.GetPathFromVMDiskPath(diskManager.diskPath); datastore.Exists(ctx, dsPath) { klog.V(2).Infof("Create: VirtualDisk already exists, returning success. Name=%q", diskManager.diskPath) return diskManager.diskPath, nil } </ins> // Create specification for new virtual disk <ins> diskFormat := vclib.DiskFormatValidType[diskManager.volumeOptions.DiskFormat] </ins> vmDiskSpec := &types.FileBackedVirtualDiskSpec{ VirtualDiskSpec: types.VirtualDiskSpec{ AdapterType: diskManager.volumeOptions.SCSIControllerType,

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In some cases, a create volume request can succeed in vSphere but time out in the vSphere storage plugin. This request will be retried, but fails with on subsequent attempts. As a result, the PersistentVolume object never gets created, and the pod requesting it never starts. Recovery requires manual steps. What you expected to happen: Since vSphere successfully created the volume, the storage plugin should reconcile and allow the PersistentVolume to get created. How to reproduce it (as minimally and precisely as possible): This is difficult to reproduce because it is caused by specific timing between vSphere and kubernetes. For testing, I a line of code to [][1] to inject failures after vSphere created the volume. [1]: 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 storage
Fixed by
Change:
-mode=fix  -repo_root "${KUBE_ROOT}"  "${KUBE_ROOT}"  <del> 2>&1 | grep -Ev "vendor/github.com/seccomp/libseccomp-golang/seccomp(_internal)?.go: pkg-config not supported: #cgo pkg-config: libseccomp" || (exit "${PIPESTATUS[0]}") </del> <ins> 2>&1 | grep -Ev "$(kube::util::join | "${KNOWN_PKG_CONFIG_ERRORS[@]}")" || (exit "${PIPESTATUS[0]}") </ins> # Run kazel to update the pkg-srcs and all-srcs rules as well as handle # Kubernetes code generators.

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Got the following error while trying to run : How to reproduce it (as minimally and precisely as possible): Ran this on a fresh install of ubuntu 19.04, Go 1.12.6, and bazel 0.26.1. Anything else we need to know?: Seems like the change might have been due to the update in vendored deps from ( ). Although this script is run in CI where it is working so may be some set of recommende pkg versions would help prevent this problem? Environment: Cloud provider or hardware configuration: OS (e.g: ): ubuntu 19.04 Kernel (e.g. ): 5.0.0-15-generic bazel: 0.26.1 Go: 1.12.6
Not sure who owns this... /sig testing
Seems like the errors are "warnings" and can be ignored? It seems that BUILD files are properly updated by update-bazel, And bazel builds do work properly... /cc
/sig release this is not a failure /retitle hack/update-bazel produces warnings there was some discussion on the original PR about filtering them out but nothing conclusive I'll file a PR to do that now.. /assign
aside: this is actually from :-) we're working around the lack of support because we only need it for this package and on all known systems we compile on so far it only needs the one link flag as previously specified in the cgo config.
filed
Glad to see it. The output message is so misleading that I have spent hours on this issue
sorry about that the output does say "error" but it's actually considered a non-fatal warning in the upstream code and doesn't cause the script (or build) to fail.
was merged before this discussion was resolved , so we kinda saw this coming. :/ Hopefully we can get the fix from in merged as quick as possible
/reopen we have a new a new occurrence with libipmctl
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
I have the same question. This output is a bit annoying.
We can update the script to handle this issue and suppress the warning. The previous PR is an example. On Thu, Apr 16, 2020, 12:14 AM <:
/assign
Change:
INDIRECT=$$(go list -e                                 -f '{{range .Deps}}{{.}}{{"n"}}{{end}}'           ./cmd/libs/go2idl/deepcopy-gen                     <del> | grep "^$(PRJ_SRC_PATH)"                          </del> <ins> | grep --color=never "^$(PRJ_SRC_PATH)"            </ins> | sed 's|^$(PRJ_SRC_PATH)|./|'                     | xargs go list -e -f '{{.Dir}} {{.Dir}}/*.go');   echo $$DIRECT $$INDIRECT                              

Discussion:
Using the grep from OSX, fails when GREPOPTIONS/GREPCOLOR is set as shown below (). Workaround : unset GREPOPTIONS/GREPCOLOR Note that using GNU grep using brew install will show that GREPOPTIONS shows immediately that GREP_OPTIONS may be interfering with make ()
oh, here's badly manged conversion-
Will look, thanks. For make-related bugs, please @ me directly.
Will do. thanks
This breaks building kubernetes inside Alpine Linux:
I'm pressing more and more on the idea that the only supported build is the dockerized build. Trying to accomodate every random environment is just too taxing. , Marc Villacorta wrote:
I agree with We can support the stuff in to run on mac to get you dockerized but everything else is only supported in there. I've worked around a few BSD/OSX things in but it isn't fun. We should try to keep that stuff isolated.
I agree, with the usual caveat that we need to be doing all of the build in one container with as little as possible happening outside. OS X tends to have old and broken versions of important programs, which is terrible. We discussed setting up CI for it but it's not going to happen in the near term. Alpine/Busybox purposefully omit features from their versions for good reasons, but it's still more work to support than it's worth.
Ok, I will re-think my workflow.
How did you find yourself building in Alpine, in I may ask? , Marc Villacorta wrote:
nothing is forcing me to use Alpine I just like the distro. I run stuff on CoreOS and my aim is to solve the build-deliver-run pipeline with a single small container. By the way, I have the problem installing the GNU package :-)
Change:
ttlSeconds = int(v1.DefaultClientIPServiceAffinitySeconds) //default to 3 hours if not specified.  Should 0 be unlimited instead???? } <del> if _, exists := lb.services[svcPort]; !exists { </del> <ins> if state, exists := lb.services[svcPort]; !exists || state == nil { </ins> lb.services[svcPort] = &balancerState{affinity: *newAffinityPolicy(affinityType, ttlSeconds)} klog.V(4).InfoS("LoadBalancerRR service does not exist, created", "servicePortName", svcPort) } else if affinityType != "" {

Discussion:
As suggested in , some portions of the code contains the map checking for nil values in map, and others don't have. Even though we're never assigning nil values to this map, we should standardize the portions that does not have this check in module. Example: Should be like this: I can take care of this issue.
/sig network
There have been discussions of deprecating the user-space proxier. Maybe transfer it to . A question is if anybody still uses it. Seems like you do, so if possible please explain if you have a use-case where the user-space proxier is wanted/needed.
Hey Actually, I was casually reading the source code and I saw a over there regarding the nil checks. Regarding your question, we should check if anyone actually uses it though, or maybe discuss its usage or deprecation a little further.
Quick question though: I saw in the news that the user-space proxy porting was near completion, maybe it's worth talking to them in order to check upon the status.
I don't object to making it clearer or more consistent, if you want to spend time on it, but it's not a high priority. That said, I think a nil value in that map would be really bad (and should be impossible) and I don't know how we would raise a signal about it.
let us know if you want to try to fix it, otherwise we can just close this.
I already opened a PR with the clearer nil checks for this specific module in , so you can review it. I think whether this would have nil values into the service map we should discuss this apart and try to reproduce this case (if any would happen).
PR submitted, so let's review and discuss further there. /assign dcbw /triage accepted
Change:
// the caller in framing the chunk. func NewDocumentDecoder(r io.ReadCloser) io.ReadCloser { scanner := bufio.NewScanner(r) <ins> // the size of initial allocation for buffer 4k buf := make([]byte, 4*1024) // the maximum size used to buffer a token 5M scanner.Buffer(buf, 5*1024*1024) </ins> scanner.Split(splitYAMLDocument) return &YAMLDecoder{ r:       r,

Discussion:
What happened: When calling the token size for the buffer is the default which is NOT changable. Larger documents (which is likely when using a yaml separator) causes a This was uncovered using kudo... the issue is What you expected to happen: limitation should be documented if they exist size should be calling code managed How to reproduce it (as minimally and precisely as possible): Call with a doc larger than token size Anything else we need to know?: The fixing PR provides more detail if needed. Code concern is: duplicate of which I will now close Environment: Kubernetes version (use ): 1.17 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 api-machinery
/cc
OK so the request here is that we call on the scanner to permit larger documents? I think 5MB is a good max size? (Since YAML is more verbose than proto, where the (IIRC) 1.5MB limit is enforced.)
Adding labels-- this is a good one for new contributors.
/assign 0xMH because of open PR
GitHub didn't allow me to assign the following users: 0xMH. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 0xMH because of open PR 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
/remove-help /remove good first issue
Change:
if err := ClearUDPConntrackForIP(&fexec, tc.ip); err != nil { t.Errorf("%s test case:, Unexpected error: %v", tc.name, err) } <del> expectCommand := fmt.Sprintf("conntrack -D --orig-dst %s -p udp", tc.ip) + familyParamStr(isIPv6(tc.ip)) </del> <ins> expectCommand := fmt.Sprintf("conntrack -D --orig-dst %s -p udp", tc.ip) + familyParamStr(IsIPv6String(tc.ip)) </ins> execCommand := strings.Join(fcmd.CombinedOutputLog[svcCount], " ") if expectCommand != execCommand { t.Errorf("%s test case: Expect command: %s, but executed %s", tc.name, expectCommand, execCommand)

Discussion:
<!-- 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 bug What happened: There is a bug in ipv6, see: What you expected to happen: The judgement logic should be: 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: /sig network /area ipv6
/assign cc
Change:
UID:        "bar", APIVersion: "v1", }, <del> Reason:  "Killed", Message: "some other verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   1, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Killed", Message:             "some other verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               1, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"bar", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'Killed' some other verbose message: 1`, expectUpdate: false,

Discussion:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted
Change:
} func portsFromString(spec string) []api.Port { <ins> if spec == "" { return []api.Port{} } </ins> parts := strings.Split(spec, ",") var result []api.Port for _, part := range parts {

Discussion:
$ run thockin/hostnametcp 1 hostname-tcp E1002 14:48:23. ] Container port is not integer: strconv.ParseInt: parsing "": invalid syntax
Change:
RepoDigests: []string{"foo-rd31", "foo-rd32"}, Size:        3, }, <ins> { ID:          "4", RepoTags:    []string{"foo-tag41", "foo-tag42"}, RepoDigests: []string{"foo-rd41", "foo-rd42"}, Size:        3, }, </ins> } }

Discussion:
What happened: When two or more images on a given node have the same size, their order inside the field set by the process is not deterministic. This problem has the side effect of continually triggering controllers which assume this list to be always equal on node updates unless images are or removed. What you expected to happen: The order of images should be stable even when two images have the same size, using the image ID as a second sort field would help this. How to reproduce it (as minimally and precisely as possible): Choose a node and run: Run a few times: It should be possible to see and images alternating on the output. Anything else we need to know?: Our particular use case make it really common for multiple images to have the same size on a given node. I came across this problem while debugging slow updates to DaemonSets and finding out that the kube-controller-manager was leaking memory until it eventually dies due to OOM: <img width="800" alt="Screen Shot 2019-06-30 at 20 27 22" src="https://user-"I was able to track this leak to a large number of watched elements in memory and by taking a look at the logs with increased verbosity I figured it was due to too many Node notifications being processed by the DaemonSet controller: <img width="800" alt="Screen Shot 2019-06-30 at 20 36 23" src="https://user-"It's possible that other controllers in the wild that watch nodes and only ignore the conditions timestamps on updates to face the same problem. I'll send a simple PR to fix this shortly. Environment: Kubernetes version (use ): But by taking a look at the code this problem also happens on master.
/sig node
Nice debugging here :)
Change:
Force               bool GracePeriodSeconds  int IgnoreAllDaemonSets bool <ins> IgnoreErrors        bool </ins> Timeout             time.Duration DeleteEmptyDirData  bool Selector            string

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : on multiple nodes, if one node failed, the command aborting. Without special purpose, maybe it's better to continue processing other nodes. Why is this needed: Follow the pattern of other subcommand, such as kubectl delete.
/sig cli
/triage accepted /assign
done /close
Closing this issue. <detailsIn response to : done /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
I would wait the patch get merged before closing :)
Change:
BeforeEach(func() { By("deploying csi hostpath driver") <del> clusterRole = externalAttacherClusterRole(cs, config, false) serviceAccount = externalAttacherServiceAccount(cs, config, false) externalAttacherClusterRoleBinding(cs, config, false, serviceAccount, clusterRole) </del> <ins> clusterRole = csiClusterRole(cs, config, false) serviceAccount = csiServiceAccount(cs, config, false) csiClusterRoleBinding(cs, config, false, serviceAccount, clusterRole) </ins> csiHostPathPod(cs, config, false, f, serviceAccount) }) AfterEach(func() { By("uninstalling csi hostpath driver") csiHostPathPod(cs, config, true, f, serviceAccount) <del> externalAttacherClusterRoleBinding(cs, config, true, serviceAccount, clusterRole) serviceAccount = externalAttacherServiceAccount(cs, config, true) clusterRole = externalAttacherClusterRole(cs, config, true) </del> <ins> csiClusterRoleBinding(cs, config, true, serviceAccount, clusterRole) serviceAccount = csiServiceAccount(cs, config, true) clusterRole = csiClusterRole(cs, config, true) </ins> }) It("should provision storage with a hostPath CSI driver", func() {

Discussion:
Current CSI E2E test has some issues which prevent it to run successfully the a local cluster. /sig storage /kind bug /assign
Change:
if attachID != "" { t.Errorf("Expected empty attachID, got %q", attachID) } <del> }(spec, test.expectVolumeAttachment) </del> <ins> }(spec) </ins> if test.expectVolumeAttachment { expectedAttachID := getAttachmentName("test-vol", test.driver, "fakeNode") status := storage.VolumeAttachmentStatus{ Attached: true, } <ins> // We want to ensure the watcher, which is created in csiAttacher, // has been started before updating the status of attachment. <-attachmentWatchCreated </ins> markVolumeAttached(t, csiAttacher.k8s, nil, expectedAttachID, status) } wg.Wait()

Discussion:
Which test(s) are flaking: TestAttacherWithCSIDriver Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: a test binary for the affected package: the affected test using the tool (setting the timeout to a generous timeout relative to the normal test runtime of .02 seconds): failures are seen, look at the logs to see the details about the error: /sig storage cc
/assign can you help investigate this flake?
I have found the root cause. /assign
filed to address this issue.
Change:
// [Serial]: the tests read global kube-controller-manager metrics, so no other test changes them in parallel. f.Context("SELinuxMount metrics [LinuxOnly]", feature.SELinux, feature.SELinuxMountReadWriteOncePod, f.WithSerial(), func() { <del> // All SELinux metrics. Unless explicitly mentioned in test.expectIncreases, these metrics must not grow during // a test. allMetrics := sets.NewString( "volume_manager_selinux_container_errors_total", "volume_manager_selinux_container_warnings_total", "volume_manager_selinux_pod_context_mismatch_errors_total", "volume_manager_selinux_pod_context_mismatch_warnings_total", "volume_manager_selinux_volume_context_mismatch_errors_total", "volume_manager_selinux_volume_context_mismatch_warnings_total", "volume_manager_selinux_volumes_admitted_total", ) </del> // Make sure all options are set so system specific defaults are not used. seLinuxOpts1 := v1.SELinuxOptions{ User:  "system_u",

Discussion:
[It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is not bumped on two Pods with the same context on RWO volume [sig-storage] [It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is bumped on two Pods with a different context on RWO volume [sig-storage] Sample failure: October 25, 2023 It fails since The PR a label to some SELinux metric and the tests do not count with that. No response /sig storage
/assign /triage accepted