jiebi/CodeConvo huggingface dataset:
Change:
tty           bool } <del> func extractPodAndContainer(cmd *cobra.Command, args []string, p *execParams) (podName string, containerName string, err error) { if len(p.podName) == 0 && len(args) == 0 { return "", "", cmdutil.UsageError(cmd, "POD is required for exec") </del> <ins> func extractPodAndContainer(cmd *cobra.Command, argsIn []string, p *execParams) (podName string, containerName string, args []string, err error) { if len(p.podName) == 0 && len(argsIn) == 0 { return "", "", nil, cmdutil.UsageError(cmd, "POD is required for exec") </ins> } if len(p.podName) != 0 { printDeprecationWarning("exec POD", "-p POD") podName = p.podName <del> if len(args) < 1 { return "", "", cmdutil.UsageError(cmd, "COMMAND is required for exec") </del> <ins> if len(argsIn) < 1 { return "", "", nil, cmdutil.UsageError(cmd, "COMMAND is required for exec") </ins> } <ins> args = argsIn </ins> } else { <del> podName = args[0] if len(args) < 2 { return "", "", cmdutil.UsageError(cmd, "COMMAND is required for exec") </del> <ins> podName = argsIn[0] args = argsIn[1:] if len(args) < 1 { return "", "", nil, cmdutil.UsageError(cmd, "COMMAND is required for exec") </ins> } } <del> return podName, p.containerName, nil </del> <ins> return podName, p.containerName, args, nil </ins> } <del> func RunExec(f *cmdutil.Factory, cmd *cobra.Command, cmdIn io.Reader, cmdOut, cmdErr io.Writer, p *execParams, args []string, re remoteExecutor) error { podName, containerName, err := extractPodAndContainer(cmd, args, p) </del> <ins> func RunExec(f *cmdutil.Factory, cmd *cobra.Command, cmdIn io.Reader, cmdOut, cmdErr io.Writer, p *execParams, argsIn []string, re remoteExecutor) error { podName, containerName, args, err := extractPodAndContainer(cmd, argsIn, p) </ins> namespace, err := f.DefaultNamespace() if err != nil { return err

Discussion:
When running , if you don't specify the deprecated and instead just do , it doesn't strip off the 1st command line arg, so sends the command to the container, whereas correctly sends just Regression from
FYI
We still support --, correct?
yes, we still support , but it's marked deprecated.
cc
has the fix. (and better unit test coverage) Sorry for the breakage!
Change:
source $(dirname ${BASH_SOURCE})/${KUBE_CONFIG_FILE-"config-default.sh"} function detect-master () { <del> echo "KUBE_MASTER_IP: $KUBE_MASTER_IP" echo "KUBE_MASTER: $KUBE_MASTER" </del> <ins> echo "KUBE_MASTER_IP: $KUBE_MASTER_IP" echo "KUBE_MASTER: $KUBE_MASTER" </ins> } # Get minion IP addresses and store in KUBE_MINION_IP_ADDRESSES[] function detect-minions { <del> echo "Minions already detected" </del> <ins> echo "Minions already detected" </ins> } # Verify prereqs on host machine

Discussion:
Running vagrant from scratch gives the error: For vagrant cluster, the last minion cannot be detected. The /tmp/minions file only shows two minions, but after a while, using the same command, i.e. will get three minions. There is a race between kube-up and validate-, we should wait a while before panic.
I can look to fix this.
Change:
func (obj *Unstructured) UnstructuredContent() map[string]interface{} { if obj.Object == nil { <del> obj.Object = make(map[string]interface{}) </del> <ins> return make(map[string]interface{}) </ins> } return obj.Object }

Discussion:
What happened: In I introduced an optimization - do a deep copy instead of to and from JSON roundtrip to convert anything that implements . I then discovered that the method that is used there in both and may mutate the original object. This is problematic because previously (before ) there was no mutation and because this is unexpected and may lead to data races - it is bad behaviour to mutate original object when you just want a copy of it. This issue was fixed by . However the underlying issue is not fixed here - is brittle and dangerous. Method name does not imply that it mutates data when you call it. And godoc does not mention that either: Something needs to be done about it IMO. This method is misused in these places (mutation side effect is not intended): Also implementation in does not implement the behaviour required by godoc in . What you expected to happen: There should be a method that returns the current unstructured contents without mutation and perhaps not providing the write-through effect. /kind bug /sig api-machinery
/cc
Is this still required and could I work on it? I'm looking for something to work on as a new contributor :)
Yes and yes! :)
Perfect, I'll get started on it!
I've got out. I'd appreciate a review :)
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
Change:
} func Test_ConstructVolumeSpec(t *testing.T) { <ins> if runtime.GOOS == "darwin" { t.Skipf("Test_ConstructVolumeSpec is not supported on GOOS=%s", runtime.GOOS) } </ins> fm := &mount.FakeMounter{ MountPoints: []mount.MountPoint{ {Device: "/dev/sdb", Path: "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1"},

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: unit tests fail on osx. What you expected to happen: How to reproduce it (as minimally and precisely as possible): To see this unit test fail, you need to run go test on an osx machine. Environment: OS: macOS High Sierra v10.13.3
/sig storage /assign
Change:
package vsphere import ( <del> "fmt" </del> "io/ioutil" <del> "strings" </del> ) <del> const ( UUIDPath   = "/sys/class/dmi/id/product_serial" UUIDPrefix = "VMware-" ) </del> <ins> const UUIDPath = "/sys/class/dmi/id/product_serial" </ins> <del> func GetVMUUID() (string, error) { </del> <ins> func getRawUUID() (string, error) { </ins> id, err := ioutil.ReadFile(UUIDPath) if err != nil { <del> return "", fmt.Errorf("error retrieving vm uuid: %s", err) } uuidFromFile := string(id[:]) //strip leading and trailing white space and new line char uuid := strings.TrimSpace(uuidFromFile) // check the uuid starts with "VMware-" if !strings.HasPrefix(uuid, UUIDPrefix) { return "", fmt.Errorf("Failed to match Prefix, UUID read from the file is %v", uuidFromFile) } // Strip the prefix and white spaces and - uuid = strings.Replace(uuid[len(UUIDPrefix):(len(uuid))], " ", "", -1) uuid = strings.Replace(uuid, "-", "", -1) if len(uuid) != 32 { return "", fmt.Errorf("Length check failed, UUID read from the file is %v", uuidFromFile) </del> <ins> return "", err </ins> } <del> // need to add dashes, e.g. "564d395e-d807-e18a-cb25-b79f65eb2b9f" uuid = fmt.Sprintf("%s-%s-%s-%s-%s", uuid[0:8], uuid[8:12], uuid[12:16], uuid[16:20], uuid[20:32]) return uuid, nil </del> <ins> return string(id), nil </ins> }

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: Running the vSphere cloud provider on a windows node throws the following error: This is because the vm identifier is retrieved with the command - , which assumes that the uuid and serial are the same. On some vmware vm versions, the uuid and serial are not the same. vmware (comment), vmware (comment) What you expected to happen: Kubelet is able to find vm in vCenter from the identifier looked up on the node. or should be used instead to find the vm identifier. How to reproduce it (as minimally and precisely as possible): Issue only occurs on some vm versions, such as 13. Anything else we need to know?: On the linux side, this issue was resolved by switching from looking up the id from to . See Some discussion about this issue here - Environment: Kubernetes version (use ): 14.0-beta.1 Cloud provider or hardware configuration: Vsphere OS (e.g: ): Windows 2019 Kernel (e.g. ): Install tools: Others:
/sig windows /sig vmware
/milestone v1.14
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.14 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
Change:
// We're sending new job to see if it reaches syncHandler. testJob.Name = "foo" fakeWatch.Add(&testJob) <del> select { case <-received: case <-time.After(controllerTimeout): t.Errorf("Expected 1 call but got 0") } </del> <ins> t.Log("Waiting for job to reach syncHandler") <-received } </ins> <del> // We're sending fake finished job, to see if it reaches syncHandler - it should not, // since we're filtering out finished jobs. testJobv2 := experimental.Job{ ObjectMeta: api.ObjectMeta{Name: "foo"}, </del> <ins> func TestIsJobFinished(t *testing.T) { job := &experimental.Job{ </ins> Status: experimental.JobStatus{ Conditions: []experimental.JobCondition{{ <del> Type:               experimental.JobComplete, Status:             api.ConditionTrue, LastProbeTime:      unversioned.Now(), LastTransitionTime: unversioned.Now(), </del> <ins> Type:   experimental.JobComplete, Status: api.ConditionTrue, </ins> }}, }, } <del> fakeWatch.Modify(&testJobv2) select { case <-received: t.Errorf("Expected 0 call but got 1") case <-time.After(controllerTimeout): </del> <ins> if !isJobFinished(job) { t.Error("Job was expected to be finished") } job.Status.Conditions[0].Status = api.ConditionFalse if isJobFinished(job) { t.Error("Job was not expected to be finished") } job.Status.Conditions[0].Status = api.ConditionUnknown if isJobFinished(job) { t.Error("Job was not expected to be finished") </ins> } }

Discussion:
Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.
Change:
type PersistentVolume struct { TypeMeta   `json:",inline"` <del> ObjectMeta `json:"metadata,omitempty"` </del> <ins> ObjectMeta `json:"metadata,omitempty" description:"standard object metadata; see http://docs.k8s.io/api-conventions.md#metadata"` </ins> //Spec defines a persistent volume owned by the cluster Spec PersistentVolumeSpec `json:"spec,omitempty" description:"specification of a persistent volume as provisioned by an administrator"`

Discussion:
PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?
Change:
} } <del> if instanceType, err := getInstanceTypeByProviderIDOrName(ctx, instances, node); err != nil { </del> <ins> if instanceType, err := getInstanceTypeByProviderIDOrName(ctx, instances, providerID, node.Name); err != nil { </ins> return nil, err } else if instanceType != "" { klog.V(2).Infof("Adding node label from cloud provider: %s=%s", v1.LabelInstanceType, instanceType)

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: introduces a regression that func is invoked on a Node obj without , hence it can fail fetching the node addresses when the is not set. What you expected to happen: I would expect cloud-controller-manager to be able to initialize new Node. How to reproduce it (as minimally and precisely as possible): the gcp legacy-cloud-controller v1.18.1 () that the node-controller cannot initialize a new Node. Logs of the cloud-controller-manager repeated multiple times: Ensure that the Node is with the taint. Ensure that the of the Node is not set. The cloud-controller-manager is not running on the host machine and that's why it cannot call the gce matadata. But it was never a hard requirement for cloud-controller-manager to run on the host machine. Anything else we need to know?: The legacy cloud-controller-manager v1.17.x is working perfectly fine. Environment: Kubernetes version (use ):v1.18.1 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 cloud-provider /kind regression
/cc
can we open a new issue re:
Change:
# if there are no files vendored under this package... if [[ -z "$(find "${DEPS_DIR}/${PACKAGE}" -mindepth 1 -maxdepth 1 -type f)" ]]; then <del> # and we have the same number of submodules as subdirectories... if [[ "$(find "${DEPS_DIR}/${PACKAGE}/" -mindepth 1 -maxdepth 1 -type d | wc -l)" -eq "$(echo "${modules}" | grep -cE "^${PACKAGE}/")" ]]; then </del> <ins> # and we have at least the same number of submodules as subdirectories... if [[ "$(find "${DEPS_DIR}/${PACKAGE}/" -mindepth 1 -maxdepth 1 -type d | wc -l)" -le "$(echo "${modules}" | grep -cE "^${PACKAGE}/")" ]]; then </ins> echo "Only submodules of ${PACKAGE} are vendored, skipping" >&2 continue fi

Discussion:
When updating go-oidc, running failed when looking for licenses; specifically, it was looking for ’s file, but that was no longer vendored. Since no packages are actually used, the license shouldn’t be needed. On master, No response Tip of the master branch. N/A N/A N/A N/A N/A
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 k8s-infra /cc
Change:
// This client will attempt a one-shot connection, then die, without restarting the pod. // Test can then be asserted based on whether the pod quit with an error or not. func createNetworkClientPod(f *framework.Framework, namespace *v1.Namespace, podName string, targetService *v1.Service, targetPort int) *v1.Pod { <ins> return createNetworkClientPodWithRestartPolicy(f, namespace, podName, targetService, targetPort, v1.RestartPolicyNever) } // Create a client pod which will attempt a netcat to the provided service, on the specified port. // It is similar to createNetworkClientPod but supports specifying RestartPolicy. func createNetworkClientPodWithRestartPolicy(f *framework.Framework, namespace *v1.Namespace, podName string, targetService *v1.Service, targetPort int, restartPolicy v1.RestartPolicy) *v1.Pod { </ins> pod, err := f.ClientSet.CoreV1().Pods(namespace.Name).Create(context.TODO(), &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ GenerateName: podName + "-",

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: The NetworkPolicy e2e test fails regardless of which CNI plugin is enabled. The test assumes the client Pod can recheck connectivity after updating its label, but the client won't restart after the first failure, so the second check will always fail. What you expected to happen: The test should succeed if a CNI plugin implements NetworkPolicy correctly. How to reproduce it (as minimally and precisely as possible): a CNI that supports NetworkPolicy. the e2e test by focusing "should allow ingress access from updated pod". test will always fail. Anything else we need to know?: Environment: Kubernetes version (use ): 16.3 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 testing /assign
/remove-sig testing /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I see this in Calico 3.10 as well confirming that its definitely an issue.
Change:
"strings" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake"

Discussion:
make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
see example successful run:
For reference -
fix in
screaming
Change:
) const ( <del> criticalPodName   = "critical-pod" guaranteedPodName = "guaranteed" burstablePodName  = "burstable" bestEffortPodName = "best-effort" </del> <ins> criticalPodName            = "critical-pod" guaranteedPodName          = "guaranteed" burstablePodName           = "burstable" bestEffortPodName          = "best-effort" systemCriticalPriorityName = "critical-pod-test-high-priority" </ins> ) var _ = framework.KubeDescribe("CriticalPod [Serial] [Disruptive] [NodeFeature:CriticalPod]", func() { f := framework.NewDefaultFramework("critical-pod-test") ginkgo.Context("when we need to admit a critical pod", func() { tempSetCurrentKubeletConfig(f, func(initialConfig *kubeletconfig.KubeletConfiguration) { if initialConfig.FeatureGates == nil {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
"http://metadata.google.internal/0.2/", "http://metadata.google.internal/computeMetadata/v2/", // kube-env. <del> "http://metadata.google.internal/0.1/meta-data/attributes/kube-env", "http://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/kube-env", </del> "http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env", // VM identity. <del> "http://metadata.google.internal/0.1/meta-data/service-accounts/default/identity", "http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/identity", </del> "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity", // Forbidden recursive queries. "http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true",

Discussion:
Warning: The v0.1 and v1beta1 metadata server endpoints are deprecated and scheduled for shutdown on September 30, 2020. This test (which runs in most e2e jobs that run on GCE): Schedules a container that runs this: Resulting in a number of legacy metadata endpoints getting hit. To see if this test is going to start failing across all release branches on Sep 30th, we could try disabling the endpoints ahead of time via: In fact and support for expecting different results based on whether is set. My concern is the test expects 200 for some root endpoints, and 403 for disabled endpoints. However the e-mail I received as a GCP customer tells me any legacy endpoints may return 404. I'm inclined to suggest we remove the legacy endpoints from the check, bump the image version, and cherry-pick use of the new image version back to all release-branches. WDYT since you were involved with the earlier PRs /sig auth /sig cloud-provider /provider gcp /sig testing /priority important-soon (I'm tempted to critical-urgent this but it's not drop-everything yet) /milestone v1.20
/kind cleanup
Heyho I wanted to check how it is going? The code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each relevant issue has a chance to be considered. As the issue is tagged for 1.20, is it still planned for this release?
Bug Triage here, we're pretty late into code freeze and it doesn't look like there has been much activity recently. I am going to clear the milestone on this issue. /milestone clear
any update here?
Try to cleanup the legacy endpoints in
/milestone v1.21
/reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: )
Reopened this issue. <detailsIn response to : /reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: ) 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
/triage accepted /assign