jiebi/CodeConvo huggingface dataset:
Change:
Bug report Kubernetes version Client Version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-beta.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-24T22:35:03Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-beta.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-24T22:30:23Z", GoVersion:"go1.7.3", Compiler:"gc", Platform:"linux/amd64"} When you curl the api you get a list of third party resources, however their selflinks are missing a forward slash:
fixed with , you may take a look.
This looks like it affects root scoped resources in general -- both custom ones (e.g. ServiceCatalog brokers, as noted in kubernetes-incubator/service-catalog) and "built-in" ones, like namespaces and nodes:
cc

Discussion:
} } <ins> func TestRootSelfLink(t *testing.T) { storage := map[string]rest.Storage{} simpleStorage := GetWithOptionsRootRESTStorage{ SimpleTypedStorage: &SimpleTypedStorage{ baseType: &genericapitesting.SimpleRoot{}, // a root scoped type item: &genericapitesting.SimpleRoot{ ObjectMeta: metav1.ObjectMeta{Name: "foo"}, Other:      "foo", }, }, takesPath: "atAPath", } storage["simple"] = &simpleStorage handler := handle(storage) server := httptest.NewServer(handler) defer server.Close() resp, err := http.Get(server.URL + "/" + prefix + "/" + testGroupVersion.Group + "/" + testGroupVersion.Version + "/simple/foo") if err != nil { t.Fatalf("unexpected error: %v", err) } if resp.StatusCode != http.StatusOK { t.Errorf("Unexpected status: %d, Expected: %d, %#v", resp.StatusCode, http.StatusOK, resp) body, err := ioutil.ReadAll(resp.Body) if err != nil { t.Fatalf("unexpected error: %v", err) } t.Logf("Data: %s", string(body)) } var out genericapitesting.SimpleRoot if _, err := extractBody(resp, &out); err != nil { t.Fatalf("unexpected error: %v", err) } if out.SelfLink != "/"+prefix+"/"+testGroupVersion.Group+"/"+testGroupVersion.Version+"/simple/foo" { t.Errorf("unexpected self link: %#v", out) } } </ins> func TestMetadata(t *testing.T) { simpleStorage := &MetadataRESTStorage{&SimpleRESTStorage{}, []string{"text/plain"}} h := handle(map[string]rest.Storage{"simple": simpleStorage})

GetContext:         ctxFn, SelfLinker:         a.group.Linker, ClusterScoped:      true, <del> SelfLinkPathPrefix: gpath.Join(a.prefix, resourcePath, "/"), </del> <ins> SelfLinkPathPrefix: gpath.Join(a.prefix, resourcePath) + "/", </ins> SelfLinkPathSuffix: suffix, }
Change:
I tried to create a kubernetes deployment with vSphere volume with volume path "[datastore] kubevols/redis-master". In this case the cloud provider queries the getDeviceNameFromMount() to return the path of the volume mounted. Since getDeviceNameFromMount() queries the filesystem to get the mount references, it returns a volume path "[datastore]040kubevols/redis-master". Later the kubelet searches for this volume path in both the actual and desired states. Th actual and desired states contains volume with path "[datastore] kubevols/redis-master". So, it couldn't find such volume path and therefore kubernetes stalls unable to make any progress further similar to one described in . However, when I create a kubernetes deployment with volume path - "[datastore]kubevols/redis-master" which doesn't contain any spaces, it works perfectly fine. So, the basic problem is to format and return the correct volume path from getDeviceNameFromMount() function. Alternatively, we can format it properly in the cloud provider code but this has to be done individually in all the cloud provider code base. Inorder to prevent it, it would be better to fix the getDeviceNameFromMount() function to return the correct formatted volume path.
CC Kubernetes should handle volumes with spaces (looks like vsphere is the first such volume) gracefully. Non a blocker issue for 1.5.
you should make sure that the 1.5 release notes capture that "vsphere volumes w/spaces have problems". Known issue accumulator in
getDeviceNameFromMount is function which queries /proc/mount to get mount points. 040 - is an escape sequence. 040 is the ascii code, in octal(base 8) number system, of the space. The mount command interprets 040 as literal space in the mount point. : Can't we provide a fix for this in 1.5 release itself? There a 2 options: can provide a fix in getDeviceNameFromMount. can provide a fix to vSphere cloud provider to fix it after the call to getDeviceNameFromMount. For option 1, we have to make sure it works for all cloud providers where as for option 2 its not needed. Let me know which option you think is feasible. I am ok with anything.
1 is the right answer. But we're very close to 1.5.0 release (<1 week). I'd also like whoever addresses this to ensure the entire system works end-to-end for volumes with spaces, not just patch one little corner. I'm afraid it would be a large change and we're not going to have enough time to validate it in 1.5. You can certainly start working on it. If you get a PR in time, we can consider it for 1.5.0. Otherwise it'll have to go in a patch release.

Discussion:
"fmt" "os" "path" <ins> "strings" </ins> "github.com/golang/glog" "k8s.io/kubernetes/pkg/api/resource"

if err != nil { return nil, err } <ins> volumePath = strings.Replace(volumePath, "040", " ", -1) </ins> glog.V(5).Infof("vSphere volume path is %q", volumePath) vsphereVolume := &v1.Volume{ Name: volumeName,
Change:
PR has broken my local build (, ). It unsets GOROOT and go build then looks into which does not exist. PTAL, it's really annoying regression.
same here
ugh, sorry. too many supported ways of building kubernetes. will fix.
Yup, I hit this too.
Pretty much every red hatter will hit this.
thanks for a quick fix

Discussion:
[[ -n ${1-} ]] || { kube::log::error_exit "!!! Internal error. No platform set in kube::golang::set_platform_envs" } <del> # make sure we have a clean slate first kube::golang::unset_platform_envs </del> export GOOS=${platform%/*} export GOARCH=${platform##*/}
Change:
Feature Request Currently the Kubernetes Azure assumes kubernetes is deployed to the same Azure Resource Group as all of the dependencies. In my case our case we're interested in deploying kubernetes to a Virtual Network that sits in a different resource group to the cluster itself, this will enable us to deploy kubernetes to a subnet in a locked down vnet. I think there might be a few ways to do this. can add a field to , and if the need arises to do the same for the NetworkSecurityGroup or RouteTable then we could do the same there. We could assume that if the isn't provided then the cluster is in the same RG as the VNET. support for Resource IDs (). I think this is a substantial change, looking at the code. I'm inclined to think the first option is best for now, as it's the path of least resistance. What do you think? When we decide what's needed I'm happy to muck in and make the changes :) Cheers,
I'm curious for thoughts on this. I laid out the three options here: The easiest one is to simply remove the check where we inspect the subnet to make sure the route table is set correctly - the subnet/vnet references aren't used anywhere else. The second easiest is to add . The hardest, but most correct is the third option of using full identifiers. I'm leaning towards the first one in the short term, and the full identifier option in the longer-run; there are some platform improvements that will tie-in nicely with supporting full identifiers, but without requiring reving/versioning the config file.
Hadn't thought of the first option, quickly knocked together the . At least I think that's all is needed anyway, but i could be missing something. I agree with you on the third option, especially about not having a breaking change. If we choose two then I'll raise a PR for the above change. But i'll hold off for now :)
cc:
Is there any chance you'd be willing to remove the subnet-routetable check instead of the second option and see if that meets your needs? I think that's what we want to go with short-term. Chances are, if people aren't configuring the route table / subnet correctly, then they likely won't find their way to the error message anyway. (Longer term we hope to move away from needing the config file at all, similar to other clouds.)
Yeah sure, I'll knock it up this evening then tag you in the PR :)

Discussion:
} } <del> // ensure the subnet is properly configured subnet, err := az.SubnetsClient.Get(az.ResourceGroup, az.VnetName, az.SubnetName, "") if err != nil { // 404 is fatal here return err } if subnet.RouteTable != nil { if *subnet.RouteTable.ID != *routeTable.ID { return fmt.Errorf("The subnet has a route table, but it was unrecognized. Refusing to modify it. active_routetable=%q expected_routetable=%q", *subnet.RouteTable.ID, *routeTable.ID) } } else { subnet.RouteTable = &network.RouteTable{ ID: routeTable.ID, } glog.V(3).Info("create: updating subnet") _, err := az.SubnetsClient.CreateOrUpdate(az.ResourceGroup, az.VnetName, az.SubnetName, subnet, nil) if err != nil { return err } } </del> targetIP, err := az.getIPForMachine(kubeRoute.TargetNode) if err != nil { return err
Change:
If kube-apiserver is run with , odd things happen e.g. We probably should validate that 0.
I'd like to work on this:)

Discussion:
"Currently only applies to long-running requests.") fs.IntVar(&s.MasterCount, "apiserver-count", s.MasterCount, <del> "The number of apiservers running in the cluster.") </del> <ins> "The number of apiservers running in the cluster, must be a positive number.") </ins> // See #14282 for details on how to test/try this option out. // TODO: remove this comment once this option is tested in CI.

if errs := options.InsecureServing.Validate("insecure-port"); len(errs) > 0 { errors = append(errors, errs...) } <ins> if options.MasterCount <= 0 { errors = append(errors, fmt.Errorf("--apiserver-count should be a positive number, but value '%d' provided", options.MasterCount)) } </ins> return errors }
Change:
Meta from When enabled frakti with kubelet, failed with errors: Kubelet logging: This is because the param in could be empty string:
assigning to you since you already have a PR up

Discussion:
// since whether the process is running in a TTY cannot be changed after it has started.  We // need the api.Pod to get the TTY status. pod, found := kl.GetPodByFullName(podFullName) <del> if !found || pod.UID != podUID { </del> <ins> if !found || (string(podUID) != "" && pod.UID != podUID) { </ins> return nil, fmt.Errorf("pod %s not found", podFullName) } containerSpec := kubecontainer.GetContainerSpec(pod, containerName)
Change:
Hi, I have been trying to run api-server as an standalone service along with etcd. I am passing etcd-servers and cluster-ip-range as arguments, here is the error I am getting: etcd servers are up and running on that address. Any leads as to how to resolve this? TIA.
This is only happening with go1.8 version, not really sure what is causing issue while parsing the URI.
Caused by this change i believe - CC as 1.8beta1 is being worked on here -
Thanks
I'm getting this exact issue using Kubernetes 1.5.7 and Go 1.8.3. Reverting to Go 1.7 seems to resolve it. This happened after updating a Go 1.7-compiled 1.4.8 Kubernetes cluster to 1.5.7, not sure if that's a corner case. For reference, my stack trace:

Discussion:
} base := host hostURL, err := url.Parse(base) <del> if err != nil { return nil, "", err } if hostURL.Scheme == "" || hostURL.Host == "" { </del> <ins> if err != nil || hostURL.Scheme == "" || hostURL.Host == "" { </ins> scheme := "http://" if defaultTLS { scheme = "https://"
Change:
When debugging Pod level QoS with CRI dockershim, I found that Pod level OoS actually doesn't work: dockershim+cgroupfs dockertools+cgroupfs And after dug it deeper, I noticed CgroupParent is not properly set at all: Finally, found the root cause is that that in is accidentally override, so it's always empty. PR: will fix this.
BTW, I also wrote a patch to make based Pod level QoS work in CRI dockershim, I will send it after this is fixed.
-- i am interested in the systemd patch.. i was hoping to find time to add that this week, so its good to know you have something. the problem if i recall was no clear place to inspect docker's configured cgroup driver.
Yes, so a is to dockershim during initialization. May I send a PR and and have you review if it sounds good. It's:

Discussion:
Binds: generateMountBindings(config.GetMounts()), } <del> // Apply cgroupsParent derived from the sandbox config. if lc := sandboxConfig.GetLinux(); lc != nil { // Apply Cgroup options. // TODO: Check if this works with per-pod cgroups. // TODO: we need to pass the cgroup in syntax expected by cgroup driver but shim does not use docker info yet... hc.CgroupParent = lc.GetCgroupParent() } </del> // Apply Linux-specific options if applicable. if lc := config.GetLinux(); lc != nil { // Apply resource options.

applyContainerSecurityContext(lc, podSandboxID, createConfig.Config, hc) } <ins> // Apply cgroupsParent derived from the sandbox config. if lc := sandboxConfig.GetLinux(); lc != nil { // Apply Cgroup options. // TODO: Check if this works with per-pod cgroups. // TODO: we need to pass the cgroup in syntax expected by cgroup driver but shim does not use docker info yet... hc.CgroupParent = lc.GetCgroupParent() } </ins> // Set devices for container. devices := make([]dockercontainer.DeviceMapping, len(config.Devices)) for i, device := range config.Devices {
Change:
https://k8s- Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite} Previous issues for this test:
Builds: ci-kubernetes-e2e-gce-release-1.5 ci-kubernetes-e2e-gci-gce-release-1.5 ci-kubernetes-e2e-gci-gke-release-1.5 ci-kubernetes-e2e-gci-gke-staging-parallel Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gke-release-1.5 ci-kubernetes-e2e-gke-staging-parallel Failed: [] [HPA] Horizontal pod autoscaling (scale resource: CPU) [] ReplicationController light Should scale from 1 pod to 2 pods {Kubernetes e2e suite}
There is a problem w/contacting controller service. This is already fixed by on master. The fix needs to propagated to the 1.5 branch.
ping looks like this is still occasionally happening, PTAL
Looking at the most recent issues here: it looks like there were a lot of instances where it wasn't this bug -- something else failed (like cluster networking, or connection to the API server), which caused this test to fail. There are a couple where there weren't a bunch of simultaneous failures, and on those I see some failures to collect metrics at all (but hard to tell anything w/o getting the Heapster logs). Finally, I do see a test run (https://k8s-) from 9 days ago where it looks like we are getting metrics from Heapster, just perhaps not the right ones. I'll do a bit more digging. P.S. Is there any way we can get the Heapster logs as part of the saved artifacts from test runs
How does heapster run? Is it possible to get the logs into the artifact directory?Here's the script that dumps the logs:
I've inspected https://k8s- run. HPA correctly scales "from 2 to 1" in the previous test case, but there are no HPA logs at all for subsequent test case for "from 1 to 2". Anyway, this problem appeared to happen only once 14 days ago, many bugs have been fixed since then. Most probably the root of the problem was not related to HPA. In my opinion, this should not be a release blocker.
This Issue hasn't been active in 53 days. It will be closed in 36 days (Jun 12, 2017). cc You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days
Closing as obsolete.

Discussion:
} framework.ExpectNoError(framework.RunRC(controllerRcConfig)) <del> // Make sure endpoints are propagated. // TODO(piosz): replace sleep with endpoints watch. time.Sleep(10 * time.Second) </del> <ins> // Wait for endpoints to propagate for the controller service. framework.ExpectNoError(framework.WaitForServiceEndpointsNum( c, ns, controllerName, 1, startServiceInterval, startServiceTimeout)) </ins> }
Change:
https://k8s- Failed: [] Loadbalancing: L7 [Feature:Ingress] [] GCE [Slow] [Feature: Ingress] shoud create ingress with given static-ip {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Loadbalancing: L7 [Feature:Ingress] [] GCE [Slow] [Feature: Ingress] shoud create ingress with given static-ip {Kubernetes e2e suite}
We are seeing these a lot in etcd rollback tests. Two different error messages.
Oh, here we go again. Another case for . Let me adjust the quota on that project.
I doubled the quota to 10. Watch upcoming runs .
points out that we may be leaking resources across runs, but I don't see a persistent leak. I doubled the quota on static IP addresses.
For unknown reasons, the GLBC is failing to delete the ingress resources. Unfortunately, the e2e fallback cleanup mechanism is also failing. It's trying to list resources via exec.Command( gcloud ... list --regexp=XYZ ) but always coming back with 0 resources. Putting the regular expression in quotes returns valid results. Expect a PR this afternoon.
PR is successfully deleting the remaining resources. The etcd upgrade test is now failing roughly half the time rather than continuously. After glancing over the recent failures, I've noticed a few consistent behaviors: objects are created and the l7 address is successfully hit. ingress objects are not cleaned up by the GLBC. (The test framework has to manually delete them) file does not contain log messages saying the ingress objects are being created. It also doesn't say that a delete ingress obj notification has been received. Log of glbc. glbc. I'm puzzled to why the ingress resources exist without the noting their creation. The other question is why the delete notification is not received/logged. Will investigate further...
for why the logs look incomplete, please see kubernetes/test-infra.
explains why this test does not clean up resources - causing the flake. [tl;dr] The GLBC only deletes L7 resources for ingress objects that it's cached locally. Caching happens soon after startup, but this races with the test's ingress deletion.
Thanks, Nick. Oh, and now I see a comment that is relevant to this. That case should probably be .
this is to be closed by he is going to remove when this trips
-- can we bump this from the release-1.6? It does not seem to be blocking for the release.
done

Discussion:
By(fmt.Sprintf("WARNING: possibly leaked static IP: %vn", ipErr)) } <del> // Fail if the controller didn't cleanup </del> <ins> // Logging that the GLBC failed to cleanup GCE resources on ingress deletion // See kubernetes/ingress#431 </ins> if pollErr != nil { <del> Failf("L7 controller failed to delete all cloud resources on time. %v", pollErr) </del> <ins> Logf("error: L7 controller failed to delete all cloud resources on time. %v", pollErr) </ins> } }
Change:
Hey Guys, When running command on release-1.4 branch, I got the below errors, my GO version is , how to fix it or something else have I missed?
dup of . fixed by . we can close this. /sig api-machinery
Sure, close it.

Discussion:
"net/url" "os" "reflect" <ins> "runtime" "strings" </ins> "testing" "k8s.io/kubernetes/pkg/util/sets"

// These fields are not copied "SessionTicketsDisabled", "SessionTicketKey", <del> "DynamicRecordSizingDisabled", "Renegotiation", </del> // These fields are unexported "serverInitOnce",

"sessionTicketKeys", ) <ins> // See #33936. if strings.HasPrefix(runtime.Version(), "go1.7") { expected.Insert("DynamicRecordSizingDisabled", "Renegotiation") } </ins> fields := sets.NewString() structType := reflect.TypeOf(tls.Config{}) for i := 0; i < structType.NumField(); i++ {
Change:
In large clusters, I'm seeing logs like this coming from route controller: Logs from route controller for that node:
OK - so the "rate limit exceeded" errors were caused by colliding tests in the same project. So the problems are that: timeout seems to be too low we are not handling errors exactly as we should
The first one is fixed by
Second problem was fixed by . Can we close this?
Yes.

Discussion:
Description:     k8sNodeRouteTag, }).Do() if err != nil { <del> return err </del> <ins> if isHTTPErrorCode(err, http.StatusConflict) { glog.Info("Route %v already exists.") return nil } else { return err } </ins> } return gce.waitForGlobalOp(insertOp) }
Change:
Kubernetes version (use ): v1.4.6 Environment: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS v1235.2.0 Kernel (e.g. ): 6-coreos-r1 SMP Wed Dec 7 00:29:42 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux What happened: When creating a service-type loadBalancer, adding creates an internal ELB, but the only allowed value for is 0.0.0.0/0. This limitation prevents you from specifying custom CIDR range for your hybrid cloud (Direct Connect to private data center) What you expected to happen: The limitation is unnecessary. Even in an AWS only scenario (no hybrid cloud), it makes sense to allow a CIDR range for a subnet where your calling services are deployed. How to reproduce it (as minimally and precisely as possible): Create a service-type loadBalancer and set loadBalancerSourceRanges to a value other than 0.0.0.0/0
Any update on this? Also, is anyone working on adding support for securityGroup?
any progress on this? I also really would like to have this flexibility in place for integrating k8s into an existing VPC.

Discussion:
// ServiceAnnotationLoadBalancerInternal is the annotation used on the service // to indicate that we want an internal ELB. <del> // Currently we accept only the value "0.0.0.0/0" - other values are an error. // This lets us define more advanced semantics in future. </del> const ServiceAnnotationLoadBalancerInternal = "service.beta.kubernetes.io/aws-load-balancer-internal" // ServiceAnnotationLoadBalancerProxyProtocol is the annotation used on the

internalELB := false internalAnnotation := apiService.Annotations[ServiceAnnotationLoadBalancerInternal] if internalAnnotation != "" { <del> if internalAnnotation != "0.0.0.0/0" { return nil, fmt.Errorf("annotation %q=%q detected, but the only value supported currently is 0.0.0.0/0", ServiceAnnotationLoadBalancerInternal, internalAnnotation) } if !service.IsAllowAll(sourceRanges) { // TODO: Unify the two annotations return nil, fmt.Errorf("source-range annotation cannot be combined with the internal-elb annotation") } </del> internalELB = true }
Change:
From : Full log: https://k8s-
Summary of my investigation: In the log I can see that for a claim started: must have called GCE volume provisioner because GCE PD was created Right after call there must be either or in the log, see [1]. Neither of these is actually in the log. This indicates that call did not finish at all. 1: On the other hand, is kept inside a . E.g. on this line we can see it is actually there and second run of the same operation was refused: The operation must have been deleted from the map because later we can see that a new operation with the same name is admitted: Conclusion: disappeared from GoRoutineMap without finishing and logging ether success or failure. Initially, I thought that call could have panicked, but there would be panic in the log and there is none. Root cause is still unknown. It looks it happened only once.
And the reason is that controller-manager was restarted after provisioning and before saving the PV to Kubernetes (at to be precise). Naturally, newly started controller-manager had empty GoRoutineMap and tries to provision a PV again. Solution: must be interpreted not as failure but as success, Kubernetes should adopt volumes it created and forgot about them. Patch will follow shortly.

Discussion:
return err } <del> return gce.waitForZoneOp(createOp, zone) </del> <ins> err = gce.waitForZoneOp(createOp, zone) if isGCEError(err, "alreadyExists") { glog.Warningf("GCE PD %q already exists, reusing", name) return nil } return err </ins> } func (gce *GCECloud) doDeleteDisk(diskToDelete string) error {