New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split up core ksonnet package into separate packages #42
Comments
Adding this to 0.4.0 . In 0.4.0 we should try to rationalize our package structure and otherwise overhaul the organization of our ksonnet registry (e.g. #1454) |
/area 0.4.0 |
/priority p0 |
/remove-priority p1 |
I think the next step would be to come up with an initial proposal for the refactor. |
Here's a list of the components still in the core package ambassador So we basically have 2 types of components left
The GCP specific components should probably be moved into their own package. For common components we have a couple options
|
I think the only remaining item is to rename core. I vote renaming it to common. |
"common" to me implies general utility for other components, like logging. "core" is not bad IMHO if it's basically the content of an MVP. My $0.02. |
one argument for common is kubeflow/core/util.libsonnet which is used by other components. |
…ogram. (kubeflow#42) * Create a google group for folks at the Insight Data Scient Fellows program. * Some folks will be kicking the tires on Kubeflow. * Add jeremy@lewi.us to test IAP via googlegroups. Will remove in follow on PR. * Define the IAM policy file. * Update README
* snapshot * first pass on pipeline refactoring * fixes for naming of pv, pvc and references in deployment * fix for pipelines-viewer, minioPd
The core package consists of
These should probably each be their own package. The core component could then depend on these packages.
The reason we didn't do this in the initial PR #36 was because ksonnet doesn't yet support having packages depend on other packages see ksonnet/ksonnet#231
The text was updated successfully, but these errors were encountered: