jiebi/CodeConvo huggingface dataset:
Change:
return &apiregistration.APIService{ ObjectMeta: metav1.ObjectMeta{Name: name}, Spec: apiregistration.APIServiceSpec{ <ins> Group:   strings.SplitN(name, ".", 2)[0], Version: strings.SplitN(name, ".", 2)[1], </ins> Service: &apiregistration.ServiceReference{ Namespace: "foo", Name:      "bar",

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: runs as a APIService but it fails with and the endpoint returns on kubernetes clusters with v1.15. It works with all previous cluster versions perfectly but gives the following status on v1.15 but I also don't see any changes in Releasing notes that effects APIService What you expected to happen: APISerice should run correctly and the endpoint should be responding. How to reproduce it (as minimally and precisely as possible): Linkerd dosent have to be installed to check this, and discovery happens directly at the url without any communication with the underlying mesh. In the repo, running this generates the required certs and applies the config to the cluster To check the status of the APIService, can be used Anything else we need to know?: I did check with clean 1.15 clusters and its the same. I also don't see any changes in 1.15 release notes that effects APIServices. Environment: Kubernetes version (use ):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: Testing is done on kind but its the same with minikube
/sig api-machinery
that sounds bad.. i didnt remember any breaking change except for making the port confiugrable.. /cc
what does interrogating the service directly return?
On Clusters 1.15, where the status of APIService is it gives On Clusters 1.14.3, where the status of APIService is it gives
looks related If the aggregated server returns non-200 status code, it is treated as unavailable. what endpoint is checked by the available controller?
i skimmed implementation from smi-metrics.. it only serves on prefixes so when the available controller checks the root endpoint it returns a 404.
but then it dosent fail on clusters running v1.14, In that version the apiService is marked as
fixed by , picked to 1.15.x in , will be in v1.15.1
Awesome Thanks for the quick fix :)
Change:
d.To.Dir.Delete()   // Ignore error } <ins> type Downloader struct { mapper  meta.RESTMapper dclient dynamic.Interface ns      string } func NewDownloader(f cmdutil.Factory) (*Downloader, error) { var err error var d Downloader d.mapper, err = f.RESTMapper() if err != nil { return nil, err } d.dclient, err = f.DynamicClient() if err != nil { return nil, err } d.ns, _, _ = f.DefaultNamespace() return &d, nil } func (d *Downloader) Download(info *resource.Info) (*unstructured.Unstructured, error) { gvk := info.Object.GetObjectKind().GroupVersionKind() mapping, err := d.mapper.RESTMapping(gvk.GroupKind(), gvk.Version) if err != nil { return nil, err } var resource dynamic.ResourceInterface switch mapping.Scope.Name() { case meta.RESTScopeNameNamespace: if info.Namespace == "" { info.Namespace = d.ns } resource = d.dclient.Resource(mapping.Resource).Namespace(info.Namespace) case meta.RESTScopeNameRoot: resource = d.dclient.Resource(mapping.Resource) } return resource.Get(info.Name, metav1.GetOptions{}) } </ins> // RunDiff uses the factory to parse file arguments, find the version to // diff, and find each Info object for each files, and runs against the // differ.

Discussion:
/kind bug /sig cli /area kubectl Hello. This is my first interaction with the Kubernetes community, so please forgive me if i have left out any crucial details, or if, perhaps, this is PEBKAC after all! I am keen to have a working feature, as described in and I am running K8s v1.9.3 and realise that this feature is in alpha, but i thought i would ask anyway. We're not on v1.9.4 yet, but the changelog doesn't mention the feature. What you expected to happen: I have some services deployed to Kubernetes with YAML files, that has been working reliably. We always use to deploy things. When a service is already deployed, and i make a minor change in the config file, for example the service port, i expect to see that in the diff. Instead, gives no output and exits with a . How to reproduce it (as minimally and precisely as possible): Consider the file : I make sure that it is correctly running on the cluster: Great, looking good. Now, i change the value to use Docker image tag and save. Now, i run: The stderr/stdout output is empty, and the exit code is . Anything else we need to know?: Environment: Kubernetes version: Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-09T21:50:44Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I have this same issue - if I change, say, to in my , running returns empty. If I try tweaking the version I'm diffing (which I don't understand) - e.g. - then I see a bunch of differences, but not actually the change I was expecting in the number of replicas.
I'll take this. Sorry for the inconvenience.
Change:
} func printGlusterfsPersistentVolumeSource(glusterfs *corev1.GlusterfsPersistentVolumeSource, w PrefixWriter) { <ins> endpointsNamespace := "<unset>" if glusterfs.EndpointsNamespace != nil { endpointsNamespace = *glusterfs.EndpointsNamespace } </ins> w.Write(LEVEL_2, "Type:tGlusterfs (a Glusterfs mount on the host that shares a pod's lifetime)n"+ "    EndpointsName:t%vn"+ "    EndpointsNamespace:t%vn"+ "    Path:t%vn"+ "    ReadOnly:t%vn", <del> glusterfs.EndpointsName, glusterfs.EndpointsNamespace, glusterfs.Path, glusterfs.ReadOnly) </del> <ins> glusterfs.EndpointsName, endpointsNamespace, glusterfs.Path, glusterfs.ReadOnly) </ins> } func printPersistentVolumeClaimVolumeSource(claim *corev1.PersistentVolumeClaimVolumeSource, w PrefixWriter) {

Discussion:
What happened: What you expected to happen: EndpointNamespace should be the string name of the namespace used. How to reproduce it (as minimally and precisely as possible): Create a glusterfs PV using an EndpointNamespace entry and run 'kubectl describe pv' on the resulting PV. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T17:09:13Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Brightbox OS (e.g: ): Ubuntu 18.04.3 LTS Kernel (e.g. ): Linux bionic-vm 4.15.0-58-generic -Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm 1.15
/sig cli
/assign
Change:
return &FileStore{path: path}, nil } <ins> // writeFileAndSync is copied from ioutil.WriteFile, with the extra File.Sync // at the end to ensure file is written on the disk. func writeFileAndSync(filename string, data []byte, perm os.FileMode) error { f, err := os.OpenFile(filename, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, perm) if err != nil { return err } n, err := f.Write(data) if err == nil && n < len(data) { err = io.ErrShortWrite } f.Sync() if err1 := f.Close(); err == nil { err = err1 } return err } </ins> func (fstore *FileStore) Write(key string, data []byte) error { if err := validateKey(key); err != nil { return err

Discussion:
The reboot test may cause corrupted checkpoint left on the node. https://k8s- This prevents the sandbox from being stopped properly, so kubelet cannot create a new one. One option is to log and remove the corrupted checkpoint, while cleaning up the pod sandbox resources with best effort (i.e., may leak resources). Another option is to not clean up, and force a human being to intervene and remove the corrupt checkpoint manually. The proper solution perhaps is to scan the checkpoints at startup (or periodically) and repair/remove corrupt checkpoints. /cc related:
/cc
should this block ?
If we can scan the checkpoints at startup time, then repair the corrupted checkpoint, which means, we can recover the state from the runtime, why we introduce the checkpoint at the first place? :-) I am ok with your idea upon the corrupted checkpoints, removing the bad ones as the workaround. Anyway, Kubelet will fire an event of failedSync with the proper message, some manual intervene (the remedy system) can be fired based on the event to resolve the leak resource issue.
I think this shouldn't be the blocker for v1.6, but has an acceptable workaround to address this, and I would like to include that if no one disagreed with that approach.
Adding to milestone to track
Moving this back to 1.6. The checkpoint implementation use , which does not sync at all. No wonder the checkpoints would be corrupted in the reboot tests. I reproduced this issue with a simple go program + reboots on a VM. The problem went away once I forced a I will upload a PR to fix this. /cc
Change:
} ) <del> func TestGetServicePrincipalTokenFromMSIWithUserAssignedID(t *testing.T) { configs := []*AzureAuthConfig{ { UseManagedIdentityExtension: true, UserAssignedIdentityID:      "UserAssignedIdentityID", }, // The Azure service principal is ignored when // UseManagedIdentityExtension is set to true { UseManagedIdentityExtension: true, UserAssignedIdentityID:      "UserAssignedIdentityID", TenantID:                    "TenantID", AADClientID:                 "AADClientID", AADClientSecret:             "AADClientSecret", }, } env := &azure.PublicCloud for _, config := range configs { token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) msiEndpoint, err := adal.GetMSIVMEndpoint() assert.NoError(t, err) spt, err := adal.NewServicePrincipalTokenFromMSIWithUserAssignedID(msiEndpoint, env.ServiceManagementEndpoint, config.UserAssignedIdentityID) assert.NoError(t, err) assert.Equal(t, token, spt) } } func TestGetServicePrincipalTokenFromMSI(t *testing.T) { configs := []*AzureAuthConfig{ { UseManagedIdentityExtension: true, }, // The Azure service principal is ignored when // UseManagedIdentityExtension is set to true { UseManagedIdentityExtension: true, TenantID:                    "TenantID", AADClientID:                 "AADClientID", AADClientSecret:             "AADClientSecret", }, } env := &azure.PublicCloud for _, config := range configs { token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) msiEndpoint, err := adal.GetMSIVMEndpoint() assert.NoError(t, err) spt, err := adal.NewServicePrincipalTokenFromMSI(msiEndpoint, env.ServiceManagementEndpoint) assert.NoError(t, err) assert.Equal(t, token, spt) } } </del> func TestGetServicePrincipalToken(t *testing.T) { config := &AzureAuthConfig{ TenantID:        "TenantID",

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --https://prow.ppc64le- Below two test cases started failing on ppc64le: 6th June 2021 https://k8s- ... was the delta between the passing and failing tests Started failing after
/assign
/sig cloud-provider /priority important-soon /triage accepted /assign
Thanks for reporting the issue. This was caused by vendor changes in , which introduced external dependency on IMDS. If IMDS endpoint is not reachable, then the new logic would report error.
Filed to clean up the failed tests.
Change:
"k8s.io/kubernetes/pkg/api/unversioned" "k8s.io/kubernetes/pkg/client/cache" client "k8s.io/kubernetes/pkg/client/unversioned" <del> controllerFramework "k8s.io/kubernetes/pkg/controller/framework" </del> <ins> controllerframework "k8s.io/kubernetes/pkg/controller/framework" </ins> "k8s.io/kubernetes/pkg/fields" "k8s.io/kubernetes/pkg/labels" "k8s.io/kubernetes/pkg/runtime"

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
import ( "fmt" <ins> "math/rand" </ins> "net/http" "net/http/httptest" <ins> "reflect" "sort" </ins> "sync" "testing" "time"

Discussion:
I've noticed a issue where if you have multiple replicated slave pods that don't have a HOST assigned and you reduce the number of replicas in the replicationController definition for those pods, sometimes the currently assigned (and running) pods get killed and the unassigned pod will get assigned to run in the killed pods place. The issue can be reproduced using the guestbook example provided in the repo. Steps to reproduce: (Note this is not always deterministic and may need multiple attempts) the master pod the master service the replicated slaves the Slave Controller definition to only have 1 replicas the Slave Controller with new definition The expected behavior should be that the scheduler is able to determine that unassigned pods are more viable candidates when reducing number of replicas. It seems to be more likely that since this issue is not deterministic, the ordering in which the command returns result is not always deterministically in the same order
: please can you look at this or suggested someone else? Thank you.
Unassign myself from this bug since I cannot get working on this soon. Also remove kubelet from the label since it is not kubelet issue. This is obviously a replicaController issue. cc/ Instead of destroying pod in pending state, replicaController unbound running pod from a node. Kubelet running on such node has this new desire state and kill unwanted pod to match it.
Yes, the replication controller should be smarter, taking into account Phase, Readiness, recency, ... This will be a significant problem for auto-scalers, but I expect manual scaling to be infrequent. I doubt we'll get to this soon. A PR would be welcome. Place to change is here:
Hi, I am final year Master's student of International Institute of Information Technology, Hyderabad. I am familiar with docker and containers. I have basic understanding of Go language with some hands on Docker API. This project seems interesting and a solution to this will also be a good addition to Kubernetes. So I would like to pick this as my GSoC project. I have started reading about Replication Controller and Pods and going though the code. I would appreciate if someone has any inputs for me on this. Thanks, Swapnil Patil
Change:
return nil, fmt.Errorf("Error creating floatingip for openstack load balancer %s: %v", name, err) } <del> status.Ingress = append(status.Ingress, v1.LoadBalancerIngress{IP: floatIP.FloatingIP}) </del> <ins> status.Ingress = []v1.LoadBalancerIngress{{IP: floatIP.FloatingIP}} } else { status.Ingress = []v1.LoadBalancerIngress{{IP: vip.Address}} </ins> } return status, nil

Discussion:
When creating a service passing the annotation , two IPs are created in the service, a private and a public: Having a private IP is not a desired scenario for service discovery in federated global environments. If we have, for example, a cluster in GKE and join a local OpenStack cluster, this private IP is written in the DNS zone but the GKE cluster won't be able to access it. We could add an annotation to say we don't want the private IP to be registered in service's LoadBalancer Ingress field, like: or And when it's false, only the public IP would be written in the service, therefore in the DNS zone /kind feature
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig openstack /sig federation
'' sounds better.
I don't like adding annotations just to make things work. I counter-propose just not publishing the private IP whenever there is also a floating-ip (without a configuration option to control this behaviour).
Change:
import ( "context" "fmt" <ins> "net/http" </ins> "path" "regexp" "strings"

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: check disk status before disk azure disk There is little possibility that attach disk would cost 10min, and disk could be attached, deleted in same time, that would cause race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
return totalAllocatable } <ins> // modified from https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/kubelet/config.go#L110 // the proxy version was causing and non proxy used a value that isn't set by e2e func decodeConfigz(contentsBytes []byte) (*kubeletconfig.KubeletConfiguration, error) { // This hack because /configz reports the following structure: // {"kubeletconfig": {the JSON representation of kubeletconfigv1beta1.KubeletConfiguration}} type configzWrapper struct { ComponentConfig kubeletconfigv1beta1.KubeletConfiguration `json:"kubeletconfig"` } configz := configzWrapper{} kubeCfg := kubeletconfig.KubeletConfiguration{} err := json.Unmarshal(contentsBytes, &configz) if err != nil { return nil, err } scheme, _, err := kubeletconfigscheme.NewSchemeAndCodecs() if err != nil { return nil, err } err = scheme.Convert(&configz.ComponentConfig, &kubeCfg, nil) if err != nil { return nil, err } return &kubeCfg, nil } </ins>

Discussion:
ci-kubernetes-e2e-aks-engine-azure-master-windows-containerd-serial-slow Kubernetes e2e suite: [sig-windows] [Feature:Windows] Memory Limits [Serial] [Slow] Allocatable node memory should be equal to a calculated allocatable memory value expandmore this month No response_ /sig windows
/assign
/triage accepted /priority important-soon
Change:
rc.Start() // Create pods sequentially (back-to-back). e2eLags have been sorted. <del> batchlag, e2eLags := createBatchPodSequential(f, testPods) </del> <ins> batchlag, e2eLags := createBatchPodSequential(f, testPods, podType) </ins> rc.Stop() deletePodsSync(f, append(bgPods, testPods...))

Discussion:
Test: [sig-node] Density [Serial] [Slow] create a sequence of pods latency/resource should be within limit when create 10 pods with 50 background pods /kind flake <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
Although the pod polling exhausted 4 times (interval 2s, total 6s+) to get pod Running, but from the kubelet log, the time from the pod found to Running status reported is almost less than 5s, so wo may reduce the poll interval to 1s, or make this time more relaxed
http://perf- ! This is caused by as . The commit will be reverted, and it make fail yesterday. ! EDITED I mean if this flake points out there are some other performance downgrades in v1.24. Only recently, no version 99% -- -- v1.20 ~2200ms v1.21 ~2200ms v1.22 ~2300ms v1.23 ~2650ms v1.24(before) ~2200ms v1.24(after ) ~6600ms
Editing title as this was also failing on containerd: /milestone v1.24 I think this confirms that the revert above fixed the issue, as the failures stopped after the revert merged. /close
Closing this issue. <detailsIn response to : Editing title as this was also failing on containerd: 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:
cd $(TEMP_DIR) && echo "ENV ETCD_UNSUPPORTED_ARCH=$(ARCH)" >> Dockerfile endif <ins> docker run --rm --privileged multiarch/qemu-user-static:$(QEMUVERSION) --reset -p yes docker buildx version BUILDER=$(shell docker buildx create --use) </ins> # And build the image <del> docker build  </del> <ins> docker buildx build  </ins> --pull  <ins> --load  --platform linux/$(ARCH)  </ins> -t $(REGISTRY)/etcd-$(ARCH):$(IMAGE_TAG)  --build-arg BASEIMAGE=$(BASEIMAGE)  --build-arg RUNNERIMAGE=$(RUNNERIMAGE)  $(TEMP_DIR) <ins> docker buildx rm $$BUILDER </ins> push: build docker tag $(REGISTRY)/etcd-$(ARCH):$(IMAGE_TAG) $(MANIFEST_IMAGE)-$(ARCH):$(IMAGE_TAG)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- post-kubernetes-push-image-etcd n/a 2020-08-11 Started failing when merged No new versions of etcd are getting pushed until this gets fixed, when means the following PRs haven't fully taken effect: /sig api-machinery /priority critical-urgent /milestone v1.23 /assign FYI
/sig release /area release-eng
I've opened to rollback the offending commit, would like to keep this open until we can figure out the correct fix-forward
/triage accepted
was triggered by the merge of , which pushed So that's now current / includes whatever PRs linked in the description may have tried to change (excluding )
does this need promotion at all or are we good with the existing image?
/remove-priority critical-urgent /priority important-soon The job is back to passing
Recent updates are related to Debian base image update and golang upgrade. Nice to get a promotion. Good enough to use .
Yeah, looks like that the env in the build job does not search for docker CLI plugins in the path, which makes it unavailable during the run.
I think we have to set the environment variable like we already do in other build jobs, proposing the fix in
Latest test run is green:
Change:
}, {Name: "abc-1234", Image: "image", ImagePullPolicy: "IfNotPresent", TerminationMessagePolicy: "File", SecurityContext: fakeValidSecurityContext(true)}, } <del> if errs := validateContainers(successCase, volumeDevices, field.NewPath("field")); len(errs) != 0 { </del> <ins> if errs := validateContainers(successCase, false, volumeDevices, field.NewPath("field")); len(errs) != 0 { </ins> t.Errorf("expected success: %v", errs) }

Discussion:
I found that kubelet will not allocate hostports specified from initContainers. And PodFitsHostPorts in kube-scheduler does not take initContainer into consideration. Also, kube-apiserver think such pod is illegal, but I think it OK. We should make the behavior of spec.HostPorts in initContainer clear
/sig node
Exactly. I think this makes sense. Since initContainers are expected to be completed, we should not expose extra port mappings during creating pod sandbox, which may bring in security risks.
Sounds good to me.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale