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

Reduce time for first Integration start #2520

Closed
apupier opened this issue Jul 22, 2021 · 6 comments
Closed

Reduce time for first Integration start #2520

apupier opened this issue Jul 22, 2021 · 6 comments

Comments

@apupier
Copy link
Contributor

apupier commented Jul 22, 2021

During first integration deployment a lot of bom dependencies are downloaded. See https://gist.github.com/apupier/6a9fed422bba9b5fde85164055df89a8 With a simple timer example it can take 20 minutes on a not so fast network.

Maybe the container might be can be prepoluated with common ones?

@squakez
Copy link
Contributor

squakez commented Jul 22, 2021

I think it could be interesting to have a simple timer-2-log integration used to imprint the operator container. We would reduce the very first startup time. In any case I can expect 20 minutes in a local developer environment, not on a public cloud :)

@tadayosi
Copy link
Member

While it doesn't improve the very first run, using Maven repository mirror in a cluster is a way to make subsequent runs faster.
I introduced this technique for local e2e testing:
https://camel.apache.org/camel-k/latest/contributing/e2e.html#using-nexus

@tadayosi
Copy link
Member

Perhaps we can make Maven mirroring as the default option and preload a common set of camel jars into the mirror during kamel installation.

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

@squakez
Copy link
Contributor

squakez commented Mar 31, 2022

I am working on something related to the build, and we may think to find an easy way to bundle the known basic set of dependencies. We can use a similar approach on what we do with local make images-dev, where we copy development artifacts. As an example, we can see the following list of dependencies downloaded from a fresh 1.8.2 installation:

1.8.2.log

against the list of dependencies downloaded in 1.9.0-SNAPSHOT (which I created via make images-dev):

1.9.0-SNAPSHOT.log

There is half the number of dependencies needed to download. We may even go further by finding a way to calculate automatically the rest of needed dependencies (ie, the catalog and the related boms).

@squakez squakez closed this as not planned Won't fix, can't repro, duplicate, stale Oct 11, 2023
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

3 participants