jiebi/CodeConvo huggingface dataset:
Change:
supports:   false, queryParam: QueryParamFieldValidation, }, <ins> { gvk: schema.GroupVersionKind{ Group:   "", Version: "v1", Kind:    "List", }, success:    false, supports:   false, queryParam: QueryParamFieldValidation, }, </ins> } for _, test := range tests {

Discussion:
kubectl apply performs validation before the apply. Non-CRD resources (e.g. pods / deployments) don't need CRD schema for validation, but if we use resource, kubectl calls . In my Kubernetes cluster, administrator doesn't allow users to list CRDs, so user cannot apply non-CRD resources (e.g. pods / deployments) with resource. doesn't happen because we're going to apply two Deployments. should not happen because we're going to apply two Deployments. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted /assign
/priority backlog
Change:
} fs.IPVar(&s.BindAddress, "address", s.BindAddress, <del> "DEPRECATED: see --bind-address instead.") </del> <ins> "The IP address on which to serve the insecure --port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).") </ins> fs.MarkDeprecated("address", "see --bind-address instead.") <ins> fs.Lookup("address").Hidden = false </ins> <del> fs.IntVar(&s.BindPort, "port", s.BindPort, "DEPRECATED: see --secure-port instead.") </del> <ins> fs.IntVar(&s.BindPort, "port", s.BindPort, "The port on which to serve unsecured, unauthenticated access. Set to 0 to disable.") </ins> fs.MarkDeprecated("port", "see --secure-port instead.") <ins> fs.Lookup("port").Hidden = false </ins> } // ApplyTo adds DeprecatedInsecureServingOptions to the insecureserverinfo amd kube-controller manager configuration.

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: kube-controller-manager starts but listens insecurely on IPv6, even if --secure-port and --bind-address is set What you expected to happen: kube-controller-manager just listens securely when settings are provided How to reproduce it (as minimally and precisely as possible): Start a cluster on v1.12.0 and set the systemd as follows: <pre<code--bind-address=127.0.0.1  --kubeconfig=/REDACTED/controller-manager.kubeconfig  --cluster-cidr=your-pod-cidr  --cluster-name=clustername  --cluster-signing-cert-  --cluster-signing-key-  --controllers=*,bootstrapsigner,tokencleaner  --leader-elect=true  --profiling=false  --root-ca-  --service-account-private-key-  --service-cluster-ip-range=your-svc-cidr  --use-service-account-credentials=true  --secure-port=  --v=2</code</preAnything else we need to know?: --kubeconfig is deprecated but the binary does not start without it --authorization-kubeconfig is documented where? (I cannot find it in the docs, maybe my fault) the cluster bootstraps correctly and network (weave) + dns (coredns) is working scheduling of pods work csr of nodes get approved and issued Environment: Kubernetes version (use ): 1.12.0 Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 18.04.01 LTS Kernel (e.g. ): 4.15.0-34-generic Install tools: self-made (Kelseys Hard-Way guide) Others: <!-- DO NOT EDIT BELOW THIS LINE --/area controller-manager /sig cluster-lifecycle
you must set to disable insecure serving. unfortunately, the help text telling you this is hidden because the flag is marked as deprecated. opened to fix this and will pick to 1.13.x / 1.12.x
Change:
} 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) }

Discussion:
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
Change:
local platform_tag=${platform///-} # Replace a "/" for a "-" echo "+++ Building tarball: server $platform_tag" <del> local release_stage="${LOCAL_OUTPUT_ROOT}/release-stage/server/${platform_tag}/kubernetes" </del> <ins> local release_stage="${RELEASE_STAGE}/server/${platform_tag}/kubernetes" </ins> rm -rf "${release_stage}" mkdir -p "${release_stage}/server/bin"

Discussion:
Sometimes it is nice to have non-tar'd binaries for releases. We should upload those along with the our packaged tarballs. This will help fix
Change:
"github.com/onsi/ginkgo" "github.com/onsi/ginkgo/config" "github.com/onsi/ginkgo/reporters" <ins> "github.com/onsi/ginkgo/types" </ins> "github.com/onsi/gomega" )

Discussion:
We need to be able to diagnose e2e test failures after the relevant test cluster has been shut down. Right now this almost works, but not quite. Fluentd can currently only be configured to send log files to one place, for example: Cloud Logging, or (running as a pod in the e2e test cluster, and saved to local disk on the node). With the current configuration in , logs typically go to ElasticSearch (and there is an e2e test to check that that works correctly), and tears down the e2e test cluster after each test run, so the logs are deleted. The proposed solution is to have fluentd configurable to send to multiple log collector backends, and configure it as such to both Google Cloud Logging and ElasticSearch for CI e2e test runs to facilitate easier debugging. Satnam6502@ has offered to sort this out.
Originally it was possible to send logs to both Elasticsearch and Cloud Logging but at some point this got made into a binary choice of one or the other (by or ?). I propose to undo this unless there are strong objections. : what do you think?
I didn't turn it into a binary choice. :) , Satnam Singh wrote:
Yeah, pretty sure it was Joe. I am sure it was a wide decision at the time.
Would be nice to have these at maximum verbosity because when we need them we need them all, IIRC we currently only get V(2) on a kube-up cluster
I see this is marked as a post v1.0 milestone? If we don't want this urgently then I will un-assign myself for now.
There is a valid argument that we would not block the 1.0 release for lack of these persisted test logs, and hence the v1.0 milestone was tentatively removed. There is a counter argument that we stand little chance of being able to debug the existing and still-to-be-found flaky test failures in the absence of log files, and that one or more of those bugs, if not fixed, will block the launch anyway. I'd say that if there is nothing on the v1.0 milestone that you can sensibly work on, this one is fair game.

I would find it useful, and I suppose this should be on par with writing tests (of which we have a few 1.0: )
I'm not sure we'll be able to convince folks to move this to 1.0, but feel free to work on this, as it seems very valuable.
I thought about changing our setup to allow both Elasticsearch and Cloud Logging to be targeted. I've been a little hesitant because this could lead to a breakage (esp. for GKE) and we are getting close to 1.0 ...
/cc who might have memories about a GKE breakage caused by changes in env vars used for logging.
I'd love to see this fixed soon to help debug flakes, but yes, it'd be nice to at least be cc'ed on env var changes.
Try again to have it to the high priority list, as this is making debugging the system very difficult. cc Who expressed interest.
How do we access those logs? I tried to find them for gce-scalability jenkins suite, but didn't find it.
Change:
if utilfeature.DefaultFeatureGate.Enabled(features.ConsistentHTTPGetHandlers) { legacyregistry.MustRegister(LifecycleHandlerHTTPFallbacks) } <ins> if utilfeature.DefaultFeatureGate.Enabled(features.CPUManager) { legacyregistry.MustRegister(CPUManagerPinningRequestsTotal) legacyregistry.MustRegister(CPUManagerPinningErrorsTotal) } </ins> }) }

Discussion:
Add to enable observability of the cpumanager. This is required to but it's also useful in general. To the best of my knowledge, it's very hard to observe the behavior of cpumanager without peeking into the pod and/or use the podresources interface (kubelet = 1.24). But even for the latter, no well known components expose metrics consuming this information. I believe anyway kubelet some expose some basic metrics about cpumanager behaviour, while deferring more fine grained metrics to external components (NFD, node_exporter, is fine)
/sig node /assign
/triage accepted /priority important-soon (as this is important for graduation for CPU Manager to GA)
Change:
StorageClassName: &validClassName, }), }, <ins> "invalid-claim-zero-capacity": { isExpectedFailure: true, claim: testVolumeClaim("foo", "ns", core.PersistentVolumeClaimSpec{ Selector: &metav1.LabelSelector{ MatchExpressions: []metav1.LabelSelectorRequirement{ { Key:      "key2", Operator: "Exists", }, }, }, AccessModes: []core.PersistentVolumeAccessMode{ core.ReadWriteOnce, core.ReadOnlyMany, }, Resources: core.ResourceRequirements{ Requests: core.ResourceList{ core.ResourceName(core.ResourceStorage): resource.MustParse("0G"), }, }, StorageClassName: &validClassName, }), }, </ins> "invalid-label-selector": { isExpectedFailure: true, claim: testVolumeClaim("foo", "ns", core.PersistentVolumeClaimSpec{

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: If someone requests a zero (0) capacity PVC and an administrator creates a zero (0) capacity PV, Kubernetes will happily bind them together. Unfortunately, any use of this PVC/PV combination by a pod will fail. It fails because the zero capacity PV cannot be formatted or mounted successfully. Note: The same issue happens for dynamically provisioned PVs. What you expected to happen: I expect that Kubernetes would not allow creation of invalid PVC and PV objects, aka zero (0) capacity PVs and PVCs. How to reproduce it (as minimally and precisely as possible): Create a pod that requests a zero capacity PVC, using dynamic PV provisioning is simpler than creating your own zero (0) capacity PV. The pod will fail to reach a running state, since the related PV fails to be formatted and mounted successfully. Here is the error that I received for a test I performed requesting a zero capacity PVC using ceph rbd: Anything else we need to know?: Here is a related item with a specific fix for external ceph rbd provisioner: Environment: Nothing specific to environment
/sig storage
/assign
Change:
} ``` <del> This time the label query for the service is 'name=redis-slave' </del> <ins> This time the label query for the service is 'name=redis-slave'. </ins> Now that you have created the service specification, create it in your cluster with the cloudcfg cli:

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: The image () used to run the per-pod infra/pause container logs to stdout about once per second. What you expected to happen: Pause container not logging anything. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet does not expose, nor manage these logs. Writing the logs wastes resources and takes up disk space, which may not be properly accounted by kubelet. The pause image used for the e2e tests seems much better: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign Will also rebuild with
Change:
// GVK is the associated GVK GVK schema.GroupVersionKind // Issues contain machine-readable information about the typechecking result. <del> Issues *cel.Issues </del> <ins> Issues error </ins> // Err is the possible error that was encounter during type checking. Err error }

Discussion:
When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted
Change:
ServiceNodePortRange:   kubeoptions.DefaultServiceNodePortRange, ServiceClusterIPRange:  kubeoptions.DefaultServiceIPCIDR, MasterCount:            5, <del> EndpointReconcilerType: string(reconcilers.MasterCountReconcilerType), </del> <ins> EndpointReconcilerType: string(reconcilers.LeaseEndpointReconcilerType), </ins> AllowPrivileged:        false, GenericServerRunOptions: &apiserveroptions.ServerRunOptions{ AdvertiseAddress:            net.ParseIP("192.168.10.10"),

Discussion:
ref: and An e2e test should be , and the default should be updated. /assign cc
/assign
Thanks I can take this on.
Could someone point me to where the manifests are for the e2e test suites, I am happy to submit the patches?
Are there API server e2e tests currently?
there are not HA API server e2e tests that I'm aware of
I opened a PR for the default changes. Are there suggestions on a good E2E test to write if we don't have HA API server tests?
what is needed for this issue to complete? Do you think you'll get that by Monday, which is Code Freeze?
We need some E2E testing or add an integration test as defined . It will not be done today.
so are you planning to move it to 1.11, then? It's about to be automatically kicked out of 1.10 by automation.
I do not have permission to change the milestone. If you could kindly change it, that would be awesome!
[MILESTONENOTIFIER] Milestone Removed From Issue Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Reopening as this was reverted in
Change:
panicked <- true } }() s.AddUnversionedTypes(gv, &InternalSimple{}) <ins> // redefine InternalSimple with the same name, but obviously as a different type type InternalSimple struct { EmbeddableTypeMeta `json:",inline"` TestString         string `json:"testString"` } </ins> s.AddUnversionedTypes(gv, &InternalSimple{}) panicked <- false }()

Discussion:
We have moved to non-global schema in a number of places in 1.6 and 1.7. It is easy to forget registering the unversioned types like , leading to encoding errors in error cases. The registration of the unversioned types should be automatic as for the types, i.e. in .
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
do we need to close out this issue? (since referenced PR has merged)
Fixed by
Change:
func NewRunOptions(streams genericclioptions.IOStreams) *RunOptions { return &RunOptions{ PrintFlags:  genericclioptions.NewPrintFlags("created").WithTypeSetter(scheme.Scheme), <del> DeleteFlags: cmddelete.NewDeleteFlags("to use to replace the resource."), </del> RecordFlags: genericclioptions.NewRecordFlags(), Recorder: genericclioptions.NoopRecorder{},

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/triage accepted
Change:
return dataItems } <del> func collectHistogram(metric string, labels map[string]string) *DataItem { hist, err := testutil.GetHistogramFromGatherer(legacyregistry.DefaultGatherer, metric) </del> <ins> func collectHistogramVec(metric string, labels map[string]string) *DataItem { vec, err := testutil.GetHistogramVecFromGatherer(legacyregistry.DefaultGatherer, metric, nil) </ins> if err != nil { klog.Error(err) return nil } <del> if hist.Histogram == nil { klog.Errorf("metric %q is not a Histogram metric", metric) return nil } if err := hist.Validate(); err != nil { </del> <ins> if err := vec.Validate(); err != nil { </ins> klog.Error(err) return nil } <del> q50 := hist.Quantile(0.50) q90 := hist.Quantile(0.90) q95 := hist.Quantile(0.95) q99 := hist.Quantile(0.99) avg := hist.Average() </del> <ins> q50 := vec.Quantile(0.50) q90 := vec.Quantile(0.90) q95 := vec.Quantile(0.95) q99 := vec.Quantile(0.99) avg := vec.Average() </ins> msFactor := float64(time.Second) / float64(time.Millisecond)

Discussion:
The new scheduler performance test was introduced back in 1.18, back then, the metric it supported are all . However, along with , some metrics are updated to be , and hence it's no longer appropriate to return the first Histogram: However, it's very common (for instance Preemption) that the metrics may hold multiple histograms: Additionally, metrics and have been removed, we should update them to : /sig scheduling
/triage accepted /assign
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
"//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1/validation:go_default_library", "//vendor/k8s.io/apimachinery/pkg/labels:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/util/validation:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/validation/field:go_default_library", ], )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We have some cron jobs with longish names (~60 characters), and noticed that the corresponding jobs weren't being created by the cronjob controller because the name was too long. Here's what happened: There's a 63-character limit on job names (because for some reason on job creation the name gets copied into a label, where the limit is 63 chars). For example, if I try to create a job with a long name, I get the error message: By itself, this is fine. I can just make a job with a shorter name. However! If I create a cron job, the cron job controller will create jobs named . So the job's name is 11 characters longer than the job name. This means that if I create a cron job with a 63-character name, it'll result in a job name that's 74 characters, which the API will refuse to accept. This means the cron job never gets scheduled. Some possible resolutions: validation on cron job creation that refuses to let you create jobs with names 52 characters the cron job controller truncate cronjobs names remove the 63-character limit on job names (this seems difficult) There's actually a deeper problem here at play: Kubernetes' resource name limit is 253 characters. But the limit for resouce labels is 63 characters. So when a job is created, the name (which is allowed to be up to 255 chars) gets copied into a label, which has a lower limit. So the job creation fails. (these are the ) What you expected to happen: When I create a cron job, I expect it to either to create the cron job, or jobs correctly from that cron job How to reproduce it (as minimally and precisely as possible): a cronjob with a name that's more than 52 characters that it does not schedule jobs, with an error message like Anything else we need to know?: Kubernetes version: 1.7.3 Cloud provider: AWS OS: Ubuntu 16.04 Kernel: 4.4.0 example of a job definition with a long name This job definition is invalid:
There are no sig labels on this issue.

Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig apps
cc
Change:
type Config struct { NS                  string PVCs                []*v1.PersistentVolumeClaim <ins> PVCsReadOnly        bool </ins> InlineVolumeSources []*v1.VolumeSource IsPrivileged        bool Command             string

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.