jiebi/CodeConvo huggingface dataset:
Change:
// is the max character length for the USER itself. Both the DOMAIN and USER have their // own restrictions, and more information about them can be found here: // https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and <del> // https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1 </del> <ins> // https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb726984(v=technet.10) </ins> const ( maxGMSACredentialSpecLengthInKiB = 64 maxGMSACredentialSpecLength      = maxGMSACredentialSpecLengthInKiB * 1024 maxRunAsUserNameDomainLength     = 256 <del> maxRunAsUserNameUserLength       = 21 </del> <ins> maxRunAsUserNameUserLength       = 104 </ins> ) var (

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! If the matter is security related, please disclose it privately via --What happened: Currently, the character limit for the usernames set in the field is 20, which is too low, considering that "ContainerAdministrator" is a valid username and it is longer than 20 characters. A user should be able to run containers as Administrator, if needed. What you expected to happen: Users should be able to spawn pods which run as. How to reproduce it (as minimally and precisely as possible): WindowsRunAsUserName feature gate. () Anything else we need to know?: /sig windows /priority important-soon /milestone 1.16 Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: N/A OS (e.g: ): Windows Server 2019 Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others:
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : <!-- 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! --2. ` /priority important-soon /milestone 1.16 Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: N/A OS (e.g: ): Windows Server 2019 Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: </details
/milestone v1.16
Change:
JSON and YAML formats are accepted. <ins> Please refer to the models in https://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/HEAD/docs/api-reference/definitions.html to find if a field is mutable. </ins> ``` kubectl replace -f FILENAME ```

Discussion:
The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.
Change:
func listDaemonPods(ctx context.Context, c clientset.Interface, ns string, label map[string]string) *v1.PodList { selector := labels.Set(label).AsSelector() <del> options := metav1.ListOptions{LabelSelector: selector.String()} </del> <ins> options := metav1.ListOptions{ LabelSelector: selector.String(), FieldSelector: nonTerminalPhaseSelector.String(), } </ins> podList, err := c.CoreV1().Pods(ns).List(ctx, options) framework.ExpectNoError(err) gomega.Expect(podList.Items).ToNot(gomega.BeEmpty())

Discussion:
master-blocking Conformance - GCE - master - kubetest2Kubernetes e2e suite. ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test ! 2023-06-27 16:43 PDT Kubernetes e2e suite: [It] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] No response /sig cloud-provider /sig apps cc
This is more critical than I expected it starts to fail in other jobs ,%20master ,%20ipvs,%20dual,%20master From the diff the best candidate seems can you PTAL /priority critical-urgent
/assign
anyone from you can please add to this issue?
/triage accepted
I have a proposed fix in . Is there a job I can add?
/remove-kind failing-test /kind flake
Change:
for i := 0; i < 3; i++ { framework.Logf("PD Read/Writer Iteration #%v", i) By("submitting host0Pod to kubernetes") <ins> host0Pod = testPDPod([]string{disk1Name, disk2Name}, host0Name, false /* readOnly */, 1 /* numContainers */) </ins> _, err = podClient.Create(host0Pod) framework.ExpectNoError(err, fmt.Sprintf("Failed to create host0Pod: %v", err))

Discussion:
PR moved some PD tests to flaky to resolve issue (and duplicate ). These tests started failing due to PR . is working on a patch to de-flake the tests. This issue is to track the fix and should be closed when: PD tests have been deflaked (verify by running the "" e2e tests back to back for a couple of hours to verify the issue is fixed). flaky label has been removed from the "" tests that were marked flaky in CC
how to watch the submit queue and find if the flake is gone?
I don't know. is there any way can verify whether test is no longer flaky?
I'm not sure what the publicly accessible link for test history is. I took a look for you: Pod Disks should schedule a pod w/ a RW PD shared between multiple containers, write to PD, delete pod, verify contents, and repeat in rapid succession Failed 3 times in the last 30 runs. Stability: 90 % Pod Disks should schedule a pod w/two RW PDs both mounted to one container, write to PD, verify contents, delete pod, recreate pod, verify contents, and repeat in rapid succession Failed 1 times in the last 30 runs. Stability: 96 % I have a PR pending that enables the new attach/detach controller and I was able to run the tests back to back overnight without any failures. So once that gets merged, we can take a look at moving these tests back.
Something in PD attach/detach affects also 'Dynamic provisioning' e2e test, a PD is still attached to a node ~15 minutes after appropriate pod was deleted and thus deleter can't delete it. From controller log:
please take a look at https://k8s-
thanks so at least one of the flake has a different error than "container not found" In one, the error is
^^ the above seems like a possible bug in exec
^
The error to me indicates that the original container is no longer around as exec can't find the ipc namespace fd. Are we sure the container that we are trying to join is still around?
my memory is rusty but did you have an idea to randomize the container id in this pd test?
see the info here:
Close we will track this with
Change:
podsToAdd:    []*v1.Pod{testPods[0]}, }} <del> for _, tt := range tests { cache := newSchedulerCache(ttl, time.Second, nil) for _, podToAssume := range tt.podsToAssume { if err := assumeAndFinishBinding(cache, podToAssume, now); err != nil { t.Errorf("assumePod failed: %v", err) </del> <ins> for i, tt := range tests { t.Run(fmt.Sprintf("case_%d", i), func(t *testing.T) { cache := newSchedulerCache(ttl, time.Second, nil) for _, podToAssume := range tt.podsToAssume { if err := assumeAndFinishBinding(cache, podToAssume, now); err != nil { t.Errorf("assumePod failed: %v", err) } </ins> } <del> } for _, podToAdd := range tt.podsToAdd { if err := cache.AddPod(podToAdd); err != nil { t.Errorf("AddPod failed: %v", err) </del> <ins> for _, podToAdd := range tt.podsToAdd { if err := cache.AddPod(podToAdd); err != nil { t.Errorf("AddPod failed: %v", err) } </ins> } <del> } snapshot := cache.Dump() if len(snapshot.Nodes) != len(cache.nodes) { t.Errorf("Unequal number of nodes in the cache and its snapshot. expected: %v, got: %v", len(cache.nodes), len(snapshot.Nodes)) } for name, ni := range snapshot.Nodes { nItem := cache.nodes[name] if !reflect.DeepEqual(ni, nItem.info) { t.Errorf("expect n%+v; got n%+v", nItem.info, ni) </del> <ins> snapshot := cache.Dump() if len(snapshot.Nodes) != len(cache.nodes) { t.Errorf("Unequal number of nodes in the cache and its snapshot. expected: %v, got: %v", len(cache.nodes), len(snapshot.Nodes)) </ins> } <del> } if !reflect.DeepEqual(snapshot.AssumedPods, cache.assumedPods) { t.Errorf("expect n%+v; got n%+v", cache.assumedPods, snapshot.AssumedPods) } </del> <ins> for name, ni := range snapshot.Nodes { nItem := cache.nodes[name] if !reflect.DeepEqual(ni, nItem.info) { t.Errorf("expect n%+v; got n%+v", nItem.info, ni) } } if !reflect.DeepEqual(snapshot.AssumedPods, cache.assumedPods) { t.Errorf("expect n%+v; got n%+v", cache.assumedPods, snapshot.AssumedPods) } }) </ins> } }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign
Change:
var _ Interface = new(cadvisorClient) // New creates a cAdvisor and exports its API on the specified port if port > 0. <del> func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string) (Interface, error) { </del> <ins> func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string, usingLegacyStats bool) (Interface, error) { </ins> client, err := winstats.NewPerfCounterClient() return &cadvisorClient{winStatsClient: client}, err }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: is failing with: What you expected to happen: The cross build should work,. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It looks like this happened in , probably because we don't block the queue on cross :-( xref: /priority failing-test /sig release
Additionally ideally sig-release should for this job.
/assign
, is making a fix and then we'll look at making sure cross blocks PRs it runs against in the future.
Change:
"items":[ { "kind":"None", <del> "metadata":{"name":"127.0.0.1"}, </del> <ins> "metadata":{ "name":"127.0.0.1", "labels":{ "kubernetes.io/hostname":"127.0.0.1" } }, </ins> "status":{ "capacity":{"cpu":"4"}, "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]

Discussion:
I love using but I cannot figure out how to print an annotation that contains a special character like or or . This does not work: nor this: nor this: nor this: kubectl get pods tmp--dhpx0 -o jsonpath="{$['metadata']['annotations']['']}" (the last one should work according to what I can find about jsonPath, but doesn't, and anyhow is hard to get shell escaping right for. Need a way to quote a
A use case for this is extracting "created-by" or "init-container" annotations. I've wanted to do both in the last month and fought jsonpath.
FYI, this is possible with go-template. We should still fix the jsonpath though. Similar issue:
Change:
# # This entry is a stub of the major version to allow dependency checks to # pass when building Kubernetes using a pre-release of Golang. <del> # TODO: remove this when whe have the go1.23 released and not the rc. # - name: "golang: 1.<major>" #   version: 1.22 #   refPaths: #   - path: build/build-image/cross/VERSION #   - path: hack/lib/golang.sh #     match: minimum_go_version=go([0-9]+.[0-9]+) </del> <ins> - name: "golang: 1.<major>" version: 1.22 refPaths: - path: build/build-image/cross/VERSION - path: hack/lib/golang.sh match: minimum_go_version=go([0-9]+.[0-9]+) </ins> - name: "registry.k8s.io/kube-cross: dependents" <del> version: v1.31.0-go1.23rc2-bullseye.0 </del> <ins> version: v1.31.0-go1.22.5-bullseye.0 </ins> refPaths: - path: build/build-image/cross/VERSION

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)
Change:
Subsystem:         KubeletSubsystem, Name:              ActiveConfigKey, Help:              "The config source the node is actively using. The count is always 1.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

Discussion:
This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
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
/cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Change:
eps := sets.NewString() filterCmd := fmt.Sprintf("%s | grep -v '^s*$'", cmd) <ins> framework.Logf("Going to poll %v on port %v at least %v times, with a maximum of %v tries before failing", targetIP, targetPort, minTries, maxTries) </ins> for i := 0; i < maxTries; i++ { stdout, stderr, err := config.f.ExecShellInPodWithFullOutput(config.HostTestContainerPod.Name, filterCmd) if err != nil || len(stderr) > 0 {

Discussion:
What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar
Change:
// Config holds the information needed to build connect to remote kubernetes clusters as a given user type Config struct { <del> v1beta3.TypeMeta `json:",inline"` </del> <ins> // Legacy field from pkg/api/types.go TypeMeta. // TODO(jlowdermilk): remove this after eliminating downstream dependencies. Kind string `json:"kind,omitempty"` // Version of the schema for this config object. APIVersion string `json:"apiVersion,omitempty"` </ins> // Preferences holds general information to be use for cli interactions Preferences Preferences `json:"preferences"` // Clusters is a map of referencable names to cluster configs

Discussion:
has a dependency on pkg/api for , which it embeds in . Is it doing that to take advantage of validation code, or can Config just declare and directly and avoid the dependency?
A quick try (just declaring a in the package) seems to work fine with . I only included those out of habit.
Out of curiosity, is this just for a proper separate of packages or is there some functional issue as well?
mentioned encountering an issue with tests, but it's mostly just for proper separation of packages.
Related: Remove json tags from
See also
Not done:
Change:
syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0) } <ins> // DaemonSet should launch a pod on a not ready node with taint notReady:NoExecute. func TestNotReadyNodeDaemonLaunchesPod(t *testing.T) { manager, podControl, _ := newTestController() node := newNode("tainted", nil) setNodeTaint(node, nodeNotReady) node.Status.Conditions = []v1.NodeCondition{ {Type: v1.NodeReady, Status: v1.ConditionFalse}, } manager.nodeStore.Add(node) ds := newDaemonSet("simple") manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0) } // DaemonSet should launch a pod on an unreachable node with taint unreachable:NoExecute. func TestUnreachableNodeDaemonLaunchesPod(t *testing.T) { manager, podControl, _ := newTestController() node := newNode("tainted", nil) setNodeTaint(node, nodeUnreachable) node.Status.Conditions = []v1.NodeCondition{ {Type: v1.NodeReady, Status: v1.ConditionUnknown}, } manager.nodeStore.Add(node) ds := newDaemonSet("simple") manager.dsStore.Add(ds) syncAndValidateDaemonSets(t, manager, ds, podControl, 1, 0) } </ins> // DaemonSet should launch a pod on an untainted node when the pod has tolerations. func TestNodeDaemonLaunchesToleratePod(t *testing.T) { manager, podControl, _ := newTestController()

Discussion:
When writing DaemonSets we decided that they shouldn't be deleted by NodeController in case of Node problems. Now that we're moving to using taints and taint-based evictions (NC will just taint Nodes and the rest will be done by generic taint-eviction mechanism) we need to add infinite toleration for those taints to DaemonSets to keep this behavior. cc
Off the top of my head, I think the best way to implement this is to modify the , to special-case DaemonSet pods and add infinite tolerationSeconds to them. (See definition of field in the API for how to do this.) do you think you can do this? It should be a simple change. cc/ BTW the feature Marek described will be alpha in 1.6, but nobody will be able to use it (without breaking DaemonSet) unless this request is implemented. So the 1.6 milestone tag is appropriate.
Why wouldn't the daemon set controller special case that?
Yeah, I guess that's probably better - have the DaemonSet controller create pods with the toleration.
I can do this, and yes, in the DaemonSet controller.
Change:
if !found { return api.PodTerminated, nil } <ins> if pod.CurrentState.Info == nil { return api.PodWaiting, nil } </ins> running := 0 stopped := 0 unknown := 0

Discussion:
to reproduce: create vagrant kubernetes with 5 minions. try guest book example on it. After provisioning: then kill 10.245.2.6 minion: then we get: Nothing changes even after waiting for significant period of time. Please note, that while redis-master wasn't in replication controller and it's not expected for it to restart, it's still wrongfully marked as Running.