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

mkcloud should cache downloads in /var/cache #223

Open
aspiers opened this issue Feb 18, 2015 · 9 comments
Open

mkcloud should cache downloads in /var/cache #223

aspiers opened this issue Feb 18, 2015 · 9 comments
Labels

Comments

@aspiers
Copy link
Contributor

aspiers commented Feb 18, 2015

Currently stuff like the SUSE-SLE12-CLOUD-5-COMPUTE .iso get downloaded into the admin node every run. They should get downloaded into /var/cache/mkcloud on the mkcloud host to avoid this.

@bmwiedemann
Copy link
Member

You still would need to make sure that it is the latest version...
IMHO, the better alternative is to use the localdirs mechanism with rsync from clouddata (or NFS in the well-connected case)

@aspiers
Copy link
Contributor Author

aspiers commented Feb 19, 2015

Agreed on both points. But as long as the wget remains, it should use caching ...

@aspiers
Copy link
Contributor Author

aspiers commented Apr 28, 2015

Also looks like SP3-64up.qcow2 is being downloaded to /tmp. Again, /var/cache is a better place for this.

@Itxaka
Copy link
Member

Itxaka commented Aug 8, 2016

+1 This is terrible for remote workers. My local fixes right now:

  • Have SLES12-SP1.qcow2 locally stored and cp to /tmp in the wrapper script that launches mkcloud
  • Have SUSE-OPENSTACK-CLOUD-6-x86_64-GM-DVD1.iso locally stored and scp to the admin node on the sshrun() function

While this works, this is a bad quick patch to reduce my local dev deployment by about 35 minutes. We should support a timesaver like this out of the box

@AbelNavarro
Copy link
Contributor

@Itxaka notice that the Devel Cloud ISO is generated every night, so every day you should preemptively download it. I tried at some point to have a local squid proxy (I'm remote too), but since I didn't deploy every day I always needed the time for squid to cache the images.

What worked for me is to have an allocated slot in one of the mkcloud hosts. This way if caching is not working, the speed to copy the images is really fast since it remains in the local network.

@dirkmueller
Copy link
Contributor

is anyone interested in converting this into a pull request? adding a -do-not-download option should be relatively easy.

@Itxaka
Copy link
Member

Itxaka commented Aug 11, 2016

If I understand it correctly there is at least 2 images downloaded:

  • The image for the admin node (SLES12-SP1.qcow2 if you use want_sles12=1)
  • The image that is mounted on the admin node and served over tftp for node install (depends on cloudsource)

On the first case, we could download them to any dir but /tmp
On the second, Im not sure a good solution for it. Download it to a local dir and scp it to the admin node? This does not account for the develcloud image, as it changes, but a simple check for differences + delta paching would be nice to have.

At least with those 2 small fixes we would be covering some time gaps.

@bmwiedemann
Copy link
Member

To sync files, you could use

rsync -a clouddata.nue.suse.com::cloud/images/x86_64/SLES12-SP1.qcow2 /var/cache/mkcloud/

@aspiers aspiers added the bug label Aug 30, 2016
@aspiers
Copy link
Contributor Author

aspiers commented Aug 30, 2016

We should extend dl-ibs to take care of this.

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

No branches or pull requests

5 participants