jiebi/CodeConvo huggingface dataset:
Change:
} if in.XValidations != nil { <del> in, out := &in.XValidations, &out.XValidations *out = make([]ValidationRule, len(*in)) copy(*out, *in) </del> <ins> inValidations, outValidations := &in.XValidations, &out.XValidations *outValidations = make([]ValidationRule, len(*inValidations)) for i := range *inValidations { in.XValidations[i].DeepCopyInto(&out.XValidations[i]) } </ins> } return out

Discussion:
TestRoundTrip I checked that 2 weeks ago is not flaking. " install": 14, openapi and validation flake are also . No response No response /sig api-machinery
Easy to reproduce on local env.
My mistake, not this pr.
is the root cause of the flake. /cc
I didn't read far enough, the error was: deepcopy is manual for jsonprops was the manual impl that's no longer valid since we have a pointer now /assign
Working on a targeted fix now
(the last time a field was here, the same thing happened - )
Confirmed that the deep copy fix works as expected: I'll send out a PR in a moment.
Thanks for addressing it!
/triage accepted
Change:
kubeadmcmdoptions.KubeconfigDir, kubeadmcmdoptions.UploadCerts, kubeadmcmdoptions.Patches, <del> "print-join-command", "rootfs", "v") </del> <ins> "print-join-command", "rootfs", "v", "log-file") </ins> if allowedFlags.Has(flagName) { return true }

Discussion:
As originally filed at BUG REPORT Passing to both and never actually creates or writes a log file whatever the level of and regardless of whether the enclosing directory exists. only works if the undocumented is passed as well. kubeadm version : Environment: Kubernetes version: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Ubuntu 18.04.5 Kernel (e.g. ): 5.4.0 A log file to be produced at In this example fails to do anything when used with to join a node to the control plane. However, this issue persists across different subcommands.
/sig instrumentation
/assign I will try to reproduce it first
/triage accepted /assign /sig cloud-provider
Change:
_, err = as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM) if err != nil { <del> klog.Errorf("azureDisk - attach disk(%s) failed, err: %v", diskName, err) </del> <ins> klog.Errorf("azureDisk - attach disk(%s, %s) failed, err: %v", diskName, diskURI, err) </ins> detail := err.Error() if strings.Contains(detail, errLeaseFailed) || strings.Contains(detail, errDiskBlobNotFound) { // if lease cannot be acquired or disk not found, immediately detach the disk and return the original error <del> klog.V(2).Infof("azureDisk - err %v, try detach disk(%s)", err, diskName) </del> <ins> klog.V(2).Infof("azureDisk - err %v, try detach disk(%s, %s)", err, diskName, diskURI) </ins> as.DetachDiskByName(diskName, diskURI, nodeName) } } else { <del> klog.V(2).Infof("azureDisk - attach disk(%s) succeeded", diskName) </del> <ins> klog.V(2).Infof("azureDisk - attach disk(%s, %s) succeeded", diskName, diskURI) </ins> } return err }

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: add more logging in azure disk attach/detach What you expected to happen: 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: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
The issue message here doesn't say why a change was desired. The PR "Original logging is not clear when dealing with managed disk, since diskName is empty". That's more informative.
Change:
impersonationUser: "tester", expectedUser: &user.DefaultInfo{ Name:   "tester", <del> Groups: []string{}, </del> <ins> Groups: []string{"system:authenticated"}, </ins> Extra:  map[string][]string{}, }, expectedCode: http.StatusOK,

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): impersonate system:authenticated Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): Centos7 Kernel (e.g. ): Install tools: custom Others: Using RBAC What happened: Impersonating a user is not setting group which causes impersonate to fail What you expected to happen: If a user is in the tokens file they and they are impersonated the group should be for authz. How to reproduce it (as minimally and precisely as possible): sure group has cluster role a test user via token file a user with impersonate access submit a command via kubectl That request will fail with 403 response even though the user is in the group. Anything else we need to know: cc
We can probably be smart and put the authenticated group adder around the result of the impersonation filter. you see any issues with that?
We provide the group field to provide this kind of information. I'm not sure I would expect my request to the server about a particular user/group tuple to be evaluated for a different user/group tuple.
for impersonation, we already add groups when known (service accounts). doing so for the system:authenticated/system:unauthenticated groups makes sense to me
Only when the groups aren't specified, right? If memory serves, that's how we did it downstream where we can make group determination.
Change:
h.TableHandler(controllerRevisionColumnDefinition, printControllerRevision) h.TableHandler(controllerRevisionColumnDefinition, printControllerRevisionList) <ins> resorceQuotaColumnDefinitions := []metav1beta1.TableColumnDefinition{ {Name: "Name", Type: "string", Format: "name", Description: metav1.ObjectMeta{}.SwaggerDoc()["name"]}, {Name: "Age", Type: "string", Description: metav1.ObjectMeta{}.SwaggerDoc()["creationTimestamp"]}, {Name: "Request", Type: "string", Description: "Request represents a minimum amount of cpu/memory that a container may consume."}, {Name: "Limit", Type: "string", Description: "Limits control the maximum amount of cpu/memory that a container may use independent of contention on the node."}, } h.TableHandler(resorceQuotaColumnDefinitions, printResourceQuota) h.TableHandler(resorceQuotaColumnDefinitions, printResourceQuotaList) </ins> AddDefaultHandlers(h) }

Discussion:
<!-- 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?: /kind feature isn't very useful as it only shows the name and age of the resourcequota resource. It'd be nice if it also shows the current/allocated usage for each, like this: Each resourcequota summary is of the format: . I think it would be a useful feature. I wouldn't mind taking a crack at implementing it if it's deemed worth by the maintainers. Thanks.
/sig cli
/assign code-sleuth
GitHub didn't allow me to assign the following users: code-sleuth. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign code-sleuth 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 juanvallejo
Change:
Failf("Failed to find expected endpoints:nTries %dnCommand %vnretrieved %vnexpected %vn", minTries, cmd, eps, expectedEps) } <ins> func (config *NetworkingTestConfig) GetEndpointsFromTestContainer(protocol, targetIP string, targetPort, maxTries, minTries int) (sets.String, error) { return config.GetEndpointsFromContainer(protocol, config.TestContainerPod.Status.PodIP, targetIP, TestContainerHttpPort, targetPort, maxTries, minTries) } func (config *NetworkingTestConfig) GetEndpointsFromContainer(protocol, containerIP, targetIP string, containerHttpPort, targetPort, maxTries, minTries int) (sets.String, error) { cmd := fmt.Sprintf("curl -q -s 'http://%s:%d/dial?request=hostName&protocol=%s&host=%s&port=%d&tries=1'", containerIP, containerHttpPort, protocol, targetIP, targetPort) eps := sets.NewString() for i := 0; i < maxTries; i++ { stdout, stderr, err := config.f.ExecShellInPodWithFullOutput(config.HostTestContainerPod.Name, cmd) if err != nil { // A failure to kubectl exec counts as a try, not a hard fail. // Also note that we will keep failing for maxTries in tests where // we confirm unreachability. Logf("Failed to execute %q: %v, stdout: %q, stderr: %q", cmd, err, stdout, stderr) } else { var output map[string][]string if err := json.Unmarshal([]byte(stdout), &output); err != nil { Logf("WARNING: Failed to unmarshal curl response. Cmd %v run in %v, output: %s, err: %v", cmd, config.HostTestContainerPod.Name, stdout, err) continue } for _, hostName := range output["responses"] { trimmed := strings.TrimSpace(hostName) if trimmed != "" { eps.Insert(trimmed) } } return eps, nil } } return nil, fmt.Errorf("Failed to get endpoints:nTries %dnCommand %vn", minTries, cmd) } </ins> // DialFromNode executes a tcp or udp request based on protocol via kubectl exec // in a test container running with host networking. // - minTries is the minimum number of curl attempts required before declaring

Discussion:
Augment to turn on session affinity for a service, lookup the vip from a container/node and make sure we only hit a single endpoint with N ready/running endpoints.
This looks like it is still relevant can anyone confirm if we these? I still see a
/assign
Are you working on it? Could you please assign this issue to me and I am happy to fix it. Thanks a lot!
/assign I have it in my "backlog" behind NetworkPolicy stuff. Feel free to take it over if you have time.
GitHub didn't allow me to assign the following users: m1093782566. Note that only can be assigned. <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
Would appreciate :)
/assign
Change:
func configFromEnv() (cfg Config, ok bool) { cfg.Global.AuthURL = os.Getenv("OS_AUTH_URL") cfg.Global.Username = os.Getenv("OS_USERNAME") <del> cfg.Global.Password = os.Getenv("OS_PASSWORD") </del> cfg.Global.Region = os.Getenv("OS_REGION_NAME") cfg.Global.UserID = os.Getenv("OS_USER_ID") cfg.Global.TrustID = os.Getenv("OS_TRUST_ID")

Discussion:
This issue was reported in the Description When configuring components of infrastructure, environment variables allow a trivial method of gathering settings. However, not all settings should be derived from these variables. For example, the file used the CFSSLCAPKPASSWORD environment variable, where a plain-text password should be found within the variable. Figure 8.1: A string password being recovered from the CFSSLCAPKPASSWORD environment variable. If this variable is configured, an attacker could potentially gain access to its stored value through environment logging, or further exploitation of the endpoint. The assessment team found seemingly sensitive environment variables in at least the following locations: Exploit Scenario Alice configures her environment with the CFSSLCAPKPASSWORD environment variable. Eve gains access to Alice’s environment and determines that the CFSSLCAPK_PASSWORD environment variable is set. Because this variable contains the private key password, Eve is able to recover the private key and use it trivially, leading to further exploitation of Alice’s environment. Recommendation Short term, ensure highly sensitive information is not collected directly from environment variables for long periods of time. Long term, consider using Kubernetes secrets for all areas of the system. This will allow users to have one unified interface and location for all secrets, and avoid accidentally exposing secrets to other users within a host system. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-005 and it was finding 9 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 35 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig cloud-provider /area security /kind bug /remove-kind feature
Also secrets
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?
is it ok to close this issue also cc:
no, still remains
cc
seen this yet?
Thanks for the attention, we are using it as a fallback option mostly for test and dev env, we are working to remove them.
AFAIK is the only use for this testing. Would it be appropriate to move this code into ?
Submitted a PR to move password retrieval to
Change:
}) It("should provide DNS for ExternalName services", func() { <del> // TODO(xiangpengzhao): allow AWS when pull-kubernetes-e2e-kops-aws and pull-kubernetes-e2e-gce-etcd3 // have the same "service-cluster-ip-range". See: https://github.com/kubernetes/kubernetes/issues/47224 framework.SkipUnlessProviderIs("gce") </del> // Create a test ExternalName service. By("Creating a test externalName service") serviceName := "dns-test-service-3"

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): Note: Please file issues for subcomponents under the appropriate repo What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): HEAD Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: PR adds validation of clusterIP when changing service type. e2e test case failed after the PR because the validation of specified ClusterIP. This test case will run on both and . Unfortunately, the two CI jobs have different . ref: What you expected to happen: We should make config of CI jobs the same. How to reproduce it (as minimally and precisely as possible): See that PR. Anything else we need to know: /cc
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/assign
Change:
glog.V(3).Infof("Tearing down volume %v for pod %v at %v", c.volName, c.podUID, dir) // Wrap EmptyDir, let it do the teardown. <del> wrapped, err := c.plugin.host.NewWrapperUnmounter(c.volName, wrappedVolumeSpec, c.podUID) </del> <ins> wrapped, err := c.plugin.host.NewWrapperUnmounter(c.volName, wrappedVolumeSpec(), c.podUID) </ins> if err != nil { return err }

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
return response } <del> func (c *Cloud) getVpcCidrBlock() (*string, error) { </del> <ins> func (c *Cloud) getVpcCidrBlocks() ([]string, error) { </ins> vpcs, err := c.ec2.DescribeVpcs(&ec2.DescribeVpcsInput{ VpcIds: []*string{aws.String(c.vpcID)}, })

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!--What happened: When an AWS NLB is created through the Service of type, the health check security group rule is only created with a VPC primary CIDR block, as seen here: If the VPC has multiple CIDR blocks associated, and the worker nodes are running on those corresponding subnets, the health check fails. What you expected to happen: Multiple health check security group rules are created, one for each VPC CIDR block, using both and (). How to reproduce it (as minimally and precisely as possible): a VPC with with additional subnets created on a non-primary CIDR. a Kubernetes cluster (e.g. EKS) on subnets associated with a non-primary CIDR. a Service of type with nodes are healthy due to the security group rule being created only allowing traffic from the primary CIDR. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Amazon Linux 2 Kernel (e.g. ): Install tools: N/A Others: N/A
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Hi, i'll provide a fix next week
Change:
if c.ReadOnlyPort == 0 { c.ReadOnlyPort = 7080 } <ins> if c.ReadWritePort == 0 { c.ReadWritePort = 6443 } </ins> if c.CacheTimeout == 0 { c.CacheTimeout = 5 * time.Second } <del> if c.ReadWritePort == 0 { c.ReadWritePort = 443 } </del> for c.PublicAddress == nil { // Find and use the first non-loopback address. // TODO: potentially it'd be useful to skip the docker interface if it

Discussion:
Trying to hit the read-write kubernetes service from inside a cluster does not work. tailing the kube-proxy logs shows: And sure enough, kube-apiserver is not listening on the NIC on that port. 8080 is only for the localhost HTTP communications between master components (and nginx redirect after HTTPS termination). The "kubernetes" master service needs to get created with Port set to 443.
+1
This needs to be port 6443 the auth_port On Feb 6, 2015 10:14 AM, "Paulo Pires" wrote:
The code says 8443, but then a flag changes to 6443. Will fix. , Eric Tune wrote:
Holy macaroni this is a mess. , Tim Hockin wrote:
Change:
}, }), output: `Name:             bar <ins> Labels:           <none> </ins> Namespace:        foo Address: Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)

Discussion:
When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature
Change:
<!-- END MUNGE: UNVERSIONED_WARNING --> <del> This file has moved to: http://kubernetes.github.io/docs/user-guide/overview/ </del> <ins> This file has moved to: http://kubernetes.github.io/docs/user-guide/ </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In the Kubernetes documentation about it says: Based on , if I'm understanding correctly, this is somewhat misleading. It appears that what Kubernetes actually does is issue a command to each container, and it's Docker itself that decides what signal is send to pid 1 in the container. By default (as of 2020 Jul) it sends SIGTERM, but this can be configured during image build with the Dockerfile command, or at runtime with . The documentation would be altered to read (something like): It might also be the case that when Kubernetes "forcefully kill[s]" a pod, it uses rather than issuing a SIGKILL itself; if so, the relevant documentation should be updated to describe what Kubernetes actually does. Why is this needed: It would more accurately describe what happens during the pod termination process. For background: I spent a couple of hours trying to figure out why my container was receiving SIGQUIT instead of SIGTERM. Because the Kubernetes documentation said "a TERM signal is sent to the main process in each Docker container" and not "Kubernetes runs ", it didn't occur to me to look within Docker's documentation for ways in which the signal might be changed. I was unaware of until I stumbled across a which mentioned it. It turned out that the base image I was using had in it. Thanks!
/sig Docs
I would like to add this comment only because of my frustration after I spent hours to find out why doesn't generate as it was documented. Of course it happened because of in Dockerfile. Unfortunately it was totally not clear and almost impossible to find. Actually on custom () made this troubleshooting possible.