Question: // +listType=atomic Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"` // HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts <del> // file if specified. This is only valid for non-hostNetwork pods. </del> <ins> // file if specified. </ins> // +optional // +patchMergeKey=ip // +patchStrategy=merge

there is a note above hostAliases that this feature does not work with hostNework=true, yet it seems it does: when testing with a hostNetwork pod + hostAliases, there are no errors in kubelet logs at --v=10 related to this, in fact i don't see any hostAlias entries at all in there. i could not find anything blocking this in the kubelet, in fact there is normal handling of hostNetwork: i could not find any validation performed on the hostAliases field of PodSpec if hostNetwork is true on the API level. i could not find any unit tests or e2e tests related to this. the godoc should contain valid information if the feature is not supposed to work, it must be patched to not have the entries in the hosts file (perhaps?) we should have tests that ensure this type of requirement is guaranteed these steps confirm that a static pod with hostNework (deployed by kubeadm) does make use of hostAliases. create a kubeadm single node cluster directly with or one with modify the to include:wait some time for the new static pod spec to resync find the PID of the kube-apiserverget the hosts file n/a latest master 1.30.0-alpha.0 not applicable <details</detailskubeadm containerd v1.6.14 kindnet add test: update godoc:
/sig node network cluster-lifecycle /kind documentation
as reported by the hostAliases sometimes are not mounted for hostNetwork static pods, which is concerning: related slack thread:
At minimum the comment is wrong I need to be updated and we need e2e tests :/
found this, support was a while back: i will PR the API docs.
We identified an edge case here with Kubernetes v1.29. If a cloud provider did not yet initialise the node's , the code for creating the file including the hostAliases does not get run. To be concrete, in: is empty in this case which leads to to be . I was able to trace it back to this change which leads to this behaviour for static pods: For confirmation: I reverted the above commit, rebuilt kubelet and it got back to the old behaviour.

there is no perfect solution, but reverting is wrong because opens another bug, we need to study this more carefully but in the meantime installers that know the nodes addresses beforehand should set the --node-ip flag or not use cloud-provider external
yeah, as i mentioned downstream, revering is out of the question. it fixes some long standing problems. we might have to document somewhere this limitation in a cloud provider env.
i think it might be possible for us to special case this so that the hostAlias management does not wait for the node IP in a CP env, under certain conditions. just a speculation.
PRs add test: update godoc:
/triage accepted looks like it is being worked on already


Question: if err != nil { return err } <del> if len(externalIPs) > 0 { for _, externalIP := range externalIPs { err = testReachabilityOverExternalIP(externalIP, servicePort, pod) if err != nil { return err } } } </del> } return nil }

Which jobs are failing: Which test(s) are failing: - Since when has it been failing: Testgrid link: Reason for failure: Nov 4 11:59:41.385: Unexpected error: <*errors.errorString | 0xc00298c3d0: { s: "service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol", } service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol occurred Anything else we need to know: /priority important-soon /sig network /cc
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
Apparently this is related to /cc
if you're busy and want me to take a look tomorrow you can assign that to me and I can deep dive into what's missing/happening :) Happy to help and to understand better the flakiness life
so, the test adds a "fake" external IP that should be nated to the service endpoint It went through the CI, you can check the test here passing more details in the issue I opened explaining the test
ok, this is interesting the test is failing when using container runtime DOCKER https://k8s- the same periodic job that uses container runtime CONTAINERD (same as the PR) is working https://k8s- We need to understand what is different regarding the network in GCE jbos, when using docker as runtime, kubenet??? cc:
one diff between the working jobs with containerd and the failing ones with docker is that the failing ones use this part of the code for reference, kube-proxy adds the NAT rules here for external IPs here
IIRC you are using kubenet for azure jobs, are you using docker as runtime, can you please check if this tests fails there too?
The problem happens on environment that are using the bridge plugin, seems I got wrong the feature will revert until we have the right test.

We use kubenet only for IPv6 and dualstack jobs. Rest of the tests use Azure CNI. Default is docker runtime for all jobs.


Question: <ins> // +build !windows /* Copyright 2015 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package exec import "syscall" const X_OK = 0x1 func isExecutable(path string) bool { return syscall.Access(path, X_OK) == nil } </ins>

/priority critical-urgent /priority failing-test /kind bug /status approved-for-milestone This test has been failing since 2017-11-22 in which is on the , and prevents us from cutting [v1.9.0-beta.1] (kubernetes/sig-release). Is there work ongoing to bring this job back to green? https://k8s- first bad: https://k8s- this is also failing on (non-release-blocking) triage cluster suspect commit range:
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/remove-area platform/gke bad copy-pasta
This is a new test that was for a 1.9 alpha feature but actually exposed a bug with a different 1.8 alpha feature. Some discussion in . Since this seems to be a bug introduced in 1.8, I'm not sure if it needs to block 1.9. cc


Question: return err } <ins> // apply volume ownership if !c.readOnly && fsGroup != nil { err := volume.SetVolumeOwnership(c, fsGroup) if err != nil { // attempt to rollback mount. glog.Error(log("mounter.SetupAt failed to set fsgroup volume ownership for [%s]: %v", c.volumeID, err)) glog.V(4).Info(log("mounter.SetupAt attempting to unpublish volume %s due to previous error", c.volumeID)) if unpubErr := csi.NodeUnpublishVolume(ctx, c.volumeID, dir); unpubErr != nil { glog.Error(log( "mounter.SetupAt failed to unpublish volume [%s]: %v (caused by previous NodePublish error: %v)", c.volumeID, unpubErr, err, )) return fmt.Errorf("%v (caused by %v)", unpubErr, err) } if unmountErr := removeMountDir(c.plugin, dir); unmountErr != nil { glog.Error(log( "mounter.SetupAt failed to clean mount dir [%s]: %v (caused by previous NodePublish error: %v)", dir, unmountErr, err, )) return fmt.Errorf("%v (caused by %v)", unmountErr, err) } return err } glog.V(4).Info(log("mounter.SetupAt sets fsGroup to [%d] for %s", *fsGroup, c.volumeID)) } </ins> glog.V(4).Infof(log("mounter.SetUp successfully requested NodePublish [%s]", dir)) return nil }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When a volume for a CSI-based PV being mounted, the code does not apply the fsGroup value when the PV is marked as readOnly = false. What you expected to happen: if pv.readOnly == false, then the fsGroup ownership value should be applied to the mounted volume.
/assign /sig storage


Question: volumeMounts: - name: influxdb-persistent-storage mountPath: /data <del> - image: gcr.io/google_containers/heapster_grafana:v2.1.1 </del> <ins> - image: gcr.io/google_containers/heapster_grafana:v2.6.0-2 </ins> name: grafana env: resources:

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- gce-os-master-alpha-features kubernetes.Up 05.2021 log- & in this test are deprecated starting with this the tests are failing therefore I'm also pinging
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
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
Kubelet log:
It seems to be related with . /cc I read the context: fixed pull-kubernetes-e2e-gce-alpha-features job failure for PR . gce-os-master-alpha-features need a similar change.
I tried to fix it in
the PR seems to solved it, thank you!


Question: defer lb.lock.Unlock() state, exists := lb.services[svcPort] <del> if !exists { </del> <ins> if !exists || state == nil { </ins> return } for ip, affinity := range state.affinity.affinityMap {

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


Question: } // Get the pod again; it may have changed/been scheduled already. pod = &api.Pod{} <del> err := factory.Client.Get().Namespace(podID.Namespace).Resource("pods").Name(podID.Name).Do().Into(pod) if err != nil { if !errors.IsNotFound(err) { glog.Errorf("Error getting pod %v for retry: %v; abandoning", podID, err) </del> <ins> getBackoff := initialGetBackoff for { if err := factory.Client.Get().Namespace(podID.Namespace).Resource("pods").Name(podID.Name).Do().Into(pod); err == nil { break </ins> } <del> return </del> <ins> if errors.IsNotFound(err) { glog.Warning("A pod %v no longer exists", podID) return } glog.Errorf("Error getting pod %v for retry: %v; retrying...", podID, err) if getBackoff = getBackoff * 2; getBackoff > maximalGetBackoff { getBackoff = maximalGetBackoff } time.Sleep(getBackoff) </ins> } if pod.Spec.NodeName == "" { podQueue.AddIfNotPresent(pod)

If the first scheduling failed (whatever the reason is), the Error() func is called. However, the default Error function is wrong and in case of some errors may drop the pod and never requeue it for scheduling again. The problem is that if the Get() function: return an error (for me it was "dial tcp 127.0.0.1:8080: connect: cannot assign requested address", but it doesn't really matter), then we simply forget about a pod and will never schedule it again. We should retry those requests (with some backoff).


Question: return targetGroup, nil } <del> func (c *Cloud) getVpcCidrBlocks() ([]string, error) { vpcs, err := c.ec2.DescribeVpcs(&ec2.DescribeVpcsInput{ VpcIds: []*string{aws.String(c.vpcID)}, }) if err != nil { return nil, fmt.Errorf("error querying VPC for ELB: %q", err) } if len(vpcs.Vpcs) != 1 { return nil, fmt.Errorf("error querying VPC for ELB, got %d vpcs for %s", len(vpcs.Vpcs), c.vpcID) } cidrBlocks := make([]string, 0, len(vpcs.Vpcs[0].CidrBlockAssociationSet)) for _, cidr := range vpcs.Vpcs[0].CidrBlockAssociationSet { if aws.StringValue(cidr.CidrBlockState.State) != ec2.VpcCidrBlockStateCodeAssociated { continue } cidrBlocks = append(cidrBlocks, aws.StringValue(cidr.CidrBlock)) } return cidrBlocks, nil } </del> // updateInstanceSecurityGroupsForNLB will adjust securityGroup's settings to allow inbound traffic into instances from clientCIDRs and portMappings. // TIP: if either instances or clientCIDRs or portMappings are nil, then the securityGroup rules for lbName are cleared. <del> func (c *Cloud) updateInstanceSecurityGroupsForNLB(lbName string, instances map[InstanceID]*ec2.Instance, clientCIDRs []string, portMappings []nlbPortMapping) error { </del> <ins> func (c *Cloud) updateInstanceSecurityGroupsForNLB(lbName string, instances map[InstanceID]*ec2.Instance, subnetCIDRs []string, clientCIDRs []string, portMappings []nlbPortMapping) error { </ins> if c.cfg.Global.DisableSecurityGroupIngress { return nil }

<!-- 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: For each NLB created, K8s creates an ingress rule on the node group's security group for each port exposed for each CIDR attached to the VPC to allow health checks to succeed. AWS limits the number of rules per security group to 60 by default. This quota is adjustable but multiplied by the quota for security groups per network interface cannot exceed 1000. I have a VPC with 16 CIDR blocks attached to it and a quota for rules per security group set to 80. Each NLB created adds 18 new rules (16 for Health Check, 1 for Client, and 1 for MTU) to the node group's security groups. This high number of unnecessary rules created makes it impossible to create more than 4 NLBs per node group (if each one has a single port exposed). What you expected to happen: For the health check to succeed, the NLB must be able to ping the node port for the service on the cluster's node group. So the node group's security group just needs an inbound rule for each ENI of the NLB, making the number of rules necessary on the cluster's node group directly proportional to the number of AZs the NLB is configured. How to reproduce it (as minimally and precisely as possible): Create a VPC on AWS with 8 CIDRs attached to it; Create a K8s Cluster; Create a Network Load Balancer with 6 ports exposed; If the default quota of rules per security group has not been changed, the NLB creation will fail with RulesPerSecurityGroupLimitExceeded. 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 cloud-provider
/area provider/aws


Question: // Expect to only recheck DeletionTimestamp. f.expectGetDeploymentAction(d) // Sync should fail and requeue to let cache catch up. <del> f.runExpectError(getKey(d, t)) </del> <ins> // Don't start informers, since we don't want cache to catch up for this test. f.runExpectError(getKey(d, t), false) </ins> } // issue: https://github.com/kubernetes/kubernetes/issues/23218

From https://k8s- I've tried to reproduce locally in an endless loop but no failures so far. cc
Investigating.


Question: "google.golang.org/grpc" "google.golang.org/grpc/codes" <ins> "google.golang.org/grpc/metadata" </ins> "google.golang.org/grpc/status" "k8s.io/apimachinery/pkg/util/wait"

KMS Plugins require communication via grpc UDS. Currently, the k8s grpc client sets the authority header to the socket path which is marked as invalid preventing successful socket communication. I expect a custom KMS provider plugin to be sent valid authority headers so that successful communication can be established between the k8s and grpc client/server. Create a grpc server according to the and attempt to establish socket communication. This issue has been resolved in for device plugins and CSI. The same solution will likely fix this issue as well. I will create a PR for this and link it here after. <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig auth /triage accepted


Question: } now := metav1.Now() badValue := "spaces not allowed" <ins> badAPIGroup := "example.com/v1" goodAPIGroup := "example.com" </ins> scenarios := map[string]struct { template     *resource.ResourceClaimTemplate

Following YAML file is accepted without error. Notice the field, it is an instead of , containing character. This can lead to an issue when resource driver generates structured parameters' in-tree object with being just without version. The DRA scheduler plugin will try to match the parameters object based on the reference here: In latest master the code appears to use an indexer, and the issue might be hidden, if applicable at all. I did not check the reproducibility in master yet. However, main question is whether the should allow value with character in general. An error is expected from the apiserver upon object creation request, reporting that APIGroup containes APIVersion. Maybe. Have any resource driver that supports structured parameters, , for instance, also puts (gpucrd.APIGroup) value into . v1.30.1 <details</details<details</details<details</details<details</details<detailsscheduler's dynamicresources plugin </details
/sig node /triage accepted
/assign


Question: apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" clientset "k8s.io/client-go/kubernetes"

This issue was supposed to have fixed the issue where endpoint stay out of sync I also wrote a small script which would get me the out of sync endpoints compared to the endpointslices I expect the endpoints to eventually sync and reflect the most upto date information. I have just deployed the newer patch to our cluster and that has resulted in endpoints never ending up being updated if the status goes out of sync. No response Client Version: v1.29.7 Kustomize Version: v5.0.4-0.- Server Version: v1.29.7 <details</detailsalmalinux-9 <details</detailscri-o No response
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 network
from the logs, endpoint controller was retrying test1/test-qa in the expected way. It has retried 5 times and the next retry should be after 320ms, which should long enough for the informer cache to get the updated endpoints. If there is no more logs related to the failure, I think it may have synced it successfully. The python script used to detect the failure seems capturing diff between endpoints and endpointslice at a moment, but that could happen if there is any Pod change in the cluster, and technically the script is comparing endpoints of one moment with endpointslice of another moment. So did you see the endpoints not being synced after endpoint controller stopped retrying it?
Yeah i still see it and see similar messages continuously. Let me post some additional log messages after the one i posted above.
Observed the same issue in 1.29 and 1.30. I keep seeing the same error then new pods were behind a service. And the endpoint never catch up after all pods are settled.
could you provide complete log of kube-controller-manager and the yamls of the related endpoints and endpointslice?
/assign Are you able to triage this since you are already looking at this?

Yes i can get that over by EOD today
Sure, I'm waiting for more logs and the content of the endpoints to understand how it happened. Currently there are only retry logs which is expected in some cases.
We found a customer that triggered an edge case in your change of , which will cause Endpoints never updated. They have a mutatingWebhook on Endpoints object that automatically injects a label, let's say . syncServices, the endpoints controller , and they won't match since Endpoints have the extra "dummy-k: value". endpoints controller will by removing the label. mutatingWebhook will automatically adds back the label as part of the update request. From the APIServer's POV, the Endpoints object don't have any changes, thus the update request will succeed but returns the same resourceVersion as before. change in will mark that resourceVersion as stale. future pods events won't be handled correctly due to the step didn't result in a new resourceVersion. I think we should fix this by check the resulting resourceVersion from the update request, and only mark the old resourceVersion as stale when a new resourceVersion is generated. Not sure whether this is the same case others in this thread encountered :D
thanks for explaining the use case and the analysis. I did analyze the code after the issue was opened and suspected the only possibility is the returned resource version somehow equals to the one in the request but didn't know how it could happen after it has checked the desired endpoints and the current endpoints are different: Now I understand this could happen when the endpoints appear different on client side but are mutated to be same on server side. Do you plan to create a PR since you have proposed a fix? could you confirm if this is also your case, i.e. there is a mutatingWebhook for endpoints objects that could make the endpoints different from what endpoints controller expects?
Yeah, i can do a fix for this
- can we assign to you?
Sure, I'm already assigned. Given that we've had three user reports on this issue, I think it's important to address it as soon as possible. Could you please let me know when you plan to create the PR? If you're currently occupied, I'm happy to handle it and submit the PR.
Sorry, were occupied by some internal incidents last week. Just created a WIP PR for it.

Will test it in kops for this specific webhook scenario in the following two days and and remove the WIP flag
/assign


Question: glog.V(2).Infof("Error while reading product_name: %v", err) return false } <del> return strings.Contains(string(data), googleProductName) </del> <ins> name := strings.TrimSpace(string(data)) return name == "Google" || name == "Google Compute Engine" </ins> } // Enabled implements DockerConfigProvider for all of the Google implementations.

/kind bug What happened: Attempting to start kubelet on CoreOS machine with latest stable (). I have many other blades which are PXE booting where the commands work. For some reason on this box where CoreOS is installed to disk, it is not working. I have checked every possible setting and file and they are all identical ( permissions and values ). What you expected to happen: Kubelet to start and start up manifests ( api, proxy, controller ). How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet never actually starts a docker container. Doing doesn't show anything exited. I can docker pull the images from google. I've tried almost every setting I can change over the past 2 days. Environment: Kubernetes version (use ): I've tried both: v1.8.5 and v1.9.0 Cloud provider or hardware configuration: Dell R720XD. 24core 64gb ram, 22 SSDs. Most are ceph OSDs, sda is raid 1 SSDs for the OS and ideally kubernetes master. Bonded 10G cards for private network ( flannel ) and bonded 1g cards for public network. OS (e.g. from /etc/os-release): Kernel (e.g. ):Install tools: Baremetal plain install. No tools used. Others: Downloaded the bins into /opt/bin/ as described in kubernetes docs. The node is a member of etcd cluster. Manifests files are the usual, but kubelet doesn't get that far so I dont want to clutter and post configs. Systemd Kubelet Config: master- Logs from kubelet: After days of debugging, I believe it has to do with these lines in the logs: When it tries to connect to the docker-shim which it creates, on the other machines it looks like this: The success message never gets printed on the failing node. Both are identical. Flannel is up and running and can ping other flannel IPs on the network. Both docker infos are: The running containers are the OSDs.
/sig node /sig cluster-lifecycle
what are the contents of your file? looks like at least a few logs think that you are running on GCE example the log from here -
VERY interesting contents actually.

The actual device is a second hand Dell R720XD, GSA ( Google Search Appliance ) ! The contents of the file are: Yes, and even when I put it still looked for it. I spent 3 days on the issue but eventually gave up - which is rare. I tried running the kubelet in rkt, docker and just the bin on coreOS itself. No matter what it could never actually start a manifest container. It never actually reached the "kubelet started". The http port never responded either. I'd be happy to attempt it again if you think this is the cause.
wow!!! yes, if you can fix the product_name somehow, i'll help you move along :) cross my fingers
Good sir, Go0o0o0o0oood sir - after literally almost 72hrs of little to no sleep, trying every possible thing I could imagine, your simple suggestion has fixed it... You have no idea how grateful I am! lol Since rebranding the BIOS back to dell from google is a pain ( ) I am running the kubelet in rkt, and just mounting a file to that path. The just contains . Everything is up and running as expected when I started this journey lol. THANK YOU for taking the time to help.


Question: }, }, }, <del> "spec.template.spec.restartPolicy: Unsupported value": { </del> <ins> "spec.template.spec.restartPolicy: Required value": { </ins> ObjectMeta: metav1.ObjectMeta{ Name:      "myjob", Namespace: metav1.NamespaceDefault,

<!-- 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: Deployed an cronJob with an empty and it defaulted to which is an invalid option: Leaving the key out completely has the same result What you expected to happen: The empty key to default to something valid like or . Also document what this default is, my proposal would be to have as default since some tasks can't be reran easily. But it might be nice to force as default to enforce the stateless mindset even for crons :) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I guess not but I am open for questions :) Environment: Kubernetes version (use ): 1.19.2
My guess would be /sig api-machinery If it is better practice to wait for the triage instead of guessing the sig, let me know :+1:
/sig api-machinery
/assign
/remove-sig api-machinery /sig apps
/assign
/triage accepted


Question: func (runtime *DockerRuntime) RemoveContainers(containers []string) error { errs := []error{} for _, container := range containers { <del> out, err := runtime.exec.Command("docker", "rm", "--force", "--volumes", container).CombinedOutput() </del> <ins> out, err := runtime.exec.Command("docker", "stop", container).CombinedOutput() </ins> if err != nil { // don't stop on errors, try to remove as many containers as possible <del> errs = append(errs, errors.Wrapf(err, "failed to remove running container %s: output: %s, error", container, string(out))) </del> <ins> errs = append(errs, errors.Wrapf(err, "failed to stop running container %s: output: %s, error", container, string(out))) } else { out, err = runtime.exec.Command("docker", "rm", "--volumes", container).CombinedOutput() if err != nil { errs = append(errs, errors.Wrapf(err, "failed to remove running container %s: output: %s, error", container, string(out))) } </ins> } } return errorsutil.NewAggregate(errs)

<!-- 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: Run on a work node of kubernetes. Containers are killed, instead of exiting normally. Some resources are not released such as vips created by keepalived. What you expected to happen: The container exits properly so that system resources are released correctly How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: , line 139: Can I try to stop containers before removing them? Environment: Kubernetes version (use ): v1.18.5 Cloud provider or hardware configuration: OS (e.g: ): CentOS 7.4.1708 Kernel (e.g. ): 3.10.0-1127.18.2.el7.x86_64 Install tools: kubeadm
/sig cluster-lifecycle These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.
/area kubeadm /remove-kind bug /kind feature there is some discussion / Qs on the PR.


Question: portMapping(v1.ProtocolTCP, 1234, 5678, ""), }, }, <ins> { // The same container port can be mapped to different host ports &v1.Container{ Name: "fooContainer", Ports: []v1.ContainerPort{ port("", v1.ProtocolTCP, 443, 4343, "192.168.0.1"), port("", v1.ProtocolTCP, 4343, 4343, "192.168.0.1"), }, }, []PortMapping{ portMapping(v1.ProtocolTCP, 443, 4343, "192.168.0.1"), portMapping(v1.ProtocolTCP, 4343, 4343, "192.168.0.1"), }, }, { // The same container port AND same container host is not OK &v1.Container{ Name: "fooContainer", Ports: []v1.ContainerPort{ port("", v1.ProtocolTCP, 443, 4343, ""), port("", v1.ProtocolTCP, 443, 4343, ""), }, }, []PortMapping{ portMapping(v1.ProtocolTCP, 443, 4343, ""), }, }, { // multihomed nodes - multiple IP scenario &v1.Container{ Name: "fooContainer", Ports: []v1.ContainerPort{ port("", v1.ProtocolTCP, 443, 4343, "192.168.0.1"), port("", v1.ProtocolTCP, 443, 4343, "172.16.0.1"), }, }, []PortMapping{ portMapping(v1.ProtocolTCP, 443, 4343, "192.168.0.1"), portMapping(v1.ProtocolTCP, 443, 4343, "172.16.0.1"), }, }, </ins> } for i, tt := range tests {

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: A container ports spec such as: Results in this error: From . Because of this, the port mappings are not setup correctly on the host when using a CNI-compliant portmap solution. What you expected to happen: Auto-generated port names should never result in duplicates How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig node Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-01-16T21:59:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.11", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-04-05T17:16:46Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: VirtualBox OS (e.g. from /etc/os-release): Ubuntu Kernel (e.g. ): Linux node2 4.4.0-104-generic -Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others:
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
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
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
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
/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
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
I see that the problem is legit, but is this setup frequently used? why not using services instead of hostports? I mean, it will complicate more the solution but will provide a good abstraction and remove the dependency on the node.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Why is this still an issue?
Issues go stale after 90d of inactivity.


Question: return } <del> fs.StringVar(&o.BindAddress, "address", o.BindAddress, "DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). See --bind-address instead.") </del> <ins> fs.StringVar(&o.BindAddress, "address", o.BindAddress, "DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 or :: for listening in all interfaces and IP families). See --bind-address instead.") </ins> // MarkDeprecated hides the flag from the help. We don't want that: // fs.MarkDeprecated("address", "see --bind-address instead.") fs.IntVar(&o.BindPort, "port", o.BindPort, "DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve plain HTTP at all. See --secure-port instead.")

<!-- 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: There are flag descriptions where is stated that the unspecified address behaves differently depending on the IP family: However, that's not the behavior implemented in and , clarified in the golang documentation What you expected to happen: Fix the comment to state the reality, i.e How to reproduce it (as minimally and precisely as possible): From the root of the kubernetes repo Anything else we need to know?: xref 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:
/kind cleanup /help wanted /good-first-issue /priority important-longterm /cc
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.
/assign /remove-help
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
For the flag in kube-proxy, is used if the address is not specified and can't be resolved by hostname, so I suggest to remove this comment: 0.0.0.0::` for all IPv6 interfaces'
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
/remove-triage unresolved
I am very much in favor of this. Being correct and precise in these flags is valuable. To convince myself you were right, I wrote this program: And then I ran it for various inputs: In these flags and docs, we should be clear that if you are specifying a v6 addr and port you have to use syntax. Or maybe we should just audit and fix ALL such places to support and document that "nothing" is how you specify all interfaces. E.g. --bind-address=":80" is more obvious than either "0.0.0.0:80" or "[::]:80".

Even if those syntaxes work, let's just make "" the norm?
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 /lifecycle frozen
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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


Question: } } <ins> type injectListError struct { errors int storage.Interface } func (self *injectListError) List(ctx context.Context, key string, resourceVersion string, filter storage.FilterFunc, listObj runtime.Object) error { if self.errors > 0 { self.errors-- return fmt.Errorf("injected error") } return self.Interface.List(ctx, key, resourceVersion, filter, listObj) } </ins> func TestWatch(t *testing.T) { server, etcdStorage := newEtcdTestStorage(t, testapi.Default.Codec(), etcdtest.PathPrefix()) <ins> // Inject one list error to make sure we test the relist case. etcdStorage = &injectListError{errors: 1, Interface: etcdStorage} </ins> defer server.Terminate(t) cacher := newTestCacher(etcdStorage) defer cacher.Stop()

cc
This is still hapening. Assigning Isaac for triage.
Three times in the last three days, BeforeSuite failed (filed ). Otherwise, just Namespaces [Serial] should delete fast enough (90 percent of 100 namespaces in 150 seconds) is just totally borked (filed ). what prevented you from triaging this yourself? It'd be good to know so I'm less in the critical path.
Sorry, I read this wrong. I was looking at the gke-serial suite. Triaging now.
It looks like massive failures are correlated extremely strongly with failure of Etcd failure [Disruptive] should recover from SIGKILL Every time that test passes, everything else (except ) passes; every time it fails, the whole suite goes south. Reassigning to for triage.
sorry for delegating the work to you, but I completely didn't have time to do it and nobody else hasn't volunteered to do it for a while. it seems you are the author of the test, so assigning you.
No problem Just wanted to make sure there wasn't some information missing.
I'm looking at this today
It looks like the token controller is not recovering from etcd failing. The test namespace is also stuck in a terminating phase. I'll continue to investigate
Actually lot's of watch related things are broken. I can create/delete objects in the api but watch is broken. Trying to establish a watch in this state causes: Restarting the apiserver fixes the problem. I can start a watch again: cc
Not particularly useful apiserver logs Also none of the components are trying to reestablish watches so I'm assuming that they still have watches open but are not receiving anything.
startCaching is trying to lock here, but something is holding the lock. I'm looking through a stack trace right now for the offender. This is exactly where I'd expect a problem to be from the description of "bringing etcd down and up repeatedly".
Ah I think what happened is, when etcd stays down, a List never successfully finishes, and therefore it never calls the OnReplace function, and therefore the lock is never unlocked, and therefore startCaching can't exit.

There's lots in apiserver log to support this: Additionally I manually looked through the stack trace and confirmed that all of the stuck calls to Watch are stuck waiting to RLock and not some point afterwards.
This is pretty bad, etcd going down for just a bit could freeze up apiserver until it is rebooted.
I think I can make a fix.
Thanks for looking into this.
Yeah, I repro'd in a UT. Fix coming shortly.
I assigned to but if anyone wants it merged sooner than monday, feel free to review.
Many thanks to for handing me a broken server to look at, it made this super easy to find.


Question: <ins> // +build windows /* Copyright 2015 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package exec func isExecutable(path string) bool { return false } </ins>

/priority critical-urgent /priority failing-test /kind bug /status approved-for-milestone This test has been failing since 2017-11-22 in which is on the , and prevents us from cutting [v1.9.0-beta.1] (kubernetes/sig-release). Is there work ongoing to bring this job back to green? https://k8s- first bad: https://k8s- this is also failing on (non-release-blocking) triage cluster suspect commit range:
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/remove-area platform/gke bad copy-pasta
This is a new test that was for a 1.9 alpha feature but actually exposed a bug with a different 1.8 alpha feature. Some discussion in . Since this seems to be a bug introduced in 1.8, I'm not sure if it needs to block 1.9. cc


Question: return starts, nil } <del> // XXX unit test this </del> // getJobFromTemplate makes a Job from a CronJob func getJobFromTemplate(sj *batchv2alpha1.CronJob, scheduledTime time.Time) (*batchv1.Job, error) { // TODO: consider adding the following labels:

<!-- 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 feature What happened: There are some unused commet, these are meaningless. And some function‘s comment does not follow go style. What you expected to happen: We should delete them all. and fix comment following golang style 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:
/assign
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
can you edit the PR description in to say instead of ? That would automatically close this issue once the PR is merged. :)
OK, no problem~:)


Question: framework.ConformanceIt("should release no longer matching pods", func() { testRCReleaseControlledNotMatching(f) }) <ins> ginkgo.It("should test the lifecycle of a ReplicationController", func() { testRcName := "rc-test" testRcNamespace := ns testRcInitialReplicaCount := int32(1) testRcMaxReplicaCount := int32(2) rcResource := schema.GroupVersionResource{Group: "", Version: "v1", Resource: "replicationcontrollers"} rcTest := v1.ReplicationController{ ObjectMeta: metav1.ObjectMeta{ Name:   testRcName, Labels: map[string]string{"test-rc-static": "true"}, }, Spec: v1.ReplicationControllerSpec{ Replicas: &testRcInitialReplicaCount, Selector: map[string]string{"test-rc-static": "true"}, Template: &v1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Name:   testRcName, Labels: map[string]string{"test-rc-static": "true"}, }, Spec: v1.PodSpec{ Containers: []v1.Container{{ Name:  testRcName, Image: "nginx", }}, }, }, }, } ginkgo.By("creating a ReplicationController") // Create a ReplicationController _, err := f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).Create(context.TODO(), &rcTest, metav1.CreateOptions{}) framework.ExpectNoError(err, "Failed to create ReplicationController") // setup a watch for the RC rcWatchTimeoutSeconds := int64(180) rcWatch, err := f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).Watch(context.TODO(), metav1.ListOptions{LabelSelector: "test-rc-static=true", TimeoutSeconds: &rcWatchTimeoutSeconds}) framework.ExpectNoError(err, "Failed to setup watch on newly created ReplicationController") rcWatchChan := rcWatch.ResultChan() ginkgo.By("waiting for available Replicas") for event := range rcWatchChan { rc, ok := event.Object.(*v1.ReplicationController) framework.ExpectEqual(ok, true, "Unable to convert type of ReplicationController watch event") if rc.Status.Replicas == testRcInitialReplicaCount && rc.Status.ReadyReplicas == testRcInitialReplicaCount { break } } rcLabelPatchPayload, err := json.Marshal(v1.ReplicationController{ ObjectMeta: metav1.ObjectMeta{ Labels: map[string]string{"test-rc": "patched"}, }, }) framework.ExpectNoError(err, "failed to marshal json of replicationcontroller label patch") // Patch the ReplicationController ginkgo.By("patching ReplicationController") _, err = f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).Patch(context.TODO(), testRcName, types.StrategicMergePatchType, []byte(rcLabelPatchPayload), metav1.PatchOptions{}) framework.ExpectNoError(err, "Failed to patch ReplicationController") rcStatusPatchPayload, err := json.Marshal(map[string]interface{}{ "status": map[string]interface{}{ "readyReplicas":     0, "availableReplicas": 0, }, }) framework.ExpectNoError(err, "Failed to marshal JSON of ReplicationController label patch") // Patch the ReplicationController's status ginkgo.By("patching ReplicationController status") rcStatus, err := f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).Patch(context.TODO(), testRcName, types.StrategicMergePatchType, []byte(rcStatusPatchPayload), metav1.PatchOptions{}, "status") framework.ExpectNoError(err, "Failed to patch ReplicationControllerStatus") framework.ExpectEqual(rcStatus.Status.ReadyReplicas, int32(0), "ReplicationControllerStatus's readyReplicas does not equal 0") ginkgo.By("fetching ReplicationController status") rcStatusUnstructured, err := dc.Resource(rcResource).Namespace(testRcNamespace).Get(testRcName, metav1.GetOptions{}, "status") framework.ExpectNoError(err, "Failed to fetch ReplicationControllerStatus") rcStatusUjson, err := json.Marshal(rcStatusUnstructured) framework.ExpectNoError(err, "Failed to marshal json of replicationcontroller label patch") json.Unmarshal(rcStatusUjson, &rcStatus) framework.ExpectEqual(rcStatus.Status.Replicas, testRcInitialReplicaCount, "ReplicationController ReplicaSet cound does not match initial Replica count") rcScalePatchPayload, err := json.Marshal(autoscalingv1.Scale{ Spec: autoscalingv1.ScaleSpec{ Replicas: testRcMaxReplicaCount, }, }) framework.ExpectNoError(err, "Failed to marshal json of replicationcontroller label patch") // Patch the ReplicationController's scale ginkgo.By("patching ReplicationController scale") _, err = f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).Patch(context.TODO(), testRcName, types.StrategicMergePatchType, []byte(rcScalePatchPayload), metav1.PatchOptions{}, "scale") framework.ExpectNoError(err, "Failed to patch ReplicationControllerScale") var rcFromWatch *v1.ReplicationController ginkgo.By("waiting for ReplicationController's scale to be the max amount") foundRcWithMaxScale := false for event := range rcWatchChan { rc, ok := event.Object.(*v1.ReplicationController) framework.ExpectEqual(ok, true, "Unable to convert type of ReplicationController watch event") if rc.ObjectMeta.Name == testRcName && rc.ObjectMeta.Namespace == testRcNamespace && rc.Status.Replicas == testRcMaxReplicaCount && rc.Status.ReadyReplicas == testRcMaxReplicaCount { foundRcWithMaxScale = true rcFromWatch = rc break } } framework.ExpectEqual(foundRcWithMaxScale, true, "failed to locate a ReplicationController with max scale") framework.ExpectEqual(rcFromWatch.Status.Replicas, testRcMaxReplicaCount, "ReplicationController ReplicasSet Scale does not match the expected scale") // Get the ReplicationController ginkgo.By("fetching ReplicationController; ensuring that it's patched") rc, err := f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).Get(context.TODO(), testRcName, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to fetch ReplicationController") framework.ExpectEqual(rc.ObjectMeta.Labels["test-rc"], "patched", "ReplicationController is missing a label from earlier patch") rcStatusUpdatePayload := rc rcStatusUpdatePayload.Status.AvailableReplicas = 1 rcStatusUpdatePayload.Status.ReadyReplicas = 1 // Replace the ReplicationController's status ginkgo.By("updating ReplicationController status") rcStatus, err = f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).UpdateStatus(context.TODO(), rcStatusUpdatePayload, metav1.UpdateOptions{}) framework.ExpectNoError(err, "failed to update ReplicationControllerStatus") framework.ExpectEqual(rcStatus.Status.ReadyReplicas, int32(1), "ReplicationControllerStatus readyReplicas does not equal 1") ginkgo.By(fmt.Sprintf("waiting for ReplicationController readyReplicas to be equal to %v", testRcMaxReplicaCount)) for event := range rcWatchChan { rc, ok := event.Object.(*v1.ReplicationController) framework.ExpectEqual(ok, true, "unable to convert type of ReplicationController watch event") if rc.Status.Replicas == testRcMaxReplicaCount && rc.Status.ReadyReplicas == testRcMaxReplicaCount { break } } ginkgo.By("listing all ReplicationControllers") rcs, err := f.ClientSet.CoreV1().ReplicationControllers("").List(context.TODO(), metav1.ListOptions{LabelSelector: "test-rc-static=true"}) framework.ExpectNoError(err, "failed to list ReplicationController") framework.ExpectEqual(len(rcs.Items) > 0, true) ginkgo.By("checking that ReplicationController has expected values") foundRc := false for _, rcItem := range rcs.Items { if rcItem.ObjectMeta.Name == testRcName && rcItem.ObjectMeta.Namespace == testRcNamespace && rcItem.ObjectMeta.Labels["test-rc-static"] == "true" && rcItem.ObjectMeta.Labels["test-rc"] == "patched" && rcItem.Status.Replicas == testRcMaxReplicaCount && rcItem.Status.ReadyReplicas == testRcMaxReplicaCount { foundRc = true } } framework.ExpectEqual(foundRc, true) // Delete ReplicationController ginkgo.By("deleting ReplicationControllers by collection") err = f.ClientSet.CoreV1().ReplicationControllers(testRcNamespace).DeleteCollection(context.TODO(), &metav1.DeleteOptions{}, metav1.ListOptions{LabelSelector: "test-rc-static=true"}) framework.ExpectNoError(err, "Failed to delete ReplicationControllers") ginkgo.By("waiting for ReplicationController to have a DELETED event") for event := range rcWatchChan { if event.Type == "DELETED" { break } } }) </ins> }) func newRC(rsName string, replicas int32, rcPodLabels map[string]string, imageName string, image string, args []string) *v1.ReplicationController {

According to this APIsnoop query, there are still some remaining ReplicationController endpoints which are untested. Create a ReplicationController with a static label Patch the ReplicationController with a new Label and updated data Patch the ReplicationController's status Patch/Scale the ReplicationController's Replica count to 2 Replicas Get the ReplicationController Replace the ReplicationController's Status List all ReplicationControllers in all Namespaces find the ReplicationControllers(1) ensure that the ReplicationController is found and is patched Delete Namespaced ReplicationControllers(1) via a Collection with a LabelSelector Discover useragents: See all endpoints hit from this test Display test coverage change If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Deployment replaced ReplicationController a while back. It should be part of conformance. We need to check more than the data-aspect (beyond crud), we need to verify the data-plane. In this case we need to check the pods as well and not just the ReplicationController status. Moved to backlog by conformance subgroup.
PR:
/open /reopen We need this open to track the test promotion and flakyness. We can't write a promotion PR until the test has no flakes for 2 weeks.
Reopened this issue. <detailsIn response to : /open /reopen We can't write a promotion PR until the test has no flakes for 2 weeks. 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
/retitle Promote CoreV1ReplicationController lifecycle mock test - +7 coverage Need to verify two weeks on non-flakeyness.
/retitle Write CoreV1ReplicationController lifecycle test+promote - +7 coverage
Closing in favour of /close
Closing this issue. <detailsIn response to : Closing in favour of /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


Question: // from container runtime. BlockImagePulls      bool imagePullTokenBucket chan bool <del> T                    *testing.T </del> <ins> T                    TB </ins> } const FakeHost = "localhost:12345"

We have many "test only" packages through out the project, containing fixtures, helpers, utilities, etc... These test libraries are not intended for use in production binaries. They often lack rigorous review and sufficient testing for use in production binaries. We should make sure they don't accidentally get pulled in. Strawman proposal, test only packages must import "testing". Blank import is sufficient: Then write a presubmit that fails if we find symbol in the release binary. This approach is trivial and fairly effective although a more sophisticated approach could print a dep chain.
/assign
I hope I will be able to contribute once this gets marked as .
/triage accepted
I think that will be enough a new script or a check in the building scripts /cc since he has experience from the providerless building effort
I got what we want to achieve here but I'm little confused about: If I execute: after adding the import then only it is giving - what do we want to achieve by executing this command exactly? I got what it is doing. I've opened a thread in slack as well:
Hello! Is there anyone working on this issue at the moment? If not and the issue it's still relevant, I would like to work on it if possible. Thank you.
I opened a PR in the meantime, if it's not needed anymore, I can close it.


Question: "strings" "time" <ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" testutils "k8s.io/kubernetes/test/utils" </ins> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Test: [sig-node] Restart [Serial] [Slow] [Disruptive] Kubelet should correctly account for terminated pods after restart I've also seen on /kind flake /sig node Looks like occasionally we have a second 50m CPU pod hanging around on the node, blocking enough pods getting scheduled for the test: I'm a bit puzzled because no pods are listed as currently running when the node dumps debug info. Could be a bug?
another case [sig-node] Container Manager Misc [Serial] Validate OOM score adjustments [NodeFeature:OOMScoreAdj] affected the Restart test case, see the kubelet log, the kubelet-container-manager guaranteede9d81584 pod was received almost simultaneously with the restart-test pod
Since at 0316 21:25:08, the container of pod guaranteede9d81584 has just been creating, but the test case [sig-node] Container Manager Misc [Serial] has already finished at 0316 21:25:06, so the test case check condition may be not strict
/triage accepted /assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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


Question: } experimentalQOSReserved, err := cm.ParseQOSReserved(s.QOSReserved) if err != nil { <del> return err </del> <ins> return fmt.Errorf("--qos-reserved value failed to parse: %w", err) </ins> } var cpuManagerPolicyOptions map[string]string

During kubelet start up if the system reserved or kube reserved values failed to parse, the kubelet won't start up. The error logged looks like, However, it doesn't not inform the user which system reserved or kube reserved quantity has failed and what was the corresponding value of that quantity. The error log should also container quantity type and the value that failed to parse, so that user can fix them easily. Try to start kubelet with unparsable values of system reserved, something like, The error logged would look like, As you can see above, it doesn't say was not able to parse with the value No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind feature /sig node
/assign
Thanks for Should I close in favour of yours?
Oh sorry, I didn't see your PR. Either way works for me. You can either incorporate ideas from my PR and I'll drop mine, or drop your PR. I don't feel strongly either way.
/triage accepted /priority backlog /assign
Let's go with yours!
Thanks /close (in favor of )
Closing this issue. <detailsIn response to : Thanks (in favor of ) 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


Question: See our documentation on [kubernetes.io]. <del> Try our [interactive tutorial]. </del> Take a free course on [Scalable Microservices with Kubernetes]. To use Kubernetes code as a library in other applications, see the [list of published components](https://git.k8s.io/kubernetes/staging/README.md).

Hello, Upon visiting the . There is a link for interactive tutorial which is being inactive. Error from (k8 page)[] is ! We have to remove the page link.
label:sig/docs
/sig docs /kind documentation
Per let's delete this reference for now and we can add something later potentially following
/triage accepted /assign


Question: func formatCPUSummary(summary framework.ContainersCPUSummary) string { // Example output for a node (the percentiles may differ): <del> // CPU usage of containers on node "e2e-test-foo-node-0vj7": </del> <ins> // CPU usage of containers: </ins> // container        5th%  50th% 90th% 95th% // "/"              0.051 0.159 0.387 0.455 // "/runtime        0.000 0.000 0.146 0.166

<!-- 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: Now, benchmark test make docker as the only runtime. What you expected to happen: benchmark test should be generic to all CRI container runtimes Related to 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:
/area test /area node-e2e
/sig node


Question: package api import ( <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/runtime" )

has a dependency on pkg/api for , which it embeds in . Is it doing that to take advantage of validation code, or can Config just declare and directly and avoid the dependency?
A quick try (just declaring a in the package) seems to work fine with . I only included those out of habit.
Out of curiosity, is this just for a proper separate of packages or is there some functional issue as well?
mentioned encountering an issue with tests, but it's mostly just for proper separation of packages.
Related: Remove json tags from
See also
Not done:


Question: "github.com/GoogleCloudPlatform/kubernetes/pkg/client/clientcmd" ) <ins> func NewClientCache(loader clientcmd.ClientConfig) *clientCache { return &clientCache{ clients: make(map[string]*client.Client), configs: make(map[string]*client.Config), loader:  loader, } } </ins> // clientCache caches previously loaded clients for reuse, and ensures MatchServerVersion // is invoked only once type clientCache struct { loader        clientcmd.ClientConfig clients       map[string]*client.Client <ins> configs       map[string]*client.Config </ins> defaultConfig *client.Config matchVersion  bool }

This seems like a bug to me No output, and command exits success... wat. Have to explicitly pass to see expected output. If the client version is greater the server version, it should be making requests based on the server's newest accepted apiversion.
cc


Question: * You may co-own fields by updating your manifest to match the existing value; in this case, you'll become the manager if the other manager(s) stop managing the field (remove it from their configuration). See http://k8s.io/docs/reference/using-api/api-concepts/#conflicts`, err) } return err

What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc


Question: source "${KUBE_ROOT}/test/cmd/authorization.sh" source "${KUBE_ROOT}/test/cmd/batch.sh" source "${KUBE_ROOT}/test/cmd/certificate.sh" <ins> source "${KUBE_ROOT}/test/cmd/convert.sh" </ins> source "${KUBE_ROOT}/test/cmd/core.sh" source "${KUBE_ROOT}/test/cmd/crd.sh" source "${KUBE_ROOT}/test/cmd/create.sh"

was removed in 1.20 in favor of a plugin. However, this is not included in release artifacts. The binary is included in release artifacts, and ideally easily installable via kubectl plugin managers like . /sig cli /assign
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
This question came up in a docs review of a page referencing () Once this is resolved, please ensure the website is updated to document installation/use of this tool.
/sig release


Question: rbac.NewRule("get", "list", "watch").Groups(storageGroup).Resources("storageclasses").RuleOrDie(), rbac.NewRule("get", "create", "delete").Groups(legacyGroup).Resources("services", "endpoints").RuleOrDie(), rbac.NewRule("get").Groups(legacyGroup).Resources("secrets").RuleOrDie(), <ins> // openstack rbac.NewRule("get", "list").Groups(legacyGroup).Resources("nodes").RuleOrDie(), </ins> // recyclerClient.WatchPod rbac.NewRule("watch").Groups(legacyGroup).Resources("events").RuleOrDie(),

Is this a request for help? : No What keywords did you search in Kubernetes issues before filing this one? : PVC, Openstack, RBAC Is this a BUG REPORT or FEATURE REQUEST? : BUG REPORT Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-19T18:44:27Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.4.666+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-05-30T09:26:07Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-47-generic Install tools: kubeadm Others: N/A What happened: kube-controller-manager could not list nodes becase of missing permission for persistent-volume-binder service account. What you expected to happen: persistent-volume-binder service account should be able to list nodes. How to reproduce it (as minimally and precisely as possible): bootstrap a cluster with RBAC and try to create cinder PVC on openstack. Anything else we need to know:
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 .
/sig auth


Question: glog.Errorf("Failed to kill container %q(id=%q) in pod %q: %v, %v", container.Name, kubeContainerID.String(), format.Pod(pod), ErrPostStartHook, err) } <del> return msg, ErrPostStartHook </del> <ins> return msg, fmt.Errorf("%s: %v", ErrPostStartHook, handlerErr) </ins> } }

<!-- 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: NO FailedPostStartHook Error Message After Upgrade to 1.7.8 When we use 1.6.3 , We can get message like Error syncing pod, skipping: failed to "StartContainer" for "xxxx" with PostStart handler: command '/xxxxxx' exited with 1: Hook do errexit, this is stderr : "PostStart Hook Failed" From Event, But After Upgrade to 1.7.8 ,the FailedPostStartHook Event always have no message What you expected to happen: we need the message to find out the poststarthook failed reason How to reproduce it (as minimally and precisely as possible): Use PostStartHook And Fail It Anything else we need to know?: line 123 ,dont delete it Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.8", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T06:54:19Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.8", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-05T06:35:40Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):CentOS Linux 7 (Core) Kernel (e.g. ):4.13.7- Install tools: Others:
/area kubelet /sig node
I think this was fixed from 1.8. see:
the error message is in handlerErr ,so didnot fix this
I've just updated to kubernetes 1.8 and still no error message in However, I've never seen it there, as I've been using k8s for a few days, some of which were spent on searching how to debug hooks... Anyway client and server version: Server is running as a part of minikube
thanks for pointing it out! I send PR .

PTAL.
We also require the error message included in the Event Would you please add it?
Seems like the is already included in the according to implementation.
the m.runner.Run in master seems same as release-1.7 ,And I found the msg is empty in release-1.7so the handlerErr may not included in msg.
ping and for confirmation. thanks!
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
JUST FOR SOMEBODY WHO CARE ABOUT THE PostStartHook Event Message "the msg is empty " have really already been fixed in It's in release 1.7.12 but it seems the release note didn't mention this


Question: apiserverServiceTypeFlag      = "api-server-service-type" apiserverAdvertiseAddressFlag = "api-server-advertise-address" <ins> apiserverPortFlag             = "api-server-port" </ins> dnsProviderSecretName = "federation-dns-provider.conf"

<!-- 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 ): 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): 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 ): 1.6.2 Environment: Cloud provider or hardware configuration: AWS using Juju OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ): 4.4.0-59-generic Install tools: Juju Others: What happened: kubefed init entered a infinite loop health checking the federation api service What you expected to happen: kubefed to exit with a success code How to reproduce it (as minimally and precisely as possible): Anything else we need to know: When doing a kubefed init on a cluster setup using VMs on aws (using Juju in my case) the worker nodes have two IPs: one that is visible to the internet and one internal visible only to VMs within aws. In my case for example the VM on aws hosting the kubernetes-worker node had external IP in the 54.174.73.1/24 subnet and it also had an internal IP in the 172.31.60.1/24 subnet. Using a client machine outside aws to bootstrap federation: I got the kubefed client stuck on doing a health check against the clouds internal subnet https://172.31.60.XXX:/healthz . To address this I can use the flag and pass the external IP of any kubernetes-worker node.

With this flag kubeconfig file gets updated with the right endpoint for the federation-apiserver. However, apart from the I should also be able to specify the desired port the service will be listening on. I have to make sure that port is opened on the aws routing/firewall prior to issuing . In the example above, kubefed init will try to reach https://54.174.73.XXX:/healthz, port is randomly assigned and is not reachable. I should be able to first open the port on aws and then do a with and port pinned to .
/cc
/assign
is there a reason why you are not using the default load balanced service on AWS?
I am using Juju to stay cloud agnostic. AWS just happened to be where I deployed this time. Juju just grabs machines (virtual or physical) from wherever you have resources from. In effect your cluster is more like an on-prem than anything else. How would the default load balanced service work?
got it.


Question: kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod # Create a cluster role named "foo" with API Group specified <del> kubectl create clusterrole foo --verb=get,list,watch --resource=rs.extensions </del> <ins> kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps </ins> # Create a cluster role named "foo" with SubResource specified kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

create clusterrole command with resource value not work. I got this example command from the help note. But got error with the example command. I think it should work like yes. No response <details</details<detailsno cloud env, just vm </details<details</details<detailskubeadm </details<detailsClient: Version: 20.10.7 API version: 1.41 Go version: go1.13.8 Git commit: 20.10.7-0ubuntu5~20.04.2 Built: Mon Nov 1 00:34:17 2021 OS/Arch: linux/amd64 Context: default Experimental: true Server: Engine: Version: 20.10.7 API version: 1.41 (minimum version 1.12) Go version: go1.13.8 Git commit: 20.10.7-0ubuntu5~20.04.2 Built: Fri Oct 22 00:45:53 2021 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.5.5-0ubuntu3~20.04.2 GitCommit: runc: Version: 1.0.1-0ubuntu2~20.04.1 GitCommit: docker-init: Version: 0.19.0 GitCommit: </details<details</details
/sig CLI
/sig auth /assign
extensions/v1beta1 is no longer served since 1.16 the example should be updated to refer to
Thanks, for this information, I will update this. One more thing I have to ask here should I also do update the files/folders under folder like
Hi Any Inputs on this!
I don't know how the translation files are maintained, sorry
Don't be sorry, it's OK! Thanks!
/assign I will update the docs.
Hi I am already working on it. I have one doubt on translation files, which I already asked in the channel. Could you please tell me if you know that it will be a great help!
/usassign ok
You can check the kubectl example. ! And the role/clusterrole and something else alse needs an update.

Code in website: I think it is generated
yes, I already saw where to update the things, but I have one doubt in file which is under translation , I just wonder I have to update this file or not. see this
/cc
Hi PTAL!
Hi could you please take a look!
Hi Friendly reminder!
Fix it here PTAL!
/triage accepted


Question: [[ "$(uname)" == "Darwin" ]] } <ins> function kube::build::ensure_tar() { if [[ -n "${TAR:-}" ]]; then return fi # Find gnu tar if it is available, bomb out if not. TAR=tar if which gtar &>/dev/null; then TAR=gtar else if which gnutar &>/dev/null; then TAR=gnutar fi fi if ! "${TAR}" --version | grep -q GNU; then echo "  !!! Cannot find GNU tar. Build on Linux or install GNU tar" echo "      on Mac OS X (brew install gnu-tar)." return 1 fi } </ins> function kube::build::clean_output() { # Clean out the output directory if it exists. if kube::build::has_docker ; then

Since I've been having troubles with installation, I've digged a bit and found out that the permissions inside Kubernetes tarballs changed between 0.16.0 and 0.17.0. I've downloaded both tarballs, extracted them into separate directories and then extracted the Kubernetes server tarballs. This is what I get: I suppose, there has been a concious decision to restrict the world's access to those binaries. However, this breaks the installation routine mentioned above and probably makes life a bit more difficult in several other places. I'd be thankful for a correction if this wasn't intended or a pointer to the appropriate commit it this is legit -- I'd correct the installation.
assigning this to you to decide who the eventual assignee should be :)
Any news on this front? 0.20.1 is still restricted.
Apologies for the issue. It wasn't intentional -- likely an artifact of build scripts being run by different people? I'll check out 0.20.2 as I build it to make sure it has the right perms.
Apologies, but 0.20.2 didn't include fixed permissions. I now understand the issue, : "make release" builds a tarball using the permissions on files in your local git tree. I had "umask 027" set when I cloned, so those in-the-repo files had no world-readable perms. Setting "umask 022" before running "make release" is not enough -- it has to be part of creating the local tree when cloning. I'll update instructions and the next release (20.3 or 21.0) should fix this issue. And longer term, we need to put a bit more effort into releasing from a known-good environment and not rely on a developer's workstation's idiosyncrasies -- sorry this bit you.
I can't repro Trying again a different way, but I don't think the umask before clone should do anything (in particular, umasks aren't "sticky" on files, they're sticky to processes.)
And let's pretend on my personal fork isn't woefully out of date (who uses master on their personal fork? I should really just delete that that thing.) Comment updated.
Ah, I see the problem now.

works fine for the server tar, but the full tar also packages examples, etc., and for that, tar tends to just pick up the permissions of the git tree. Got it.
I'll take this. I'm going to write a script to build official bits, and this is easy enough to fix along the way.
Seems not fixed as of Kubernetes 1.0.7
sorry about that. is doing the 1.1.1 release and has been improving release scripts -- is 1.1.1 good re: permissions?
was not built by .
Reassigning to as release-oncall. Quinton, I can mentor or advise as necessary.
And yeah, is fine: There's no real bug here. There was a process issue that occurred with 1.0.7. We can rebuild the binaries if we need to.
FYI, leaving this issue closed, as per 's comment above. If anyone disagrees, please re-open this issue.


Question: "io/ioutil" "os" "path/filepath" <ins> "regexp" </ins> "strconv" "strings"

<!-- 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: Currently, we have logic here to look for the disk names with but this fails when we have devices which are starting with e.g: on ppc64le architecture, NPIV based fc disks are discovered as follows: and here is the udev information for one of the disk: Because of the existing logic k8s fails to detect the disk because it does not start with instead starts with , so pod creation fails with the following error: What you expected to happen: FC disk should get attached properly to the pod How to reproduce it (as minimally and precisely as possible): sample pod yaml on a machine with path names starts with Anything else we need to know?: Environment:
/sig storage
/triage accepted


Question: } } <ins> // flushUnschedulableQLeftover moves pod which stays in unschedulableQ longer than the durationStayUnschedulableQ // to activeQ. func (p *PriorityQueue) flushUnschedulableQLeftover() { p.lock.Lock() defer p.lock.Unlock() var podsToMove []*v1.Pod currentTime := p.clock.Now() for _, pod := range p.unschedulableQ.pods { lastScheduleTime := podTimestamp(pod) if !lastScheduleTime.IsZero() && currentTime.Sub(lastScheduleTime.Time) > unschedulableQTimeInterval { podsToMove = append(podsToMove, pod) } } if len(podsToMove) > 0 { p.movePodsToActiveQueue(podsToMove) } } </ins> // Pop removes the head of the active queue and returns it. It blocks if the // activeQ is empty and waits until a new item is added to the queue. It also // clears receivedMoveRequest to mark the beginning of a new scheduling cycle.

<!-- Please only use this template for submitting enhancement requests --What would you like to be : The scheduler places unschedulable pods in "unschedulabe" queue and retries them only when certain events happen that could potentially make them schedulable. This logic works well in almost all scenarios, but inevitable race condition in large distributed systems, could potentially cause some events to be seen before pods are to the unschedulable queue. If this happens, pods may be left in the unschedulable queue and not be retried. Such scenarios should be rare and even if they occur, usually there are other events that trigger a retry and cover them. However, if such scenarios happen in smaller and low churn clusters, other events may not be seen for a while and pods may be stuck in the unschedulable queue for a long time. The scheduling queue () has a method that is triggered every second to move backed off pods to the active queue. We should add another go routine that is triggered every 30 seconds and moves pods whose last schedule time is older than 1 minute from "unschedulble" queue to the active queue. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug I don't know if this should be marked as a bug. I don't have any report of such issue. It is more of a precaution to prevent issues. /sig scheduling
I am worried if this will lead to continuous repeated scheduling failures?
What is the problem with repeated scheduling failures? The scheduler had a FIFO until recently. It used to keep retrying unschedulable pods all the time.
can I take this?
Sure, thanks!
GitHub didn't allow me to assign the following users: denkensk. 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
It increases the schedule possibility of unschedulble pods and the chances of scheduling failures. Should we also consider latter?


Question: <del> The original file is https://github.com/kubernetes-csi/external-attacher/blob/<version>/deploy/kubernetes/rbac.yaml </del> <ins> The original file is https://github.com/kubernetes-csi/external-attacher/blob/VERSION/deploy/kubernetes/rbac.yaml </ins>

<!-- 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 below README files, URLs are written. But these URL include version name(master, release-1.0, etc...) which are enclosed in <and not shown in md files. What you expected to happen: URL will be shown correctly.
/sig storage
/remove-kind bug /kind documentation
can I take it up, as there is no activity for some days?
I already posted PR, thanks.


Question: } } } <ins> func TestNewSMBMapping(t *testing.T) { tests := []struct { username    string password    string remotepath  string expectError bool }{ { "", "password", `remotepath`, true, }, { "username", "", `remotepath`, true, }, { "username", "password", "", true, }, } for _, test := range tests { _, err := newSMBMapping(test.username, test.password, test.remotepath) if test.expectError { assert.NotNil(t, err, "Expect error during newSMBMapping(%s, %s, %s, %v)", test.username, test.password, test.remotepath) } else { assert.Nil(t, err, "Expect error is nil during newSMBMapping(%s, %s, %s, %v)", test.username, test.password, test.remotepath) } } } </ins>

<!-- 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: azure file remount on Windows in same node would fail What you expected to happen: If user delete a pod with azure file mount in deployment and it would probably schedule a pod on same node, azure file mount will fail since command would fail if file share is already mounted on the node: It's related to bug: Error logs would be like following: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9-v1.12, master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign
/sig windows
/sig azure
/milestone v1.14 cc This may be good to backport to 1.12 or 1.13 too if customers are using those versions.


Question: } func (o *Options) Run() error { <del> config := o.config if len(o.ConfigFile) > 0 { if c, err := o.loadConfigFromFile(o.ConfigFile); err != nil { return err } else { config = c } </del> <ins> // If user only want to generate a configure file. if len(o.WriteConfigTo) > 0 { return o.writeConfigFile() </ins> } <del> // Apply algorithms based on feature gates. // TODO: make configurable? algorithmprovider.ApplyFeatureGates() server, err := NewSchedulerServer(config, o.master) </del> <ins> server, err := NewSchedulerServer(o.config, o.master) </ins> if err != nil { return err }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We face But there is no way to generate default config file How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version 1.9.2
I'll take a look it /sig scheduling
/assign
Hi, same issue with controller-manager
Any updates here? , and don't have this flag. Is it even will be supported?
/cc
if not set, component should be use default value; why we'd like to dump all default config?
Because the documentation on the config file format is either nonexistent or difficult to find. If the program itself can generate a template, that fulfills (most of) the need for documentation of the format.
+1 for this, from my expirence, add an option to write the default config is really helpful.
/assign
also in 1.10
Deprecating all flags, prompting folks to use config files in advance is great, except when there's no documentation nor example anywhere. That means that we can't actually migrate to the new settings, and I can't seem to find clear alpha/beta/stable status for the new config file spec, nor timeline for the removal. It is also pretty confusing that the scheduler expects us to use a config file, but the controller-manager does not?
This issue indeed applies to kube-controller-manager. And there should already had deprecation policy.
According to , the flag will be available in . Since I can't find any reference online to an example config file, perhaps one could be provided or linked to here?
will you be able to pick my patch and generate a config file? I do not get my devbox handy so can only post here until Monday.


Question: const timeout = 10 * time.Second for _, signal := range []string{"-TERM", "-KILL"} { glog.V(2).Infof("Killing process %d (%s) with %s", pid, name, signal) <del> _, err := exec.Command("sudo", "kill", signal, strconv.Itoa(pid)).Output() </del> <ins> cmd := exec.Command("sudo", "kill", signal, strconv.Itoa(pid)) // Run the 'kill' command in a separate process group so sudo doesn't ignore it attrs := &syscall.SysProcAttr{} // Hack to set unix-only field without build tags. setpgidField := reflect.ValueOf(attrs).Elem().FieldByName("Setpgid") if setpgidField.IsValid() { setpgidField.Set(reflect.ValueOf(true)) } else { return fmt.Errorf("Failed to set Setpgid field (non-unix build)") } cmd.SysProcAttr = attrs _, err := cmd.Output() </ins> if err != nil { glog.Errorf("Error signaling process %d (%s) with %s: %v", pid, name, signal, err) continue

Failed: https://k8s- Run so broken it didn't make JUnit output!
unknown syscall.SysProcAttr field 'Setpgid' in struct literal Looks like we should revert


Question: if f.IgnoreNotFound != nil { cmd.Flags().BoolVar(f.IgnoreNotFound, "ignore-not-found", *f.IgnoreNotFound, "Treat "resource not found" as a successful delete. Defaults to "true" when --all is specified.") } <ins> if f.Wait != nil { cmd.Flags().BoolVar(f.Wait, "wait", *f.Wait, "If true, wait for resources to be gone before returning. This waits for finalizers.") } </ins> if f.Output != nil { cmd.Flags().StringVarP(f.Output, "output", "o", *f.Output, "Output mode. Use "-o name" for shorter output (resource/name).") } } // NewDeleteCommandFlags provides default flags and values for use with the "delete" command

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig CLI What happened: Running leads to nil pointer dereference: What you expected to happen: is expected to run delete with wait in that case How to reproduce it (as minimally and precisely as possible): (with any valid resource yaml) Anything else we need to know?: Discovered in when accidentally enabled wait for deletion from other commands than and saw failing integration tests in https://k8s- Environment: Kubernetes version (use ): latest master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
This bug was introduced in : is set in that requires to be non-nil flag is being set in is normally being set in method which is not invoked in . a result, the invocation of resource finder leads to nil pointer dereference (see stack trace in the description).
/cc


Question: t.Errorf("Expected 1 call but got 0") } } <ins> func TestSortingActivePods(t *testing.T) { numPods := 5 podList := newPodList(numPods) pods := make([]*api.Pod, len(podList.Items)) for i := range podList.Items { pods[i] = &podList.Items[i] } // pods[0] is not scheduled yet. pods[0].Spec.Host = "" pods[0].Status.Phase = api.PodPending // pods[1] is scheduled but pending. pods[1].Spec.Host = "bar" pods[1].Status.Phase = api.PodPending // pods[2] is unknown. pods[2].Spec.Host = "foo" pods[2].Status.Phase = api.PodUnknown // pods[3] is running but not ready. pods[3].Spec.Host = "foo" pods[3].Status.Phase = api.PodRunning // pods[4] is running and ready. pods[4].Spec.Host = "foo" pods[4].Status.Phase = api.PodRunning pods[4].Status.Conditions = []api.PodCondition{{Type: api.PodReady, Status: api.ConditionTrue}} getOrder := func(pods []*api.Pod) []string { names := make([]string, len(pods)) for i := range pods { names[i] = pods[i].Name } return names } expected := getOrder(pods) for i := 0; i < 20; i++ { idx := rand.Perm(numPods) randomizedPods := make([]*api.Pod, numPods) for j := 0; j < numPods; j++ { randomizedPods[j] = pods[idx[j]] } sort.Sort(activePods(randomizedPods)) actual := getOrder(randomizedPods) if !reflect.DeepEqual(actual, expected) { t.Errorf("expected %v, got %v", expected, actual) } } } </ins>

I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil