Create links on kubeflow.org to redirect to ksonnet tarballs and deploy scripts

[jlewi]

We would like the getting started experience to be something like

curl https://kubeflow.org/version/0.2.1/scripts/deploy.sh | bash

To support that we'd like to host links in kubeflow.org that will automatically redirect to

1. The scripts containing the code for a specific version/release
2. Tarballs of the ksonnet registry (to avoid GitHub API limits) see Make downloading our ksonnet registry for getting started efficient #1154

We'd also like to create links that point to the most recent release and head e.g.

curl https://kubeflow.org/version/stable/scripts/deploy.sh | bash
curl https://kubeflow.org/version/head/scripts/deploy.sh | bash

So that its easy for users to automatically get the latest release or version.

What should the URL structure be? Proposal

Proposal 1:

https://kubeflow.org/version/${VERSION}/${PLATFORM}/scripts/deploy.sh 
https://kubeflow.org/version/${VERSION}/source.tar.gz

Proposal 2:

https://kubeflow.org/version/${VERSION}/scripts/${PLATFORM}/deploy.sh 
https://kubeflow.org/version/${VERSION}/source.tar.gz

Anybody know off hand how we could use hugo to easily have these URLs mapped to GitHub URLs e.g.

For source.tar.gz we can just grab the links from our releases page
https://github.com/kubeflow/kubeflow/releases

[activatedgeek]

We could create a releases page which has embedded JS to do the following things

1. Fetch all releases from https://github.com/gitapi/repos/kubeflow/kubeflow/releases. This is a public API, does not requires auth and will run client-side. Unless somebody keeps reloading aimlessly, it is unlikely that the rate-limiting happens for the client.

2. Populate the JSON from 1. into HTML dynamically for users to click and download.

An alternative for 1. is to instead of using netlify builds, we use the custom build server like we do for Kubeflow, and just before doing the Hugo build step, we grab the releases and put them into a markdown file just like Hugo needs. This has a chance of rate-limit from happening so only run this on release tags and skip otherwise.

[jlewi]

@richardsliu Do you want to look into this.

[ankushagarwal]

Can't we just use curl https://github.com/raw/kubeflow/kubeflow/<version>/scripts/gke/deploy.sh | bash for now?

[jlewi]

That's what we are doing now and it works. But it means we have to update multiple places every time we publish an update. I hope we can do something like create a static HTML page for each link and just redirect. Side benefit is that it might help us coect download metrics.

…

On Fri, Jul 13, 2018, 4:04 AM Ankush Agarwal ***@***.***> wrote: Can't we just use curl https://github.com/raw/kubeflow/kubeflow/<version>/docs/gke/configs/deploy.sh | bash for now? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1156 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAvcA9dPpxMeKpmafiUWHv-ihsdoU6MWks5uGH7QgaJpZM4VIIYf> .

[jlewi]

It looks like netify might support this
https://www.netlify.com/docs/redirects/

[jlewi]

This works you can now do

curl -L https://kubeflow.org/version/stable/scripts/deploy.sh

An alternative idea raised in #96 was force pushing Git tags.

But as @pdmack suggested that can get squirrelly.

The next step is probably #1239 so that you don't have to specify the version in two places. See this comment

[pdmack]

@jlewi I wonder if "version/stable" is required? i.e., https://kubeflow.org/scripts/deploy.sh implicitly pointing to 0.2.2? WDYT?