jiebi/CodeConvo huggingface dataset:
Change:
I'm seeing a large number of unique prometheus series showing up (due to the logging we for anonymous reflectors). This is a small cluster but I believe this may have unbounded cardinality.
we storing the resource version in the metric name?
cc
Came into the same problem, checked the code, seems we use + + as metric names, for most reflector, they use a default name provided by which is go filename. I think the proper way is use as the metric name, and add a label, like
opened a pr to fix this, ptal thanks :)

Discussion:
Name:      "items_per_watch", Help:      "How many items an API watch returns to the reflectors", }, []string{"name"}) <ins> lastResourceVersion = prometheus.NewGaugeVec(prometheus.GaugeOpts{ Subsystem: reflectorSubsystem, Name:      "last_resource_version", Help:      "Last resource version seen for the reflectors", }, []string{"name"}) </ins> ) func init() {

prometheus.MustRegister(shortWatchesTotal) prometheus.MustRegister(watchDuration) prometheus.MustRegister(itemsPerWatch) <ins> prometheus.MustRegister(lastResourceVersion) </ins> cache.SetReflectorMetricsProvider(prometheusMetricsProvider{}) }

} func (prometheusMetricsProvider) NewLastResourceVersionMetric(name string) cache.GaugeMetric { <del> rv := prometheus.NewGauge(prometheus.GaugeOpts{ Subsystem: name, Name:      "last_resource_version", Help:      "last resource version seen for the reflectors", }) prometheus.MustRegister(rv) return rv </del> <ins> return lastResourceVersion.WithLabelValues(name) </ins> }

r := &Reflector{ name: name, // we need this to be unique per process (some names are still the same)but obvious who it belongs to <del> metrics:       newReflectorMetrics(makeValidPromethusMetricName(fmt.Sprintf("reflector_"+name+"_%d", reflectorSuffix))), </del> <ins> metrics:       newReflectorMetrics(makeValidPromethusMetricLabel(fmt.Sprintf("reflector_"+name+"_%d", reflectorSuffix))), </ins> listerWatcher: lw, store:         store, expectedType:  reflect.TypeOf(expectedType),

return r } <del> func makeValidPromethusMetricName(in string) string { </del> <ins> func makeValidPromethusMetricLabel(in string) string { </ins> // this isn't perfect, but it removes our common characters <del> return strings.NewReplacer("/", "_", ".", "_", "-", "_").Replace(in) </del> <ins> return strings.NewReplacer("/", "_", ".", "_", "-", "_", ":", "_").Replace(in) </ins> } // internalPackages are packages that ignored when creating a default reflector name. These packages are in the common
Change:
Typo fix. Will add the PR links.
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
You don't need an issue for typo fix. Please submit the PR directly.
/kind cleanup
sure, let me close it.

Discussion:
} // relist queries the container runtime for list of pods/containers, compare <del> // with the internal pods/containers, and generats events accordingly. </del> <ins> // with the internal pods/containers, and generates events accordingly. </ins> func (g *GenericPLEG) relist() { glog.V(5).Infof("GenericPLEG: Relisting")
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: There will be error when kubelet restarts on a agent if pod in that agent has an azure disk mounted, the error would be like following: azureDisk - No t a mounting point for disk andykubewin175-dynamic-pvc--92c7-11e7-b86b- on varlibkubeletpods-92c7-11e7-b86b-volumespvc--92c7-11 e7-b86b- What you expected to happen: pod could still works well even if kubelet restarts on the agent How to reproduce it (as minimally and precisely as possible): consider following scenario: A pod mounting an azure disk in a k8s agent The kubelet is restarted in that k8s agent The pod could not start up, it always reports error as following: 4d 1m 3065 kubelet, 14777acs9000 Warning FailedMount MountVolume.SetUp failed for volume "pvc--92c7-11e7-b86b-" : azureDisk - No t a mounting point for disk andykubewin175-dynamic-pvc--92c7-11e7-b86b- on varlibkubeletpods-92c7-11e7-b86b-volumespvc--92c7-11 e7-b86b- 4d 1m 3157 kubelet, 14777acs9000 Warning FailedMount Error syncing pod Anything else we need to know?: Environment: Kubernetes version (use ): 1.7, 1.8 Cloud provider or hardware configuration**: azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
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 azure
/assign andyzhangx

Discussion:
return err } if !mountPoint { <del> return fmt.Errorf("azureDisk - Not a mounting point for disk %s on %s", diskName, dir) </del> <ins> glog.V(4).Infof("azureDisk - already mounted to target %s", dir) return nil </ins> } if err := os.MkdirAll(dir, 0750); err != nil {
Change:
ref Test is failing on GCE slow and GCI GCE slow: https://k8s- https://k8s- Example failure https://k8s-
The test nodes appear to lose their authorization for accessing resources about 26m into the test. One of many "Unauthorized" errors starting at
, does this ring any bells ?
The certificates are all expiring:
I believe this is the regression introduced cc/ Can you guys take a look?
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. kind: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
thanks. I'll open a PR to revert that.
Revert here

Discussion:
ETCD_QUORUM_READ: $(yaml-quote ${ETCD_QUORUM_READ}) EOF fi <ins> if [ -n "${CLUSTER_SIGNING_DURATION:-}" ]; then cat >>$file <<EOF CLUSTER_SIGNING_DURATION: $(yaml-quote ${CLUSTER_SIGNING_DURATION}) EOF fi </ins> else # Node-only env vars.

# Optional: [Experiment Only] Run kube-proxy as a DaemonSet if set to true, run as static pods otherwise. KUBE_PROXY_DAEMONSET="${KUBE_PROXY_DAEMONSET:-false}" # true, false <ins> # Optional: duration of cluster signed certificates. CLUSTER_SIGNING_DURATION="${CLUSTER_SIGNING_DURATION:-}" </ins> # Optional: enable pod priority ENABLE_POD_PRIORITY="${ENABLE_POD_PRIORITY:-}" if [[ "${ENABLE_POD_PRIORITY}" == "true" ]]; then

if [[ -n "${VOLUME_PLUGIN_DIR:-}" ]]; then params+=" --flex-volume-plugin-dir=${VOLUME_PLUGIN_DIR}" fi <ins> if [[ -n "${CLUSTER_SIGNING_DURATION:-}" ]]; then params+=" --experimental-cluster-signing-duration=$CLUSTER_SIGNING_DURATION" fi </ins> local -r kube_rc_docker_tag=$(cat /home/kubernetes/kube-docker-files/kube-controller-manager.docker_tag) local container_env="" if [[ -n "${ENABLE_CACHE_MUTATION_DETECTOR:-}" ]]; then
Change:
Glusterfs+Heketi use GB units for expanding volume. Using GiB incorrectly leads to expanding the volume to smaller size than user requested. /sig storage cc

Discussion:
var clusterIDs []string capacity := p.options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)] volSizeBytes := capacity.Value() <del> sz := int(volume.RoundUpSize(volSizeBytes, 1024*1024*1024)) </del> <ins> // Glusterfs creates volumes in units of GBs sz := int(volume.RoundUpSize(volSizeBytes, 1000*1000*1000)) </ins> glog.V(2).Infof("create volume of size: %d bytes and configuration %+v", volSizeBytes, p.provisionerConfig) if p.url == "" { glog.Errorf("REST server endpoint is empty")

// Find out delta size expansionSize := (newSize.Value() - oldSize.Value()) <del> expansionSizeGB := int(volume.RoundUpSize(expansionSize, 1024*1024*1024)) </del> <ins> expansionSizeGB := int(volume.RoundUpSize(expansionSize, 1000*1000*1000)) </ins> // Make volume expansion request volumeExpandReq := &gapi.VolumeExpandRequest{Size: expansionSizeGB}
Change:
It should be possible to create a PodSecurityPolicy with zero restrictions. This was the intent with the (a.k.a. "AllowAny") allowed seccomp profile, but it is rejected during the validation phase. /kind bug
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/auth: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details

Discussion:
} if allowed := annotations[seccomp.AllowedProfilesAnnotationKey]; allowed != "" { for _, p := range strings.Split(allowed, ",") { <ins> if p == seccomp.AllowAny { continue } </ins> allErrs = append(allErrs, apivalidation.ValidateSeccompProfile(p, fldPath.Key(seccomp.AllowedProfilesAnnotationKey))...) } }

invalidSeccompDefault.Annotations = map[string]string{ seccomp.DefaultProfileAnnotationKey: "not-good", } <ins> invalidSeccompAllowAnyDefault := validPSP() invalidSeccompAllowAnyDefault.Annotations = map[string]string{ seccomp.DefaultProfileAnnotationKey: "*", } </ins> invalidSeccompAllowed := validPSP() invalidSeccompAllowed.Annotations = map[string]string{ seccomp.AllowedProfilesAnnotationKey: "docker/default,not-good",

errorType:   field.ErrorTypeInvalid, errorDetail: "must be a valid seccomp profile", }, <ins> "invalid seccomp allow any default profile": { psp:         invalidSeccompAllowAnyDefault, errorType:   field.ErrorTypeInvalid, errorDetail: "must be a valid seccomp profile", }, </ins> "invalid seccomp allowed profile": { psp:         invalidSeccompAllowed, errorType:   field.ErrorTypeInvalid,

validSeccomp := validPSP() validSeccomp.Annotations = map[string]string{ seccomp.DefaultProfileAnnotationKey:  "docker/default", <del> seccomp.AllowedProfilesAnnotationKey: "docker/default,unconfined,localhost/foo", </del> <ins> seccomp.AllowedProfilesAnnotationKey: "docker/default,unconfined,localhost/foo,*", </ins> } validDefaultAllowPrivilegeEscalation := validPSP()
Change:
I don't see an existing issue, so opening one for tracking. PR builds are currently failing due to the SHA of a remote archive changing. ... $ sha256sum 27a13726ff8621cfa4592fbef116b253043c2b093c8814265dc4489a0e67d229 cc cc cc
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
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/release: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
cc
/assign We can probably just bump the sha, but I'm trying to figure out what changed...
I found a copy of the which matched the sha256sum (thanks There's no diff when I compare the extracted trees. There's also no diff if I compare the output on each. The new and old gzip'd tarballs are slightly different sizes (old bytes, new bytes). If I ungzip them, they are the same size ( bytes) but they still have different sha256sums. My best guess at this point is that there was some library change recently which is creating slightly different versions of these tarballs, but I don't know how it's different. I also don't know why the archive tarballs for other repos don't seem to have changed.
go 1.8 vs 1.9 gzip library maybe?
It seems like the order of some files in the tarball may have changed.
Yeah, we're not alone:
I guess we should start mirroring these archives somewhere rather than depending on GitHub.

Discussion:
http_archive( name = "io_bazel_rules_go", <del> sha256 = "f9cc31e9d66dad1154de3c214158916411040e2c2614e4fbc2bab67330e95f82", </del> <ins> sha256 = "27a13726ff8621cfa4592fbef116b253043c2b093c8814265dc4489a0e67d229", </ins> strip_prefix = "rules_go-82483596ec203eb9c1849937636f4cbed83733eb", urls = ["https://github.com/bazelbuild/rules_go/archive/82483596ec203eb9c1849937636f4cbed83733eb.tar.gz"], )

# https://bazel-review.googlesource.com/#/c/10390/ http_archive( name = "io_bazel", <del> sha256 = "667d32da016b1e2f63cf345cd3583989ec4a165034df383a01996d93635753a0", </del> <ins> sha256 = "892a84aa1e7c1f99fb57bb056cb648745c513077252815324579a012d263defb", </ins> strip_prefix = "bazel-df2c687c22bdd7c76f3cdcc85f38fefd02f0b844", urls = ["https://github.com/ixdy/bazel/archive/df2c687c22bdd7c76f3cdcc85f38fefd02f0b844.tar.gz"], )
Change:
Currently, Docker create the host directory if the host path does not exist. For host path, Kubelet doesn't check the host directory existence, and pass the mount to docker directly. Given so, we should: 1) Either clearly define the expectation in CRI; 2) Or create the host directory ourselves when it doesn't exist. /cc
I think hostPath is expected to be already exist and kubelet should create the host directory if it is not exist.
Hmm, another problem is how to known whether hostPath is (expected) file or directory? Since it doesn't exist, we can only assume it is a directory?
There is a new field in the hostpath spec, that may help:
Another thing we may want to clearly define is: If when the host path is a symlink, what is the expected behavior. I think we assume container runtime should follow the symlink and mount the real content, but it's not clearly defined anywhere.
can you clarify, when you say "host path", are you referring specifically to hostPath volumes, or to any volume plugin's host-side path that gets passed into CRI?
I believe it's .
/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. 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

Discussion:
type Mount struct { // Path of the mount within the container. ContainerPath string `protobuf:"bytes,1,opt,name=container_path,json=containerPath,proto3" json:"container_path,omitempty"` <del> // Path of the mount on the host. </del> <ins> // Path of the mount on the host. If the hostPath doesn't exist, then runtimes // should report error. If the hostpath is a symbolic link, runtimes should // follow the symlink and mount the real destination to container. </ins> HostPath string `protobuf:"bytes,2,opt,name=host_path,json=hostPath,proto3" json:"host_path,omitempty"` // If set, the mount is read-only. Readonly bool `protobuf:"varint,3,opt,name=readonly,proto3" json:"readonly,omitempty"`

message Mount { // Path of the mount within the container. string container_path = 1; <del> // Path of the mount on the host. </del> <ins> // Path of the mount on the host. If the hostPath doesn't exist, then runtimes // should report error. If the hostpath is a symbolic link, runtimes should // follow the symlink and mount the real destination to container. </ins> string host_path = 2; // If set, the mount is read-only. bool readonly = 3;
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is used by servicecontroller and routecontroller, for controller-manager, we have an option to set it, but for cloud-controller-manager, it will always be of default value 'kubernetes'. Here are some examples where it was in use: aws: azure: gce: openstack What you expected to happen: Having an option to set the value. How to reproduce it (as minimally and precisely as possible):
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 cluster-lifecycle /area cloudprovider
oops looks like a PR ready already :)

Discussion:
fs.BoolVar(&s.EnableProfiling, "profiling", true, "Enable profiling via web interface host:port/debug/pprof/.") fs.BoolVar(&s.EnableContentionProfiling, "contention-profiling", false, "Enable lock contention profiling, if profiling is enabled.") fs.StringVar(&s.ClusterCIDR, "cluster-cidr", s.ClusterCIDR, "CIDR Range for Pods in cluster.") <ins> fs.StringVar(&s.ClusterName, "cluster-name", s.ClusterName, "The instance prefix for the cluster.") </ins> fs.BoolVar(&s.AllocateNodeCIDRs, "allocate-node-cidrs", false, "Should CIDRs for Pods be allocated and set on the cloud provider.") fs.StringVar(&s.Master, "master", s.Master, "The address of the Kubernetes API server (overrides any value in kubeconfig).") fs.StringVar(&s.Kubeconfig, "kubeconfig", s.Kubeconfig, "Path to kubeconfig file with authorization and master location information.")
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pod creation doesn't finish due to the following error. If the directory doesn't exist it will be created instead of returning error. What you expected to happen: Pod with FC volume works properly. How to reproduce it (as minimally and precisely as possible): Clean up under the "/var/lib/kubelet/plugins" Create a Pod with FC volume Environment: Kubernetes version (use ):Install tools: local-up- /cc
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 storage

Discussion:
} // mount it globalPDPath := util.MakeGlobalPDName(*b.fcDisk) <ins> if err := os.MkdirAll(globalPDPath, 0750); err != nil { return devicePath, fmt.Errorf("fc: failed to mkdir %s, error", globalPDPath) } </ins> noMnt, err := b.mounter.IsLikelyNotMountPoint(globalPDPath) if err != nil { return devicePath, fmt.Errorf("Heuristic determination of mount point failed:%v", err)

return devicePath, nil } <del> if err := os.MkdirAll(globalPDPath, 0750); err != nil { return devicePath, fmt.Errorf("fc: failed to mkdir %s, error", globalPDPath) } </del> err = b.mounter.FormatAndMount(devicePath, globalPDPath, b.fsType, nil) if err != nil { return devicePath, fmt.Errorf("fc: failed to mount fc volume %s [%s] to %s, error %v", devicePath, b.fsType, globalPDPath, err)
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Running kube-apiserver without specifing "--service-cluster-ip-range" will print “no --service-cluster-ip-range specified” and exit. But it provide a default value "10.0.0.0/24". Do we need remove validation of --service-cluster-ip-range specified? What you expected to happen: Since we have provided the default value '10.0.0.0/24', user need not to specify --service-cluster-ip-range in command line. How to reproduce it (as minimally and precisely as possible): Run kube-apiserver without "--service-cluster-ip-range". kube-apiserver --etcd-servers="http://localhost:2379" --storage-backend="etcd2" Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.0.572+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-13T05:45:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.0.584+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-13T08:56:26Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ):4.10.0-33-generic Install tools: Others:
/sig api-machinery
I think the problem is that we do not set the default value for the ServiceClusterIPRange, we can see the code: and so the validation will fail.
No, it had set the default value in
We can see the execution sequence In the function we do not set the value and then we go to the function ,so there is something wrong. And the Line you point out is for construct . Maybe there is a little confusion.
So, I think why we must validate service-cluster-ip-range specificaiton which have been provided a default value after validation: )
I first think there may other use for Validate and ServiceClusterIPRange, So we can directly set the value for ServiceClusterIPRange and should not use DefaultServiceIPRange everywhere. I think you PR may be better
cc

Discussion:
if err := kubeoptions.DefaultAdvertiseAddress(s.GenericServerRunOptions, s.InsecureServing); err != nil { return err } <del> _, apiServerServiceIP, err := master.DefaultServiceIPRange(s.ServiceClusterIPRange) </del> <ins> serviceIPRange, apiServerServiceIP, err := master.DefaultServiceIPRange(s.ServiceClusterIPRange) </ins> if err != nil { return fmt.Errorf("error determining service IP ranges: %v", err) } <ins> s.ServiceClusterIPRange = serviceIPRange </ins> if err := s.SecureServing.MaybeDefaultWithSelfSignedCerts(s.GenericServerRunOptions.AdvertiseAddress.String(), []string{"kubernetes.default.svc", "kubernetes.default", "kubernetes"}, []net.IP{apiServerServiceIP}); err != nil { return fmt.Errorf("error creating self-signed certificates: %v", err) }