jiebi/CodeConvo huggingface dataset:
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: With the recent change to the way admission control plugins are handled the generated documentation doesn't provide a list of plugins that are enabled: REF: What you expected to happen: I expected to be able to determine what admission plugins are enabled on the apiserver. With the default enabled plugins enumerated I can determine that by evaluating the list against the explicitly and and admission control plugins. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : </details
/cc
/assign

Discussion:
} fs.StringSliceVar(&a.EnablePlugins, "enable-admission-plugins", a.EnablePlugins, ""+ <del> "admission plugins that should be enabled in addition to default enabled ones. "+ </del> <ins> "admission plugins that should be enabled in addition to default enabled ones ("+ strings.Join(a.defaultEnabledPluginNames(), ", ")+"). "+ </ins> "Comma-delimited list of admission plugins: "+strings.Join(a.Plugins.Registered(), ", ")+". "+ "The order of plugins in this flag does not matter.") fs.StringSliceVar(&a.DisablePlugins, "disable-admission-plugins", a.DisablePlugins, ""+ <del> "admission plugins that should be disabled although they are in the default enabled plugins list. "+ </del> <ins> "admission plugins that should be disabled although they are in the default enabled plugins list ("+ strings.Join(a.defaultEnabledPluginNames(), ", ")+"). "+ </ins> "Comma-delimited list of admission plugins: "+strings.Join(a.Plugins.Registered(), ", ")+". "+ "The order of plugins in this flag does not matter.") fs.StringVar(&a.ConfigFile, "admission-control-config-file", a.ConfigFile,

return orderedPlugins } <ins> //Return names of plugins which are enabled by default func (a *AdmissionOptions) defaultEnabledPluginNames() []string { defaultOnPluginNames := []string{} for _, pluginName := range a.RecommendedPluginOrder { if !a.DefaultOffPlugins.Has(pluginName) { defaultOnPluginNames = append(defaultOnPluginNames, pluginName) } } return defaultOnPluginNames } </ins>
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: AWS dynamic provisioner fail to provision PV, if fsType is specified in storageClass parameters What you expected to happen: AWS dynamic provisioner provision PV successfully. How to reproduce it (as minimally and precisely as possible): Set fsType in storageClass for AWS provisioner and create PVC for it. Also, see log for pull-kubernetes-e2e-kops-aws in below PR for e2e. failed with below error: Anything else we need to know?: /sig storage It seems that below commit affects this issue. Environment: Kubernetes version (use ): k8s v1.12 alpha Cloud provider or hardware configuration: AWS Install tools: e2e test

Discussion:
} case "kmskeyid": volumeOptions.KmsKeyId = v <ins> case volume.VolumeParameterFSType: // Do nothing but don't make this fail </ins> default: return nil, fmt.Errorf("invalid option %q for volume plugin %s", k, pluginName) }
Change:
Add test for "on PVC add", see Test for "on PVC update" is not needed, because it has already been tested in all volume scheduling tests.
/sig
docs:

Discussion:
classWait      = "wait" classImmediate = "immediate" <ins> sharedClasses = map[storagev1.VolumeBindingMode]*storagev1.StorageClass{ modeImmediate: makeStorageClass(classImmediate, &modeImmediate), modeWait:      makeStorageClass(classWait, &modeWait), } </ins> ) const (

cases := map[string]struct { pod        *v1.Pod pvcs       []*testPVC <ins> pvs        []*testPV </ins> trigger    func(config *testConfig) shouldFail bool }{

}, shouldFail: false, }, <del> // TODO test rescheduling on PVC add/update </del> <ins> "reschedule on delay binding PVC add": { pod: makePod("pod-reschedule-onpvcadd", config.ns, []string{"pvc-reschedule-onpvcadd"}), pvs: []*testPV{ { name:   "pv-reschedule-onpvcadd", scMode: modeWait, node:   node1, }, }, trigger: func(config *testConfig) { pvc := makePVC("pvc-reschedule-onpvcadd", config.ns, &classWait, "") if _, err := config.client.CoreV1().PersistentVolumeClaims(config.ns).Create(pvc); err != nil { t.Fatalf("Failed to create PersistentVolumeClaim %q: %v", pvc.Name, err) } }, shouldFail: false, }, </ins> } for name, test := range cases {

} } <ins> // Create PVs for _, pvConfig := range test.pvs { pv := makePV(pvConfig.name, sharedClasses[pvConfig.scMode].Name, pvConfig.preboundPVC, config.ns, pvConfig.node) if _, err := config.client.CoreV1().PersistentVolumes().Create(pv); err != nil { t.Fatalf("Failed to create PersistentVolume %q: %v", pv.Name, err) } } </ins> // Create pod if _, err := config.client.CoreV1().Pods(config.ns).Create(test.pod); err != nil { t.Fatalf("Failed to create Pod %q: %v", test.pod.Name, err)

} // Create SCs <del> scs := []*storagev1.StorageClass{ makeStorageClass(classImmediate, &modeImmediate), makeStorageClass(classWait, &modeWait), } for _, sc := range scs { </del> <ins> for _, sc := range sharedClasses { </ins> if _, err := clientset.StorageV1().StorageClasses().Create(sc); err != nil { t.Fatalf("Failed to create StorageClass %q: %v", sc.Name, err) }
Change:
https://k8s- /sig apps /priority critical-urgent /assign PR that the test: /cc
GitHub didn't allow me to assign the following users: mortent. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : https://k8s- /priority critical-urgent /assign /cc 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
/kind flake
I'm looking into this.
The test is still flaky, but with different symptom: An example flake: https://k8s- It's likely because the collision count was updated in a previous sync loop, but the in the cache store hasn't been updated and we used a stale collision count while calculating the new hash: /assign

Discussion:
"//staging/src/k8s.io/client-go/rest:go_default_library", "//staging/src/k8s.io/client-go/tools/cache:go_default_library", "//staging/src/k8s.io/client-go/tools/record:go_default_library", <ins> "//staging/src/k8s.io/client-go/util/retry:go_default_library", </ins> "//test/integration/framework:go_default_library", ], )

"k8s.io/kubernetes/pkg/scheduler/factory" labelsutil "k8s.io/kubernetes/pkg/util/labels" "k8s.io/kubernetes/pkg/util/metrics" <ins> "k8s.io/kubernetes/staging/src/k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/test/integration/framework" )

} } <ins> func updateDS(t *testing.T, dsClient appstyped.DaemonSetInterface, dsName string, updateFunc func(*apps.DaemonSet)) *apps.DaemonSet { var ds *apps.DaemonSet if err := retry.RetryOnConflict(retry.DefaultBackoff, func() error { newDS, err := dsClient.Get(dsName, metav1.GetOptions{}) if err != nil { return err } updateFunc(newDS) ds, err = dsClient.Update(newDS) return err }); err != nil { t.Fatalf("Failed to update DaemonSet: %v", err) } return ds } </ins> func forEachFeatureGate(t *testing.T, tf func(t *testing.T)) { for _, fg := range featureGates() { func() {

// Wait for the DaemonSet to be created before proceeding err = waitForDaemonSetAndControllerRevisionCreated(clientset, ds.Name, ds.Namespace) if err != nil { <del> t.Fatalf("Failed to create DeamonSet: %v", err) </del> <ins> t.Fatalf("Failed to create DaemonSet: %v", err) </ins> } ds, err = dsClient.Get(ds.Name, metav1.GetOptions{})

// Make an update of the DaemonSet which we know will create a hash collision when // the next ControllerRevision is created. <del> _, err = dsClient.Update(ds) if err != nil { t.Fatalf("Failed to update DaemonSet: %v", err) } </del> <ins> ds = updateDS(t, dsClient, ds.Name, func(updateDS *apps.DaemonSet) { updateDS.Spec.Template.Spec.TerminationGracePeriodSeconds = &one }) </ins> // Wait for any pod with the latest Spec to exist err = wait.PollImmediate(100*time.Millisecond, 10*time.Second, func() (bool, error) {
Change:
https://k8s- /sig apps /priority critical-urgent /assign PR that the test: /cc
GitHub didn't allow me to assign the following users: mortent. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : https://k8s- /priority critical-urgent /assign /cc 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
/kind flake
I'm looking into this.
The test is still flaky, but with different symptom: An example flake: https://k8s- It's likely because the collision count was updated in a previous sync loop, but the in the cache store hasn't been updated and we used a stale collision count while calculating the new hash: /assign

Discussion:
import ( "bytes" "fmt" <ins> "reflect" </ins> "sort" "github.com/golang/glog"

} // Handle name collisions between different history <del> // TODO: Is it okay to get from dsLister? </del> <ins> // Get the latest DaemonSet from the API server to make sure collision count is only increased when necessary </ins> currDS, getErr := dsc.kubeClient.ExtensionsV1beta1().DaemonSets(ds.Namespace).Get(ds.Name, metav1.GetOptions{}) if getErr != nil { return nil, getErr } <ins> // If the collision count used to compute hash was in fact stale, there's no need to bump collision count; retry again if !reflect.DeepEqual(currDS.Status.CollisionCount, ds.Status.CollisionCount) { return nil, fmt.Errorf("found a stale collision count (%d, expected %d) of DaemonSet %q while processing; will retry until it is updated", ds.Status.CollisionCount, currDS.Status.CollisionCount, ds.Name) } </ins> if currDS.Status.CollisionCount == nil { currDS.Status.CollisionCount = new(int32) }
Change:
<!-- This form is for bug reports ! If you're looking for help check and the . If the matter is security related, please disclose it privately via --What happened: Unable to spin up cluster using the kubetest, with 'ci/latest' image. The CI jobs are failing, because the cluster is not provisioned properly. I have tried locally, i am still getting the same error. Could be releated to this PR /cc
is your kubernetes checkout in ? the one in that CI image is a bit odd actually. cc
ohhh this is not good, kubetest --extract will of course not extract over your $GOPATH, but will then use the cluster/* scripts :man_facepalming:
i use kubetest directly, it extracts the image given in the --extract arg.
Yes
This is the full o/p from my local run.
PR sent in
I am also getting this error. My k8s is at and command that i am using is:
This should be fixed now by a revert in , sorry about that. We'll follow up with something better soon.

Discussion:
#  CFSSLJSON_BIN: The path of the installed cfssljson binary # function kube::util::ensure-cfssl { <del> echo "Installing cfssl from vendor" GOBIN="${KUBE_OUTPUT_BINPATH:-}" go install k8s.io/kubernetes/vendor/github.com/cloudflare/cfssl/cmd/cfssl GOBIN="${KUBE_OUTPUT_BINPATH:-}" go install k8s.io/kubernetes/vendor/github.com/cloudflare/cfssl/cmd/cfssljson CFSSL_BIN="$(PATH="${KUBE_OUTPUT_BINPATH:-}:${PATH}" command -v cfssl)" CFSSLJSON_BIN="$(PATH="${KUBE_OUTPUT_BINPATH:-}:${PATH}" command -v cfssljson)" if [[ ! -x ${CFSSL_BIN} || ! -x ${CFSSLJSON_BIN} ]]; then echo "Failed to install cfssl." >&2 exit 1 </del> <ins> if command -v cfssl &>/dev/null && command -v cfssljson &>/dev/null; then CFSSL_BIN=$(command -v cfssl) CFSSLJSON_BIN=$(command -v cfssljson) return 0 fi # Create a temp dir for cfssl if no directory was given local cfssldir=${1:-} if [[ -z "${cfssldir}" ]]; then kube::util::ensure-temp-dir cfssldir="${KUBE_TEMP}/cfssl" </ins> fi <ins> mkdir -p "${cfssldir}" pushd "${cfssldir}" > /dev/null echo "Unable to successfully run 'cfssl' from $PATH; downloading instead..." kernel=$(uname -s) case "${kernel}" in Linux) curl --retry 10 -L -o cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 curl --retry 10 -L -o cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 ;; Darwin) curl --retry 10 -L -o cfssl https://pkg.cfssl.org/R1.2/cfssl_darwin-amd64 curl --retry 10 -L -o cfssljson https://pkg.cfssl.org/R1.2/cfssljson_darwin-amd64 ;; *) echo "Unknown, unsupported platform: ${kernel}." >&2 echo "Supported platforms: Linux, Darwin." >&2 exit 2 esac chmod +x cfssl || true chmod +x cfssljson || true CFSSL_BIN="${cfssldir}/cfssl" CFSSLJSON_BIN="${cfssldir}/cfssljson" if [[ ! -x ${CFSSL_BIN} || ! -x ${CFSSLJSON_BIN} ]]; then echo "Failed to download 'cfssl'. Please install cfssl and cfssljson and verify they are in $PATH." echo "Hint: export PATH=$PATH:$GOPATH/bin; go get -u github.com/cloudflare/cfssl/cmd/..." exit 1 fi popd > /dev/null </ins> } # kube::util::ensure_dockerized
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When I start the apiserver, found apiserver crased due to the priority class already exists. 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 ): 1.11.1 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
/sig api-machinery
hi do you happen to have multiple apiservers start at the same time?
yes, I have a HA environment which have 3 apiserver.
sadly, it's the racing then. might launch your servers one-by-one to avoid it for now.
/sig scheduling /priority important-soon
I think is working on PR . As mentioned, following change should be able to fix this:
Yes, and should be picked to release branches once complete
fixed it in as said. Thanks
FWIW, this is a "me too" for a multi-master environment. I've set up a sync-based start-up to prevent multiple API server processes from launching at the same time. Thanks for the fix!

Discussion:
if err != nil { if apierrors.IsNotFound(err) { _, err := schedClientSet.PriorityClasses().Create(pc) <del> if err != nil { </del> <ins> if err != nil && !apierrors.IsAlreadyExists(err) { </ins> return false, err } else { glog.Infof("created PriorityClass %s with value %v", pc.Name, pc.Value)
Change:
It started happening on 2018-08-16: https://k8s- https://k8s- https://k8s- /assign /cc /sig scalability I see that before this happens kubelet was able to successfully print all nodes in ready state. Also in kube- I can't see any 'GET /api/v1/nodes' call around that time which suggests that this is rather problem with out test infrastructure or networking than issue with nodes really being not ready that time. I see that GetMasterAndWorkerNodesOrDie never dies and ignores an error returning empty array in case of call error:
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:
func GetMasterAndWorkerNodesOrDie(c clientset.Interface) (sets.String, *v1.NodeList) { nodes := &v1.NodeList{} masters := sets.NewString() <del> all, _ := c.CoreV1().Nodes().List(metav1.ListOptions{}) </del> <ins> all, err := c.CoreV1().Nodes().List(metav1.ListOptions{}) ExpectNoError(err) </ins> for _, n := range all.Items { if system.IsMasterNode(n.Name) { masters.Insert(n.Name)
Change:
/kind failing-test /priority critical-urgent /sig network /milestone v1.12 /cc
ping
Also failures on
TLS errors connection refused 503 service unavailable especially around metrics and healthz in ways that make me suspect things didn't start correctly. Or perhaps API mismatch? /cc 've looked at some similar failures in the past. Any chance you might give a look over this and ?
in both and here looks like api mismatch?
Test output shows no DNS server can be reached, but logs say coredns pods are running (https://k8s-): cc
The CoreDNS configmap is incorrectly configured and hence the test fails. I'm working on the fix.
/assign
, , Does it make sense to keep that e2e test ?, knowing that this test is specific for "Federation" and that federation has now merged into "multicluster" and removed all e2e tests about "Federation + Serial" (formerly "ci-federation-e2e-gce-serial") : can you say if that use case is still supported in kubernetes v1.12 ?
I can say that Federation v1 has not been exercised since v1.10. I think a good question for the Federation v2 folks is not only whether they still need the tests, but also whether they need the configmap support specific to what Federation v1 used -- I'll defer to
If ya'll decide the use case is no longer valid, please open an issue / remove the test once 1.13 release opens.
tests are failing
/reopen /cc
Reopening this issue. <detailsIn response to : /reopen /cc 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
More failures:
Looks like this is failing since Kube-dns is now enabled.
Since we'd previously discussed this not being a relevant test case, and it seems less appropriate even if it's this coupled to the dns implementation and we've got the kube-dns to coredns transition happening in the next release most likely....Can we just disable/remove the test?
Opened to disable this test.
Thank you!

Discussion:
moreForeverTestTimeout = 2 * 60 * time.Second ) <del> var _ = SIGDescribe("DNS configMap federations", func() { </del> <ins> var _ = SIGDescribe("DNS configMap federations [Feature:Federation]", func() { </ins> t := &dnsFederationsConfigMapTest{dnsTestCommon: newDnsTestCommon()}
Change:
We should add a watch test that: a watch a background thread, makes a bunch of random changes the RV from the first item received by the watch. each subsequent item X, open a new watch at the previous RV and verify that the first thing received matches X. Record X's RV for the next iteration. /sig api-machinery
cc
/assign cc
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
/area conformance
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
A test for this was via , we just need to promote it to be a conformance test

Discussion:
test/e2e/apimachinery/watch.go: "should be able to start watching from a specific resource version" test/e2e/apimachinery/watch.go: "should be able to restart watching from the last resource version observed by the previous watch" test/e2e/apimachinery/watch.go: "should observe an object deletion if it stops meeting the requirements of the selector" <ins> test/e2e/apimachinery/watch.go: "should receive events on concurrent watches in same order" </ins> test/e2e/apps/daemon_set.go: "should run and stop simple daemon" test/e2e/apps/daemon_set.go: "should run and stop complex daemon" test/e2e/apps/daemon_set.go: "should retry creating failed daemon pods"

/* Testname: watch-consistency <ins> Release : v1.15 </ins> Description: Ensure that concurrent watches are consistent with each other by initiating an additional watch for events received from the first watch, initiated at the resource version of the event, and checking that all resource versions of all events match. Events are produced from writes on a background goroutine. */ <del> It("should receive events on concurrent watches in same order", func() { </del> <ins> framework.ConformanceIt("should receive events on concurrent watches in same order", func() { </ins> c := f.ClientSet ns := f.Namespace.Name
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I am using Persistent Local Volumes. The mountpoints for it are set up with 0700 permissions. When running a pod with a user other than root, and with fsGroup to allow access to the volume, the permissions are wrong and the pod cannot use the volume. The permissions are changed from 0700 to 2760. What you expected to happen: fsGroup makes the volume usable for the group by setting the permissions to 2770. How to reproduce it (as minimally and precisely as possible): You need a cluster with local volumes whose permissions are set to 0700. pv-permission- As you can see, the permissions are 2760. Since the execute bit is missing for the group, the directory cannot be used. Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.2 Cloud provider or hardware configuration: libvirt/QEMU OS (e.g. from /etc/os-release): CentOS Linux release 7.5.1804 (Core) Kernel (e.g. ): 3.10.0-862.11.6.el7.x8664 SMP Tue Aug 14 21:49:04 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Others:
/sig storage
The fix is probably to add execute bits here
do you see any problem with setting group execute for fsgroup?
I think that execute should be fine.
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

Discussion:
) const ( <del> rwMask = os.FileMode(0660) roMask = os.FileMode(0440) </del> <ins> rwMask   = os.FileMode(0660) roMask   = os.FileMode(0440) execMask = os.FileMode(0110) </ins> ) // SetVolumeOwnership modifies the given volume to be owned by

if info.IsDir() { mask |= os.ModeSetgid <ins> mask |= execMask </ins> } err = os.Chmod(path, info.Mode()|mask)