Tf-operator: Rename project

[wbuchwalter]

If I understand correctly mlkube was the internal name of this project at Google?
What do you think of renaming this repo to TFJob, or Tensorflow-operator?
Not a big deal, but it would be good for discoverability/clarity IMO.

[jlewi]

I'm open to renaming this. The reason I called it mlkube is because I'm hoping that it will eventually grow into a broader effort to make TF/ML work well on K8s. So I chose the name mlkube to reflect this more general goal. TfJob is just one part but I'm hoping to cover other aspects of the ML lifecycle as well.

The part that I'm looking at next is the next iteration of TensorBoard as a service. Basically, the idea is that TensorBoard will use an SQL DB as its backend storing data from more than 1 job. You can then have 1 or more webservers. So the idea would be to make that easy to deploy on K8s ideally using an SQL database suited to where its running.

That said I'm all for increasing visibility and discoverability; so if you think a different name would help let me know.

Are you interested in having a VC to discuss plans/ideas?

[wbuchwalter]

Are you interested in having a VC to discuss plans/ideas?

Absolutely!
I just sent an email to the address figuring on your Github profile.

[bhack]

Why not pushing this in the official repo https://github.com/tensorflow/ecosystem?

[jlewi]

@bhack I've been in discussion with the TF folks. The current plan is to do a review in the next couple weeks to see whether this should be hosted in https://github.com/tensorflow. If the TF team is supportive then it will move to its own repo within https://github.com/tensorflow.

I'd prefer its own repository as opposed to hosting it in https://github.com/tensorflow/ecosystem because mlkube is focused on TF on K8s whereas the ecosystem includes other frameworks (e.g. spark and hadoop). I think its cleaner to keep them separate.

[bhack]

@jlewi Any solution that will give more exposure to this project is good. Now that DCOS support k8 also @klueska could be interested in this.

[jlewi]

The TensorFlow team has agreed to give this project is own repository under tensorflow. We just need to come up with a name. The thinking is that the repository should be scoped somewhat narrowly to Tf for Kubernetes and the name should reflect that.

Suggestions?

How about?
k8s-crds
k8s-custom-resources
k8s-jobs
k8s-controllers
k8s-components
k8s

Since it will be under the tensorflow org I don't think we need tensorflow in the name and this appears to be consistent with other repos.

/cc @klueska @bhack @wbuchwalter @jhseu @vishh @aronchick

[bhack]

I like k8s and k8s-jobs

[bhack]

@jlewi There will be an official announce, blog post, social to promote a little bit this switch?

[wbuchwalter]

k8s-jobs is the clearest IMO.
crds and custom-resources are not a very well known feature of k8s unless you are already deep in the ecosystem.
k8s might be a bit too vague, and create confusion as to what is inside (i.e. tensorflow-serving ? )

[aronchick]

I would prefer k8s-crd. k8s-job has a special meaning in the k8s world. I know that k8s-crd is not well understood, but it's the most descriptive/accurate (one assumes that you'll know what it means if you're deploying to K8s.

[bhack]

@wbuchwalter @aronchick I agree with your comments. What I like of k8s name is that it really seems more an "official effort". It is more like: "this is the official Tensorflow effort if you want to use it on k8".
We come from a story of a not so much lucky https://github.com/tensorflow/ecosystem so a strong signal is important an this was the main motivation of my previous comment about the promotion of the switch. /cc @cfregly

[jlewi]

@aronchick @wbuchwalter @bhack I prefer k8s as well. I like it because its simple and generic enough to still be appropriate if we want to add components to aid TF on k8s which aren't CRDs. An example might be a UI/Dashboard or a server to stage packages so you don't have to build docker images just to distribute your code (so the UX would be similar to staging packages on hadoop/spark).

Another idea would be to name it based on function e.g.
k8s-training

But I don't think that will hold up since a lot of components can be used for training and inference; e.g. TfJob.

[jlewi]

@bhack I hope we will do some announcements/blog posts (kubecon?) but those will happen after the move. One of the things highlighted in a discussion yesterday with the TensorFlow team is that we need more realistic examples/tutorials. Taking an existing TensorFlow example and showing how to run it distributed on K8s would make a great blog post. Its just a question of finding someone with cycles.

/cc @aronchick

[bhack]

@jlewi Yes I think it is sane.

[jlewi]

@jhseu do you want to weigh in?

[jhseu]

No strong opinion. Any of the listed options seem reasonable to me.

[jlewi]

@jhseu lets go with tensorflow/k8s then.

[jlewi]

Project has been moved. Thanks @jhseu