jiebi/CodeConvo huggingface dataset:
Change:
fi APISERVER_LOG=${LOG_DIR}/kube-apiserver.log <del> ${CONTROLPLANE_SUDO} "${GO_OUT}/hyperkube" apiserver "${authorizer_arg}" "${priv_arg}" ${runtime_config}  </del> <ins> ${CONTROLPLANE_SUDO} "${GO_OUT}/hyperkube" kube-apiserver "${authorizer_arg}" "${priv_arg}" ${runtime_config}  </ins> ${cloud_config_arg}  "${advertise_address}"  "${node_port_range}" 

Discussion:
Hyperkube supports a number of short aliases for commands, such as , , , , etc, rather than the longer , , , etc. There are comments indicating this is "unfortunate" and we still currently create these aliases in the hyperkube docker image: It'd be nice to simplify this, assuming we can find all uses of the short aliases and remove them. /kind cleanup Not sure which sig should own this, so tagging a few. /sig architecture cluster-lifecycle cli cc
interestingly, the command doesn't create the short aliases, though we also don't really use anywhere either.
I think we can just go ahead and start the deprecation cycle for this. WDYT? cc
cc as well
+1 to nuke it
/assign :wink: ok?
SGTM
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
/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
I would like to work on it!
It seems like this issue was already solved in ?
I don't think the hyperkube code was changed in that PR, only the image?
Yes, thanks for your comment, can i try to fix it ?
I made a PR here: . Review/feedback/suggestions appreciated! :)
/assign /unassign
GitHub didn't allow me to assign the following users: Rand01ph.

Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /unassign 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
/remove-sig architecture cli /sig release Does anyone even still use hyperkube? Wouldn't they use kubeadm or k3s instead?
AFAIK, SAP (the company) still use hyperkube.
aks-engine deployer ( ) still uses hyperkube
Since this ticket is completed now. Can this todo be removed?
we are removing the whole thing :)
Change:
"fmt" api "k8s.io/api/core/v1" <del> extensions "k8s.io/api/extensions/v1beta1" </del> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/labels" </ins> "k8s.io/kubernetes/pkg/security/apparmor" "k8s.io/kubernetes/test/e2e/framework" <ins> . "github.com/onsi/gomega" </ins> ) const ( appArmorProfilePrefix = "e2e-apparmor-test-" appArmorAllowedPath   = "/expect_allowed_write" appArmorDeniedPath    = "/expect_permission_denied" <ins> loaderLabelKey   = "name" loaderLabelValue = "e2e-apparmor-loader" </ins> ) // AppArmorDistros are distros with AppArmor support

Discussion:
The "AppArmor load AppArmor profiles should enforce an AppArmor profile" e2e test in failing on our 5k-node gce clusters - https://k8s- (run no. 8) due to timeout: Seems like the test is trying to load the profiles across all the nodes using a daemonset and then running a test pod to check that. It's passing on our 2k-node clusters (https://k8s-) but failing for 5k - suggesting that it's likely due to size of the cluster. I think it's the ds creation taking longer on large cluster. cc
Seems like you're the most relevant here. Could one of you take a look into it? And does increasing the timeout for the test-pod based on no. of nodes sound reasonable?
Assigning it you since is OOO. Feel free to reassign as apt.
This is part of the correctness suite and large cluster tests are release-blocking.
FYI
Reassigning to who is back on Tuesday. He wrote the AppArmor stuff and should be able to debug this quickly. /assign
Ref
Could you manage to take a look into this?
Sorry, I meant to reply to this! I have a fix, just need to confirm it works. I think you're right about the DaemonSet timing out. There's no reason this needs to load the profiles on every node, so the fix just runs a single loader, and uses pod affinity to co-schedule the test pod.
Smooth!
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/scalability: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
}) ginkgo.It("should work with the pod containing more than 6 DNS search paths and longer than 256 search list characters", func(ctx context.Context) { <del> ginkgo.By("Getting the kube-dns IP") svc, err := f.ClientSet.CoreV1().Services("kube-system").Get(ctx, "kube-dns", metav1.GetOptions{}) framework.ExpectNoError(err, "Failed to get kube-dns service") kubednsIP := svc.Spec.ClusterIP </del> // All the names we need to be able to resolve. namesToResolve := []string{ "kubernetes.default",

Discussion:
an E2E test that assumes that a service named "kube-dns" exists in the "kube-system" namespace. This is a kubeadm-ism, and the test fails if the cluster DNS is not configured the way kubeadm configures it. Although this E2E test isn't a conformance test, making it functional on non-kubeadm clusters would increase its utility for distributors that may wish to run this E2E test as a conformance test. [sig-network] DNS HostNetwork should resolve DNS of partial qualified names for services on hostNetwork pods with dnsPolicy: ClusterFirstWithHostNet Since we ran it on an OpenShift cluster. No response The test makes assumptions about how the cluster DNS is configured. The test uses (not ), so it does not need to specify , as far as I can tell. Omitting obviates the need to look up the service. I believe that the service lookup was left in as an oversight during the development of the test when it was changed from specifying "None" to specifying "ClusterFirst": Cc: /sig network
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
responded on the pr.
It seems kubeadm inherited the status-quo, I can't find any place that mandates the Service name for DNS Asking for double checking, but the docs seems to mention that this is more a recommendation than a preescription If it seems that the test can be done in a more portable way we should do it
Change:
const ( // Notice that if someday we also have minimum docker version requirement, this should also be updated. <del> fakeDockerVersion = "1.11.2" </del> <ins> fakeDockerVersion = "1.13.1" </ins> fakeImageSize = 1024

Discussion:
The current node e2e tests include images using Docker 1.11.x to , with the pending PR to test 18.06 () We should update the images to drop older docker versions. I think we can start by getting rid of 1.11 and 1.12, so that we still have three minor versions tested: , , and 1.13.x /cc (for cos and ubuntu)
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
/assign Yang, could you take a look? Thanks
Change:
} } <ins> // While we only use a bounded number of nodes in the test. We need to know // the actual number of nodes in the cluster, to avoid running resourceMonitor // against large clusters. actualNodes, err := e2enode.GetReadySchedulableNodes(c) framework.ExpectNoError(err) </ins> // Start resourceMonitor only in small clusters. <del> if numNodes <= maxNodesToCheck { </del> <ins> if len(actualNodes.Items) <= maxNodesToCheck { </ins> resourceMonitor = e2ekubelet.NewResourceMonitor(f.ClientSet, e2ekubelet.TargetContainers(), containerStatsPollingInterval) resourceMonitor.Start() }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: https://k8s- Which test(s) are failing: [] [sig-node] kubelet [] [sig-node] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. Since when has it been failing: 2019-09-26 Testgrid link: Reason for failure: Anything else we need to know: /cc
is there someone who can pick this up since it's constantly failing in the master-informing? Thanks :)
Could you help us here?
Looked into the test logs, and it seems like the in was accidentally removed in , which caused its value to be 0. As the current log is showing: And last succeeded test log is: I'll send a PR to fix this. /cc
It seems that this PR didn't help. This run already contains this PR and it failed:
/milestone v1.17 /priority critical-urgent
I0926 12:39:42.660] I0926 12:35:26. ] Trace[]: "Reflector ListAndWatch" (started: 2019-09-26 12:33:26. +0000 UTC m=+1132.) (total time: 2m0.000301191s):
Seems like the test is timing out creating the pods and reflector to watch those pods.
Looks like the section of code taking a long time is
Checked KAS log and seeing about 7000 requests of the form I1010 12:26:59. 1 ] GET /api/v1/nodes/gce-scale-cluster-minion-group-1-4p2m:/proxy/stats/summary: (9.753712ms) 200 [ (linux/amd64) kubernetes/ -- [] [sig-node] kubelet [] [sig-node] Clean up pods on node kubelet should be able to delete 10 pods per node in 1m0s. 146.148.73.158:] between replicationcontroller being created and the pod list/watch request.
The is only supposed to run if there are less than 10 nodes in the cluster. However, the situation doesn't hold with this change: (or ) was changed to .

While the e2e test only uses 10 () nodes from the cluster, the resource monitor is querying all the nodes in the cluster. Thus the client qps limit was exceeded and caused the reflector to be throttled. I'll send a fix
/assign
Change:
RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, <ins> "bad supplementalGroups large than math.MaxInt32": { Containers: []api.Container{{Name: "ctr", Image: "image", ImagePullPolicy: "IfNotPresent"}}, SecurityContext: &api.PodSecurityContext{ HostNetwork:        false, SupplementalGroups: []int64{maxID, 1234}, }, RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, "bad supplementalGroups less than 0": { Containers: []api.Container{{Name: "ctr", Image: "image", ImagePullPolicy: "IfNotPresent"}}, SecurityContext: &api.PodSecurityContext{ HostNetwork:        false, SupplementalGroups: []int64{minID, 1234}, }, RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, "bad runAsUser large than math.MaxInt32": { Containers: []api.Container{{Name: "ctr", Image: "image", ImagePullPolicy: "IfNotPresent"}}, SecurityContext: &api.PodSecurityContext{ HostNetwork: false, RunAsUser:   &maxID, }, RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, "bad runAsUser less than 0": { Containers: []api.Container{{Name: "ctr", Image: "image", ImagePullPolicy: "IfNotPresent"}}, SecurityContext: &api.PodSecurityContext{ HostNetwork: false, RunAsUser:   &minID, }, RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, "bad fsGroup large than math.MaxInt32": { Containers: []api.Container{{Name: "ctr", Image: "image", ImagePullPolicy: "IfNotPresent"}}, SecurityContext: &api.PodSecurityContext{ HostNetwork: false, FSGroup:     &maxID, }, RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, "bad fsGroup less than 0": { Containers: []api.Container{{Name: "ctr", Image: "image", ImagePullPolicy: "IfNotPresent"}}, SecurityContext: &api.PodSecurityContext{ HostNetwork: false, FSGroup:     &minID, }, RestartPolicy: api.RestartPolicyAlways, DNSPolicy:     api.DNSClusterFirst, }, </ins> "bad-active-deadline-seconds": { Volumes: []api.Volume{ {Name: "vol", VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{}}},

Discussion:
Help review this, thanks.
Are you asking for better validation on pod creation? I'm not really sure what you mean when you say "tip".
Yes, I mean it's better validate the pod when create. The tip mean the validation info response from server and show by client.
Change:
KUBE_BUILD_CONFORMANCE=${KUBE_BUILD_CONFORMANCE:-y} KUBE_BUILD_PULL_LATEST_IMAGES=${KUBE_BUILD_PULL_LATEST_IMAGES:-y} <del> # The mondo test tarball is deprecated as of Kubernetes 1.14, and the default # will be set to 'n' in a future release. # See KEP sig-testing/20190118-breaking-apart-the-kubernetes-test-tarball KUBE_BUILD_MONDO_TEST_TARBALL=${KUBE_BUILD_MONDO_TEST_TARBALL:-y} </del> # Validate a ci version # # Globals:

Discussion:
What happened: On 2019-02-22 was merged with an indication that the mondo test tarball noted as deprecated as per But it did not include a timeline for eventual removal. What you expected to happen: It's been 7 months now. We should formalize a plan for removal. /sig testing /sig release /kind cleanup /priority important-soon
Enhancement tracking issue ref:
removes the deprecated mondo test tarball.
Change:
KUBE_GCS_MAKE_PUBLIC=y KUBE_GCS_UPLOAD_RELEASE=y KUBE_GCS_RELEASE_BUCKET=kubernetes-release <del> KUBE_GCS_PROJECT=google-containers </del> KUBE_GCS_RELEASE_PREFIX=release/${KUBE_RELEASE_VERSION} KUBE_GCS_LATEST_FILE="release/latest.txt" KUBE_GCS_LATEST_CONTENTS=${KUBE_RELEASE_VERSION}

Discussion:
I cant bring up the monitoring addons on my local cluster after I turns out that thats because I am using an older version of docker which does not allow "-" in namespaces. I get error on running . suggested that we can change the path to use googlecontainers instead of google-containers since that works for all versions of docker. Using google-containers only works for docker versions 1.5+ Filling this issue to hear what others think about this.
SGTM
Fine with me. I'm working on moving the e2e images, can make this change at same time.
SGTM. Take note Let me know when we definitely decide to do this and I will re-generate the image names for the images that I have created and pushed.
please double and triple check to get everything :) , Satnam Singh wrote:
Thanks for heads-up. I am in the middle of pushing kubernetes/pause and etcd_server to Will make sure use the right path here.
fwiw GoogleCloudPlatform/kubernetes to complement already merged PRs...
Change:
"//pkg/apis/coordination/install:go_default_library", "//pkg/apis/core:go_default_library", "//pkg/apis/core/install:go_default_library", <ins> "//pkg/apis/discovery/install:go_default_library", </ins> "//pkg/apis/events/install:go_default_library", "//pkg/apis/extensions/install:go_default_library", <ins> "//pkg/apis/flowcontrol/install:go_default_library", "//pkg/apis/imagepolicy/install:go_default_library", "//pkg/apis/networking/install:go_default_library", "//pkg/apis/node/install:go_default_library", </ins> "//pkg/apis/policy/install:go_default_library", "//pkg/apis/rbac/install:go_default_library", "//pkg/apis/scheduling/install:go_default_library",

Discussion:
What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted
Change:
import ( "os" <del> "github.com/spf13/cobra" </del> "k8s.io/component-base/cli" <del> cliflag "k8s.io/component-base/cli/flag" </del> _ "k8s.io/component-base/logs/json/register" // for JSON log format registration _ "k8s.io/component-base/metrics/prometheus/restclient" _ "k8s.io/component-base/metrics/prometheus/version" // for version metric registration

Discussion:
When running kubelet, if the Run function fails, the returned error has no output, and the cause of the error cannot be located. such as After the error is returned, there is no position output, so the user cannot know the cause of the error. But previous versions had log output Run the Run function, when there is an error exit, print the error log Misconfigured cgroupRoot No response <details</details<details</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
/assign
/sig node
/cc
Change:
func init() { api.Scheme.AddDefaultingFuncs( <ins> func(obj *ReplicationController) { if len(obj.DesiredState.ReplicaSelector) == 0 { obj.DesiredState.ReplicaSelector = obj.DesiredState.PodTemplate.Labels } if len(obj.Labels) == 0 { obj.Labels = obj.DesiredState.PodTemplate.Labels } }, </ins> func(obj *Volume) { if util.AllPtrFieldsNil(&obj.Source) { glog.Errorf("Defaulting volume source for %v", obj)

Discussion:
It doesn't make sense to define pod template with a set of labels that is strict subset of replicaSelector (or at least I can't find an use-case). For that reason I think that the labels in pod template part of replication controller should be optional and user should care about them only if he wants to define a superset of what replicaSelector already defines.
I've heard the same comments from a client. I think that it'd be more intuitive if we always specify pod labels in the template (so that we can copy&paste pod definition), and replicaSelector is optional (by default pod labels).
It would be reasonable for the selector to be a subset. I'm fine with intelligent defaulting but we need to be careful not to conflate the 2 concepts, which I think would increase the amount of confusion.
Setting RC selector from pod template labels SGTM. Any concerns It wouldn't have to work with separate templates, though it would be desirable if it did. It would be nice if we could add preconditions based on other objects (resource version of pod template in this case) to etcd transactions.
I think we agreed in another issue that defaulting the selector from the pod template labels is reasonable. No argument from me. One problem with pod templates is that we lose the strict relationship between selector and template, so if you change the template the RC needs to behave intelligently (I refuse to create more pods because the template selector doesn't match mine, etc)
We should do this, and we should default replicas to 1. We could also consider defaulting replication controller labels from pod template labels. That way, essentially the only thing that would need to be specified for a singleton RC would be the pod template.
I don't think we can default replicas to 1, since we can't tell the difference between an explicit zero and a default zero, and I think there are lots of reasonable cases where you want to set replicas == 0 on create. (esp. in the context of socket activation)
Responded on the PR: We can distinguish default from 0 if we make it a pointer.
Change:
return cc.handler(csr) } <ins> // IgnorableError returns an error that we shouldn't handle (i.e. log) because // it's spammy and usually user error. Instead we will log these errors at a // higher log level. We still need to throw these errors to signal that the // sync should be retried. func IgnorableError(s string, args ...interface{}) ignorableError { return ignorableError(fmt.Sprintf(s, args...)) } type ignorableError string func (e ignorableError) Error() string { return string(e) } </ins>

Discussion:
Each node waiting for bootstrapping creates 1 line per 2-3s in the logs when the requesting client doesn't have access. It should not be logging at v(0), these are all v(4) level. We should be reporting these appropriately. I don't want a 5k node cluster showing this.
I'd like to fix it
Change:
return cephfsVolume.plugin.host.GetPodVolumeDir(cephfsVolume.podUID, utilstrings.EscapeQualifiedNameForDisk(name), cephfsVolume.volName) } <ins> // GetKeyringPath creates cephfuse keyring path func (cephfsVolume *cephfs) GetKeyringPath() string { name := cephfsPluginName volumeDir := cephfsVolume.plugin.host.GetPodVolumeDir(cephfsVolume.podUID, utilstrings.EscapeQualifiedNameForDisk(name), cephfsVolume.volName) volumeKeyringDir := volumeDir + "~keyring" return volumeKeyringDir } </ins> func (cephfsVolume *cephfs) execMount(mountpoint string) error { // cephfs mount option ceph_opt := ""

Discussion:
The goal of this issue is to design a CephFS driver using FUSE client for Kubernetes.</brExisting Ceph kernel client has the following drawbacks:</br• Kernel client does not support client-enforced quotas. • Kernel CephFS doesn't support quota or capacity, capacity requested by PVC is not enforced or validated. • Kernel CephFS doesn't work with SELinux, setting SELinux label in Pod's security context will not work.
Just a detail. Since we will rely on ceph-fuse, we will need the ceph-fuse client to be available on all kubernetes nodes. We can add a parameter to allow the use of the kernel client as well. I would say better make the fuse client opt-in and keep the kernel one as the default option. The kernel client might support quotas in the future. Thanks
/sig storage
We are also inclined to use fuse instead of kernel client ,any progress on this issue?
I like to continue this job and prepare to send a PR to make kubernetes support cephfs fuse mounting.
/assign I think this task would be valuable. =)
waiting for the PR, do you have a plane to support s3 fuse ?
No, no plan for s3fs-fuse currently
also see and cc
Ceph-fuse support in the command to display the specified secret, it may take some time to support, because it involves LibFUSE(I will follow up this demand). On the other hand, ceph-fuse has stability, quota function, expansion, upgrade and other advantages. Although ceph-fuse only supports the secret file way, but if it can be pushed to the k8s community, there is a very meaningful thing.