Skip to content
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

Don't check in vendor for bootstrap; it adds 160M which slows down cloning the registry as part of Kubeflow deployment #1051

Closed
pdmack opened this issue Jun 21, 2018 · 7 comments

Comments

@pdmack
Copy link
Member

pdmack commented Jun 21, 2018

With the bootstrap vendor dir, a top-level git grep becomes ineffective for some general queries. There seems to be a lot of code here, worthy of its own home IMHO.

@jlewi
Copy link
Contributor

jlewi commented Jun 21, 2018

Does it make sense to move bootstrap into its own repo? If we moved the ksonnet registry into its own registry would that help? Or is that just an orthogonal issue?

@pdmack
Copy link
Member Author

pdmack commented Jun 21, 2018

# find bootstrap/ -type f | wc -l
9714

@jlewi
Copy link
Contributor

jlewi commented Jun 22, 2018

So most of that is just vendor

find ./vendor -type f | wc -l
9692

Is it not possible to simply exclude vendor for git grep?

@pdmack
Copy link
Member Author

pdmack commented Jun 22, 2018

git grep is just a pain point. Does bootstrap have references to the rest of the kubeflow src tree?

@jlewi
Copy link
Contributor

jlewi commented Jul 4, 2018

No I think it could be moved to its own repo. My only reticence is that it would be unfortunate if we have to create a new repo each time we add a go program because there is a cost to managing each repo.

@kunmingg What do you think?

@jlewi
Copy link
Contributor

jlewi commented Jul 8, 2018

The vendor directory is currently 160M. Since our Kubeflow deployment scripts clone the repo a large repository is highly undesirable since it negatively impacts user experience.

Since we use glide to manage dependencies we don't need to check in the dependencies; we could just run glide install.

This comes at the expense of introducing some flakiness into the build process we can mitigate that by

  1. Creating a Docker image with glide installed suitable for building go binaries.

  2. Adding retries as needed to handle flakes pulling dependencies.

Moving it into its own repository would also work but that comes with its own headaches. I think I'd prefer to just strip out vendor.

@jlewi jlewi changed the title Should bootstrap be moved to its own repo? Don't check in vendor for bootstrap; it adds 160M which slows down cloning the registry as part of Kubeflow deployment Jul 8, 2018
@jlewi
Copy link
Contributor

jlewi commented Jul 16, 2018

This is fixed.

@jlewi jlewi closed this as completed Jul 16, 2018
surajkota pushed a commit to surajkota/kubeflow that referenced this issue Jun 13, 2022
* jupyter web app manifest version v3

* Define v3 versions of the manifests that use the patterns as described
in http://bit.ly/kf_kustomize_v3

* Define a new base_v3 package
* Use a configmap generator to generate a config map containing application specific parameters
* Make the parameters available to the command line by setting environment variables to
the config map and then referencing them in the command line.

Related to kubeflow#774

* Try to fix the tests.

* Move the jupyter configs back to the base directory so that
  base is still a valid kustomization package becaue the tests
  will use the current version of kfctl which doesn't support loader
  None.

* Fix the test.

* Fix conflict.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants