Create a global configuration store and inherit configuration for profiles

[jorgemoralespou]

This is a RFE for adding the ability to have a global configuration store for minishift, where you can set configuration, addons, etc.. that would apply to any new created profile.

I would like all my instances to have 8 GB of memory and 2 GB of ram and always use virtualbox, and I want always to install the addon user by default.

$ minishift config set --global memory 8GB
$ minishift config set --global cpus 2
$ minishift config set --global vm-driver virtualbox
$ minishift addon enable --global admin-user

Then if I create a new profile(instance) I'll have that configuration applied:

$ minishift start --profile example
-- Creating vm using Virtualbox with 8GB ram and 2 cpus

If I want to provide some other configuration, I can do:

$ minishift config set --profile otherexample memory 4GB
$ minishift start --profile otherexample
-- Creating vm using Virtualbox with 4GB ram and 2 cpus 

or

$ minishift start --profile otherexample --memory 4GB
-- Creating vm using Virtualbox with 4GB ram and 2 cpus
$ minishift config list --profile otherexample
-- memory=4GB
-- cpu=2 (global)
-- vm-driver=virtualbox (global) 

In this way I can easily define what are my typical defaults, and what are my explicit non-defaults.

Then I can delete a profile safely, and create a new one, and will inherit the defaults if nothing else specified. You can probably do this currently via environment variables on your shell, but this is not intuitive, and a user would most likely not know where things are configured. This way provides consistency in that a user can do "minishift config list [--profile profile]" and see the configuration applied to the profile, either because it's global and inherited, or because the user has set it.

This should also be where cached images, oc clients, isos should be stored, in a global configuration space, and maybe only symlinked in the specific profile. This would help not bloat the system, and reduce startup speed of every new instance.

[hferentschik]

See also #1480

[hferentschik]

Also an alternative approach which could be a stepping stone is the ability to copy a given profile. See #1480 (comment)

Adding a global option to the config and addon command leave several open questions which would need first discussing/resolution. A profile copy command could easily be added w/o breaking consistency. In the long run a --global flag could exist in parallel to a profile copy command.

[jorgemoralespou]

Why adding a new command? copy/clone? What would it copy? What if I don't want to copy everything from one profile? Should I create "bare" profiles that I will not run just to hold the things I want to copy as "templates"?

[hferentschik]

Some question around a global switch:

• How do we display global vs local config in commands like minishift config view? Just display the merged config
• Where do we store the shared config? allinstances.json? Should we in this case take the step and move the default profile into the profiles directory?
• minishift addon enable --global admin-user - what are the semantics here? What if this is not a default add-on. Does this command also copy the add-on or does it just enable it? In the latter, it would then get ignored when minishift start is called, since it would not be installed in the new profile (add-ons are not shared between profiles). If it is supposed to copy the add-on, the question becomes from where?

[hferentschik]

This should also be where cached images, oc clients, isos should be stored, in a global configuration space,

That's an independent issue really and yes, the aim is to share cached images, oc clients, isos

and maybe only symlinked in the specific profile.

no symlinks needed. Also on Windows that would not even work

[jorgemoralespou]

@hferentschik

How do we display global vs local config in commands like minishift config view? Just display the merged config

$ minishift config view [--profile otherexample]
-- memory=4GB
-- cpu=2 (global)
-- vm-driver=virtualbox (global) 

Where do we store the shared config? allinstances.json? Should we in this case take the step and move the default profile into the profiles directory?

Yes. In a place where "minishift delete --profile xxx" would not destroy, and that by default if I just install minishift, I will have.

minishift addon enable --global admin-user - what are the semantics here? What if this is not a default add-on. Does this command also copy the add-on or does it just enable it? In the latter, it would then get ignored when minishift start is called, since it would not be installed in the new profile (add-ons are not shared between profiles). If it is supposed to copy the add-on, the question becomes from where?

No, if it's not default addon, then a "install --global" would be needed.

[gbraad]

Global config is in line what my thinking when I worked on hostfolders. It was renamed to allinstances instead, but I still believe it is the better option.

Jumbling with copy and clones from other prifiles feels cumbersome and convoluted.

+1

[gbraad]

In hostfolders precendence is as follows

• default
• all instances (global) overrides
• instance config override is final

In the case of hostfolders it is not displayed, but we can alter this.

[gbraad]

Also on Windows that would not even work

Windows has junctions and these work similarly
Ref: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx

[gbraad]

I have the situation I often perform... and I will write it as suggested by both

global

minishift config set --global iso-url centos
minishift config set --global memory 4G
minishift config set --global disk-size 8G
minishift config set --global check-network-http-host http://10.0.75.1:5000/v2/
minishift config set --global check-network-ping-host 10.0.75.1
minishift config set --global insecure-registry 10.0.75.1
minishift config set --global registry-mirror http://10.0.75.1:5000
minishift config set --global hyperv-virtual-switch DockerNAT  # I wish this was implemented!
minishift config set --global network-netmask 24
minishift config set --global network-gateway 10.0.75.1
minishift config set --global network-nameserver 8.8.8.8

minishift start --profile openshift01 --network-ipaddress 10.0.75.128
minishift start --profile openshift02 --network-ipaddress 10.0.75.129

Copy/clone

minishift start --profile mirror-registry-centos-dockernat
CTRL+c
minishift profile delete mirror-registry-centos-dockernat
# or minishift profile set mirror-registry-centos-dockernat    # sounds like a side-effect too create this way

minishift config set --profile mirror-registry-centos-dockernat iso-url centos
minishift config set --profile mirror-registry-centos-dockernat memory 4G
minishift config set --profile mirror-registry-centos-dockernat disk-size 8G
minishift config set --profile mirror-registry-centos-dockernat check-network-http-host http://10.0.75.1:5000/v2/
minishift config set --profile mirror-registry-centos-dockernat check-network-ping-host 10.0.75.1
minishift config set --profile mirror-registry-centos-dockernat insecure-registry 10.0.75.1
minishift config set --profile mirror-registry-centos-dockernat registry-mirror http://10.0.75.1:5000
minishift config set --profile mirror-registry-centos-dockernat hyperv-virtual-switch DockerNAT  # I wish this was implemented!
minishift config set --profile mirror-registry-centos-dockernat network-netmask 24
minishift config set --profile mirror-registry-centos-dockernat network-gateway 10.0.75.1
minishift config set --profile mirror-registry-centos-dockernat network-nameserver 8.8.8.8

minishift profile copy mirror-registry-centos-dockernat openshift01
minishift start --profile openshift01 --network-ipaddress 10.0.75.128

minishift profile copy mirror-registry-centos-dockernat openshift02
minishift start --profile openshift02 --network-ipaddress 10.0.75.129

Conclusion

As you can see, I have several settings I use globally, that will never change between instances. But with a copy, this would always have to involve creating a 'profile store' to keep the settings in, and making this available before the instance gets started.

[jorgemoralespou]

I think the experience can be improved for the copy & clone, as I don't fully opose to this option as intermediate step and/or alternate.

I'll rewrite your example:

minishift start --profile mirror-registry-centos-dockernat --bare # This can instruct this is a template profile. No control c needed as "--bare" will just create a non-runnable profile

minishift config set --profile mirror-registry-centos-dockernat iso-url centos
minishift config set --profile mirror-registry-centos-dockernat memory 4G
minishift config set --profile mirror-registry-centos-dockernat disk-size 8G
minishift config set --profile mirror-registry-centos-dockernat check-network-http-host http://10.0.75.1:5000/v2/
minishift config set --profile mirror-registry-centos-dockernat check-network-ping-host 10.0.75.1
minishift config set --profile mirror-registry-centos-dockernat insecure-registry 10.0.75.1
minishift config set --profile mirror-registry-centos-dockernat registry-mirror http://10.0.75.1:5000
minishift config set --profile mirror-registry-centos-dockernat hyperv-virtual-switch DockerNAT  # I wish this was implemented!
minishift config set --profile mirror-registry-centos-dockernat network-netmask 24
minishift config set --profile mirror-registry-centos-dockernat network-gateway 10.0.75.1
minishift config set --profile mirror-registry-centos-dockernat network-nameserver 8.8.8.8

minishift start --profile openshift01 --from-profile mirror-registry-centos-dockernat --network-ipaddress 10.0.75.128 # Uses the bare profile as --from-profile to copy the settings from there

minishift start --profile openshift02 --from-profile mirror-registry-centos-dockernat --network-ipaddress 10.0.75.129

This is less verbose and provides a "nicer" experience. But eventually, the last command is what struggles me most, but could work for the time being.

[LalatenduMohanty]

I think minishift profile copy command makes sense as the first step and the global config can be a long run fix. Because IMO there will be two kind of users

1. Users will copy one profile to another and then modify stuff. As it creates an physiological thought process that profiles are isolated from each other.
2. Users who will like to have global config which will be applicable to all profiles.

P:S: profile clone might not be a good idea as clone means it should be exactly the same. But we will not reuse every artifacts in the new profile.

[LalatenduMohanty]

Created a separate issue #1649 for profile copy/clone feature

[jorgemoralespou]

@LalatenduMohanty where do we stand with this feature? IMHO this should be high priority, and I see it keep postponing.
When working with profiles, what most annoys me is the fact I need to repeat many configuration I always want for my profiles (mem, cpus, iso-url, image-cache,...).

It's really annoying.

[LalatenduMohanty]

@LalatenduMohanty where do we stand with this feature? IMHO this should be high priority, and I see it keep postponing.
When working with profiles, what most annoys me is the fact I need to repeat many configuration I always want for my profiles (mem, cpus, iso-url, image-cache,...).

It's really annoying.

We are going to schedule it in the current sprint.

[LalatenduMohanty]

Resolved via 563b6f8 #2616