pengale
commented
5 years ago Recognizing that this would make it easier to demo, I'm not sure we should redistribute Cirros in the snap.
Perhaps you can help me understand: What are we trying to address by doing so?
@ryan-beisner moving cirros into the snap addresses two issues:
1) On a slow, unreliable network (e.g., potentially the wifi at the con), the cirros image can take a long while to download, which means that we hit the five minute max on the run time of snap configure hooks. (This timeout is not currently configurable.)
2) Moving the file into the snap makes it easier to clean up afterward -- it'll simply get deleted with the rest of the snap.
Point #2 can be addressed by downloading the cirros image to /var/snap/microstack/common/images rather than /images, which was . But that makes the workaround for Point #1, which is to download the cirros image in advance, a bit trickier.
I'm going to test the snap's behavior in the case where we try to create /var/snap/microstack/images in advance of installing the snap. If that works, I'll push an alternative to this PR which downloads the cirros image, but hides it in /var/snap/microstack/common/images, rather than leaving a mess on the user's system.
Put it in the data dir, along with the mysql tarball. It's therefore available to the configure script, in a predictable place.
The process to update the cirros image is to
1) Update the image in data 2) Update the configure script to point to the new image.