release .yaml manifest

[sebgoa]

Hi, having to install ksonnet to try kubeflow and then learn how to use it to be able to have the manifests is a bit cumbersome.

Would be nice to release the working manifests in the github release page, so that one can just kubectl apply to get going and test kubeflow quickly.

[jlewi]

I understand the sentiment, but I think this might actually create more friction

• Our docs would be more confusing. We'd have a "Quick Quick Start" which shows how to use the YAML but that will only get you so far. For example, you can't easily substitute in your own models or docker images for training. So IMO we're conveying the wrong impression to users. Then we have to tell people to switch from the YAML to ksonnet.

• It creates an extra burden on the developers to keep the manifests up to date.

Did you look at the katacode self paced tutorial?

I think that approach of giving users an already deployed environment that they can try out is much better.

Do you have suggestions about how that can be improved?

[sebgoa]

I hear you, but now you are asking kubeflow users to embrace and learn ksonnet as well.

I like ksonnet, bitnami who I work at contributed to the project, but I don't think it is super friendly for the users. Using kubeflow requires 6 or 7 ks commands. Folks will need to learn what they do, before diving into understanding kubeflow itself.

just my 2 cts.

[jlewi]

I agree but I think there are better ways to solve this than providing manifests.

For people who want to dive into ML, neither kubectl nor ks is a really great entrypoint. A better entrypoint would probably be JupyterHub. So how can we simplify the steps to giving users access to JupyterHub?

What if there was a web app that users could go to "http://kubeflow.io/click-to-deploy" which would automatically deploy Kubeflow for users on a suitable K8s cluster (either an existing cluster or new one) and then automatically redirect users to JupyterHub running in that cluster?

I don't think this would be that difficult. The biggest problem would probably be delegating credentials to the web app so that it could authenticate to the K8s master. For the web app could just get an OAuth bearer token from the user and use that.

I think this would be really cool and open up Kubeflow to a whole new set of users.

Thoughts?

[jlewi]

An even simpler solution could be to create a bootstrap script and Docker container with ksonnet and just run that (either locally or in a cluster). I think we could get to the following experience pretty easily

kubectl run --image=gcr.io/kubeflow/bootstrap

[jlewi]

Closing this in favor of #105

[sub-mod]

I still vote for manifest. The burden of keeping manifests updated can be shared by the community.
Nothing against ksonnet.But there can exist multiple paths towards kubeflow.