jiebi/CodeConvo huggingface dataset:
Change:
newCfg := make(map[string]string) newCfg[cfgAccessToken] = token.token.AccessToken newCfg[cfgRefreshToken] = token.token.RefreshToken <ins> newCfg[cfgEnvironment] = token.environment </ins> newCfg[cfgClientID] = token.clientID newCfg[cfgTenantID] = token.tenantID newCfg[cfgApiserverID] = token.apiserverID

Discussion:
What happened: AAD support in kubectl does not work for sovereign cloud The 'environment' parameter was introduced to support sovereign cloud, but it works in first round. The 'environment' value is not persisted, so follow-up requests will fail. What you expected to happen: 'environment' parameter persisted in kubectl config file. How to reproduce it (as minimally and precisely as possible): Use kubectl to connect to Azure sovereign cloud, make the token expire, and do auth. Anything else we need to know?: Environment: Kubernetes version (use ): 1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Change:
} func tryDecodePodList(data []byte, defaultFn defaultFunc) (parsed bool, pods api.PodList, err error) { <del> obj, err := api.Scheme.Decode(data) </del> <ins> json, err := utilyaml.ToJSON(data) if err != nil { return false, api.PodList{}, err } obj, err := api.Scheme.Decode(json) </ins> if err != nil { return false, pods, err }

Discussion:
Following on from the Kubelet should accept YAML pod specifications. Currnelty it supports only JSON pod specifications.
Change:
} dryRun := cmdutil.GetFlagBool(cmd, "dry-run") <ins> output := cmdutil.GetFlagString(cmd, "output") shortOutput := output == "name" </ins> encoder := f.JSONEncoder() decoder := f.Decoder(false)

Discussion:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR
Change:
"${e2e}" "${auth_config[@]:+${auth_config[@]}}"  --host="https://${KUBE_MASTER_IP-}"  --provider="${KUBERNETES_PROVIDER}"  <del> ${E2E_REPORT_DIR+"--report_dir=${E2E_REPORT_DIR}"} </del> <ins> ${E2E_REPORT_DIR+"--report_dir=${E2E_REPORT_DIR}"}  "${@}" </ins>

Discussion:
Twice in the last two weeks I have dealt with "bugs" which turned out to be due to the fact that the fundamental requirements of pod networking were not being met. We need a way for a user to very quickly verify that the basic assumptions are met: pods can talk to pods, master can talk to pods, pods can talk to master, services work, etc.
Sounds like something that should have a dual life as an e2e test.
Yes, I ran into the similar issues when I tried to have containervm image as the default one. It turns out just some simple network configuration issues.
Service and replication controller that creates two pods, where the pod takes the kube service as an argument and tries to connect to the other pods described by endpoints?
Yeah that's sorta what I was thinking, too.
After gets merged, I think the easiest path to finishing this off is to just parameterize so that it's easy to point it at an existing cluster and run only the network test.
This is fixed by
Not completely fixed yet; need simple way to run it on existing cluster.
Remaining action item: Write a go script (bash if you must) that runs the networking test from against an existing cluster. Something that you can run via "go run" would be great, or adding flags to such that you can run it with something like "_output/go/bin/e2e -test=network" would be great too.
Reopening. Along the way in , we're moving the e2e script. But I also noticed this is relying on test assets. If you're trying to ship something to users, isn't something we ship to users.
Running will work after . We might end up renaming the test as part of the Ginkgo migration, in which case we can update this issue to indicate the correct invocation.
Closing this as is merged.
Change:
if err := Convert_v1_Context_To_api_Context(&curr.Context, newContext, s); err != nil { return err } <ins> if *out == nil { *out = make(map[string]*api.Context) } </ins> if (*out)[curr.Name] == nil { (*out)[curr.Name] = newContext } else {

Discussion:
What happened: I have a test case: This behaves different with different client-go versions. With , the test passes. This is using in with in With , this test panics. This is using in with in Panic logs: Basically it its creating an object to decode into, and this object has some maps. These are set to nil, so when we try to populate them we get a panic. What you expected to happen: Behavior remains the same as previous release, or at least have some alternative that works here? How to reproduce it (as minimally and precisely as possible): I pasted the test above that reproduces this. This can be reproduced with a project with just that file, and a file with only client-go. Using go 1.13
/sig api-machinery
/assign
Change:
fi replace_prefixed_line "${basic_auth_csv}" "${KUBE_PASSWORD},${KUBE_USER}," "admin,system:masters" fi local -r known_tokens_csv="${auth_dir}/known_tokens.csv" <ins> if [[ -e "${known_tokens_csv}" && "${METADATA_CLOBBERS_CONFIG:-false}" == "true" ]]; then rm "${known_tokens_csv}" fi </ins> if [[ -n "${KUBE_BEARER_TOKEN:-}" ]]; then replace_prefixed_line "${known_tokens_csv}" "${KUBE_BEARER_TOKEN},"             "admin,admin,system:masters" fi

Discussion:
/sig cluster-lifecycle
Very rarely we are seeing known tokens files filled with the NULL character, with ASCII value 000. Restarting the master doesn't fix the issue because the is saved between restarts.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
network_mode="custom" fi echo "Creating new ${network_mode} network: ${NETWORK}" <del> gcloud compute networks create --project "${NETWORK_PROJECT}" "${NETWORK}" --mode="${network_mode}" </del> <ins> gcloud compute networks create --project "${NETWORK_PROJECT}" "${NETWORK}" --subnet-mode="${network_mode}" </ins> else PREEXISTING_NETWORK=true PREEXISTING_NETWORK_MODE="$(check-network-mode)"

Discussion:
/kind bug What happened: Warning printed by : What you expected to happen: No warning. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This is my first e2e cluster. Logs with more context below. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): Description: Ubuntu 14.04 LTS
This is probably an issue in the scripts.
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. Prevent issues from auto-closing with an comment. 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
This has started failing in tests: https://k8s-
/shrug /milestone v1.10 /assign /assign /priority failing-test /priority critical-urgent /sig network /sig testing
I think this might be only in the staging gcloud release; at least doesn't mention this being removed.
and yeah, gce-canary is also using staging gcloud /shrug
/assign I'll fix kubetest, is patching k8s
/approved-for-milestone
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/status in-review
should we close this issue since the PR merged?
waiting for , and that need to be cherrypicked into older releases
still need to cherrypick into previous releases
agreed, but isn't blocking 1.10 any more /milestone clear
cherrypick is done, closing /close
Change:
if err != nil { return err } <del> if !labels.AreLabelsInWhiteList(pod.Spec.NodeSelector, whitelist) { </del> <ins> if !isSubset(pod.Spec.NodeSelector, whitelist) { </ins> return errors.NewForbidden(resource, pod.Name, fmt.Errorf("pod node label selector labels conflict with its namespace whitelist")) }

Discussion:
What happened: The function return when whitelist is empty. The function is implemented as follows: What you expected to happen: When the whitelist is empty, any key of labels can not in it. Should the function return when whitelist is empty?
/sig api-machinery
/assign /cc (we think you might have opinions on fixing this)
I only see one consumer. Rather than change the semantic, I would suggest moving it to the point of use and renaming it.
Yes, this function is wrong, I agree with David. P.S. we don't advertise interface stability for this library so this is OK. But even if we did, I think callers of this function are probably not expecting this behavior and should be examined.) P.P.S. The way it should work is via set difference, the labels should be a subset of the list. P.P.P.S. These are sets and not lists, and the names should be changed to reflect that. P.P.P.P.S. If you're making a change here anyway, please lose the word "whitelist".
Okay, I will submit a pr.
Change:
return ss.(*scaleSet), nil } <del> func buildTestVMSS(lbBackendpoolIDs []string) compute.VirtualMachineScaleSet { </del> <ins> func buildTestVMSS(name string, lbBackendpoolIDs []string) compute.VirtualMachineScaleSet { </ins> lbBackendpools := make([]compute.SubResource, 0) for _, id := range lbBackendpoolIDs { lbBackendpools = append(lbBackendpools, compute.SubResource{ID: to.StringPtr(id)}) } expectedVMSS := compute.VirtualMachineScaleSet{ <del> Name: to.StringPtr(testVMSSName), </del> <ins> Name: &name, </ins> VirtualMachineScaleSetProperties: &compute.VirtualMachineScaleSetProperties{ ProvisioningState: to.StringPtr("Running"), VirtualMachineProfile: &compute.VirtualMachineScaleSetVMProfile{

Discussion:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestEnsureBackendPoolDeletedConcurrently Testgrid link: Reason for failure: /sig cloud-provider
cc
/assign /area provider/azure
Change:
"Metric":    gstruct.Ignore(), "Value":     gomega.BeNumerically(">=", lower), "Timestamp": gstruct.Ignore(), <ins> "Histogram": gstruct.Ignore(), </ins> })) }

Discussion:
There's been a quite a few failures across jobs that query node metrics. The test is Last passing - First failing - appears to point to which is bump in prometheus client library. Possibly related? /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
Verified with presubmit that reverting the prometheus client library results in the test passing. Opened PR for revert in
/cc
/assign
thanks for filing this issue! I think seems like a promising fix (thanks ) and there's a fair chance we won't need the revert
ack, thanks for the fix, it seems we can go with that then and hold the revert.
Change:
// SelectorFromValidatedSet returns a Selector which will match exactly the given Set. // A nil and empty Sets are considered equivalent to Everything(). // It assumes that Set is already validated and doesn't do any validation. <ins> // Note: this method copies the Set; if the Set is immutable, consider wrapping it with ValidatedSetSelector // instead, which does not copy. </ins> func SelectorFromValidatedSet(ls Set) Selector { if ls == nil || len(ls) == 0 { return internalSelector{}

Discussion:
A common pattern in Kubernetes (both internally and in third party usage) is something like: (this is from the ). This is commonly called at a fairly high rate; in our case we would actually end up seeing this account for significant portions of CPU/memory to compute the and run on it. In our controller, as an optimization, we replaced usage of and just used our own simpler label matching code, leading to a 70% speed up in our function (which does more than just match) and 96% allocation size improvement; see I believe similar could be done in Kubernetes directly by having a specialized Selector implementation for simple labels. This would transparently given substantial performance benefits to anyone using the library
/sig api-machinery
is the change here a new kind of selector matching or a tweak to something existing? It's hard to tell if this is proposing a new design to partition types of selectors that needs a kep versus a perf tweak to existing code that is straight-forward.
The proposal is an internal performance improvement to make a specialized implementation of the selector matching internally. So two concrete implementations for 1 shared interface. is a PoC of this. I think it can be extended (by me, or others if someone wants to) to complete it
We discussed this one during our bug triage. There seemed to be the feeling that this is large enough to need a KEP? Would you be up for that? Additionally you could bring it up in our SIG meeting to socialize / discuss it more if you wanted.
The patch shared in helps to explain, it's a lot smaller than the description made it sound. This is a special case for equality-only selectors. Probably still worth bringing up at a sig-meeting, but if if the patch is a good representation, it is more bounded than expected from the issue description.
/triage accepted
Change:
return keyring.Lookup(image) } <ins> type FakeKeyring struct { auth docker.AuthConfiguration ok   bool } func (f *FakeKeyring) Lookup(image string) (docker.AuthConfiguration, bool) { return f.auth, f.ok } </ins>

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:
// and may be the result of another HTTP actor. // It supports wrapped errors and returns false when the error is nil. func IsUnexpectedServerError(err error) bool { <del> if status := APIStatus(nil); errors.As(err, &status) && status.Status().Details != nil { </del> <ins> status, ok := err.(APIStatus) if (ok || errors.As(err, &status)) && status.Status().Details != nil { </ins> for _, cause := range status.Status().Details.Causes { if cause.Type == metav1.CauseTypeUnexpectedServerResponse { return true

Discussion:
I have a controller that creates objects. It uses to notice when create fails due to a deleting namespace. This check was working well until I moved it away from each call. In some cases, the error is wrapped using causing the function to always return false. I expected to work on both wrapped and unwrapped errors, like the functions do. This short program shows the issue: I am able to work around it by first calling . This type assertion should be replaced with a call to : /sig api-machinery v1.22.5, but I also see the affected code in master. <details</detailsn/a n/a k3s n/a n/a
/cc /triage accepted
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Change:
return filepath.Join(fstore.path, key) } <ins> // ensurePath creates input directory if it does not exist func ensurePath(path string) error { if _, err := os.Stat(path); err != nil { // MkdirAll returns nil if directory already exists return os.MkdirAll(path, 0755) } return nil } </ins> func validateKey(key string) error { if len(key) <= keyMaxLength && keyRegex.MatchString(key) { return nil

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Using to start a cluster with only one node and found that there are some error logs in kubelet as following: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
cc
/cc
Seems caused by my env due to I cannot access gcr due to the proxy failed, will continue to check...
We should create the checkpoint directory when creating the checkpoint store, or else the list failed error will be quite spammy before a container is created.
Will push a fix soon.
Change:
spec: containers: - name: kubedns <del> image: gcr.io/google_containers/kubedns-amd64:1.6 </del> <ins> image: gcr.io/google_containers/kubedns-amd64:1.7 </ins> resources: # TODO: Set memory limits when we've profiled the container for large # clusters, then set request = limit to keep this container in

Discussion:
Now that merged, we need to build a new kube-dns release.
I just put in a PR yesterday to fix the missing changelog entry for kube-dns:1.6
Change:
glog.V(2).Infof("couldn't find properties for %s, skipping", key) continue } <ins> if details.Type == nil { glog.V(2).Infof("nil details for %s, skipping", key) continue } </ins> fieldType := *details.Type if value == nil { glog.V(2).Infof("Skipping nil field: %s", key)

Discussion:
This happens with several different objects that I tried creating.
happens with simplest pod I can find:
have fix, but working on test.
Change:
return "<none>" } <ins> // findNodeRole returns the role of a given node, or "" if none found. // The role is determined by looking in order for: // * a kubernetes.io/role label // * a kubeadm.alpha.kubernetes.io/role label // If no role is found, ("", nil) is returned func findNodeRole(node *api.Node) string { if role := node.Labels[kubeadm.NodeLabelKubeadmAlphaRole]; role != "" { return role } // No role found return "" } </ins> func printNodeList(list *api.NodeList, options printers.PrintOptions) ([]metav1alpha1.TableRow, error) { rows := make([]metav1alpha1.TableRow, 0, len(list.Items)) for i := range list.Items {

Discussion:
used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This has been fixed in recent versions
Change:
indexer.Add(resourceQuota) // old service was a load balancer, but updated version is a node port. <del> oldService := &api.Service{ ObjectMeta: api.ObjectMeta{Name: "service", Namespace: "test"}, </del> <ins> existingService := &api.Service{ ObjectMeta: api.ObjectMeta{Name: "service", Namespace: "test", ResourceVersion: "1"}, </ins> Spec:       api.ServiceSpec{Type: api.ServiceTypeLoadBalancer}, } newService := &api.Service{

Discussion:
With the migration to podutils and adding some presubmits (from periodic jobs) we are seeing some failures in presubmits. The error seems to have issues finding the right node to create.
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
/sig node /sig testing
any leads on solving this one?
see notes on slack -
/assign
this looks good now!