User should be able to copy the required minishift artifacts to a different machine and re-create the setup.

[LalatenduMohanty]

It will be helpful in multiple ways.

• An user attending an OpenShift workshop can just copy the setup after the workshop and start on user's personal workstation from the point where workshop has ended and not from scratch
• An instructor creating a demo on minishift and just copies the directory and gives to the participants to try. So that participents does not have to go through all the steps just to run the demo.

[gbraad]

this is like a VM export, and in a way complicated by the fact that each providers treats this differently.

[hferentschik]

this is like a VM export, and in a way complicated by the fact that each providers treats this differently.

This does not include the VM state. Just the cached ISO, oc, config bundles, ... Everything VM specific (everything under ~/.minishift/machines) won't be added.

[gbraad]

~/.minishift/machines wont be added OK, but is the rest relevant in all cases?

a minishift startshould be sufficient to get it up and running, plus possible config bundles.

[praveenkumar]

Let me understand correctly if we don't include machines than our minishift setup-cdk doesn't perform that (create required directory and push iso and oc binary there also create config file with proper details)? I am not able to fully understand how this zip will ramp up users during the workshop?

[hferentschik]

I am not able to fully understand how this zip will ramp up users during the workshop?

It only really helps once we have things like custom bundles. Say you want to have a workshop which uses pipelines and some sort of Jenkins setup. You can prepare the config bundles and assuming we end up having them under ~/.minishift/bundles, you can bundle this up, together with cached ISO and oc. Maybe certain VM config settings in config.json.

The idea being is that once you unpacked the zip file (and we even can provide a command for that), you just do minishift up and all is working. Everyone gets the same config. Also there is no network traffic. In a workshop setting everyone might share the same network connection. If everyone would start downloading ISO and oc, there might be GitHub API rate limits occurring, since everyone would have the same external IP.

Really, from a Minishift perspective the question is whether we want to offer some sort of convenience commands (zip-config, unzip-config). Obviously you can do this already, if you know which files to but into the archive. The advantage of doing it via a Minishift command is, that we know which files to include into the zip. Also applying the config would be slightly easier with a helper command.

[hferentschik]

a minishift startshould be sufficient to get it up and running, plus possible config bundles.

exactly - except we have the ISO, oc, further down the road docker images, config.json as well. It's just about having a simple way of adding the relevant resources while ignoring files which should not be added.

[thesteve0]

This will also cache Docker images in the machine and such?

[praveenkumar]

This will also cache Docker images in the machine and such?

I think idea is to cached docker image as tarball and then finally have those in zip but that still in our future roadmap.

[thesteve0]

Then this is useless for a workshop until you implement that. Just letting you know from experience of teaching many workshops. This was a key requirement of being able to use the all in one for workshops. Can you not cache them in the ISO as part of the image?

On Mon, Feb 13, 2017 at 8:44 PM, Praveen Kumar notifications@github.com wrote:

This will also cache Docker images in the machine and such?

I think idea is to cached docker image as tarball and then finally have those in zip but that still in our future roadmap.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/minishift/minishift/issues/397#issuecomment-279606936, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVswxxUGO37ZG6Jx7mP5o4MRkNEId54ks5rcTEogaJpZM4L_GPA .

[gbraad]

Would it work to have a template?

$ tar -zxvf minishift-workshop-20170214.tar.gz
$ cd workshop
$ ./prepare.sh

prepare.sh

#!/bin/bash
CACHE=~/.minishift/cache
mkdir -p ${CACHE}/oc
mkdir -p ${CACHE}/iso
mv minishift-b2d.iso ${CACHE}/iso
mv oc ${CACHE}/oc
mv minishift ~/.local/bin
minishift config import workshop-bundle.cfg

And it would suffice for the user to do:

$ minishift start

[hferentschik]

Then this is useless for a workshop until you implement that. Just letting you know from experience of teaching many workshops. This was a key requirement of being able to use the all in one for workshops.

Having the images cached is a key requirement? All images for a given app? For starters I'd like to just cache the OpenShift image, mainly because this will enhance a lot the startup speed as well. When it comes to "caching" all Docker images, I think the better approach is to use a host folder and let Docker write the data onto the host directly. Then all images will be cached. You can already do that right now, but we need a consistent approach to host folder mounts to make this a general feature.

Can you not cache them in the ISO as part of the image?

What do you mean? When we build the default ISOs? I don't think this is feasible. What could be done is to fork the ISO repo and create an ISO just for a given workshop. Might work, but takes effort and won't be so easy, since the actual data partition for Docker/OpenShift does not get created until boot time.

The two ways of doing this imo are:

• via save/load of the images (this could be made part of the discussed command)
• mount the docker storage directory to the host

[hferentschik]

Would it work to have a template?

Sure, but the idea would be to do this "from within".

[LalatenduMohanty]

My idea was to copy the extra disk i.e. /mnt/sda1 and the user should be able to set up the minishift in a way that use can reuse the /mnt/sda1 partition from the previous setup. This way user can reuse all the cached things. At this point I am not sure if this is doable but interested to spend some time to to see if we can do it.

IMO it should work similar to how current minishift start -> [do your stufff] -> minishift stop -> minishift start works. The only difference is after minishift stop I should be able to take the tar/zip to a different machine and then minishift start or some other command should just start from the last state before minishft stop.

[gbraad]

the data partition is 20G, and maybe even larger in future releases. this seems like a large chunk of data to move around. it is possible to do this without much effort, but it is not the most elegant of approaches. WDYT?

[LalatenduMohanty]

@gbraad Agree. Not an elegant solution if we have to copy 20GB. But as the disk image is thin provisioned the actual copy size will be couple of GBs maximum I think.

[gbraad]

Sparse or not, it is still far from ideal as we also use the disk for swap space and some temp data. This means that no matter what, the disk will have grown to an initial size of at least 2G on first use. Maybe this is acceptable?

[LalatenduMohanty]

@gbraad lets ask @thesteve0 @jorgemoralespou what size they think acceptable. IMO few GBs is ok (but not elegant).

[thesteve0]

For a workshop we need to cache all the builder docker images and all the DB images. This is a must have for being able to use minishift in a workshop scenario. I think 4 should enough

[gbraad]

Experienced it myself today; way to push into the registry as part of the process, but even earlier (from docker images) as the initial origin container is needed to standup an environment

[jorgemoralespou]

@LalatenduMohanty @hferentschik I would not cache the disk, but provide a command load/unload or whatever that does the provisioning. This will take some time (more than using the disk) but also is more reusable. I'm still thinking in profiles ;-)

Main problem with docker save is that it saves full images in a tar, so I would rather have something like this script that does save layers, and them recreates the images. This will save a lot of space. There's probably many tools/ways we can do this with the knowledge our people working with docker have (Like Antonio Murdaca).

Also, when transporting configuration, one needs to know what's different per architecture so you can either provide a bundle per architecture or provide one that fits all. (I'm referring to the oc client in .minishift/cache/oc)

Sorry for being silent lately, but a complex week of travel. Should be back at monitoring you ;-)

[hferentschik]

I would not cache the disk, but provide a command load/unload or whatever that does the provisioning.

I never intended to cache the disk. That makes no sense from what we try to achieve. What we need are the Docker images. The brute force approach is the import/export. But as you say, there are many ways on which we could improve on this. Thanks for the pointers to the scripts. We take a closer look at this, once it becomes more current.

[LalatenduMohanty]

@jorgemoralespou @thesteve0 Is this still relevant because with image caching you can do it with some scripting. Do you still think minishift should be provide this?

[thesteve0]

Yes

Coming at you from my phone, please excuse typos, poor grammar, curtness, and dashing good looks

On Jan 24, 2018 11:54 AM, "Lalatendu Mohanty" notifications@github.com wrote:

@jorgemoralespou https://github.com/jorgemoralespou @thesteve0 https://github.com/thesteve0 Is this still relevant because with image caching you can do it with some scripting. Do you still think minishift should be provide this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/minishift/minishift/issues/397#issuecomment-360094190, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVsw3LUKXUJ-kPOcH-ZHneL4njWNbLiks5tNwvcgaJpZM4L_GPA .

[jorgemoralespou]

@LalatenduMohanty I agree. We need to make this portability just one command. I'll be writing a blog soon about this, but still there's some gotchas that should be fixed.

minishift profile export and minishift profile import.

There's some global configuration that should be preserved when importing if the user already has a minishift install.

[praveenkumar]

@jorgemoralespou What we can have is export and import command on the minishift level and profile level.

@minishift/minishift-dev wdyt?

minishift export => create the tarball of reusable data of minishift
minishit import <tarball> => extract and put it as part of <MINISHIFT_HOME>

minishift profile foo export => create the tarball only for the profile reusable data
minishift profile foo import <tarball> => extract and put as part of given profile.

[LalatenduMohanty]

@praveenkumar Sounds good to me. I would suggest, lets rename issue to address export/import feature .

[gbraad]

We have discussed this before; what are the actual artifacts you can/want to export?

[jorgemoralespou]

I would keep this on the backlog for some more time. There are other issues I would prioritize that could affect this one. e.g. #2532 that could potentially modify how caches are created/stored and could provide also insight into how to do this issue in the future.

[gbraad]

I would not like to discuss/consider this in isolation, but involve what is needed to make #2531 work.

[praveenkumar]

There are other issues I would prioritize that could affect this one. e.g. #2532 that could potentially modify how caches are created/stored and could provide also insight into how to do this issue in the future.

@jorgemoralespou Right but on the top level if you see this will not going to affect other issues as of now. #2532 improves the overall cache experience though.

[praveenkumar]

what are the actual artifacts you can/want to export?

ls -ll ~/.minishift
total 40
drwxrwxr-x. 6 prkumar prkumar 4096 Jun 29 09:42 addons => Need exported
drwxrwxr-x. 5 prkumar prkumar 4096 Jun 29 09:42 cache => Need exported
-rw-rw-r--. 1 prkumar prkumar 1038 Jun 29 17:17 ca.pem
-rw-rw-r--. 1 prkumar prkumar 1078 Jun 29 17:17 cert.pem
drwxrwxr-x. 2 prkumar prkumar 4096 Jun 29 09:44 certs 
drwxrwxr-x. 2 prkumar prkumar 4096 Jun 29 09:42 config => Need exported
-rw-------. 1 prkumar prkumar 1679 Jun 29 17:17 key.pem 
drwxrwxr-x. 2 prkumar prkumar 4096 Jun 29 10:22 logs
drwxrwxr-x. 2 prkumar prkumar 4096 Jun 29 17:40 machines 
drwxrwxr-x. 2 prkumar prkumar 4096 Jun 29 09:42 tmp

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gbraad]

Artifacts should be the project definition, target OpenShift version, and the used containers. This has however been a separate discussion. On Sat, Oct 27, 2018 at 8:41 PM stale[bot] notifications@github.com wrote:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

--

Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.