jiebi/CodeConvo huggingface dataset:
Code change:
t.Errorf("expected mount options: %v, got: %v", tc.spec.PersistentVolume.Spec.MountOptions, vol.MountFlags) } } <ins> // Verify the deviceMountPath was created by the plugin if tc.stageUnstageSet { s, err := os.Stat(tc.deviceMountPath) if err != nil { t.Errorf("expected staging directory %s to be created and be a directory, got error: %s", tc.deviceMountPath, err) } else { if !s.IsDir() { t.Errorf("expected staging directory %s to be directory, got something else", tc.deviceMountPath) } } } </ins> }) } }

Related discussion:
text: 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
Code change:
}, func(client kubeclientset.Interface, obj runtime.Object) error { rs := obj.(*extensionsv1.ReplicaSet) <del> err := client.Extensions().ReplicaSets(rs.Namespace).Delete(rs.Name, &metav1.DeleteOptions{}) </del> <ins> orphanDependents := false err := client.Extensions().ReplicaSets(rs.Namespace).Delete(rs.Name, &metav1.DeleteOptions{OrphanDependents: &orphanDependents}) </ins> return err })

Related discussion:
text: Problem: When users sends a cascading deletion request to federation i.e they set orphanDependents=false, then federation should also set orphanDependents=false, when it sends the request to underlying clusters.
Fixed by
Code change:
<ins> apiVersion: "v1beta1" kind: "Service" id: "monitoring-influxdb" port: 8085 containerPort: 8086 selector: name: "influxGrafana" </ins>

Related discussion:
text: examples/monitoring/influx-grafana- and friends NEED to be replaced by a replication controller ASAP. As it stands they are bad examples. Also, they should probably move to contrib/monitoring to match contrib/logging and contrib/dns
Code change:
KUBE_PROXY_OPTS=" --hostname-override=${1}  --master=http://${2}:8080  <del> --logtostderr=true" </del> <ins> --logtostderr=true  ${3}" </ins> EOF }

Related discussion:
text: There should be a way to select the iptables proxy-mode.
Are you interested in modifying ubuntu deploy scripts to use a user provided configure file?
This is fixed by and it will be merged in soon.
This fix breaks cluster/kube- while kubernetes provider is rather than ubuntu, as the following variables are only defined in ubuntu folder PROXYSETTING=${PROXYSETTING:-""} DEBUG=${DEBUG:-"false"} When I run KUBERNETES_PROVIDER=vagrant and run cluster/kube- It will fail with error "==master: [ERROR ] {'pid': 5871, 'retcode': 1, 'stderr': ' line 21: DEBUG: unbound variable', 'stdout': ''}" I will open a separated issue to discuss the solution.
I do not understand. I have not tried KUBERNETESPROVIDER=vagrant and run cluster/kube-, can you please clarify what is going wrong? This PR () affected only files in cluster/ubuntu/; are you saying that some of them are used when KUBERNETESPROVIDER=vagrant? This PR did not introduce PROXY_SETTING or DEBUG.
I tried running kube- with the Vagrant provider, but ran into a different (and much prior) problem; see --- any help would be appreciated.
OK, I see you opened issue for this and PR fixed it. Thanks. I will respond to the larger question under .
Code change:
echo "Found multiple ephemeral block devices, formatting with btrfs as RAID-0" mkfs.btrfs -f --data raid0 ${block_devices[@]} fi <del> echo "${block_devices[0]}  /mnt/ephemeral  btrfs  noatime  0 0" >> /etc/fstab </del> <ins> echo "${block_devices[0]}  /mnt/ephemeral  btrfs  noatime,nofail  0 0" >> /etc/fstab </ins> mkdir -p /mnt/ephemeral mount /mnt/ephemeral

Related discussion:
text: On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.
Code change:
k := kubelet.NewMainKubelet( getHostname(), dockerClient, <del> cadvisorClient, </del> etcdClient, *rootDirectory, *networkContainerImage,

Related discussion:
text: So today, cadvisor became wedged and just stopped paying attention to its socket. Not kubelet's fault. But when I would launch all I would get would be: It took me a bit of trolling through netstat and lsof to figure out that the problem was cadvisor being completely locked up. kill -9 cadvisor and everything started working well. I wonder if we should emit more messages during startup about what operation we are about to attempt, not just the results of operations, as I was blaming docker for a while....
kubelet shouldn't block on this. I'll take a look.
Any ideas what was locking cAdvisor? and was it just not responding to requests?
I don't have any idea why it was locked. If I find another one locked I'll hang onto it to debug. Journal had: obviously the 'kill' came from me. It would not respond to systemctl cadvisor stop. netstat looking at port 4194 showed me At which point I realized cadvisor wasn't handling its sockets right since so many long dead kubelet sockets hadn't been cleaned up, so I kill -9'd it.
I cut some interesting info from the cadvisor journal log (trying to cut hostnames) You can see the last message about failed to update stats for container ... happened Oct 08 01:06:01. It was then silent until I killed it Oct 08 19:20:13, even though I'm pretty sure dnf was still being launched every hour on the hour. So it was wedged for about 18 hours.
What kernel is this on? We've seen there is a kernel bug fixed in 3.12+ that sometimes hangs us forever on exit. We're not quite sure how it gets triggered...
16.3
Code change:
return nil, fmt.Errorf("%s does not support block volume provisioning", a.plugin.GetPluginName()) } <del> var sku, resourceGroup, location, account string </del> <ins> var sku, resourceGroup, location, account, shareName string </ins> <del> // File share name has a length limit of 63, and it cannot contain two consecutive '-'s. name := util.GenerateVolumeName(a.options.ClusterName, a.options.PVName, 63) name = strings.Replace(name, "--", "-", -1) </del> capacity := a.options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)] requestGiB := int(volumehelpers.RoundUpToGiB(capacity)) secretNamespace := a.options.PVC.Namespace

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: use an existing azure file share name should be possible in azure file plugin What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig azure /assign
Code change:
} // In IPVS proxy mode, the following flags need to be set <del> const sysctlRouteLocalnet = "net/ipv4/conf/all/route_localnet" </del> const sysctlBridgeCallIPTables = "net/bridge/bridge-nf-call-iptables" const sysctlVSConnTrack = "net/ipv4/vs/conntrack" const sysctlConnReuse = "net/ipv4/vs/conn_reuse_mode"

Related discussion:
text: CVSS Rating: In typical clusters: medium (5.4) In clusters where API server insecure port has not been disabled: high (8.8) A security issue was discovered in which allows adjacent hosts to reach TCP and UDP services bound to running on the node or in the node's network namespace. For example, if a cluster administrator runs a TCP service on a node that listens on , because of this bug, that service would be potentially reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. If the example service on port required no additional authentication (because it assumed that only other localhost processes could reach it), then it could be vulnerable to attacks that make use of this bug. The Kubernetes API Server's default insecure port setting causes the API server to listen on where it will accept requests without authentication. Many Kubernetes installers explicitly disable the API Server's insecure port, but in clusters where it is not disabled, an attacker with access to another system on the same LAN or with control of a container running on the master may be able to reach the API server and execute arbitrary API requests on the cluster. This port is deprecated, and will be removed in Kubernetes v1.20. You may be vulnerable if: You are running a vulnerable version (see below) Your cluster nodes run in an environment where untrusted hosts share the same layer 2 domain (i.e. same LAN) as nodes Your cluster allows untrusted pods to run containers with (the Kubernetes default is to allow this capability). Your nodes (or hostnetwork pods) run any localhost-only services which do not require any further authentication. To list services that are potentially affected, run the following commands on nodes: - On a master node, an lsof entry like this indicates that the API server may be listening with an insecure port: kubelet/kube-proxy v1.18.0-1.18.3 kubelet/kube-proxy v1.17.0-1.17.6 kubelet/kube-proxy <=1.16.10 Prior to upgrading, this vulnerability can be mitigated by manually adding an iptables rule on nodes. This rule will reject traffic to 127.0.0.1 which does not originate on the node. Additionally, if your cluster does not already have the API Server insecure port disabled, we strongly suggest that you disable it.
Code change:
} // In IPVS proxy mode, the following flags need to be set <del> const sysctlRouteLocalnet = "net/ipv4/conf/all/route_localnet" </del> const sysctlBridgeCallIPTables = "net/bridge/bridge-nf-call-iptables" const sysctlVSConnTrack = "net/ipv4/vs/conntrack" const sysctlConnReuse = "net/ipv4/vs/conn_reuse_mode"

Related discussion:
text: Add the following flag to your kubernetes API server command line: Packets on the wire with an IPv4 destination in the range 127.0.0.0/8 and a layer-2 destination MAC address of a node may indicate that an attack is targeting this vulnerability. Although the issue is caused by , the current fix for the issue is in (although future versions may have the fix in instead). We recommend updating both and to be sure the issue is addressed. The following versions contain the fix: kubelet/kube-proxy master - fixed by kubelet/kube-proxy v1.18.4+ - fixed by kubelet/kube-proxy v1.17.7+ - fixed by kubelet/kube-proxy v1.16.11+ - fixed by To upgrade, refer to the documentation: This issue was originally raised in issue which details how the sets which causes the system not to reject traffic to localhost which originates on other hosts. IPv6-only services that bind to a address are not affected. There may be additional attack vectors possible in addition to those fixed by and its cherry-picks. For those attacks to succeed, the target service would need to be UDP and the attack could only rely upon sending UDP datagrams since it wouldn't receive any replies. Finally, the target node would need to have reverse-path filtering disabled for an attack to have any effect. Work is ongoing to determine whether and how this issue should be fixed. See for up-to-date status on this issue. This vulnerability was reported by János Kövér, Ericsson with additional impacts reported by Rory McCune, NCC Group and Yuval Avrahami and Ariel Zelivansky, Palo Alto Networks. /area security /kind bug /committee product-security /sig network /sig node /area kubelet
For insecure port removal:
The original announcement contained an error. The announcement makes it sound like upgrading kube-proxy will address the issue, but that is incorrect. I have edited the issue summary to add the following paragraph in the "Fixed Versions" section: Additionally, I have changed the components in listed versions to say kubelet/kube-proxy instead of kube-proxy.
Could you add numerical CVSS scores to these? "High" is too vague, frequently varies from vendor to vendor. I can calculate a score from the vector myself, but adding the score would save us some work...
Edited.
Code change:
} // In IPVS proxy mode, the following flags need to be set <del> const sysctlRouteLocalnet = "net/ipv4/conf/all/route_localnet" </del> const sysctlBridgeCallIPTables = "net/bridge/bridge-nf-call-iptables" const sysctlVSConnTrack = "net/ipv4/vs/conntrack" const sysctlConnReuse = "net/ipv4/vs/conn_reuse_mode"

Related discussion:
text: Also, the vector scores are clickable and will show the CVSS scores too.
To be clear, this is fixed in v1.18.4+, v1.17.7+, and v1.16.11+ correct?
Right. Sorry if the extra paragraph in "Fixed Versions" made that unclear.
Got it. Thank you!
So just to be sure, this wouldn't be a problem in an EKS cluster running in its own VPC, right? (assuming no untrusted hosts on the same VPC)
Are all the conditions listed under , a logical AND ?
Edit: after more testing, I think is indeed required
The attack can be done from any pod with (this is still K8S default), so you might not be safe. a more accurate title: "Node setting allows to bypass localhost boundary"
We believe that of the four conditions, you might be affected if (1 and (2 or 3) and 4) are true for your cluster. Sorry that it's not super clear from the text. Trying and failing to convey info concisely and with precision makes me glad that I'm in software, not law.
Isn't this broadly fixed by ? We're discussing better answers and options for deployment, too, but I am curious what the close-condition for this bug is?
I made a typo in the issue description saying that this is addressed by instead of . I'll edit it now. Sorry about that. Yes, this is mostly fixed by . I marked this as closed due to that PR fixing the majority of security issues caused by the setting. We can re-open if people think that we should address the remaining case that talks about.
Sorry, folks. I thought that this issue was already closed. Maybe that makes my response above to less confusing.
Yes, this being open was one of the major points of confusion for us. Appreciate the clarification
/label official-cve-feed (Related to )
Code change:
} dc := &DeploymentController{ <del> queue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "doesnt-matter"), </del> <ins> queue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "doesnt_matter"), </ins> } dc.enqueueDeployment = dc.enqueue

Related discussion:
text: What happened: From : What you expected to happen: Metrics should register successfully. How to reproduce it (as minimally and precisely as possible): Run kubernetes-integration test Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please add a sig label by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Code change:
pollInterval           = time.Second * 5 ) <del> type testStatus struct { </del> <ins> type testCase struct { </ins> Name             string RestartPolicy    api.RestartPolicy Phase            api.PodPhase

Related discussion:
text: Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc
Code change:
containerName := p.ContainerName if len(containerName) == 0 { if len(pod.Spec.Containers) > 1 { <del> usageString := fmt.Sprintf("Defaulting container name to %s.", pod.Spec.Containers[0].Name) if len(p.SuggestedCmdUsage) > 0 { usageString = fmt.Sprintf("%sn%s", usageString, p.SuggestedCmdUsage) </del> <ins> fmt.Fprintf(p.ErrOut, "Defaulting container name to %s.n", pod.Spec.Containers[0].Name) if p.EnableSuggestedCmdUsage { fmt.Fprintf(p.ErrOut, "Use '%s describe pod/%s -n %s' to see all of the containers in this pod.n", p.ParentCommandName, pod.Name, p.Namespace) </ins> } <del> fmt.Fprintf(p.ErrOut, "%sn", usageString) </del> } containerName = pod.Spec.Containers[0].Name }

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: The pod name is missing in suggested cmd usage when executing : What you expected to happen: The suggested cmd usage should be a complete cmd like the one got from How to reproduce it (as minimally and precisely as possible): Use to attach any pod/deployment/service, the PodName will be missing in the suggested cmd usage like above. Anything else we need to know?: It works fine for kubectl < v1.12 Environment: Kubernetes version (use ): v1.13.1 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli /assign
Code change:
// Update uncertain volumes - the new markVolumeOpts may have updated information. // Especially reconstructed volumes (marked as uncertain during reconstruction) need // an update. <del> updateUncertainVolume = utilfeature.DefaultFeatureGate.Enabled(features.SELinuxMountReadWriteOncePod) && podObj.volumeMountStateForPod == operationexecutor.VolumeMountUncertain </del> <ins> updateUncertainVolume = utilfeature.DefaultFeatureGate.Enabled(features.NewVolumeManagerReconstruction) && podObj.volumeMountStateForPod == operationexecutor.VolumeMountUncertain </ins> } if !podExists || updateUncertainVolume { // Add new mountedPod or update existing one.

Related discussion:
text: Kubernetes 1.27 with feature gate enabled and disabled, a rebooted node is not able to re-start pods that were running there before the reboot. The node reports in Pod events: The Pod should start just fine. On Kubernetes 1.27: NewVolumeManagerReconstruction feature gate. a StatefulSet that uses a volume. -reboot the node which runs the StatefulSet Pod. The reason is that kubelet's VolumeManager reconstructs the volume as uncertain during startup and it uses a provisional outer volume name for it, because it has not seen the API server and Pods in it yet. This provisional volume ID is then used in ActualStateOfWorld forever. While kubelet does mount the volume after reboot, it's not able to match it with the Pod that needs it. Kubelet reports , while the volume is mounted with ID in my case (= the provisional name, we use for it) and not (=). It is not reproducible with enabled. <details</details<detailsAWS + AWS EBS CSI driver, but it should not be relevant. </details<details</details<details</details<details</details<details</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
/sig storage /priority important-soon This is reproducible when SELinuxMountReadWriteOncePod is disabled and NewVolumeManagerReconstruction enabled. They both got enabled by default as beta in 1.28. So someone has to explicitly disable SELinuxMountReadWriteOncePod to hit this bug.
Code change:
switch { case strings.HasPrefix(subs[0][2], "ci"): <del> // Special case. CI images populated only by ci-cross area urlSuffix = "ci-cross" </del> <ins> // Just use whichever the user specified urlSuffix = subs[0][2] </ins> default: urlSuffix = "release" }

Related discussion:
text: https://k8s- /kind bug /sig cluster-lifecycle /milestone v1.10 /priority failing-test cc also cc should this even be in 1.10 blocking dashboard?
/priority critical-urgent (who owns this?)
(also https://k8s-)
Is this actually running now? /cc
It looks like it's failing to up the cluster, I don't remember what the previous status of this job was, I thought all kubeadm 1.10 jobs were running previously...
The reason this failed was the cross CI job was failing to push the images that are used by that job. /cc
/subscribe
the latest cross build for 1.9 is as following We seem to have only one job that does cross builds on master : https://k8s-*build&i=nope&files=&repos=test-infra So the job fails ( for example in )
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<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
Code change:
if err != nil { return admission.NewForbidden(a, err) } <ins> // refuse to operate on non-existent namespaces </ins> if !exists { <del> return nil </del> <ins> // in case of latency in our caches, make a call direct to storage to verify that it truly exists or not namespaceObj, err = l.client.Namespaces().Get(a.GetNamespace()) if err != nil { return admission.NewForbidden(a, fmt.Errorf("Namespace %s does not exist", a.GetNamespace())) } </ins> } <del> namespace := namespaceObj.(*api.Namespace) if namespace.Status.Phase != api.NamespaceTerminating { return nil </del> <ins> // ensure that we're not trying to create objects in terminating namespaces if a.GetOperation() == admission.Create { namespace := namespaceObj.(*api.Namespace) if namespace.Status.Phase != api.NamespaceTerminating { return nil } return admission.NewForbidden(a, fmt.Errorf("Unable to create new content in namespace %s because it is being terminated.", a.GetNamespace())) </ins> } <del> return admission.NewForbidden(a, fmt.Errorf("Unable to create new content in namespace %s because it is being terminated.", a.GetNamespace())) </del> <ins> return nil </ins> } // NewLifecycle creates a new namespace lifecycle admission control handler

Related discussion:
text: We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example
Code change:
name = "go_default_library", srcs = [ "aws_ebs.go", <ins> "azure_disk.go", </ins> "gce_pd.go", "in_tree_volume.go", "openstack_cinder.go",

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Azure is not listed as "migratable" in could refer to Why is this needed:
/sig azure /assign