jiebi/CodeConvo huggingface dataset:
Change:
description: A conformant Kubernetes distribution MUST support DaemonSet RollingUpdates. release: v1.10 file: test/e2e/apps/daemon_set.go <ins> - testname: Deployment, completes the scaling of a Deployment subresource codename: '[sig-apps] Deployment Deployment should have a working scale subresource [Conformance]' description: Create a Deployment with a single Pod. The Pod MUST be verified that it is running. The Deployment MUST get and verify the scale subresource count. The Deployment MUST update and verify the scale subresource. The Deployment MUST patch and verify a scale subresource. release: v1.21 file: test/e2e/apps/deployment.go </ins> - testname: Deployment Recreate codename: '[sig-apps] Deployment RecreateDeployment should delete old pods and create new ones [Conformance]'

Discussion:
[x] two weeks soak end date : 26 Feb 2021 According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. with this query you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a Deployment with a static label Read the Deployment Update the DeploymentScale Get the DeploymentScale to ensure it is updated Patch the DeploymentScale Read the DeploymentScale to ensure it is Patch Delete the Namespace and Deployment Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent ----------------------------------------|
patchAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource readAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource replaceAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource (3 rows) If a test with these calls gets merged, test coverage will go up by N points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Issue was presented in the Conformance meeting of 9 Feb 2021 and it was agreed that that method see to achieve the purpose and a PR can be created. A similar approach would be taken for the DepoymentScale endpoints, and this issue was created for that purpose.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
auth_args="${auth_args} --client-ca-file=${CLIENT_CA_FILE}" fi <del> net_plugin_dir_args="" if [[ -n "${NET_PLUGIN_DIR}" ]]; then net_plugin_dir_args="--network-plugin-dir=${NET_PLUGIN_DIR}" </del> <ins> cni_conf_dir_args="" if [[ -n "${CNI_CONF_DIR}" ]]; then cni_conf_dir_args="--cni-conf-dir=${CNI_CONF_DIR}" fi cni_bin_dir_args="" if [[ -n "${CNI_BIN_DIR}" ]]; then cni_bin_dir_args="--cni-bin-dir=${CNI_BIN_DIR}" </ins> fi container_runtime_endpoint_args=""

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.
Change:
// TODO (#113700): patch claim := claim.DeepCopy() claim.Status.ReservedFor = valid <ins> // When a ResourceClaim uses delayed allocation, then it makes sense to // deallocate the claim as soon as the last consumer stops using // it. This ensures that the claim can be allocated again as needed by // some future consumer instead of trying to schedule that consumer // onto the node that was chosen for the previous consumer. It also // releases the underlying resources for use by other claims. // // This has to be triggered by the transition from "was being used" to // "is not used anymore" because a DRA driver is not required to set // `status.reservedFor` together with `status.allocation`, i.e. a claim // that is "currently unused" should not get deallocated. // // This does not matter for claims that were created for a pod. For // those, the resource claim controller will trigger deletion when the // pod is done. However, it doesn't hurt to also trigger deallocation // for such claims and not checking for them keeps this code simpler. if len(valid) == 0 && claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer { claim.Status.DeallocationRequested = true } </ins> _, err := ec.kubeClient.ResourceV1alpha2().ResourceClaims(claim.Namespace).UpdateStatus(ctx, claim, metav1.UpdateOptions{}) if err != nil { return err

Discussion:
When a ResourceClaim: uses delayed allocation does not get created for a specific pod (i.e. not from a template) then it currently gets allocated and remains allocated until: scheduling of a pod fails because the node originally chosen for the allocation isn't suitable, in which case the scheduler triggers deallocation via the user deletes the claim What we want instead is that deallocation gets triggered when the last user of such an allocated claim gets removed from . To avoid races, deallocation must be done through . This can be implemented either as a controller or directly in the API server.
/assign
/triage accepted /sig node /priority important-longterm /kind feature
Change:
} tf.ClientConfigVal = cmdtesting.DefaultClientConfig() <del> ioStreams, _, _, errBuf := genericclioptions.NewTestIOStreams() </del> <ins> ioStreams, _, outBuf, errBuf := genericclioptions.NewTestIOStreams() </ins> cmd := NewCmdDrain(tf, ioStreams) var recovered interface{}

Discussion:
When draining a node, using kubectl drain [NODE], the output resembles this: Expected output should indicate that the node was drained, for example: kubectl drain [NODE] No response <details</details<detailsCan reproduce locally using and printing the output </details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted
Change:
Protocol: ProtocolTCP, SetType:  HashIPPort, } <ins> setName := "NOT" </ins> fcmd := fakeexec.FakeCmd{ CombinedOutputScript: []fakeexec.FakeCombinedOutputAction{ // Success <del> func() ([]byte, error) { return []byte("10.120.7.100,tcp:8080 is in set FOOBAR."), nil }, </del> <ins> func() ([]byte, error) { return []byte("10.120.7.100,tcp:8080 is in set " + setName + "."), nil }, </ins> // Failure func() ([]byte, error) { <del> return []byte("192.168.1.3,tcp:8080 is NOT in set FOOBAR."), &fakeexec.FakeExitError{Status: 1} </del> <ins> return []byte("192.168.1.3,tcp:8080 is NOT in set " + setName + "."), &fakeexec.FakeExitError{Status: 1} </ins> }, }, }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--The method only finds string in output of , but when the name of the set contains , it will return no matter the entry exists in ipset or not. What happened: returns false whenever entry exists if the name of set contains , e,g: , , What you expected to happen: returns whether the entry exists whatever the set name is How to reproduce it (as minimally and precisely as possible): replace the set name to any name containing , for example in of , then cd to and run , and it fails on . Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.6, but the bug still exists in Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig network /kind bug
/assign
This page says that returns non-zero when entry does not exist in set, and zero when entry exists: and I tested the output of (ipset v6.29 on Ubuntu 16.04 LTS, kernel 4.4.0-116-generic),the result goes as follow: so maybe we can judge by return value of command and the separated output of stdout and stderr,
Change:
// at least "minFeasibleNodesToFind" feasible nodes no matter what the value of this flag is. // Example: if the cluster size is 500 nodes and the value of this flag is 30, // then scheduler stops finding further feasible nodes once it finds 150 feasible ones. <del> // When the value is 0, default percentage (50%) of the nodes will be scored. </del> <ins> // When the value is 0, default percentage (5%--50% based on the size of the cluster) of the // nodes will be scored. </ins> PercentageOfNodesToScore int32 // DEPRECATED.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Kubernetes scheduler has that specifies what percentage of the cluster nodes should be scored in each scheduling cycle. The scheduler stops scanning more nodes once that many nodes are found feasible for running the pod under consideration. The default value of this config option is 50 (for 50%). We should let the scheduler determine this value based on the size of the cluster when this config option is not provided. I'd propose this formula for finding the percentage: . This is a linear formula that gives us 50 when the cluster size is 100 nodes and 10 for a 5000 node cluster. The scheduler already has a lower bound of 50 nodes per scheduling cycle. As a part of this change, we should also add a 5% lower bound for the formula (If the result of the formula is below 5, we should return 5). Why is this needed: To improve scheduler performance in large clusters. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature /sig scheduling
/assign /remove-help
/assign wgliang
Thanks
Change:
arg:         "bar", expectFatal: true, }, <ins> { description: "cordon for multiple nodes", node:        node, expected:    cordoned_node, cmd:         NewCmdCordon, arg:         "node node1 node2", expectFatal: false, }, { description: "uncordon for multiple nodes", node:        cordoned_node, expected:    node, cmd:         NewCmdUncordon, arg:         "node node1 node2", expectFatal: false, }, </ins> } for _, test := range tests {

Discussion:
They should be consistent with all other commands that allow multiple arguments (since they already allow label selectors). should cordon all of them, not return an error.
Hi , can I take this if no one has been working on it?
Please also refer . These two and should take multiple arguments as it is very common to get subset of nodes in this way . So it would be very nice if these would work:
Change:
"context" "fmt" "os" <ins> "strings" </ins> "time" "github.com/onsi/ginkgo/v2"

Discussion:
Example failure - Serial node e2e tests This is new test introduced in v1.27 No response No response No response /sig node
It seems the issue is that a previous test that ran had a pod around which was not terminated, namely The test started around but (which was created by pod-conditions-test), was fully terminated only at which is after this test started: Due to the pod not being fully terminated when the test is being run, the metric assertions fail.
/triage accepted
Change:
```bash export KUBE_AWS_ZONE=eu-west-1c export NUM_NODES=2 <ins> export MASTER_SIZE=m3.medium </ins> export NODE_SIZE=m3.medium export AWS_S3_REGION=eu-west-1 export AWS_S3_BUCKET=mycompany-kubernetes-artifacts

Discussion:
I propose that we default to for the master node (and maybe for 150 nodes?). We've seen problems with running out of memory on the master with the , and we've seen pauses that look like CPU exhaustion on the t2 class in general. Also the master is the hardest instance to resize. It is doable to reconfigure the ASG for the nodes (or add a new one, but the master is tricky). what do you think? cc
Change:
} } <del> clientBuilder, rootClientBuilder := createClientBuilders(logger, c) </del> <ins> clientBuilder, rootClientBuilder := createClientBuilders(c) </ins> saTokenControllerDescriptor := newServiceAccountTokenControllerDescriptor(rootClientBuilder)

Discussion:
The kube-controller-manager issues a warning during startup when is specified without providing a . This warning is misleading because the legacy service account token controller, which relies on the , is no longer required for most modern Kubernetes clusters unless explicitly needed for generating long-lived tokens. Additionally, the documentation does not clearly state the purpose of this flag or its impact on legacy token mechanisms. I expected that the warning related to the would either not appear or be updated to reflect its relevance only to the legacy token mechanism. Furthermore, I expected the documentation to clearly explain that this flag is only necessary for enabling the legacy service account token controller and to provide updated guidance on generating long-lived tokens. kube-controller-manager with the --use-service-account-credentials flag but without the --service-account-private-key-file flag. the warning message that is issued during initialization. the current documentation for kube-controller-manager flags and the process for generating long-lived service account tokens. for context <details</details<detailsBare metal </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 auth
Change:
if [[ "${version}" != "v1beta3" ]]; then kube::log::status "Testing kubectl(${version}:minions)" <del> kube::test::get_object_assert minions '{{range.items}}{{.id}}:{{end}}' '127.0.0.1:' </del> <ins> kube::test::get_object_assert minions "{{range.items}}{{.$id_field}}:{{end}}" '127.0.0.1:' </ins> # TODO: I should be a MinionList instead of List kube::test::get_object_assert minions '{{.kind}}' 'List'

Discussion:
This works: Are we using /var/run for testing?
Curiously travis shows a similar error message regarding /var/run/kubernetes, but it isn't failing: I suspect the /var/run/kubernetes issue is not what's causing the failure here.
However, I am able to reproduce the failure on my machine. I note that in your case, the fatal error says For me, it says The ip addresses showing through here (which appear to be in the GCE space?) are worrying.
It seems it still failing. I've run it locally and it failed with the following error: The aforementioned line: I think it is expected that there are some pods started by k8s (e.g. elasticsearch). Does it mean the test has a bug?
Strangely the same code () passes tests on travis (https://travis-)
I think you're reading it backwards. The test is expecting no pods to be started, but finding the k8s add-on pods, which is normal if it were running against a normal master. In Travis, it's a synthetic environment with no add-ons. This should be assigned to whoever the checks (on mobile.. I know I merged the PR but don't remember who :)). We need to exclude the add-ons (perhaps by finally getting around to putting them in a separate namespace).
the assertions, so CC'ing for comment.
I looked into this with and it seems that test- may fail locally depending on the kubeconfig. Some commands are using defaults for kubectl and thus sometimes they contact another cluster. I'll send a PR to fix this.
Change:
}, Type: corev1.SecretTypeBootstrapToken, Data: map[string][]byte{ <del> bootstrapapi.BootstrapTokenIDKey:               []byte(tokenID), bootstrapapi.BootstrapTokenSecretKey:           []byte(secret), </del> <ins> bootstrapapi.BootstrapTokenIDKey:               []byte(validTokenID), bootstrapapi.BootstrapTokenSecretKey:           []byte(validSecret), </ins> bootstrapapi.BootstrapTokenUsageAuthentication: []byte("true"), }, }

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
case cache.Sync: err, retry := s.createLoadBalancerIfNeeded(namespacedName, service, cachedService.service) if err != nil { <ins> s.eventRecorder.Event(service, "creating loadbalancer failed", err.Error()) </ins> return err, retry } // Always update the cache upon success.

Discussion:
If a LoadBalancer cannot be created (e.g. quota limit hit), there is currently no way to know why other than reviewing the logs (?). We could put an status message / object into LoadBalancerStatus.
We could make an event for this too Justin Santa Barbara < :
+1 for event
I think that is reasonable, but we need to be careful how we define it. Event also sounds good. , Justin Santa Barbara < :
I'm in favor of status as well as an event. The pattern I recommend is an array of conditions, similar to NodeCondition, where each contains at least a Status, Reason, and Message.
+1 for an event. I'd argue this is important enough for usability that we should get it into v1.
How often does this failure mode occur?
I unfortunately don't have stats, but it can happen for a handful of reasons. I think these are the most likely: Cloud provider unavailability/errors Ran out of quota from the cloud provider The cluster is using a cloud provider that doesn't support external load balancers I expect the third one is most common by far. We could perhaps move that into the API object validation rather than writing events to handle that particularly case, but using events would solve all the cases together.
Change:
{% if grains.network_mode is defined and grains.network_mode == 'openvswitch' %} <del> openvswitch: pkg: - installed service.running: - enable: True </del> sdn: cmd.wait: - name: /kubernetes-vagrant/network_closure.sh - watch: <del> - pkg: docker-io - pkg: openvswitch </del> <ins> - sls: docker </ins> {% endif %}

Discussion:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?
Change:
// but this is not possible with libcontainers Set() method // See https://github.com/opencontainers/runc/issues/932 func setSupportedSubsystems(cgroupConfig *libcontainerconfigs.Cgroup) error { <del> for _, sys := range getSupportedSubsystems() { </del> <ins> for sys, required := range getSupportedSubsystems() { </ins> if _, ok := cgroupConfig.Paths[sys.Name()]; !ok { <del> return fmt.Errorf("Failed to find subsystem mount for subsystem: %v", sys.Name()) </del> <ins> if required { return fmt.Errorf("Failed to find subsystem mount for required subsystem: %v", sys.Name()) } // the cgroup is not mounted, but its not required so continue... glog.V(6).Infof("Unable to find subsystem mount for optional subsystem: %v", sys.Name()) continue </ins> } if err := sys.Set(cgroupConfig.Paths[sys.Name()], cgroupConfig); err != nil { return fmt.Errorf("Failed to set config for supported subsystems : %v", err)

Discussion:
If I run first time it goes fine (after reboot). For subsequent runs I get nodes NotReady. I've tried restarting docker but that won't help. Before christams this used to work all the time. Running Arch Linux if it helps. In I see
/sig node
ditto for me: Looking for a work around I noticed that HugePages recently moved to beta. I can get pods to start again by disabling the HugePages feature gate .
/assign
cc
default Arch kernel doesn't have a hugetlb cgroup controller compiled in(been there done that, I use Arch as well), so you have to prepare your own kernel to run it.
If it were a kernel problem I would have expected the kubelet to fail the first time it was started rather than the second time. This isn't confined to Arch, though. I'm having the same problem with the default Debian kernel:
can you check if your Kernel was compiled with flag? You can do it by running: I bet we have to add documentation, describing this behavior. On Ubuntu 16.04 machine:
Sure, looks like it was not: Documentation (especially in the error message) would be great, but if the kubelet isn't going to survive a restart, I would prefer that it not start the first time. Better to fail immediately than eventually.
can you please check if works (as in fails!) for you?
No, this doesn't resolve the issue. Logs from the first start: Logs from the second start:
Do you have the directory? in that case what i have is insufficient :( If you don't have that directory, then we should probably look for a better spot to put that check? any advice?
No, that directory is missing on my system:
I'm seeing this issue as well.
I am preparing a fix to not fail when hugetlb mount is not present. Will post a fix shortly.
I posted a fix here: