--
You received this message because you are subscribed to the Google Groups "kubeflow-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CACijwiYimdfLrw51fs9fh6yrYn2_sVqmcpQH9uDni0da_QSVyg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/63dde059-37b6-507d-aeef-6cd8aa13426d%40arrikto.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CAFrZaExxs%3DrtiNNvBcGRHv3b3TPiYYb-KJvvMoAPvGYPmQ4cQg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/8478ee5e-592a-42bc-9968-18b469c45b7fn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/f41a5877-8175-442c-abb7-ffc796915871n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CACijwiZBAp%2BVgm0KY-EZ46UEZybE6-HRcsFpDubWxNuarJ4U%2BQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/d02ce379-c5e6-4809-13cd-0eaf168b1423%40arrikto.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/0a676b58-177b-4489-bd96-ba45a4e932afn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CAHD%3DcxYZW-0jn3M6eRnH2En5ugGmeZyJ9ik0FJTYrOD21aKQqw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/d2cdf7eb-a413-4605-8da8-b936ca5f3e67n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/d2cdf7eb-a413-4605-8da8-b936ca5f3e67n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CA%2B%3DSMmKZ5%2BGp_%2B4DTnpi%2BZ-X1u35wD7tJxcjKDD7JcXBNd6UsA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CACijwiYVy1sv20vVnTjE6Dtj%3DpP5Rm_kVTOHwg9o7iQoMB%2BuEg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/68e41875-66bf-fb35-a2de-d66a2d2482c7%40arrikto.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/bfc408aa-1ab2-6273-1989-ae0b34b2de85%40arrikto.com.
> A core distribution of Kubeflow distributing applications based on core WGs (Notebooks, Training, AutoML, Serving and Pipelines) on vanilla OSS Kubernetes, Istio and KNative> Vendor specific distributions (e.g. AWS, Google, IBM, Arrikto, Seldon...) are not part of this WG, and need to be managed independently.The idea of a "core"/default/official distribution seems problematic. Is there a reason we can't treat all distributions uniformly?All distributions are opinionated. Whether you are using only OSS components or not; every distribution represents a set of opinionated decisions.Anything which creates a perception that one distribution is endorsed by Kubeflow over others seems inherently problematic to me.A WG says Kubeflow is responsible for this distribution and that seems problematic to me.Why do we need to create WGs to sponsor distributions? This just seems like an invitation for conflict as various groups agitate to advance their agenda by getting their opinions upstreamed.Adopting only OSS tech doesn't preempt this (emacs vs. vim, helm vs kustomize, etc...)If folks want to collaborate on a distribution, why don't they just pick a name spin up a GitHub repo and invite interested parties to collaborate? If we adopt a policy of no distributions within Kubeflow then we carve out a clear space for an ecosystem of distributions.
Great to see discussion on this topic.
+1 to the argument for maintaining a minimalistic base reference architecture for users to try out Kubeflow and various components. Vendor neutral config like kfctl_k8s_istio (https://www.kubeflow.org/docs/started/k8s/overview/) for vanilla KF deployments is a good example. Given the fact that there are limitless customizations possible for a ML platform, maintaining opinionated configs beyond the reference ones inside Kubeflow looks unsustainable. Is the new proposal different from current kfctl_k8s_istio ?
--
You received this message because you are subscribed to the Google Groups "kubeflow-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CA%2B%3DSMmJrs9TJJYp9Le3iRToxWdC0wDTROdDu1p7vyzuEN5ZVZA%40mail.gmail.com.
Hi Folks,Over the past couple of months we've been working hard to divide Kubeflow into working groups responsible for different KF applications.
We now have 5 different work groups (listed here) that own all the major applications.
There is an open question about what to do about some of the remaining applications/pieces that don't fit neatly into these work groups. These include
central dashboard - (https://github.com/kubeflow/community/issues/380)pod defaults controller - (https://github.com/kubeflow/community/issues/381)Control Plane/kfctl/manifests - (https://github.com/kubeflow/community/pull/402)
Auth/Dex/Profile ControllerReference Architectures / generic KFDefsWe've been debating what to do at the recent community meetings. I wanted to start a thread to give everyone an opportunity to chime in.To summarize it looks like there are two proposals on the table1. Spin up appropriate WGs to own and maintain these applications going forward2. KF stops assuming responsibility for bundling and deploying all the applications
- Each application should be installable on its own with that responsibility assumed by the applications owners and/or WG
- Vendors would be responsible for composing the applications into distributions and providing glue (e.g. Dex or middleware like ISTIO) at their discretion.
#2 raises the question what ties the various applications into a cohesive platform?One possibility is that pipelines & metadata not deployment is what binds together the applications into a cohesive platform.
This idea is something we first discussed at our 2019 summit. All Kubeflow applications would follow some conventions that enable:
- using them in pipelines
- consistently logging metadata
Adhering to these conventions is what would distinguish a KF application from a non KF application.
Thoughts?J
--
You received this message because you are subscribed to the Google Groups "kubeflow-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CACijwiYimdfLrw51fs9fh6yrYn2_sVqmcpQH9uDni0da_QSVyg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CABW14FNYN1QX%2BEKsrSLsLi4Bhk%3DPOkb9KznkmcL%3DkGTVR-yduw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/CACijwiYe5wXsYnEfH%3Diai%3DjS4JE%3D6qzO%2BF%3DL-Ov2VjVW7t_mUg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "kubeflow-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubeflow-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubeflow-discuss/a6a7b64d-ffa7-4fe9-8d7c-57f38cf708fcn%40googlegroups.com.