Release process for kubebench

[amsaha]

We needed some help with packaging Kubebench for releasing (related issue on Kubebench repo: issue kubeflow/kubebench#88):

1. We are following the instructions at https://github.com/kubeflow/kubeflow/blob/master/docs_dev/releasing.md. Are these the correct instructions to follow?
2. We currently have 4 Dockerfiles for the Kubebench repo - 1 controller and 3 per benchmark (currently, just the tf-cnn benchmark exists). They can be found here: https://github.com/kubeflow/kubebench/tree/master/build/images.
   MUST we have a single Dockerfile that will be called via the build_image.sh file in the kubebench repo (we are yet to add that .sh file) or can we have multiple Dockerfiles?
3. How do we test the packaging code?

@xyhuang @johnugeorge

[amsaha]

/assign @jlewi
/assign @ankushagarwal

[amsaha]

/help

[k8s-ci-robot]

@amsaha:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[abhi-g]

@amsaha I believe the release process for now is still as documented at the link https://github.com/kubeflow/kubeflow/blob/master/docs_dev/releasing.md. You should have to only follow the "Image Auto Release" section.

@kunmingg Please find some time to help out with the questions #2 and #3 above.

[kunmingg]

@amsaha

2. Do you want to have each image released by their own workflow (use multi dockerfile could be easier in this case) or one workflow release 4 image (can use 1 dockerfile and change params for each image build in this case)?

For one workflow release 4 image, need some customization after workflow created.
One example can be found here:
#1102

To have your workflow daily released, add workflow to release config at: https://github.com/kubeflow/kubeflow/blob/master/releasing/prow_config_release.yaml

3. If each build_image.sh works, workflow should works too. I can help check result once PR merged.

[amsaha]

Thanks @kunmingg. I will take a look and decide accordingly.

[amsaha]

@kunmingg

@xyhuang and I took further look at it and it seems that the cleanest option is to have each image released by their own workflow.

Since each repo can have only one build_image.sh (as it seems is the case from looking at https://github.com/kubeflow/kubeflow/blob/master/docs_dev/releasing.md) I think we can pass different values to EXTRA_ARGS in the call to build_image.sh and use that to select the appropriate DockerFile.

[xyhuang]

Created a PR here at #1538, the current solution is:
we will use 2 components under the kubebench pkg: kubebench-controller, and kubebench-examples, where kubebench-controller will build & push the 1 image for the controller, and kubebench-examples will build & push 3 images in the examples. Considering that the examples will continue growing in the future, building them together might make it easier to maintain.
@amsaha @kunmingg please let me know if this sounds like a reasonable solution. thx.

[amsaha]

@xyhuang
So if I understand correctly kubebench-examples: builds multiple images for all kubebench examples means that if there are multiple examples (currently there is only tf-cnn) all will be build in one shot, right?

BTW, the current structure of https://github.com/kubeflow/kubeflow/blob/master/releasing/prow_config_release.yaml requires that there is one build_image.sh for the entire repo (kubebench). So we will need a wrapper build_image.sh at the root level of the kubebench repo that will have to call both kubebench-controller/build_image.sh and kubebench-examples/build_image.sh, right?

[jlewi]

Who is actually working on this? The issue is assigned to @kunmingg but I don't think @kunmingg is actually working on a release process for Kubebench.

[kunmingg]

@amsaha and @xyhuang is working on it.

[abhi-g]

I had assigned to @kunmingg when the issue needed his input. Reassigning back.. /assign @amsaha /assign @xyhuang

…

On Mon, Sep 17, 2018 at 2:30 PM Kunming Qu ***@***.***> wrote: @amsaha <https://github.com/amsaha> and @xyhuang <https://github.com/xyhuang> is working on it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1510 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALOqZmO_ifbl3SmRxsVBDBd-UeAzsE1Nks5ucBRygaJpZM4Wi2cK> .

[xyhuang]

@jlewi @kunmingg We have pushed build_image scripts in kubebench repo, we are waiting for #1538 to be merged. Please let me know if there is anything else needed. thx.

[jlewi]

As mentioned on Slack we revamped the image release process to allow images to be built and pushed from post submits.

See updated instructions: https://github.com/kubeflow/kubeflow/blob/master/docs_dev/releasing.md#image-auto-release

I apologize for the churn but our existing process of using a cron job just wasn't scaling and providing actionable signal.

[xyhuang]

thanks, we have followed the new release process and the images are showing up in gcr.io/kubeflow-images-public correctly. This issue can be closed.
/close

[k8s-ci-robot]

@xyhuang: Closing this issue.

In response to this:

thanks, we have followed the new release process and the images are showing up in gcr.io/kubeflow-images-public correctly. This issue can be closed.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.