jiebi/CodeConvo huggingface dataset:
Change:
var wg sync.WaitGroup var failMu sync.Mutex failed := false <ins> if *serial { *parallel = 1 } else if *parallel == 0 { *parallel = len(plats) } throttle := make(chan int, *parallel) </ins> for _, plat := range plats { wg.Add(1) <del> fn := func(plat string) { </del> <ins> go func(plat string) { // block until there's room for this task throttle <- 1 defer func() { // indicate this task is done <-throttle }() </ins> f := false serialFprintf(os.Stdout, "type-checking %sn", plat) errors, err := c.verify(plat)

Discussion:
Background: We recently introduced Guaranteed Pod QOS on jobs running in GCP project (). Introducing limits on jobs naturally started causing some failures, one of which was (). The original memory limit of caused the pod to be unscheduleable, so it was bumped down to () at which point the pod became scheduleable and the job ran successfully (). At that point, after observing metrics, I mistakenly concluded that this was much higher than needed and suggested bumping down again (). This caused the job to continue to run, but to fail on and sometimes . was recently refactored to not depend on GOPATH (). This was a fairly significant change so I looked at the metrics before and after the rewrite was merged. (June 25th) ! (June 27th) ! Memory usage nearly double for post-merge, which appears to be directly related to the rewrite given that on other branches remained relatively constant. This can be affirmed further by the fact that and are failing with the new resource limits, while older release branches are not. I can see a few options for how we may be able to remedy this issue in the short term: Revert the rewrite to get back to lower (yet still very high) memory usage Separate into a separate job to not reduce signal on the rest of Bump memory limits back up to to get this running successfully again for now I plan to look into fixing up but think it would be a good idea to take one of the directions mentioned above if this cannot be remedied quickly. /priority critical-urgent /sig testing /cc
latest run is green
hmm
Change:
return nodeIP, nodeIPExists } <del> func getInstanceTypeByProviderIDOrName(ctx context.Context, instances cloudprovider.Instances, node *v1.Node) (string, error) { instanceType, err := instances.InstanceTypeByProviderID(ctx, node.Spec.ProviderID) </del> <ins> // getInstanceTypeByProviderIDOrName will attempt to get the instance type of node using its providerID // then it's name. If both attempts fail, an error is returned. func getInstanceTypeByProviderIDOrName(ctx context.Context, instances cloudprovider.Instances, providerID, nodeName string) (string, error) { instanceType, err := instances.InstanceTypeByProviderID(ctx, providerID) </ins> if err != nil { providerIDErr := err <del> instanceType, err = instances.InstanceType(ctx, types.NodeName(node.Name)) </del> <ins> instanceType, err = instances.InstanceType(ctx, types.NodeName(nodeName)) </ins> if err != nil { return "", fmt.Errorf("InstanceType: Error fetching by providerID: %v Error fetching by NodeName: %v", providerIDErr, err) }

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: introduces a regression that func is invoked on a Node obj without , hence it can fail fetching the node addresses when the is not set. What you expected to happen: I would expect cloud-controller-manager to be able to initialize new Node. How to reproduce it (as minimally and precisely as possible): the gcp legacy-cloud-controller v1.18.1 () that the node-controller cannot initialize a new Node. Logs of the cloud-controller-manager repeated multiple times: Ensure that the Node is with the taint. Ensure that the of the Node is not set. The cloud-controller-manager is not running on the host machine and that's why it cannot call the gce matadata. But it was never a hard requirement for cloud-controller-manager to run on the host machine. Anything else we need to know?: The legacy cloud-controller-manager v1.17.x is working perfectly fine. Environment: Kubernetes version (use ):v1.18.1 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /kind regression
/cc
can we open a new issue re:
Change:
expect := api.PodList{ ListMeta: api.ListMeta{ResourceVersion: "10"}, Items: []api.Pod{ <del> {ObjectMeta: api.ObjectMeta{Name: "foo", ResourceVersion: "1"}}, </del> <ins> // We expect items to be sorted by its name. </ins> {ObjectMeta: api.ObjectMeta{Name: "bar", ResourceVersion: "2"}}, {ObjectMeta: api.ObjectMeta{Name: "baz", ResourceVersion: "3"}}, <ins> {ObjectMeta: api.ObjectMeta{Name: "foo", ResourceVersion: "1"}}, </ins> }, }

Discussion:
kubectl returns resources in a random order, which makes it hard to look for things when users have a lot resources. Returning resources in deterministic order should be a helpful and trivial change (hopefully). We have an issue about pagination , but that's a larger and separate issue.
We should be cause to not do this on the * namespace - I think thats a special case. No disagreement for other list calls
What is the default etcd response order? Last created or last modified? Sent from my iPhone
I think the order is by key if sort param is given. If not given, the order is by last created (maybe, but we shouldn't trust it). It seems we are not trying to get sorted result from etcd.
Today, I think it's random order in the child key space in etcd (because the node structure uses a map), so you get golang map iteration order without sort. I don't know if sort on server is any cheaper than sort on client today, so we may want to do this in rest / registry rather than by passing etcd.
Apart from performance, sorting in clients means we can also take control of how responses are sorted, so for * namespace, we can sort by namespace, then by resource ID. , Clayton Coleman wrote: Master of Electrical and Computer Engineering Carnegie Mellon University
We can always hint sort to the registry storage layer in the future, so sorting on the client now won't kill us.
Just took a closer look at our rest/registry code to implement the sort (in client), but implementation-wise, it seems much easier to pass sort to etcd (one line change). Also, namespace is a prefix on resource, so sort across all namespace with etcd key will essentially sort resources by namespace then by Name. If we are to implement sort on client side, we can either: sort package: have each list object, ie.e PodList, ControllerList, implement sort interface. (We won't do this). have ListMeta implement sort interface, if there is a way to find enclosing structs (so we can use items field) have api.Object implement sort interface, verify object is list before sorting. sort algorithm ourself, and do it in rest. Is there other golang or kubernetes idom that I haven't been aware of that can be applied to this use case?

----- Original Message ----- I think sorting it on etcd is fine for now - that's the simplest possible thing that works.
Is there any material perf impact in etcd to enable it? Sent from my iPhone
Probably not material. Can always switch away if necessary
Famous last words :-) Sent from my iPhone
Got my hat ready
Change:
embed = [":go_default_library"], deps = [ "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/api/meta:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library",

Discussion:
What happened: When sending a request to the server side apply endpoint (), if the apiVersion provided in the object is different from the apiVersion in the url, it returns a 500 error, like: What you expected to happen: The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error. Anything else we need to know?: The check should probably be done somewhere near this . The issue, though, is that the patch is given as a byte array, and needs to be deserialized into an object to access the apiVersion field. How to reproduce it (as minimally and precisely as possible): With a kube-apiserver built from head, running with :
/kind bug /sig api-machinery /wg apply /priority important-longterm /assign
Change:
sleep 5 <del> POD_LIST_1=$($CLOUDCFG -json list pods | jq ".items[].id") </del> <ins> POD_LIST_1=$($CLOUDCFG '-template={{range.Items}}{{.ID}} {{end}}' list pods) </ins> echo "Pods running: ${POD_LIST_1}" $CLOUDCFG stop redisSlaveController

Discussion:
We have an e2e test that runs the guestbook example. We should also have one that runs through the other example.
Change:
return options, fmt.Errorf("service-cluster-ip-range[0] is not a valid cidr") } <del> serviceIPRange, apiServerServiceIP, err = master.DefaultServiceIPRange(*(primaryServiceClusterCIDR)) </del> <ins> serviceIPRange, apiServerServiceIP, err = master.ServiceIPRange(*(primaryServiceClusterCIDR)) </ins> if err != nil { return options, fmt.Errorf("error determining service IP ranges for primary service cidr: %v", err) }

Discussion:
API server defaults the service CIDR. We should instead just fail if it is not specified. Defaulting is a wild guess and very likely to be wrong. /sig network /kind bug
For existing clusters that don't currently set it, is setting it to anything other than the current default a breaking change?
Yes. You can not really change it (well, you can expand it, but not totally move it), unless you delete ALL services, including kubernetes.default. I filed this aspirationally. It's not on fire, it's just a dumb thing to have provided a default for.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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:
<del> DOCKER_OPTS="--bridge cbr0 --iptables=false -r=false" </del> <ins> DOCKER_OPTS="--bridge cbr0 --iptables=false --ip-masq=false -r=false" </ins>

Discussion:
We need to version-lock to docker 1.2 until they fix this flag, or else we need to drop 1.2 support, or else we need to detect the docker version before writing the flags file. - we need something here ASAP.
After a little bit thinking, I think we shouldn't have the problem. kube-push only updates our own binaries, not docker's. kube-up builds a new cluster which will pull the latest docker, but we can change docker's defaults, so that at the minion's provision stage, we disable both --iptables and --ip-masq.
Something like for gce.
Change:
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ <del> liggitt </del> pwittrock seans3 soltysh

Discussion:
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-cli-plugin repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig cli

The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the cli-runtime repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig cli
Change:
// or can be started, and updates the cached pod state so that downstream components can observe what the // pod worker goroutine is currently attempting to do. If ok is false, there is no available event. If any // of the boolean values is false, ensure the appropriate cleanup happens before returning. <ins> // // This method should ensure that either status.pendingUpdate is cleared and merged into status.activeUpdate, // or when a pod cannot be started status.pendingUpdate remains the same. Pods that have not been started // should never have an activeUpdate because that is exposed to downstream components on started pods. </ins> func (p *podWorkers) startPodSync(podUID types.UID) (ctx context.Context, update podWork, canStart, canEverStart, ok bool) { p.podLock.Lock() defer p.podLock.Unlock()

Discussion:
The following log line is often (~30times) logged during our tests in : . This suggests a possible bug as it was assumed to do not happen. No log line saying . Look at artifacts of all (or almost all) builds of: No response <details</details<detailsReproducible in tests </details<details</details<details</details<details</details<details</details
/sig node FYI
/triage accepted since it's a new error, it is a regression. So adding a corresponding priority /priority important-soon
are you working on this? Should I assign bug to you?
Yes, I'm taking a look at this. /assign
/cc
This is a metrics only error (we don’t report a fraction of metrics) and has no functional impact.
That makes sense, but is it expected that this is a valid state in first place? . My assumption was that if static is false, (i.e. API pod) then we should have a config?
I took a closer look at the logs, it seems that this is happening when we enter while a static pod is being synced which has UID reuse and another pod which has the same full name did not terminate yet. In this case, we block the static pod from starting i.e. () returns false: Because the pod can't start, we don't set : which means that when we log metrics there is no set and thus or are both defaulted to false:
Based on the above, it looks like this case is expected. As a result, maybe the simplest option is to simply drop the log statement since by design we only want to into account a subset of the states for the metrics?
Change:
rc=0 # List of dependencies we need to avoid dragging back into kubernetes/kubernetes <del> forbidden_repos=( "k8s.io/klog"  # we have switched to klog v2, so avoid klog v1 ) for forbidden_repo in "${forbidden_repos[@]}"; do deps_on_forbidden=$(go mod graph | grep " ${forbidden_repo}@" || echo "") if [ -n "${deps_on_forbidden}" ]; then kube::log::error "The following have transitive dependencies on ${forbidden_repo}, which is not allowed:" echo "${deps_on_forbidden}" echo "" rc=1 fi done </del> <ins> # Check if unwanted dependencies are removed go run k8s.io/kubernetes/cmd/dependencyverifier "${KUBE_ROOT}/hack/unwanted-dependencies.json" </ins> outdated=$(go list -m -json all | jq -r " select(.Replace.Version != null) |

Discussion:
Add a file to track dependencies we want to remove or avoid picking back up. Examples: (as opposed to ) {analysis,spec,strfmt,validate} () and () () Add a presubmit that uses to do the following: if any items in the "unwanted but still present" list are no longer present and prompts to move them to the "absent and not allowed" list if any items in the "absent and not allowed" list are present and fails. Dependency updates often reintroduce problematic dependencies that were previously dropped. /area code-organization /cc
/sig architecture /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig architecture /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I may help with it. /assign I checked the code, there is already a logic to check forbidden dependencies. can draw a go mod graph
yeah, that was sort of ad-hoc, and doesn't do the ratcheting bit we want (record a dependency we have but don't want, once we no longer use it, require moving it to the forbidden list)
Change:
<ins> apiVersion: test.com/v1 kind: Example metadata: name: test spec: test: test </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! If the matter is security related, please disclose it privately via --Changing the scope field of a CRD ist not possible since it's immutable. But even after deleting and re-creating the CRD with changed scope it doesn't let me create resources of the CRD's kind. Re-creating CRD with changed scope should just work. Here is a full example that in the end leads to the error when trying to create a resource after re-creating the CRD. Kubernetes version (use ): v1.21.4 Cloud provider or hardware configuration: vSphere 7.0 OS (e.g: ): Centos 7 Kernel (e.g. ): 3.10.0-1160.42.2.el7.x86_64
/sig api-machinery
/assign /triage accepted
This appears to be working as intended. The example custom resource you use: It Cluster scoped because it has no namespace. But once the CRD is namespace scoped, you should not be able to create cluster scoped custom resources of that type. If instead you add a namespace to Example, it should be created, e.g.:
if the above seems to have answered your question - please feel free to close the issue :) Thank you!
kubectl will automatically use the namespace so this is definitely not the issue here. I can reproduce this issue with my above script in a fresh (v1.22.2) cluster. You can add the namespace in the last manifest, it makes no difference. From my understanding this really seems to be a bug.
Yes, that's true. Good catch. Okay, we need to root cause this.
I tried using curl to create the custom resource directly against the API and got the same result: So the problem seems to be in the API server (not in kubectl).
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
Change:
err := ds.checkpointManager.GetCheckpoint(id, checkpoint) if err != nil { glog.Errorf("Failed to retrieve checkpoint for sandbox %q: %v", id, err) <ins> if err == errors.ErrCorruptCheckpoint { err = ds.checkpointManager.RemoveCheckpoint(id) if err != nil { glog.Errorf("Failed to delete corrupt checkpoint for sandbox %q: %v", id, err) } } </ins> continue } result = append(result, checkpointToRuntimeAPISandbox(id, checkpoint))

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
FilenameParam(flags.Filenames...). Flatten(). Do() <ins> checkErr(r.Err()) </ins> count := 0 err = r.Visit(func(info *resource.Info) error {

Discussion:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.
Change:
return statefulSet, pollErr } <ins> type updateJobFunc func(*batch.Job) func UpdateJobWithRetries(c clientset.Interface, namespace, name string, applyUpdate updateJobFunc) (job *batch.Job, err error) { jobs := c.Batch().Jobs(namespace) var updateErr error pollErr := wait.PollImmediate(10*time.Millisecond, 1*time.Minute, func() (bool, error) { if job, err = jobs.Get(name); err != nil { return false, err } // Apply the update, then attempt to push it to the apiserver. applyUpdate(job) if job, err = jobs.Update(job); err == nil { Logf("Updating job %s", name) return true, nil } updateErr = err return false, nil }) if pollErr == wait.ErrWaitTimeout { pollErr = fmt.Errorf("couldn't apply the provided updated to job %q: %v", name, updateErr) } return job, pollErr } </ins> // NodeAddresses returns the first address of the given type of each node. func NodeAddresses(nodelist *api.NodeList, addrType api.NodeAddressType) []string { hosts := []string{}

Discussion:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in . Previous issues for this test:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}