Create the KFDef object to the cluster when kubeflow is deployed using kfctl CLI

[adrian555]

As a follow up of #241, this issue is opened for discussion on creating the KfDef object when the kubeflow is deployed through kfctl command line.

Background:

Currently if kubeflow is installed through kubeflow operator with the instructions in https://github.com/kubeflow/kfctl/blob/master/operator.md, a KfDef kind object is created. We can use this object as the root owner object for any kubeflow resources deployed. The solution in #241 is to use the ownerReferences with this object to help clean up resources when deleting kubeflow. As we can see the benefit with this approach, we propose to create the same KfDef object when kubeflow is not installed through the operator.

/cc @animeshsingh /cc @vpavlin

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the labels:

Label	Probability
kind/feature	0.95

Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback! Links: app homepage, dashboard and code for this bot.

[vpavlin]

Thanks @adrian555

I think this would be best and keep things consistent. I believe reimplementing core K8S functionality (owner based garbage collection) is not a good idea and having point of reference for what is deployed (KFDef manifest uploaded) in the cluster might be useful anyway.

[animeshsingh]

@gabrielwen @jlewi @yanniszark - thoughts - and anyone would like to pick this up on core kfctl cli side?

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the labels:

Label	Probability
area/kfctl	0.96

Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback! Links: app homepage, dashboard and code for this bot.

[jlewi]

See comment about deleting https://github.com/kubeflow/kfctl/issues/293#issuecomment-612691634

Using an uber KFDef to own all resources and GC them on delete seems a bit ill-defined at least on GCP.

We have also been using the Application CR as a general way of providing information about what applications are installed.

In general, I think we are moving in the direction of treating kubeflow as a loose collection of applications. As opposed to an uber monolthic application.

So I don't see much need on GCP to start defining and installing KFDef objects on GKE clusters. We are also using the KFDef to define the GKE cluster itself and all the supporting GCP infrastructure. So treating the KFDef as a K8s resource that lives in the GKE cluster doesn't fit that model. For example, if you delete the K8s resource you wouldn't be GC'ing the associated GCP infrastructure.

[jtfogarty]

/priority p2