jiebi/CodeConvo huggingface dataset:
Change:
We should remove the old implementation and migrate the rest of the utility functions to . [x] Remove DockerManager (PR: ). [x] Remove --enable-cri and the relevant code (PR: ). [x] Refactor/move code in dockertools. (PRs: ...)
The dockertools package is gone, closing this issue. Note that there are still docker references in various places in the repository, as well as tangled docker/kubelet initialization code. Those will be handled in other issues/PRs.
For the record, relevant PRs:

Discussion:
"naming_test.go", "security_context_test.go", ], <ins> data = [ "fixtures/seccomp/sub/subtest", "fixtures/seccomp/test", ], </ins> library = ":go_default_library", tags = ["automanaged"], deps = [

import ( "fmt" <ins> "path" </ins> "testing" "github.com/blang/semver"

assert.Equal(t, expectedAnnotations, actualAnnotations) } <del> // TestGetSeccompSecurityOpts tests the logic of generating container seccomp options from sandbox annotations. // The actual profile loading logic is tested in dockertools. // TODO: Migrate the corresponding test to dockershim. </del> func TestGetSeccompSecurityOpts(t *testing.T) { containerName := "bar" makeConfig := func(annotations map[string]string) *runtimeapi.PodSandboxConfig {

} } <ins> func TestLoadSeccompLocalhostProfiles(t *testing.T) { containerName := "bar" makeConfig := func(annotations map[string]string) *runtimeapi.PodSandboxConfig { return makeSandboxConfigWithLabelsAndAnnotations("pod", "ns", "1234", 1, nil, annotations) } tests := []struct { msg          string config       *runtimeapi.PodSandboxConfig expectedOpts []string expectErr    bool }{{ msg: "Seccomp localhost/test profile", config: makeConfig(map[string]string{ v1.SeccompPodAnnotationKey: "localhost/test", }), expectedOpts: []string{`seccomp={"foo":"bar"}`}, expectErr:    false, }, { msg: "Seccomp localhost/sub/subtest profile", config: makeConfig(map[string]string{ v1.SeccompPodAnnotationKey: "localhost/sub/subtest", }), expectedOpts: []string{`seccomp={"abc":"def"}`}, expectErr:    false, }, { msg: "Seccomp non-existent", config: makeConfig(map[string]string{ v1.SeccompPodAnnotationKey: "localhost/non-existent", }), expectedOpts: nil, expectErr:    true, }} profileRoot := path.Join("fixtures", "seccomp") for i, test := range tests { opts, err := getSeccompSecurityOpts(containerName, test.config, profileRoot, '=') if test.expectErr { assert.Error(t, err, fmt.Sprintf("TestCase[%d]: %s", i, test.msg)) continue } assert.NoError(t, err, "TestCase[%d]: %s", i, test.msg) assert.Len(t, opts, len(test.expectedOpts), "TestCase[%d]: %s", i, test.msg) for _, opt := range test.expectedOpts { assert.Contains(t, opts, opt, "TestCase[%d]: %s", i, test.msg) } } } </ins> // TestGetApparmorSecurityOpts tests the logic of generating container apparmor options from sandbox annotations. // The actual profile loading logic is tested in dockertools. // TODO: Migrate the corresponding test to dockershim.

"docker_test.go", "kube_docker_client_test.go", ], <del> data = [ "fixtures/seccomp/sub/subtest", "fixtures/seccomp/test", ], </del> library = ":go_default_library", tags = [ "automanaged",
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.): 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 ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: It is losing in help info. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
will make a pr to address that

Discussion:
* all * certificatesigningrequests (aka 'csr') <del> * clusters (valid only for federation apiservers) </del> * clusterrolebindings * clusterroles <ins> * clusters (valid only for federation apiservers) </ins> * componentstatuses (aka 'cs') * configmaps (aka 'cm') <ins> * cronjobs </ins> * daemonsets (aka 'ds') * deployments (aka 'deploy') * endpoints (aka 'ep')

* nodes (aka 'no') * persistentvolumeclaims (aka 'pvc') * persistentvolumes (aka 'pv') <del> * pods (aka 'po') </del> * poddisruptionbudgets (aka 'pdb') <ins> * pods (aka 'po') </ins> * podsecuritypolicies (aka 'psp') * podtemplates * replicasets (aka 'rs')
Change:
Leads to this avc: In general, HostPath volumes in tests are bad news for selinux.

Discussion:
"fmt" "os" "path" <del> "path/filepath" </del> "syscall" "time"

permReason2    = "Permanent2" permMessage2   = "permanent error 2" ) <del> var source, config, tmpLogFile string </del> <ins> var source, config, hostLogFile string </ins> var lookback time.Duration var eventListOptions metav1.ListOptions

}.AsSelector().String() eventListOptions = metav1.ListOptions{FieldSelector: selector} By("Create the test log file") <del> tmpLogFile = filepath.Join("/tmp", name, path.Base(logFile)) os.MkdirAll(path.Dir(tmpLogFile), 755) _, err = os.Create(tmpLogFile) </del> Expect(err).NotTo(HaveOccurred()) By("Create config map for the node problem detector") _, err = c.Core().ConfigMaps(ns).Create(&v1.ConfigMap{

{ Name: logVolume, VolumeSource: v1.VolumeSource{ <del> HostPath: &v1.HostPathVolumeSource{Path: path.Dir(tmpLogFile)}, </del> <ins> EmptyDir: &v1.EmptyDirVolumeSource{}, </ins> }, }, {

{ Name:    name, Image:   image, <del> Command: []string{"/node-problem-detector", "--logtostderr", "--system-log-monitors=" + configFile, fmt.Sprintf("--apiserver-override=%s?inClusterConfig=false", framework.TestContext.Host)}, </del> <ins> Command: []string{"sh", "-c", "touch " + logFile + " && /node-problem-detector --logtostderr --system-log-monitors=" + configFile + fmt.Sprintf(" --apiserver-override=%s?inClusterConfig=false", framework.TestContext.Host)}, </ins> Env: []v1.EnvVar{ { Name: "NODE_NAME",

}, }, }) <ins> pod, err := f.PodClient().Get(name, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred()) // TODO: remove hardcoded kubelet volume directory path // framework.TestContext.KubeVolumeDir is currently not populated for node e2e hostLogFile = "/var/lib/kubelet/pods/" + string(pod.UID) + "/volumes/kubernetes.io~empty-dir" + logFile </ins> }) It("should generate node condition and events for corresponding errors", func() {

By(test.description) if test.messageNum > 0 { By(fmt.Sprintf("Inject %d logs: %q", test.messageNum, test.message)) <del> err := injectLog(tmpLogFile, test.timestamp, test.message, test.messageNum) </del> <ins> err := injectLog(hostLogFile, test.timestamp, test.message, test.messageNum) </ins> Expect(err).NotTo(HaveOccurred()) }

By("Clean up the node condition") patch := []byte(fmt.Sprintf(`{"status":{"conditions":[{"$patch":"delete","type":"%s"}]}}`, condition)) c.Core().RESTClient().Patch(types.StrategicMergePatchType).Resource("nodes").Name(framework.TestContext.NodeName).SubResource("status").Body(patch).Do() <del> By("Clean up the temporary directory") Expect(os.RemoveAll(path.Dir(tmpLogFile))).To(Succeed()) </del> }) }) })
Change:
Upgrade fails with: Error from: https://k8s- Related failures: https://k8s- https://k8s-
/cc
might require how do the GKE tests interact with the defaults you set up?
Looks like are pretty isolated to upgrade tests.
Also we didn't start seeing this until the ABAC default change merged so I think change might help
it will definitely help with the GCE jobs mentioned in the description of
I haven't looked at the logs, so sorry if this is just noise, but the symptom (couldn't get logs b/c pod doesn't exist) looks very similar to what happened when the kubectl taint e2e tests were running in parallel instead of serial.
Judging by the comment and digging into the history , this used to be wrapped in a retry loop. It was removed in PR
it looks like this is limited to gke jobs in the upgrade tests. since getting pod logs depends on master-node communications, it would be affected by the SSH tunnels issue ()
Not blocking under guidance

Discussion:
"--master", fmt.Sprintf("--cluster-version=%s", v), "--quiet") <del> return err </del> <ins> if err != nil { return err } waitForSSHTunnels() return nil </ins> } func NodeUpgrade(f *Framework, v string, img string) error {

args = append(args, fmt.Sprintf("--image-type=%s", img)) } _, _, err := RunCmd("gcloud", args...) <del> return err </del> <ins> if err != nil { return err } waitForSSHTunnels() return nil </ins> } // CheckNodesReady waits up to nt for expect nodes accessed by c to be ready,

} return TestContext.GCEUpgradeScript } <ins> func waitForSSHTunnels() { Logf("Waiting for SSH tunnels to establish") RunKubectl("run", "ssh-tunnel-test", "--image=gcr.io/google_containers/busybox:1.24", "--restart=Never", "--command", "--", "echo", "Hello") defer RunKubectl("delete", "pod", "ssh-tunnel-test") // allow up to a minute for new ssh tunnels to establish wait.PollImmediate(5*time.Second, time.Minute, func() (bool, error) { _, err := RunKubectl("logs", "ssh-tunnel-test") return err == nil, nil }) } </ins>
Change:
This has surfaced in Ingress and Service e2e tests that manipulate DNS entries. The service controller queries the managed dns entry, thinks that the CNAME doesn't exist and adds a new one. However, clouddns says (through a 409) that the entry already exists. Error message aside, the control flow within the service controller's endpoint_helper prevents a service from being deleted. It's unclear at this point whether there's a race condition. I doubt it given the amount of logging that happens showing that there is no concurrent CNAME entry being created. cc Have you seen this in your refactoring?
Hi I used CoreDNS for most of my testing for service controller refactoring and i did not notice these errors. my local test environment is slightly different than the CI environment. i would do more tests on this issue using CoreDNS and would confirm, if it is an issue also in coredns or just google-clouddns.
If you're not still working on this, please unassign yourself and we'll try to find someone else. Thanks.
This issue was labelled only for sig/multicluster and is thus moved over to kubernetes/federation. If this does not seem to be right, please reopen this and notify us /close

Discussion:
const ( MaxRetriesOnFederatedApiserver = 3 <del> FederatedIngressTimeout        = 10 * time.Minute </del> <ins> FederatedIngressTimeout        = 15 * time.Minute </ins> FederatedIngressDeleteTimeout  = 2 * time.Minute FederatedIngressName           = "federated-ingress" FederatedIngressServiceName    = "federated-ingress-service"

// TODO check dns record in global dns server }) <del> It("should be able to connect to a federated ingress via its load balancer", func() { </del> <ins> PIt("should be able to connect to a federated ingress via its load balancer", func() { </ins> By(fmt.Sprintf("Waiting for Federated Ingress on %v", jig.ing.Name)) // check the traffic on federation ingress jig.waitForFederatedIngress()

}) <del> It("should be able to discover a non-local federated service", func() { </del> <ins> PIt("should be able to discover a non-local federated service", func() { </ins> fedframework.SkipUnlessFederated(f.ClientSet) nsName := f.FederationNamespace.Name
Change:
Script does not support upgrade of clusters with HA master setup.
CC
PR does not allow to run upgrade scripts on cluster with HA masters. The upgrade scenario for HA clusters from 1.5 to 1.6 may be the following: all master replicas but one, master upgrade, master replicas again.
I haven't reviewed the PR yet, but the scenario you are proposing defeats the purpose of HA master! I think it's ok to say we do not support HA master upgrades yet, but we should document how this can be done manually and fix this properly later by adding support in
It's too late to add this in for 1.6.0, but we should consider backporting a fix so that users can update an HA master to 1.6.x in the near future. We should also put in a big warning in the release notes warning users not to try and upgrade if they deployed an HA master using kube-
/sig cluster-lifecycle
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 /lifecycle frozen
/remove-lifecycle frozen /sig cloud-provider /area provider/gcp changing with ownership of ""
/remove-sig cluster-lifecycle
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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

Discussion:
} function upgrade-master() { <ins> local num_masters num_masters=$(get-master-replicas-count) if [[ "${num_masters}" -gt 1 ]]; then echo "Upgrade of master not supported if more than one master replica present. The current number of master replicas: ${num_masters}" exit 1 fi </ins> echo "== Upgrading master to '${SERVER_BINARY_TAR_URL}'. Do not interrupt, deleting master instance. ==" # Tries to figure out KUBE_USER/KUBE_PASSWORD by first looking under
Change:
On some occasions Cluster Autoscaler may scale up the cluster two times. This results in growing the cluster too large. The size gets back to normal soon but the user will be forced to pay for the unneeded node for 10min/1h, depending on the cloud provider. cc:
Please provide more information.
Imagine that you have just created a pod that cannot be scheduled. CA expands one of the migs to accommodate it. Just when the node arrives there is a brief moment when the pod is still pending (scheduler didn't retry it yet) but the node is available. Scale up is over. Pod is pending. So we might try to scale up again, which would be incorrect. To protect against such situations we run a simulated scheduling on all nodes. If any node can accommodate any of the pending pods then the pod is not pending and should not trigger a scale up. After a scale up we create "virtual" nodes inside CA so that we don't scale up again for the same pods. Once the node arrives its virtual placeholder is deleted. And, if I'm correct, we have a bug here. A node with node condition ready=true but with non ready network is considered as fully started but broken. Its virtual placeholder is gone so we trigger scale up again. Seconds later the network arrives and the scale up appears to be non-needed. I'm testing right now a 10 line fix for this issue. After the fix is merged I would like to bump CA version in 1.6 as having the old code would impact all of the current CA users on GCE and GKE (and possibly on other cloud providers too).
is this a regression in cluster autoscaler for 1.6, or did the same behavior exist in 1.5?
It is a regression. Doesn't happen always (depends on the network setup timings) but when it does it is quite confusing.

Discussion:
"containers": [ { "name": "cluster-autoscaler", <del> "image": "gcr.io/google_containers/cluster-autoscaler:v0.5.0", </del> <ins> "image": "gcr.io/google_containers/cluster-autoscaler:v0.5.1", </ins> "command": [ "./run.sh", "--kubernetes=http://127.0.0.1:8080?inClusterConfig=f",
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.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): If this is a BUG REPORT, please: The table in the readme for /examples is broken. What happened: The table in the readme for /examples is broken. How to reproduce it (as minimally and precisely as possible): can be updated
Closing this issue as has merged.

Discussion:
and best practices, and to refresh command syntax, output, changed prerequisites, as needed. <del> Name | Description | Notable Features Used | Complexity Level ------------- | ------------- | ------------ | ------------ | ------------ [Guestbook](guestbook/) | PHP app with Redis | Replication Controller, Service | Beginner [WordPress](mysql-wordpress-pd/) | WordPress with MySQL | Deployment, Persistent Volume with Claim | Beginner [Cassandra](storage/cassandra/) | Cloud Native Cassandra | Daemon Set | Intermediate </del> <ins> |Name | Description | Notable Features Used | Complexity Level| ------------- | ------------- | ------------ | ------------ | |[Guestbook](guestbook/) | PHP app with Redis | Replication Controller, Service | Beginner | |[WordPress](mysql-wordpress-pd/) | WordPress with MySQL | Deployment, Persistent Volume with Claim | Beginner| |[Cassandra](storage/cassandra/) | Cloud Native Cassandra | Daemon Set | Intermediate </ins> <del> Note: Please add examples to the list above that are maintained. </del> <ins> * Note: Please add examples to the list above that are maintained. </ins> See [Example Guidelines](guidelines.md) for a description of what goes in this directory, and what examples should contain.
Change:
Fluentd-elastcisearch sends logs to an Elasticsearch installation inside the cluster. It uses ES service to access, so it doesn't work on master, because there's no kube-proxy on master. Because of that, introducing master toleration to in was unnecessary.

Discussion:
readOnly: true nodeSelector: beta.kubernetes.io/fluentd-ds-ready: "true" <del> tolerations: - key : "node.alpha.kubernetes.io/ismaster" effect: "NoSchedule" </del> terminationGracePeriodSeconds: 30 volumes: - name: varlog

sed -i -e "s@{{ *pillar['cluster_registry_disk_size'] *}}@${CLUSTER_REGISTRY_DISK_SIZE}@g" "${registry_pvc_file}" sed -i -e "s@{{ *pillar['cluster_registry_disk_name'] *}}@${CLUSTER_REGISTRY_DISK}@g" "${registry_pvc_file}" fi <del> # TODO(piosz): figure out how to not run fluentd-es pod from fluentd daemon set on master. #              Running fluentd-es on the master is pointless, as it can't communicate #              with elasticsearch from there in the default configuration. </del> if [[ "${ENABLE_NODE_LOGGING:-}" == "true" ]] &&  [[ "${LOGGING_DESTINATION:-}" == "elasticsearch" ]] &&  [[ "${ENABLE_CLUSTER_LOGGING:-}" == "true" ]]; then
Change:
Flaked three times today in gci-gce, likely caused by https://k8s-

Discussion:
status = d.Status if d.Status.UpdatedReplicas > 0 && d.Status.Replicas != d.Status.UpdatedReplicas { <ins> _, allOldRSs, err := deploymentutil.GetOldReplicaSets(d, c) newRS, nerr := deploymentutil.GetNewReplicaSet(d, c) if err == nil && nerr == nil { Logf("%+v", d) logReplicaSetsOfDeployment(d, allOldRSs, newRS) logPodsOfDeployment(c, d, append(allOldRSs, newRS), false) } </ins> return false, fmt.Errorf("deployment %q is running new pods alongside old pods: %#v", d.Name, status) }
Change:
Flaked three times today in gci-gce, likely caused by https://k8s-

Discussion:
It("RollingUpdateDeployment should delete old pods and create new ones", func() { testRollingUpdateDeployment(f) }) <del> It("RecreateDeployment should delete old pods and create new ones", func() { </del> <ins> It("RecreateDeployment should delete old pods and create new ones [Flaky]", func() { </ins> testRecreateDeployment(f) }) It("deployment should delete old replica sets", func() {
Change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? No What keywords did you search in Kubernetes issues before filing this one? SNI Cert Key order Is this a BUG REPORT or FEATURE REQUEST? Bug Report Kubernetes version 1.6 Environment: (irrelevant but still) Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS 1298.7.0 Kernel (e.g. ): 4.9.16-coreos-r1 Install tools: downloaded and installed k8s directly What happened: According to the api server docs at (and still consistent in latest source): The examples all show the key before the certificate file, and it is called "multiple key/certificate pairs". However, the API server actually requires the key after the certificate per Anything else we need to know: Quite confusing. Please update the docs to be correct.
Updated the title. It also is backwards for the -separated order of domains vs cert-key pairs. According to , the keycert is and the domains are , but the docs say "suffixed" followed by examples of the domain before_ the keycert pair::

Discussion:
"extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns "+ "trump over extracted names. For multiple key/certificate pairs, use the "+ "--tls-sni-cert-key multiple times. "+ <del> "Examples: "example.key,example.crt" or "*.foo.com,foo.com:foo.key,foo.crt".") </del> <ins> "Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".") </ins> } func (s *SecureServingOptions) AddDeprecatedFlags(fs *pflag.FlagSet) {