jiebi/CodeConvo huggingface dataset:
Change:
We'd like to deprecate alpha provisioning in 1.6. In order to make current deployments working after upgrade to 1.6 we need to deploy a default StorageClass as part of installation/upgrade on Azure so it will automatically provision volumes for PVCs marked with annotation - the annotation will be ignored and default storage class must provision the volume instead. On GCE and AWS, we use addon manager to install the default storage class, see Note that some extra code is probably needed to actually put the storage class into addons directory during installation, e.g. for manual script-based installation on GCE or for salt-based installation. Please make sure that: A default StorageClass is deployed during "default" installation. It would be nice if admin could turn this off during installation (e.g. as on GCE) If any additional manual steps are needed to deploy the default storage class make sure they're documented in appropriate installation guide.
Assigning to random Microsoft personnel for faster routing to proper person.
I believe this is fixed, correct? If so, I will close it...
Yes, it's fixed.

Discussion:
<ins> apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: default annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: kubernetes.io/cluster-service: "true" provisioner: kubernetes.io/azure-disk </ins>
Change:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Internal OpenStack cloud OS (e.g. from /etc/os-release): OS X 10.10.5 Kernel (e.g. ): Darwin Sean-Collins- 14.5.0 Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASEX8664 x86_64 Install tools: Others: What happened: kube- failed to create the heat stack KubernetesStack, and exited What you expected to happen: Create the stack KubernetesStack and continue onward How to reproduce it (as minimally and precisely as possible): See above console output Anything else do we need to know:
My suspicion is that the behavior of and the command has changed recently when
Nope, it actually looks like it's the (kubernetes)scollins ~/src/k8s/kubernetes ±swiftuploadcache » openstack catalog show object-store +-----------+
--------+ +-----------+
--------+ +-----------+
--------+ (kubernetes)scollins ~/src/k8s/kubernetes ±swiftuploadcache » openstack catalog show object-store --format value cut -d" " -f2 (kubernetes)scollins ~/src/k8s/kubernetes ±swiftuploadcache »
I'll need to check to see if the change from to is a server side change from OpenStack Keystone, or a change in , or is something that is deployed incorrectly in this environment
So, at least according to the , endpoints have an - which can be , , or - never
Yeah, so is from the

Discussion:
# Automatically detect swift url if it wasn't specified if [[ -z $SWIFT_SERVER_URL ]]; then <del> SWIFT_SERVER_URL=$(openstack catalog show object-store --format value | egrep -o "publicURL: (.+)$" | cut -d" " -f2) </del> <ins> local rgx="" if [ "$OS_IDENTITY_API_VERSION" = "3" ]; then rgx="public: (.+)$" else rgx="publicURL: (.+)$" fi SWIFT_SERVER_URL=$(openstack catalog show object-store --format value | egrep -o "$rgx" | cut -d" " -f2) </ins> fi local swift_repo_url="${SWIFT_SERVER_URL}/kubernetes"
Change:
It appears that the API server is no longer able to talk to etcd after an upgrade. See https://k8s- for an example. Interesting bits from api server log:
I have debugged a lot of 2.3.7 -3.0.14 upgrades and adding to every invocation helps a ton. Any chance we can twiddle this knob when we run these tests? Perhaps via instance metadata?
shows etcd starting, and that 3.0.14 stays running for ~10 hours, and apparently appending to its log. It looks like someone is talking to it. The failure modes I saw in testing upgrades were generally that etcd would crash, which is not what we see here.
One thing just occurred to me. We should probably have a test suite like these upgrades that simply tries to upgrade etcd without changing the version of k8s. This would let us isolate etcd failures from failures of other types.
- I think there is still one flag fix in the "migration" script that you found but didn't create a PR for. Maybe this is also reason of this failure? Can you please finish the loop and finally create that PR so that we can have the script in head updated?
I'm reopening for verifying if the problem is fixed.
I have re-built . I'll see if I can abort the current run of https://k8s-
We are currently using "3.0.14-alpha.1" image. So if you want to try a different image, I think you should update manifest files to the new image. Or rebuild 3.0.14-alpha.1 image :) [Unless I'm missing something how the test works.]
D'oh. Thanks, I just assumed the default tag in the Makefile was correct.
Should I be looking into this job: https://k8s- From the logs that pasted at the beginning (and which appear in all logs) and seems that the problem is with certificated files, not with etcd itself. - did anything change around how certs are handled? Any ideas why those tests may be facing this issue?
Actually, looking at the log that is causing it to fail: I very strongly suspect that the victim of those failures is this PR: - can you please take a look if the hypothesis sounds reasonable to you?
I have seen something related, probably the same issue. I was testing 1.4.7, persisted the etcd data dir, restarted the cluster on master and wasn't able to access any resources created when the cluster was running in 1.4.7. I was able to see those resources in etcd by using curl directly on etcd. Using etcd 3.0.15
Ok, ya this was caused by . I tried to revert and got some nasty conflicts. I'm hoping that will be ready by the EOD and will fix this issue.
thanks!
can you confirm that your PR would have caused the same problem if was running etcd v2? I'm trying to rule out any interaction with etcd v3 or our scripts related to it.
yes, I don't think this problem is etcd related, as far as i can tell right now.
- is this issue still relevant? Or can we close as obsolete?

Discussion:
${ETCD_CMD}  --name="etcd-$(hostname)"  --debug  <ins> --force-new-cluster  </ins> --data-dir=${DATA_DIRECTORY}  --listen-client-urls http://127.0.0.1:${ETCD_PORT}  --advertise-client-urls http://127.0.0.1:${ETCD_PORT}
Change:
<!-- 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.): delete pod delete pod uid Is this a BUG REPORT or FEATURE REQUEST? (choose one): maybe a bug report: the "kubectl delete pod [uid]" doesn't work. Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-10T00:30:53Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-10T00:26:06Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} What happened: First, use "kubectl get pod [podname] -o yaml" to get the details of the pod, obtaining the uid under Then use "kubectl delete pod [uid]" to delete the pod, but failed finally. the info showed like this: Error from server (NotFound): pods "-dbf8-11e6-818c-" not found. Did I get the wrong uid? What you expected to happen: It should delete pod successfully just like using podname. How to reproduce it (as minimally and precisely as possible): just do like mentioned in "What happened"
I don't think we provide pod deletion by UID... /cc
If you type "kubectl delete pod -h", there is a piece of specifications describing like this: "# Delete a pod with UID 1234-56-7890--. kubectl delete pod 1234-56-7890--" So is this a mistake?
I don't know. It could be a feature that I am not aware of. Folks from the will know better.
kubectl delete pod 1234-56-7890-- It seems this help message exists even in v1.0. Do we support this before?
AFAIK, apiserver doesn't support operations using the UID as the key. Unless kubectl implement additional logic to map the UID to a (name, namespace) tuple, it'd not be able to do that.
Delete by UID is no longer supported, this is an issue with the help text that needs to be adjusted.

Discussion:
# Force delete a pod on a dead node kubectl delete pod foo --grace-period=0 --force <del> # Delete a pod with UID 1234-56-7890-234234-456456. kubectl delete pod 1234-56-7890-234234-456456 </del> # Delete all pods kubectl delete pods --all`) )
Change:
The current way tags are implemented excludes scenarios where more than one tag is applicable. For instance [Flaky] supersedes [Disruptive], which leads to both disruptive and non-disruptive tests running together, causing flakes more in the non-disruptive. e.g. We are seeing a scenario where PersistentVolumes[Volume][Serial][Flaky] are run parallel to NodeOutOfDisk[Flaky][Disruptive]. NodeOutOfDisk causes the kubelet to evict pods, which leads to flakes in PersistentVolumes. Test grid @ https://k8s- What's the reasoning behind the current hierarchical tag scheme? Is there an inherent benefit over a multi-tag grouping system? For instance, one that could distinguish [Flaky][Disruptive] tests from [Flaky][Serial] ones? Or one that would run a [Flaky][Serial] test serially? (My understanding is that Flaky tests alway run in parallel.) Given that this is a stability issue for E2E, I'd like to ask that it be given a higher priority for a fix. cc
Ok. Agree it's high priority , for the fix keep this open, /'d maybe we need to put a pull request to the test infra repo? We need to find where the scripts that setup tests are, I don't know whether the Jenkins jobs that define what tests to skip/run are in kubernetes core anymore ...

Discussion:
BeforeEach(func() { c = f.ClientSet <ins> framework.Skipf("test is broken. #40249") </ins> nodelist := framework.GetReadySchedulableNodesOrDie(c) // Skip this test on small clusters.  No need to fail since it is not a use
Change:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure / Azure Container Service OS (e.g. from /etc/os-release): Xenial Kernel (e.g. ): latest lts Install tools: kubelet + static manifests Others: n/a What happened: I created a Service (type=LoadBalancer). The load balancer did not complete provisioning and security group was not updated, so the LB that is there doesn't work. What you expected to happen: Azure load balancer is created, external IP field is populated (doesn't show as "Pending") How to reproduce it (as minimally and precisely as possible): Try it. Anything else do we need to know: No. There is an issue opened against the repo that caused this problem: This was reported here: CC:
Should we do a fix that simply sets the 2 properties to nil before a real fix comes into go-autorest?
I'd prefer to fix it properly in but as of yet, it's unclear what the timeframe is. Let me ask for a timeline.
I agree that a proper fix in go-autorest would be preferable. But as long as it's not fixed, LBs are broken on k8s=1.5.2. That's why I would like to do a workaround until the real fix comes in.
Is there a workaround? Is there a way I can manually intervene to make the LoadBalancer work?
No. Not currently, other than building your own copy of with patch applied. I'm testing a more proper fix today or tomorrow - hope to have it in for 1.5.3.

Discussion:
} if sgNeedsUpdate { glog.V(3).Infof("ensure(%s): sg(%s) - updating", serviceName, *sg.Name) <ins> // azure-sdk-for-go introduced contraint validation which breaks the updating here if we don't set these // to nil. This is a workaround until https://github.com/Azure/go-autorest/issues/112 is fixed sg.SecurityGroupPropertiesFormat.NetworkInterfaces = nil sg.SecurityGroupPropertiesFormat.Subnets = nil </ins> _, err := az.SecurityGroupsClient.CreateOrUpdate(az.ResourceGroup, *sg.Name, sg, nil) if err != nil { return nil, err

} if sgNeedsUpdate { glog.V(3).Infof("delete(%s): sg(%s) - updating", serviceName, az.SecurityGroupName) <ins> // azure-sdk-for-go introduced contraint validation which breaks the updating here if we don't set these // to nil. This is a workaround until https://github.com/Azure/go-autorest/issues/112 is fixed sg.SecurityGroupPropertiesFormat.NetworkInterfaces = nil sg.SecurityGroupPropertiesFormat.Subnets = nil </ins> _, err := az.SecurityGroupsClient.CreateOrUpdate(az.ResourceGroup, *reconciledSg.Name, reconciledSg, nil) if err != nil { return err
Change:
Kubernetes version (use ): 2 Environment: Cloud provider or hardware configuration: LXD OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-57-generic -Ubuntu Install tools: Juju Others: What happened: The kubernetes-master charm entered a state with the following stacktrace: The 10.152.183.10 IP was already claimed by default-http-backend: What you expected to happen: default-http-backend should not deploy until after kube-dns has had a chance to reserve its dedicated IP How to reproduce it (as minimally and precisely as possible): It'll be hard to reproduce this reliably since the default-http-backend service IP is chosen randomly. However, this might occur sporadically when deploying with juju.
It looks like the juju provider always deploys kube-dns to ..*.10 and the default-http-backend already claimed it. What are other providers doing? Are they pinning dns to an IP address and not never get a collision?
I don't think this needs to be fixed for 1.6. It's a pretty rare case and only applies to deployments with Juju.
removing the 1.6 milestone as per

Discussion:
@when('kube-control.connected') <ins> @when('cdk-addons.configured') </ins> def send_cluster_dns_detail(kube_control): ''' Send cluster DNS info ''' # Note that the DNS server doesn't necessarily exist at this point. We know
Change:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): Ubuntu 16.04 What happened: I have a pod that failed. returns nothing returns the right thing. It's a bit silly to require when a pod id is explicitly given. I think this started happening recently only on the GKE (or maybe the time needed to “forget” the pod has just become shorter).
Fixed in

Discussion:
return result, err } <ins> func makePodStatus(info interface{}) string { if state, ok := info.(map[string]interface{})["State"]; ok { if running, ok := state.(map[string]interface{})["Running"]; ok { if running.(bool) { return "Running" } else { return "Stopped" } } } return "Pending" } </ins> func (storage *PodRegistryStorage) Get(id string) (interface{}, error) { pod, err := storage.registry.GetPod(id) if err != nil {

return pod, err } pod.CurrentState.Info = info <ins> pod.CurrentState.Status = makePodStatus(info) </ins> pod.Kind = "cluster#pod" return pod, err }

"foobar": "bar", "baz":    "blah", }) <ins> } func TestMakePodStatus(t *testing.T) { status := makePodStatus(map[string]interface{}{}) if status != "Pending" { t.Errorf("Expected 'Pending', got '%s'", status) } status = makePodStatus(map[string]interface{}{ "State": map[string]interface{}{ "Running": false, }, }) if status != "Stopped" { t.Errorf("Expected 'Stopped', got '%s'", status) } status = makePodStatus(map[string]interface{}{ "State": map[string]interface{}{ "Running": true, }, }) if status != "Running" { t.Errorf("Expected 'Running', got '%s'", status) } </ins> }
Change:
disabled them since was flaky. We need to find and fix the issue and then reenable these tests. cc Related issues: and
Probably should be higher priority so it doesn't get dropped
The issue is that we dont wait for the resource to be deleted unless we are using a reaper: This breaks for federation since we use finalizers. kubectl should wait for the resource to be deleted. We should also set OrphanDependents = false. This will have no effect in kubernetes but will enable cascading deletion in federation. Ref cc Will send a fix.
Sent
Updated to remove the wait (GET) at the end so it no longer fixes this issue. Sent to update the test to include a wait which fixes this issue.

Discussion:
kubectl delete secret test-secret --namespace=test-secrets ### Create a docker-registry secret in a specific namespace <ins> if [[ "${WAIT_FOR_DELETION:-}" == "true" ]]; then kube::test::wait_object_assert 'secrets --namespace=test-secrets' "{{range.items}}{{$id_field}}:{{end}}" '' fi </ins> # Pre-condition: no SECRET exists kube::test::get_object_assert 'secrets --namespace=test-secrets' "{{range.items}}{{$id_field}}:{{end}}" '' # Command

kubectl delete secret test-secret --namespace=test-secrets ### Create a tls secret <ins> if [[ "${WAIT_FOR_DELETION:-}" == "true" ]]; then kube::test::wait_object_assert 'secrets --namespace=test-secrets' "{{range.items}}{{$id_field}}:{{end}}" '' fi </ins> # Pre-condition: no SECRET exists kube::test::get_object_assert 'secrets --namespace=test-secrets' "{{range.items}}{{$id_field}}:{{end}}" '' # Command

kubectl delete secret secret-string-data --namespace=test-secrets ### Create a secret using output flags <ins> if [[ "${WAIT_FOR_DELETION:-}" == "true" ]]; then kube::test::wait_object_assert 'secrets --namespace=test-secrets' "{{range.items}}{{$id_field}}:{{end}}" '' fi </ins> # Pre-condition: no secret exists kube::test::get_object_assert 'secrets --namespace=test-secrets' "{{range.items}}{{$id_field}}:{{end}}" '' # Command

setup run_federation_apiserver run_federation_controller_manager <del> # TODO: Fix for secrets, replicasets and deployments. SUPPORTED_RESOURCES=("configmaps" "daemonsets" "events" "ingress" "namespaces" "services") </del> <ins> # TODO: Fix for replicasets and deployments. SUPPORTED_RESOURCES=("configmaps" "daemonsets" "events" "ingress" "namespaces" "services" "secrets") # Set wait for deletion to true for federation apiserver since resources are # deleted asynchronously. # This is a temporary workaround until https://github.com/kubernetes/kubernetes/issues/42594 is fixed. WAIT_FOR_DELETION="true" </ins> # WARNING: Do not wrap this call in a subshell to capture output, e.g. output=$(runTests) # Doing so will suppress errexit behavior inside runTests runTests
Change:
<!-- 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 ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): panic apiserver invalid memory address Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report <!-- 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: aws OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux ip-10-50-193-54 4.4.0-59-generic -Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others: What happened: Tried to exec: . Got back: apiserver logs: It only seems to happen on this one pod - other pods are fine. What you expected to happen: should succeed or at least give a sensible error message. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
There are no errors on the node with the pod. I also tried kubectl v1.4.8 and same problem.
It looks like your pod that's having the issue has a container with a security context, but privileged appears to be nil. Can you confirm that is the case?
Yep that's it. It seems when securityContext is specified without setting , it isn't set correctly to its default of false. e.g. the pod yaml has: Explicitly adding allows exec to succeed.
Ah, this was caused by the kubelet using versioned APIs - for his awareness. Basically any code that depends on nil pointers being set is vulnerable.

Discussion:
// isPrivileged will return true a pod has any privileged containers func isPrivileged(pod *api.Pod) bool { for _, c := range pod.Spec.InitContainers { <del> if c.SecurityContext == nil { </del> <ins> if c.SecurityContext == nil || c.SecurityContext.Privileged == nil { </ins> continue } if *c.SecurityContext.Privileged {

} } for _, c := range pod.Spec.Containers { <del> if c.SecurityContext == nil { </del> <ins> if c.SecurityContext == nil || c.SecurityContext.Privileged == nil { </ins> continue } if *c.SecurityContext.Privileged {
Change:
What keywords did you search in Kubernetes issues before filing this one? scheduler_perf. Is this a BUG REPORT or FEATURE REQUEST? Bug Kubernetes version (use ): Master Looks like perf test is broke. I'll dig into the details. Leads to Will add more details later or issue a PR if its something trivial.
i think your affinity cleanup patch, might be the source :) .... [ deleted above comment not relevant ] some other change, possibly in the affinity cleanup may have caused this, but i dont think its the stuff, that looks ok to me. Possibly just a typo might have been introduced in that patch? If not maybe its just an issue with the way we need to update the labelling json or something. I can take another look in the morning.
ok, i think i see... it wants to match the label ... from this node: into this set so the set is empty. I guess it could be a bug in the way the match selector is being produced, but the code looks clean to me. will double check.
fixed

Discussion:
{ Key:      nodeAffinityKey, Operator: v1.NodeSelectorOpIn, <del> Values:   []string{string(i)}, </del> <ins> Values:   []string{fmt.Sprintf("%v", i)}, </ins> }, }, },
Change:
Problem showed, that despite e2e tests for container's logs, we still can encounter regressions for system logs. We need to establish an e2e test for ingesting system components's logs: kubelet docker CC
broke ingesting logs from master and we didn't notice it at once Test should check that logs are present from all nodes, including master (when possible)
Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.
/sig instrumentation do you want this in v1.7? (since you're listed as sig-instrumentation leads at and I can't find a team to ping)
No, thanks for noticing!
Fixed by

Discussion:
k8s-app: fluentd-es kubernetes.io/cluster-service: "true" version: v1.22 <del> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573). </del> <ins> # This annotation ensures that fluentd does not get evicted if the node # supports critical pod annotation based priority scheme. # Note that this does not guarantee admission on the nodes (#40573). </ins> annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> scheduler.alpha.kubernetes.io/tolerations: '[{"key": "node.alpha.kubernetes.io/ismaster", "effect": "NoSchedule"}]' </ins> spec: containers: - name: fluentd-es

# Note that this does not guarantee admission on the nodes (#40573). annotations: scheduler.alpha.kubernetes.io/critical-pod: '' <ins> scheduler.alpha.kubernetes.io/tolerations: '[{"key": "node.alpha.kubernetes.io/ismaster", "effect": "NoSchedule"}]' </ins> spec: containers: - name: fluentd-gcp