@kubernetes/sig-storage-pr-reviews

/ok-to-test

/retest

can someone from GKE review this? I have an impression xfs kernel module is missing on some GKE images.

Even if it is, all it means that xfs continues not to work for them :) All other users can have broader choice of filesystems to use as hyperkube images are used much more beyond GKE

@kubernetes/sig-gcp-pr-reviews

/lgtm

@cblecker @jbeda someone could approve this?
I happened to know dynamic volume of xfs fstype is not supported due to this issue. And this PR is pending for more than 2 months...

/test pull-kubernetes-e2e-kubeadm-gce-canary

/release-note enable xfs format tool on hyperkube image

Really hoping that this makes it into 1.10

/approve no-issue

I'm not a fan of this, TBH. I wish we could keep the hyperkube image small and targeted. But to do that we'd have to remove the kublet code and create a dedicated kubelet base image with all of this stuff. A project for another day.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, jbeda, redbaron

The full list of commands accepted by this bot can be found here.

/test all [submit-queue is verifying that this PR is safe to merge]

Automatic merge from submit-queue (batch tested with PRs 58562, 56937). If you want to cherry-pick this change to another branch, please follow the instructions here.

@redbaron: The following tests failed, say /retest to rerun them all:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

@jbeda Can I cherry pick this PR to v1.7, v.1.8, v1.9?

I am glad it was merged, but it upsets me. It is yet another example when absolutely nothing is happening until some people with power have some needs. Everytime there is a keynote talk at Kubecon how awesome Kubernetes community is, I want to throw something at the stage - there is NO community, only needs of people/companies with commit rights.

@redbaron thank you for your PR, your contributions are welcome. The similar issues may happen in the high-velocity opensource projects as Kubernetes is; we understand them and working on enhancing the existing procedures.

At the same time, we would be greatly appreciated to receive these concerns in a polite and respectful way.

@redbaron The key problem with stuff like this is that there are no clear owners for this part of the project. I think this would fall under SIG-Release but we don't have that written down any place.

One of the things we are working on right now is having a clear line of ownership between all parts of the project and SIGs. That then gives folks that want to get stuff like this done a place to go and engage and perhaps start contributing. Those areas of the project with clear SIG ownership generally move faster and are easier to get PRs merged.

I'll also note that my github description says Waiting on PR review? Poke me on email, k8s slack or twitter (@jbeda).. I didn't see anything from you. Many of us are overwhelmed by github notifications and it is difficult to keep up. I'm sorry that this is a frustrating experience for you.

@andyzhangx I don't have a problem cherry picking this to previous releases.

@jbeda @andyzhangx I can speak authoritatively for this part of the code base. There's a couple issues with this PR:

• This PR is currently a noop. Adding the utility to the install list alone, will not actually add the utility to the images. The base images need to be built, pushed, and re-tagged.
• The build image system, including the hyperkube base image, is a cross-sig piece of the project. As this was adding a storage utility, I requested a review from sig-storage. @rootfs replied saying that it should be fine, but also to check with the GKE folks. I then pinged sig-gcp (who didn't end up responding).
• Because this change involves the base images, cherry picking this back is more difficult. Picking this back to 1.9 should be easy, but 1.8 and 1.7 are multiple revisions of the debian-base image behind and it is much more difficult to do without picking up unintended changes.

also heads up to @ixdy -- the next hyperkube base retag will pick up this change too.

Just to add on to @jbeda and @cblecker's comments above - hyperkube is a bit special in that it doesn't have a clear owner, so it's less well-tested and work on it tends to fall into the cracks.