jiebi/CodeConvo huggingface dataset:
Code change:
DescribeEvents(events, w) } <ins> printPodsMultiline(w, "Mounted By", mountPods) </ins> return nil }) }

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: I need to know to which Pod(s) a PVC is being mounted to, without having to go through each Pod one by one checking the Volume mounts and the PersistentVolumeClaim. The kubectl describe pvc and get pvc, only tell you to which Persistent Volume the PVC is bound to, but not if is being used by a Pod(s) What you expected to happen: Add a new field in the describe or get that lists the pods that are using the PVC as a volume mount How to reproduce it (as minimally and precisely as possible): Have a PV/PVC bound and create a pod using a volume mount Anything else we need to know?: Not sure if this is only for Azure Disk, which is the Storage Class I am using. Environment: Kubernetes version (use ): 7 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4 Install tools: Azure Kubernetes Services Others: -n/a
/sig storage
/sig cli
I think the kubectl describe can just construct this on the fly. Another angle is should we add this information to PVC object itself
That will be great, as right now the only way to correlate a PVC to a Pod is via a "describe" on the Pod.
I can work on a PR for this!
GitHub didn't allow me to assign the following users: clandry94. Note that only and repo collaborators can be assigned. <detailsIn response to : I can work on this! 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
+1 for the feature. cc
How to find "what pods are using particular PVC through command line"
+1 for the feature.
this feature will be in Kubernetes 1.12
ok kubernetes 1.12 released, how to? which command?
Can someone point to the documentation or paste command to get the pods which have the PVC in use
see the associated PR to see an example usage of this The line in should show it.
Workaround for the meantime:
Thanks , this workaround is great for those people who still use old kubernetes version.
Code change:
DescribeEvents(events, w) } <ins> printPodsMultiline(w, "Mounted By", mountPods) </ins> return nil }) }

Related discussion:
text: However it will meet an error if the pod have no volumes, so I improves it by adding a to check whether the volumes exists or not.
python script to list pods with pvc in namespace(s): Is a part of a cli to set pods with velero/restic annotations. Hope it helps someone :)
For posterity... There is a Used By: field in the output of describe.
client-go didn't give this api... ,PodPVCIndex can solve the problem
Hi thanks worked for me ;) but I want to make it reverse my workarounds with adding after didn't worked do you have any ideas
$ kubectl describe pvc -A Used" Name: ocs-deviceset-lso-volumeset-0-data-1b45dn Namespace: openshift-storage StorageClass: lso-volumeset Used By: rook-ceph-osd-1--8fwpd Also useful ^
the reason it didn't work is because each return does, in point of fact, have a key defined for claimName. That key is just set to null value. So, what you'd actually want to do is test for nulls. As nice as answer is, it's a PITA to parse unstructured human-readable command output, as opposed to command output in a markup language that well known shell parsers like jq and yq can work with. Towards that end, because I had use of this, I came up with the following: That simple not null test at the end plucks out all your nulls. Obviously invert the last conditional if you want all the nulls, but you'll get all sorts of temp things that way that you probably won't care about.
Code change:
} } } <ins> func TestMinionListConversionToNew(t *testing.T) { oldMinion := func(id string) v1beta1.Minion { return v1beta1.Minion{JSONBase: v1beta1.JSONBase{ID: id}} } newMinion := func(id string) Minion { return Minion{JSONBase: JSONBase{ID: id}} } oldMinions := []v1beta1.Minion{ oldMinion("foo"), oldMinion("bar"), } newMinions := []Minion{ newMinion("foo"), newMinion("bar"), } table := []struct { oldML *v1beta1.MinionList newML *MinionList }{ { oldML: &v1beta1.MinionList{Items: oldMinions}, newML: &MinionList{Items: newMinions}, }, { oldML: &v1beta1.MinionList{Minions: oldMinions}, newML: &MinionList{Items: newMinions}, }, { oldML: &v1beta1.MinionList{ Items:   oldMinions, Minions: []v1beta1.Minion{oldMinion("baz")}, }, newML: &MinionList{Items: newMinions}, }, } for _, item := range table { got := &MinionList{} err := Convert(item.oldML, got) if err != nil { t.Errorf("Unexpected error: %v", err) } if e, a := item.newML, got; !reflect.DeepEqual(e, a) { t.Errorf("Expected: %#v, got %#v", e, a) } } } func TestMinionListConversionToOld(t *testing.T) { oldMinion := func(id string) v1beta1.Minion { return v1beta1.Minion{JSONBase: v1beta1.JSONBase{ID: id}} } newMinion := func(id string) Minion { return Minion{JSONBase: JSONBase{ID: id}} } oldMinions := []v1beta1.Minion{ oldMinion("foo"), oldMinion("bar"), } newMinions := []Minion{ newMinion("foo"), newMinion("bar"), } newML := &MinionList{Items: newMinions} oldML := &v1beta1.MinionList{ Items:   oldMinions, Minions: oldMinions, } got := &v1beta1.MinionList{} err := Convert(newML, got) if err != nil { t.Errorf("Unexpected error: %v", err) } if e, a := oldML, got; !reflect.DeepEqual(e, a) { t.Errorf("Expected: %#v, got %#v", e, a) } } </ins>

Related discussion:
text: should have the JSON attribute name "items", not "minions"
Doh! Fix now and break clients?
Define Items and Minions and use Convertors to resolve it?
Sure. I'll make a fix.
Code change:
const ConfigSourceAnnotationKey = "kubernetes.io/config.source" const ConfigMirrorAnnotationKey = "kubernetes.io/config.mirror" const ConfigFirstSeenAnnotationKey = "kubernetes.io/config.seen" <ins> const ConfigHashAnnotationKey = "kubernetes.io/config.hash" </ins> // PodOperation defines what changes will be made on a pod configuration. type PodOperation int

Related discussion:
text: See for more context. Currently, kubelet compares the spec of a mirror pod (created via apiserver) with that of a static pod (config stored as a file) to decide whether the two are considered identical. If they differ, kubelet would delete the mirror pod and re-create it with the correct spec. Due to the fact that apiserver may set default values for some fields in the spec of the mirror pod, the specs could deviate undesirably. To avoid problems like this, we can store the config of a static pod as an annotation in the mirror pod, and compare the static pod with the annotation.
Would a hash of the config be sufficient if we're only going to compare? The whole spec would generally be more useful, but I wonder if that is too much data to put in an annotation.
This seems totally reasonable to me, but I'm still desperately curious why you can't just bypass defaulting when you generate mirror pod from static pod? (i.e. just use the static pod's configuration verbatim)
It's not kubelet who applies the default values here. The admission plugin was only run at the apiserver, and to bypass that, you have to ask apiserver to treat mirror pods differently and potentially at multiple places.
On May 22, 2015 10:38 AM, "Yu-Ju Hong" wrote: Understood, but is it really multiple places? If so then I agree it's a bad idea. Otherwise it might be worth considering as an alternative.
It's untenable for Kubelet to assume to know/circumvent all fields that will be set by other entities: admission control, defaulting, late initialization, auto-something, whatever. It needs to obey the same rules as other clients.
I don't understand why you would ever want to apply any of the things you mentioned to static pods. Static pods should be copied verbatim into the mirror pods, right? That's what I'm proposing.
What if the master is updated before the kubelet, and the master adds a new API field with a default value?
That case should be discussed in
I agree that mirror pod should reflect the true status of the static pod running on the node, and no default values should be set in this case.
Code change:
const ConfigSourceAnnotationKey = "kubernetes.io/config.source" const ConfigMirrorAnnotationKey = "kubernetes.io/config.mirror" const ConfigFirstSeenAnnotationKey = "kubernetes.io/config.seen" <ins> const ConfigHashAnnotationKey = "kubernetes.io/config.hash" </ins> // PodOperation defines what changes will be made on a pod configuration. type PodOperation int

Related discussion:
text: However, I think it'd be harder to implement this way since, as stated above, that there are many things to circumvent in the apiserver itself. It could also be harder to keep this special case from being broken by a yet another new feature/plugin. Keeping the hash of the config in the annotation seems like a good compromise even though it may not reflect the true status 100% accurately. I think this is acceptable. What do you think?
Sure, if you think the annotation approach is easier, I would go with that. I guess in the case Brian mentoined (master adds a new API field with a default value), you would not update the mirror pod, because the static pod definition has not changed?
Yes, a hash would be sufficient.
It shouldn't be necessary to update the mirror pod in the case that a new default field was updated, because that field should be populated automatically by the apiserver on decode from etcd.
We should fix this so we don't have this problem again in 1.2.
Code change:
decoder := legacyscheme.Codecs.DecoderToVersion( legacyscheme.Codecs.UniversalDeserializer(), runtime.NewMultiGroupVersioner( <del> *defaultGroup.GroupVersion(), schema.GroupKind{Group: defaultGroup.GroupVersion().Group}, schema.GroupKind{Group: extGroup.GroupVersion().Group}, </del> <ins> defaultGroup, schema.GroupKind{Group: defaultGroup.Group}, schema.GroupKind{Group: extGroup.Group}, </ins> ), )

Related discussion:
text: Execute make test WHAT=./pkg/api/testing/ And it failed with information: /kind failing-test
/sig api-machinery
what's the urgency of fixing this? Is it a release blocker?
i don't see it as a release blocker. but the problem is in client-go, so it's important to get fixed.
Code change:
} func getPatchedJS(contentType string, originalJS, patchJS []byte, obj runtime.Object) ([]byte, error) { <ins> // Remove "; charset=" if included in header. if idx := strings.Index(contentType, ";"); idx > 0 { contentType = contentType[:idx] } </ins> patchType := api.PatchType(contentType) switch patchType { case api.JSONPatchType:

Related discussion:
text: Given a request with a Content-Type header set to , the server will respond with an error because it does not exactly match the existing strings. Some browsers (Firefox, see: ) will automatically add to a Content-Type header when making an XHR request.
Code change:
dockercontainer "github.com/docker/docker/api/types/container" dockerfilters "github.com/docker/docker/api/types/filters" "github.com/golang/glog" <del> "k8s.io/api/core/v1" </del> runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime" )

Related discussion:
text: seems to belong to sig node PTAL and fix ASAP
/assign as it seems like having something to do with
Code change:
glog.Errorf("Failed to get hostname. err: %+v", err) return nil, err } <del> vs.vmUUID, err = getVMUUID() if err != nil { glog.Errorf("Failed to get uuid. err: %+v", err) return nil, err </del> <ins> if cfg.Global.VMUUID != "" { vs.vmUUID = cfg.Global.VMUUID } else { vs.vmUUID, err = getVMUUID() if err != nil { glog.Errorf("Failed to get uuid. err: %+v", err) return nil, err } </ins> } runtime.SetFinalizer(vs, logout) return vs, nil

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: What happened: Currently the vsphere cloud provider blocks the controller-manager from running if its running on a non-vmware host, because it reads and checks if its content starts with . What you expected to happen: The controller manager to start How to reproduce it (as minimally and precisely as possible): Start a on a non-vmware environment with the flags set 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:
/sig vmware
can you please share some more context- Why do you want vSphere cloud provider to work with non-vmware host (I believe you mean ESXi)? Where is this requirement coming from.
We are building a Kubernetes cluster management solution which does Kubernetes in Kubernetes and works by creating the control planes in one cluster, then creating worker instances on one of the supported platforms, among them vsphere. Currently the cluster hosting the control planes (We call it seed cluster) has to run on ESXi, otherwise the controller-manager crashes. Having the check in place for the Kubelets is completely fine and definitely makes sense, but for the controller-manager it should IMHO not be required.
Code change:
<del> apiVersion: v1 kind: ReplicationController metadata: name: es-client labels: component: elasticsearch role: client spec: replicas: 1 template: metadata: labels: component: elasticsearch role: client spec: serviceAccount: elasticsearch containers: - name: es-client securityContext: capabilities: add: - IPC_LOCK image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4 env: - name: KUBERNETES_CA_CERTIFICATE_FILE value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: "CLUSTER_NAME" value: "myesdb" - name: NODE_MASTER value: "false" - name: NODE_DATA value: "false" - name: HTTP_ENABLE value: "true" ports: - containerPort: 9200 name: http protocol: TCP - containerPort: 9300 name: transport protocol: TCP volumeMounts: - mountPath: /data name: storage volumes: - name: storage emptyDir: {} </del>

Related discussion:
text: Presently, the elasticsearch example Kubernetes configurations target elasticsearch v1.7.1, which is quite old. As of this writing, the latest elasticsearch release is v5.6.2, with many deployment changes since then. Could the elasticsearch examples be updated to target the v5 series of elasticsearch? See for a more up to date reference configuration.
cc
hey it's been a long while since I last contributed to the docs. i can do it soon but i need pointers on how to properly do it.
hey, so we need to update the stuff under examples/elasticsearch/ *&repos=kubernetes So basically update the images, yaml files etc and test that everything works (and submit a PR)
/sig testing
Ah, so there's no documentation updates anymore. OK I'll take care of it, assign it to me.
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
GitHub didn't allow me to assign the following users: me. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign me 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
/assign pires
/remove-lifecycle stale
it seems that the example moved to I am now reading that repo guidelines and will update this there. I'll also open a PR that cleans this folder in the current repo and closes this issue.
Code change:
return res, nil } <ins> // doCmdWithoutAttr a simple wrapper of netlink socket execute command func (i *Handle) doCmdWithoutAttr(cmd uint8) ([][]byte, error) { req := newIPVSRequest(cmd) req.Seq = atomic.AddUint32(&i.seq, 1) return execute(i.sock, req, 0) } </ins> func assembleDestination(attrs []syscall.NetlinkRouteAttr) (*Destination, error) { var d Destination

Related discussion:
text: <!-- 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 feature What happened: Currently, we flush ipvs services by deleting them one by one. That's because there was no flush API in libnetwork. Now, libnetwork supports flush API, I think it's time to rsync. 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 ): Cloud provider or hardware configuration**: 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 network
/area kube-proxy
/assign
Code change:
} return false, nil } <ins> // stripComments will transform a YAML file into JSON, thus dropping any comments // in it. Note that if the given file has a syntax error, the transformation will // fail and we will manually drop all comments from the file. func stripComments(file []byte) []byte { stripped, err := yaml.ToJSON(file) if err != nil { stripped = manualStrip(file) } return stripped } // manualStrip is used for dropping comments from a YAML file func manualStrip(file []byte) []byte { stripped := []byte{} for _, line := range bytes.Split(file, []byte("n")) { if bytes.HasPrefix(bytes.TrimSpace(line), []byte("#")) { continue } stripped = append(stripped, line...) stripped = append(stripped, 'n') } return stripped } </ins>

Related discussion:
text: When trying to edit multiple resources, for example: will panic. Ref as the possible cause cc
if was the cause, any fix needs to happen in 1.1 as well, was already cherry picked there
Also shows that we need a test for this case.
is the cause. When we edit multiple resources (i.e., list-type objects), the list's Accessor.annotations (type ) is nil and will panic when UpdateApplyAnnotation tries to SetAnnotations ().
Code change:
dir := cacheDir if len(dir) > 0 { version, err := clientset.Discovery().ServerVersion() <del> if err != nil { return nil, err </del> <ins> if err == nil { dir = path.Join(cacheDir, version.String()) } else { dir = "" // disable caching as a fallback </ins> } <del> dir = path.Join(cacheDir, version.String()) </del> } fedClient, err := clients.FederationClientForVersion(nil) if err != nil {

Related discussion:
text: kubectl works mostly fine without /version. But a number of commands (apply, create, convert, ....) are wired to this: A 404 on /version let's the kubectl to fail hard. For environments where might be a security problem (cf. ) this is a nogo. Relates to minimal apiserver routes:
/cc
/version is desirable (we think all servers should have it) but it should not be required for the proper functioning of a client to be able to retrieve it.
Code change:
} } <ins> // createCustomResourceDefinition removes potentially stale storage so it gets re-created func (r *crdHandler) createCustomResourceDefinition(obj interface{}) { crd := obj.(*apiextensions.CustomResourceDefinition) r.customStorageLock.Lock() defer r.customStorageLock.Unlock() // this could happen if the create event is merged from create-update events r.removeStorage_locked(crd.UID) } // updateCustomResourceDefinition removes potentially stale storage so it gets re-created </ins> func (r *crdHandler) updateCustomResourceDefinition(oldObj, newObj interface{}) { oldCRD := oldObj.(*apiextensions.CustomResourceDefinition) newCRD := newObj.(*apiextensions.CustomResourceDefinition)

Related discussion:
text: Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestWebhookConverterWithDefaulting /assign /priority important-soon /area custom-resources /sig api-machinery /kind flake /milestone v1.16
/cc
several of the webhook converter tests have similar flakes. it looks like the wait for storage version to become effective times out occasionally Rare flakes seen in all of these tests: TestWebhookConverterWithWatchCache/nontrivial-converter TestWebhookConverterWithWatchCache/metadata-mutating-converter TestWebhookConverterWithDefaulting/metadata-mutating-converter TestWebhookConverterWithWatchCache/noop-converter TestWebhookConverterWithDefaulting/empty-response TestWebhookConverterWithoutWatchCache/nontrivial-converter/check-2 TestWebhookConverterWithoutWatchCache/noop-converter/check-0/v1beta2 TestWebhookConverterWithoutWatchCache/nontrivial-converter/check-0/v1beta2
cc
Yikes, I’ll sort it out.
iiuc sending an empty patch gets short-circuited and doesn't bump CR generation, even if the storage version gets changed, which means we do not re-write to etcd and go through the encoding path this would be racing and doing noop's if the first pass of didn't get the expected storage version I will send a fix to make the patch do actual mutation
It doesn't bump generation, but the bytes to persist in etcd would still be different if the storage version had changed, so they should persist. You can verify that by changing the storage version on a CRD yourself, do an empty patch, and see if the resourceVersion changes.
you're right. Generation is for non-metadata change only, and the RV changes. I queried etcd locally and the apiVersion did change for an empty patch (sidetracking: another observation is after changing the storage version (say v1 -v2; noop convertor), empty-patching v2 endpoint would bump generation, while empty-patching v1 endpoint wouldn't)
another theory: our cached storage strategy could be stale if the CRD informer merges multiple events together (e.g. the informer does a re-list).
Code change:
} } <ins> // createCustomResourceDefinition removes potentially stale storage so it gets re-created func (r *crdHandler) createCustomResourceDefinition(obj interface{}) { crd := obj.(*apiextensions.CustomResourceDefinition) r.customStorageLock.Lock() defer r.customStorageLock.Unlock() // this could happen if the create event is merged from create-update events r.removeStorage_locked(crd.UID) } // updateCustomResourceDefinition removes potentially stale storage so it gets re-created </ins> func (r *crdHandler) updateCustomResourceDefinition(oldObj, newObj interface{}) { oldCRD := oldObj.(*apiextensions.CustomResourceDefinition) newCRD := newObj.(*apiextensions.CustomResourceDefinition)

Related discussion:
text: Two scenarios: -create-update events merged into an update event: strategy with UID:a was created on demand for CRD Foo Foo was deleted and recreated strategy with UID:b was created on demand for the new Foo new Foo got updated (e.g. switching storage version) the strategy with UID:b is supposed to be deleted and , to reflect the last update. But if the CRD informer merges the delete-create-update events into , the strategy with UID:a will be deleted, but the strategy with UID:b won't. -update events merged into a create event: strategy with UID:a was created on demand for CRD Foo Foo was updated (e.g. switching storage version) the strategy with UID:a is supposed to be deleted and , to reflect the last update. But if the CRD informer merges the create-update events into , the strategy with UID:a won't be deleted (as we don't react on create events). another race found in , which could happen in a single update.
I think I :
Code change:
} func (tc *patchTestCase) runner(t *testing.T) { <ins> scheme := NewTestScheme() metav1.AddMetaToScheme(scheme) </ins> client := NewSimpleMetadataClient(scheme, tc.object) resourceInterface := client.Resource(schema.GroupVersionResource{Group: testGroup, Version: testVersion, Resource: testResource}).Namespace(testNamespace)

Related discussion:
text: Because of this scheme mutation, this leads to concurrent use of the same scheme to cause the program to panic. It would be ideal to do this in some concurrent safe manner or add a warning or similar
/sig api-machinery
/assign
/assign /triage accepted