jiebi/CodeConvo huggingface dataset:
Change:
ClientConfig: kubeconfig, } var clientBuilder controller.ControllerClientBuilder <del> if len(s.ServiceAccountKeyFile) > 0 && s.UseServiceAccountCredentials { </del> <ins> if s.UseServiceAccountCredentials { if len(s.ServiceAccountKeyFile) > 0 { // It's possible another controller process is creating the tokens for us. // If one isn't, we'll timeout and exit when our client builder is unable to create the tokens. glog.Warningf("--use-service-account-credentials was specified without providing a --service-account-private-key-file") } </ins> clientBuilder = controller.SAControllerClientBuilder{ ClientConfig:         restclient.AnonymousClientConfig(kubeconfig), CoreClient:           kubeClient.CoreV1(),

Discussion:
/kind bug What happened: I'm unable to set up a k8s cluster with RBAC due authorization errors (guessing) Nor set up kube-dns How to reproduce it (as minimally and precisely as possible): Run each component with these options: Anything else we need to know?: PRs and were patched against and kubelet + kube-controller-manager are being executed with those patches in place. Since those patches are IPv6 related, they should not affect the errors I'm seeing. Environment: Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig auth
you are telling the controller-manager to run its control loops using service account credentials (the flag), but you are not giving the controller manager a so it can actually create those credentials. You would need to specify that, and also give the corresponding public key to the apiserver (with ) so the credentials are recognized.
Opened to make it clearer when the controller manager is in this situation (it would log a warning and fail to start, rather than continue incorrectly)
Change:
// So this function needs to be called after the extra envs are applied. func updateImageWhiteList() { // Union NodePrePullImageList and CommonImageWhiteList into the framework image pre-pull list. <del> framework.ImageWhiteList = NodePrePullImageList.Union(commontest.CommonImageWhiteList) </del> <ins> framework.ImageWhiteList = NodePrePullImageList.Union(commontest.PrePulledImages) </ins> // Images from extra envs framework.ImageWhiteList.Insert(getNodeProblemDetectorImage()) framework.ImageWhiteList.Insert(getSRIOVDevicePluginImage())

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
/assign
/lifecycle active /remove-help
what happened with ?
I redid it here There was a bit of confusion I'll fix it up.
/wg naming
Change:
# to readonly. # The configured vars will only contain platforms allowed by the # KUBE_SUPPORTED* vars at the top of this file. <del> declare -a -g KUBE_SERVER_PLATFORMS declare -a -g KUBE_CLIENT_PLATFORMS declare -a -g KUBE_NODE_PLATFORMS declare -a -g KUBE_TEST_PLATFORMS </del> <ins> declare -a KUBE_SERVER_PLATFORMS declare -a KUBE_CLIENT_PLATFORMS declare -a KUBE_NODE_PLATFORMS declare -a KUBE_TEST_PLATFORMS </ins> kube::golang::setup_platforms() { if [[ -n "${KUBE_BUILD_PLATFORMS:-}" ]]; then # KUBE_BUILD_PLATFORMS needs to be read into an array before the next

Discussion:
Commits and on master via PRs and have broken MacOS 'make' again: where "MacOS" is a non-homebrew extended MacOS with old old bash. This is also reported on other older platforms like CentOS. Master needs fixed with a new commit, then the above PRs and and the new fix need cherry picked to 1.14 as 1.14.2 is currently not buildable as is cherry picked there. :bash_fire"
/sig release /priority critical-urgent
/cc is looking at this
Change:
}, fakeCloud: &fake_cloud.FakeCloud{ Machines: []string{"node0", "node1"}, <ins> ExtID: map[string]string{ "node0": "ext-node0", "node1": "ext-node1", }, </ins> }, matchRE:              ".*", expectedRequestCount: 2, // List + Create <del> expectedCreated:      []string{"node1"}, </del> <ins> expectedNameCreated:  []string{"node1"}, expectedExtIDCreated: []string{"ext-node1"}, </ins> expectedDeleted:      []string{}, }, {

Discussion:
I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).
Change:
// set the next loop up options.Continue = m.GetContinue() <del> // Clear the ResourceVersion on the subsequent List calls to avoid the </del> <ins> // Clear the ResourceVersion(Match) on the subsequent List calls to avoid the </ins> // `specifying resource version is not allowed when using continue` error. // See https://github.com/kubernetes/kubernetes/issues/85221#issuecomment-553748143. options.ResourceVersion = "" <ins> options.ResourceVersionMatch = "" </ins> // At this point, result is already paginated. paginatedResult = true }

Discussion:
We recently started using the list pager from client-go as part of Calico, and have seen reports of the following error showing up: No error, just beautiful paged list calls. Create 1,000 resources of a particular type, such as a NetworkPolicy. (Need 500 to trigger paging) Do a of all those resources with set. Originally filed here (but maybe that repo is not monitored): Reference issue in Calico: projectcalico/calico (comment) Reference Calico list pager code: We think this is the required fix: <detailsclient-go version (but bug seems to be in master too). </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted
Change:
for i := range peerPkgs { peerPkgs[i] = genutil.Vendorless(peerPkgs[i]) } <ins> for i := range extraDirs { extraDirs[i] = genutil.Vendorless(extraDirs[i]) } </ins> // Make sure our peer-packages are added and fully parsed. <del> for _, pp := range peerPkgs { </del> <ins> for _, pp := range append(peerPkgs, extraDirs...) { </ins> context.AddDir(pp) p := context.Universe[pp] if nil == p {

Discussion:
In the codegenerator we have: So basically we process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator. This is problematic, when regenerating conversions, we simply pass to input directories only those that were changed in the meantime: We should fix that - probably by passing all CONVERSIONDIRS as inputs to conversion-gen /kind-bug
I think this caused Not sure if was related yet.
It's the other way around - this is the main bug and root cause and the other that you linked is a consequence.
Also - FYI
I actually already started looking into it - so let me assign this.
is out for review
/triage accepted
Change:
"k8s.io/kubernetes/pkg/kubelet/cm" evictionapi "k8s.io/kubernetes/pkg/kubelet/eviction/api" "k8s.io/kubernetes/pkg/kubelet/lifecycle" <ins> "k8s.io/kubernetes/pkg/kubelet/metrics" </ins> kubepod "k8s.io/kubernetes/pkg/kubelet/pod" "k8s.io/kubernetes/pkg/kubelet/qos" "k8s.io/kubernetes/pkg/kubelet/server/stats"

Discussion:
We should keep track of how stale stats used for evictions are. This will help track improvements in eviction latency, and help uncover regressions. cc If someone could assign this to me, I would appreciate that.
closing via
Change:
glog.V(1).Infof("Pulling image %s without credentials", image) } <del> return p.client.PullImage(opts, creds) </del> <ins> err := p.client.PullImage(opts, creds) // If there was no error, or we had credentials, just return the error. if err == nil || ok { return err } // Image spec: [<registry>/]<repository>/<image>[:<version] so we count '/' explicitRegistry := (strings.Count(image, "/") == 2) glog.Errorf("Foo: %s", explicitRegistry) // Hack, look for a private registry, and decorate the error with the lack of // credentials.  This is heuristic, and really probably could be done better // by talking to the registry API directly from the kubelet here. if explicitRegistry { return fmt.Errorf("image pull failed for %s, this may be because there are no credentials on this request.  details: (%v)", image, err) } return err </ins> } func (p throttledDockerPuller) Pull(image string) error {

Discussion:
I launched a pod forgetting that I had not uploaded my into the node's folder. Of course the image pull failed but the error message was not helpful: e.g. It should finish off the message with "because credentials for are not available to Kubernetes. This may be because blah"
Change:
package group import ( <del> "k8s.io/kubernetes/pkg/apis/extensions" </del> <ins> "strings" </ins> "testing" <ins> "k8s.io/kubernetes/pkg/apis/extensions" </ins> ) func TestMustRunAsOptions(t *testing.T) {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help
Change:
cliflag "k8s.io/component-base/cli/flag" "k8s.io/component-base/cli/globalflag" "k8s.io/component-base/configz" <ins> "k8s.io/component-base/metrics/features" </ins> controllersmetrics "k8s.io/component-base/metrics/prometheus/controllers" <ins> "k8s.io/component-base/metrics/prometheus/slis" </ins> "k8s.io/component-base/term" "k8s.io/component-base/version" "k8s.io/component-base/version/verflag"

Discussion:
As per, , wire up metrics/slis for ccm
/assign /sig instrumentation /sig cloud-provider
GitHub didn't allow me to assign the following users: Richabanker. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /sig instrumentation /sig cloud-provider 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
/assign
/triage accepted
/remove-triage accepted
/triage accepted
Change:
return path, nil }, <del> expectedOutput: false, expectError:    true, </del> <ins> expectedOutput: isRoot,  // ExistsPath success when running as root expectError:    !isRoot, // ExistsPath must fail when running as not-root </ins> }, { name: "relative symlink to existing file",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT What happened: TestNsenterExistsFile test is failing during make test What you expected to happen: The test should have passed. How to reproduce it (as minimally and precisely as possible): git clone run make test Anything else we need to know?: Fail logs: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig storage
If you run the test with root user, It will fail. I have make a fix:
thanks for the patch .. its working.
Change:
} for _, protocol := range protocols { <del> lbRuleName := az.getLoadBalancerRuleName(service, protocol, port.Port, subnet(service)) </del> <ins> lbRuleName := az.getLoadBalancerRuleName(service, protocol, port.Port) </ins> klog.V(2).Infof("reconcileLoadBalancerRule lb name (%s) rule name (%s)", lbName, lbRuleName) transportProto, _, probeProto, err := getProtocolsFromKubernetesProtocol(protocol)

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: When the specified internal LB uses a subnet with longer name, the LB configuration will fail with following error: What you expected to happen: When constructing the frontend IP configuration name and the load balancing rules name, the subnet name should be truncated if too long. How to reproduce it (as minimally and precisely as possible): Use a subnet that has long name (70 charactors) and create ILB service. Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: azure OS (e.g: ): Ubuntu 16.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure /assign
Change:
podName := "pod-dualstack-host-ips" <del> pod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:   podName, Labels: map[string]string{"test": "dualstack-host-ips"}, }, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:  "dualstack-host-ips", Image: imageutils.GetE2EImage(imageutils.Agnhost), }, }, HostNetwork: true, }, } </del> <ins> pod := genPodHostIPs(podName+string(uuid.NewUUID()), true) </ins> ginkgo.By("submitting the pod to kubernetes") podClient := e2epod.NewPodClient(f)

Discussion:
4 other Test Failures in ci-crio-cgroupv1-node-e2e-features. Test has failed 61 times (no passing result found). Earliest failure found at commit/ (Thu Oct 19 21:41 PDT). /cc { failed [FAILED] Error creating Pod: pods "pod-dualstack-host-ips9ddb9810-134c-4d35-a0c6-" is forbidden: violates PodSecurity "restricted:latest": host namespaces (hostNetwork=true) In [It] at: @ 10/23/23 01:38:06.024 } No response_ /sig network 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
/assign
is also failing on these tests
the test has a bug, it checks the contrary
, let's start over, 1 commit for the e2e test, other for the promotion, and let's validate everything is alright before merging
Change:
return suggestedDelay, utilerrors.NewAggregate(errs) } <del> func toFlowSchemaApplyConfiguration(fsUpdate fsStatusUpdate) *flowcontrolapplyconfiguration.FlowSchemaApplyConfiguration { condition := flowcontrolapplyconfiguration.FlowSchemaCondition(). WithType(fsUpdate.condition.Type). WithStatus(fsUpdate.condition.Status). WithReason(fsUpdate.condition.Reason). WithLastTransitionTime(fsUpdate.condition.LastTransitionTime). WithMessage(fsUpdate.condition.Message) return flowcontrolapplyconfiguration.FlowSchema(fsUpdate.flowSchema.Name). WithStatus(flowcontrolapplyconfiguration.FlowSchemaStatus(). WithConditions(condition), ) </del> <ins> // makeFlowSchemaConditionPatch takes in a condition and returns the patch status as a json. func makeFlowSchemaConditionPatch(condition flowcontrol.FlowSchemaCondition) ([]byte, error) { o := struct { Status flowcontrol.FlowSchemaStatus `json:"status"` }{ Status: flowcontrol.FlowSchemaStatus{ Conditions: []flowcontrol.FlowSchemaCondition{ condition, }, }, } return json.Marshal(o) </ins> } // shouldDelayUpdate checks to see if a flowschema has been updated too often and returns true if a delay is needed.

Discussion:
A lot of different routines failing just when setting up an apiserver. Example: <details</detailsNo errors The test still passes, but those errors seem very worrisome <detailsmaster </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery /sig testing cc
yeah, the framework has some long standing tech debt /cc
all the panics I see are:
looks like again, due to
Looks like some integration tests must not be enabling SSA.
yeah, a lot don't, because it requires openapi, which also isn't universally enabled in integration. it is really expensive at API server startup, and when we tried enabling it universally in integration it blew up runtimes and integration timed out super frequently
that's what is still open for
/triage accepted
Change:
serverVersion = flag.Bool("server_version", false, "Print the server's version number.") preventSkew   = flag.Bool("expect_version_match", false, "Fail if server's version doesn't match own version.") httpServer    = flag.String("h", "", "The host to connect to.") <del> config        = flag.String("c", "", "Path to the config file.") </del> <ins> config        = flag.String("c", "", "Path or URL to the config file.") </ins> selector      = flag.String("l", "", "Selector (label query) to use for listing") updatePeriod  = flag.Duration("u", 60*time.Second, "Update interval period") portSpec      = flag.String("p", "", "The port spec, comma-separated list of <external>:<internal>,...")

Discussion:
The kubecfg -c option is used to pass a file pointer to a representation of a model object on disk (pod, replicationController, service) for use by the operation. It would be nice if I could do the following: Where kubecfg sees the http:// and does a network operation to fetch resource for me. This would let users who want to build tutorials on how to use kubernetes to avoid steps to manually download the files locally via curl and unzip, etc. and would also let scripters that use the kubecfg client to avoid needing write access on the terminal where they run kubecfg to perform basic actions.
Change:
} } } <ins> if isDeletion { // cachedService is not reliable here as // deleting cache is the last step of federation service deletion _, err := fedClient.Core().Services(cachedService.lastState.Namespace).Get(cachedService.lastState.Name) // rebuild service if federation service still exists if err == nil || !errors.IsNotFound(err) { return sc.ensureClusterService(cachedService, clusterName, cachedService.appliedState, clusterCache.clientset) } } </ins> return nil }

Discussion:
As mentioned in when the service is deleted from the underlying cluster, the controller should recreate it, but it does not. Below's a transcript. is talking to the federation-apiserver, and is talking to the normal cluster it's pointed at.
Thanks for catching this cc
cc
This is definitely a bug, but I think that we can kick it out into v1.4. Until fixed (i.e. while in beta), we can tell customers not to delete the underlying services in their clusters.
it should not be, I have tested this before. How long did you wait when you check the service existence in last step? Can you send me the logs? The service deletion will cause federation service update, and then the federation service watcher will catch the update even and call another round of service updates to all clusters. When you delete the service, if the service got ingress ip already? I am thinking if the deletion did not trigger federation service update? So so no update event generated..
I think that the best way forward will be to encode this in a reproducible e2e test, otherwise there are too many variables to debug effectively. It's great to know that you've tested this case, and it works in at least some scenarios.
one possible solution come into my mind, currently we set the service full sync time to 10 minutes , if we change it back to 30s, then at least during the full sync, the deleted service will be re-created. I will send a PR anyway, you can judge if it should be put to v1.3
I think we need to find and fix the underlying problem, not cover it up with a shorter sync period. If we have the correct watch on each service, we will be notified as soon as they are deleted. Why is the watch notification not firing correctly?
Keeping this open until we've verified this fix in e2e tests.
I believe this to be fixed, but we still lack an e2e test to verify conclusively. would you like to take this on along with the other e2e tests that you are busy adding?
ping
plan on doing this for 1.4? or bump to 1.5?
Yes, 1.5 is fine.
switching this to 1.6 as it's too late for 1.5. ok?

Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.