jiebi/CodeConvo huggingface dataset:
Change:
kube::build::docker_image_exists golang 1.3 || { [[ ${KUBE_SKIP_CONFIRMATIONS} =~ ^[yY]$ ]] || { echo "You don't have a local copy of the golang docker image. This image is 450MB." <del> read -p "Download it now? [y/n] " -n 1 -r </del> <ins> read -p "Download it now? [y/n] " -r </ins> echo [[ $REPLY =~ ^[yY]$ ]] || { echo "Aborting." >&2

Discussion:
Sometimes it is nice to have non-tar'd binaries for releases. We should upload those along with the our packaged tarballs. This will help fix
Change:
} func (recorder *recorderImpl) AnnotatedEventf(object runtime.Object, annotations map[string]string, eventtype, reason, messageFmt string, args ...interface{}) { <del> recorder.generateEvent(object, annotations, metav1.Now(), eventtype, reason, fmt.Sprintf(messageFmt, args...)) </del> <ins> recorder.generateEvent(object, annotations, eventtype, reason, fmt.Sprintf(messageFmt, args...)) </ins> } func (recorder *recorderImpl) makeEvent(ref *v1.ObjectReference, annotations map[string]string, eventtype, reason, message string) *v1.Event {

Discussion:
is defined here but never used. As this is an unexported method it doesn't affect anyone, just a small point of confusion for the reader. /sig api-machinery /kind bug
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted </details
/triage accepted removing triage since the PR seem to be fixing the issue /assign Please close when merged! thank you
Change:
func NewFakeOOMAdjuster() *OOMAdjuster { return &OOMAdjuster{ <ins> pidLister:                 func(cgroupName string) ([]int, error) { return make([]int, 0), nil }, </ins> ApplyOOMScoreAdj:          fakeApplyOOMScoreAdj, ApplyOOMScoreAdjContainer: fakeApplyOOMScoreAdjContainer, }

Discussion:
The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. 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 See PR for docs at 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
~This would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.
Change:
ready kubernetes %v in-addr.arpa ip6.arpa { pods insecure <del> upstream </del> fallthrough in-addr.arpa ip6.arpa ttl 30 }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: I believe this started with Any thoughts /cc /priority important-soon /milestone v1.19 /sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: /priority important-soon /milestone v1.19 /sig network </details
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
// Starts background goroutines. If config_path, manifest_url, or address are empty, // they are not watched. Never returns. <del> func (kl *Kubelet) RunKubelet(config_path, manifest_url, etcd_servers, address string, port uint) { </del> <ins> func (kl *Kubelet) RunKubelet(config_path, manifest_url, etcd_servers, address, endpoint string, port uint) { </ins> if kl.DockerPuller == nil { <del> kl.DockerPuller = MakeDockerPuller() </del> <ins> kl.DockerPuller = MakeDockerPuller(endpoint) </ins> } updateChannel := make(chan manifestUpdate) if config_path != "" {

Discussion:
When using or with a key/value that has a multi-line string as value, that value will appear as quoted string in the log message, i.e. the log message will still be a single line. It would be nicer to print the value in text mode so that it goes across multiple lines, with clear indicators for start and end of the value. Indention could be used to avoid mistaking some embedded line as the start of a new log message. In JSON mode, the value should be formatted normally. /sig instrumentation /wg structured-logging Always printing as a single line can can make the log output unreadable ().
When adding something like this, can be reverted and implemented differently.
My original thinking was that only objects that explicitly ask for multi-line output get formatted that way. But that means that we need to review log calls very carefully. An alternative is to automatically switch from quoting strings to multi-line output based on some heuristic, for example when there's more than one line break.
Here's a potential implementation:
If structured logging is needed in any other case I can contribute, please inform if needed.
/triage accepted /assign /priority important-soon /area logging /cc /cc
We have the same problem as in kube-scheduler also in kubelet, it's just that no-one has seen and/or complained about the multi-line strings. With the benchmark + log analysis tool from I found the following multi-line string parameters in a kubelet log: <details</details
Change:
--secure_port=6443  --portal_net=10.100.0.0/16  --etcd_servers=http://127.0.0.1:4001  <del> --public_address_override=$private_ipv4  </del> <ins> --public_address_override=${DEFAULT_IPV4}  </ins> --logtostderr=true Restart=always RestartSec=10

Discussion:
Minor issues with 1) The examples rely on cloud vendor specific variables ($private_ipv4 ) 2) The wget command for kube-register always re-downloads
Change:
framework.ExpectEqual(len(dsList.Items), 0, "filtered list should have no daemonset") }) <del> ginkgo.It("should verify changes to a daemon set status", func() { </del> <ins> /*	Release: v1.22 Testname: DaemonSet, status sub-resource Description: When a DaemonSet is created it MUST succeed. Attempt to read, update and patch its status sub-resource; all mutating sub-resource operations MUST be visible to subsequent reads. */ framework.ConformanceIt("should verify changes to a daemon set status", func() { </ins> label := map[string]string{daemonsetNameLabel: dsName} labelSelector := labels.SelectorFromSet(label).String()

Discussion:
[x] test approval issue : [X] test pr : 26 May [x] two weeks soak end date : 9 June [x] test promotion pr : kubernetes/kubernetes According to this APIsnoop query, there are still some remaining DaemonSet endpoints which are untested. Create a watch to track daemon set events that DaemonSet with a static label Create a daemon set with a static label. Confirm that the pods are running. Get the daemon set status. Parse the response and confirm that the daemon set status conditions can be listed. Update the daemon set status. Confirm via the watch that the status has been updated. Patch the daemon set status. Confirm via the watch that the status has been patched. Using an existing as a template for a new which validates that three new endpoints are hit. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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:
// need to verify that the item matches the set of scopes matchesScopes := true for _, scope := range options.Scopes { <del> innerMatch, err := scopeFunc(corev1.ScopedResourceSelectorRequirement{ScopeName: scope}, item) </del> <ins> innerMatch, err := scopeFunc(corev1.ScopedResourceSelectorRequirement{ScopeName: scope, Operator: corev1.ScopeSelectorOpExists}, item) </ins> if err != nil { return result, nil }

Discussion:
If a Pod is subjected to a with "PriortyClass" as its scope, the quota's calculation is incorrect. See repo steps for more details. with "PriortyClass" as its scope can be calculated at all times. Create a PriorityClass named "p1"Create a quota with as its scope. Note: w/o specifying , this issue won't happenCreate a Job and wait for its completion.Check quota's usage calculation Here is incorrect - it should be . Worse calculation may happen if I create a regular pod and then delete the Job:The eventual result is totally incorrect. No response master, and possibly all versions. kind <details</details<details</details<details</details<details</details
/sig api-machinery /kind bug
/triage accepted
I would like to take this up!
is already in flight for this
Change:
return cmd, commandFns } <del> // makeSymlinks will create a symlink for each command in the local directory. func makeSymlinks(targetName string, commandFns []func() *cobra.Command) error { wd, err := os.Getwd() if err != nil { return err } var errs bool for _, commandFn := range commandFns { command := commandFn() link := path.Join(wd, command.Name()) err := os.Symlink(targetName, link) if err != nil { errs = true fmt.Println(err) } } if errs { return errors.New("Error creating one or more symlinks") } return nil } </del>

Discussion:
Follow up for the deprecation we did in 1.14:
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 /good-first-issue
This request has been marked as suitable for new contributors. 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 : /remove-lifecycle stale /good-first-issue 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
/sig release
I am willing to take this, if it is available :)
go for it. All you need to do is remove and associated code -
I ended up getting hit with the removal of the --make-symlinks flag. I looked at the threads linked to the original PR, but I did not find the actual reason behind the removal. Do you recall was the reason behind removing that capability?
the original request was from
Change:
expectedList: []framework.NodeScore{{Name: "machine1", Score: 0}, {Name: "machine2", Score: 50}}, name:         "Another stateful set with partial pod label matches", }, <ins> { pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Labels:          labels1, OwnerReferences: controllerRef("StatefulSet", "name", "abc123"), }, Spec: v1.PodSpec{ TopologySpreadConstraints: []v1.TopologySpreadConstraint{ { MaxSkew:           1, TopologyKey:       "foo", WhenUnsatisfiable: v1.DoNotSchedule, }, }, }, }, pods: []*v1.Pod{ {Spec: zone1Spec, ObjectMeta: metav1.ObjectMeta{Labels: labels2, OwnerReferences: controllerRef("StatefulSet", "name", "abc123")}}, {Spec: zone1Spec, ObjectMeta: metav1.ObjectMeta{Labels: labels1, OwnerReferences: controllerRef("StatefulSet", "name", "abc123")}}, {Spec: zone2Spec, ObjectMeta: metav1.ObjectMeta{Labels: labels1, OwnerReferences: controllerRef("StatefulSet", "name", "abc123")}}, }, nodes:        []string{"machine1", "machine2"}, sss:          []*apps.StatefulSet{{Spec: apps.StatefulSetSpec{Selector: &metav1.LabelSelector{MatchLabels: map[string]string{"baz": "blah"}}}}}, expectedList: []framework.NodeScore{{Name: "machine1", Score: 0}, {Name: "machine2", Score: 0}}, name:         "Another stateful set with TopologySpreadConstraints set in pod", }, </ins> } for _, test := range tests {

Discussion:
Currently the scheduler by default spreads the pods of a deployment based on a hard-coded . We recently a pod object api (pod.Spec.TopologySpreadConstraints) that allows specifying spread behavior at the workload level. For pods that specify topology spread constraints, the default spreading behavior should not apply. /sig scheduling /cc
I can fix this behavior, can you assign it to me?
/assign sure, lets wait for feedback first.
sure, thanks
I agree. Having the default spreading run would just water down the score given by the constraints. Other than that, this would just be a temporary fix until is finalized
Change:
cmd := []string{"cmd", "/c", "echo windows-volume-test", ">", filePath} <ins> ginkgo.By("verifying that pod will get an error when writing to a volume that is readonly") </ins> _, stderr, _ := f.ExecCommandInContainerWithFullOutput(podName, containerName, cmd...) framework.ExpectEqual(stderr, "Access is denied.") } func doReadWriteReadOnlyTest(f *framework.Framework, source v1.VolumeSource, volumePath string) { var ( <del> filePath        = volumePath + "test-file" </del> <ins> filePath        = volumePath + "test-file" + string(uuid.NewUUID()) </ins> podName         = "pod-" + string(uuid.NewUUID()) pod             = testPodWithROVolume(podName, source, volumePath) rwcontainerName = containerName + "-rw"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- Kubernetes e2e suite: [sig-windows] [Feature:Windows] Windows volume mounts check volume mount permissions container should have readOnly permissions on hostMapPath Feb 23 14:59:47.591: FAIL: cmd: [cmd /c echo windows-volume-test C:tmptest-file], stdout: "", stderr: "Access is denied."
/sig windows
/assign
Looks like it's a flaky test instead of a failing test /cc
mentioned this could be related to permissions: There might be two things happening, the test isn't actually waiting for pod to start (which is why it passes sometimes) and but when it does start it fails the test due to the permissions
` is used for creating the pods. According to the comments, the Pods should be up and running:
On successful run, I see the following in the kubelet logs: I believe we're execing into the pod when the container is actually getting deleted by containerd but the pod is running which is not giving a correct indication of the command. I am modifying the test to ensure we would wait till all the containers are Ready and log the stdout and stderr to see if we're noticing issues. I tried manually running this test on a Windows node but couldn't reproduce it.
More examples of flaking runs:
/assign
I ran the test continuously: I am guessing this might be due to some of resources constraints we have seen when other tests runs at the same time (such as ). looking into it further...
Maybe we can convert it to a serial test case?
maybe, slowly looking into is some more... I find it interesting that which essentially does the same thing
Here's another:
Figured out what is happening: If the test runs before it leaves a file behind that the new test doesn't have permissions to. To repo: Then run:
/triage accepted
Change:
# keep request = limit to keep this container in guaranteed class limits: cpu: 10m <del> memory: 20Mi </del> <ins> memory: 50Mi </ins> requests: cpu: 10m <del> memory: 20Mi </del> <ins> # Note that this container shouldn't really need 50Mi of memory. The # limits are set higher than expected pending investigation on #29688. # The extra memory was stolen from the kubedns container to keep the # net memory requested by the pod constant. memory: 50Mi </ins> args: - -cmd=nslookup kubernetes.default.svc.__PILLAR__DNS__DOMAIN__ 127.0.0.1 >/dev/null && nslookup kubernetes.default.svc.__PILLAR__DNS__DOMAIN__ 127.0.0.1:10053 >/dev/null - -port=8080

Discussion:
Observed weird memory spikes for both the dns healthz and kube-dns pods in production. Kube-dns didn't oom because there's enough headroom, but healthz did. I can't explain the spikes yet. I tried a bunch of different repros: no , bad nslookup command, sharing the node with cpu hogs etc, but was unable to trigger it. The memory grows, but stays under 10Mi. As a short term mitigation, we stole some ram from kube-dns, because it was always comfortably within limits. Related b/
can be closed -- healthz has been removed
-- close issue?
Change:
// DecodeNestedObjects decodes plugin args for known types. func (c *KubeSchedulerConfiguration) DecodeNestedObjects(d runtime.Decoder) error { <ins> var strictDecodingErrs []error </ins> for i := range c.Profiles { prof := &c.Profiles[i] for j := range prof.PluginConfig { err := prof.PluginConfig[j].decodeNestedObjects(d) if err != nil { <del> return fmt.Errorf("decoding .profiles[%d].pluginConfig[%d]: %w", i, j, err) </del> <ins> decodingErr := fmt.Errorf("decoding .profiles[%d].pluginConfig[%d]: %w", i, j, err) if runtime.IsStrictDecodingError(err) { strictDecodingErrs = append(strictDecodingErrs, decodingErr) } else { return decodingErr } </ins> } } } <ins> if len(strictDecodingErrs) > 0 { return runtime.NewStrictDecodingError(strictDecodingErrs) } </ins> return nil }

Discussion:
With the addition of server side validation in 1.23, it is now possible for a call to successfully decode it’s data and return a non-nil error when there are strict decoding errors (e.g. duplicate/unknown fields). This means that callers of can distinguish between fatal errors (that cause decoding to fail) and strict decoding errors (that still allow the decode to succeed) by inspecting the target object (to see if it was successfully decoded into) and the error itself (to see if it is a ) With the NestedObjectDecoder however, it only returns an error from giving no indication whether a strict decoding error it has returned comes from an internal decode step that short circuited (by not accounting for strict decoding errors) or actually did successfully decode, but also encountered strict decoding errors. We propose taking a few actions to minimize the possibility of erroneous short-circuiting from Document how all nested decoders should only return strict decoding errors if all decoding is successful or return only non-strict decoding (ie. fatal errors). Document this for all known in-tree and out-of-tree . Update in-tree nested decoders to do the above mentioned behavior (which is just the kube-scheduler) Long-term solutions to better guarantee that no erroneous short-circuiting is taking place could include deprecating the current interface in favor of one that returns both the target object that was decoded into along with an error return a special error type specific to indicating that all internal decoding was successful.
/sig api-machinery
/triage accepted
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" <del> kubefeatures "k8s.io/kubernetes/pkg/features" </del> "k8s.io/kubernetes/test/e2e/framework" e2enetwork "k8s.io/kubernetes/test/e2e/framework/network" <del> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" </del> imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api"

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
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
Same failure in
I think this is related to the change @ could you please help take a look?
We already discussed this in The change from correctly points out that the test isn't working as expected. It needs to be fixed. /unassign
/assign
After , the tests are still failing. Could you help check it?
The skip function is used in another case as well. We may remove that like .
will fix this.
/close the test grid is green now.
Closing this issue. <detailsIn response to : /close the test grid is green now. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
proxyTransportDial:         s.proxyTransportDial, serviceResolver:            s.serviceResolver, rejectForwardingRedirects:  s.rejectForwardingRedirects, <ins> tracerProvider:             s.tracerProvider, </ins> } proxyHandler.updateAPIService(apiService) if s.openAPIAggregationController != nil {

Discussion:
Extension API servers do not currently receive the header when requests are proxied through kube-aggregator, so spans are not linked properly. Traces from the extension API sever should be linked to the parent in kube-aggregator. tracing for kube-apiserver tracing for sample-apiserver and aggregate it to kube-apiserver a request to kube-apiserver for one of the resources from sample-apiserver sample-apiserver traces will not be linked to the kube-apiserver traces No response <detailsThis problem currently exists on . </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted