Is it possible to configure persistent configuration for all profiles?

[burrsutter]

I seems some configuration setttings are lost in this scenario:

./minishift config set memory 6144
./minishift config set cpus 2
./minishift config set disk-size 20g
./minishift config set vm-driver virtualbox
./minishift start --profile demo1

also, if you latter

./minishift profile delete demo1

the same configuration is still around.
I was expect all my config changes to be tied to a profile.

So, it seems the right solution is to put all the config settings on the minishift start command
BUT, how do I later ask the profile what its configuration is? Are you the 2G or the 6G profile?
Are you the virtualbox or the xyhve profile?

[gbraad]

Thanks for the issues and explanation. We will certainly discuss here...

[gbraad]

Marking as question

[hferentschik]

./minishift config set memory 6144
./minishift config set cpus 2
./minishift config set disk-size 20g
./minishift config set vm-driver virtualbox

You are setting the config values against the currently active profile in this case. So this is either the default profile or another profile which you created and activates later.

If you want to set the config prior to starting the VM, you would need to do something like:

minishift --profile test config set memory 6144

I don't think there is an issue here so far. IMO it is consistent in behaviour. '--profile' is a global option and can be used with any minishift command to ad hoc execute a command against a given profile.

What maybe could be discussed is the behaviour of

 minishift profile set bar

where bar is a non existened profile. In this case you get:

Error: 'bar' is not a valid profile

One could in this case create an empty profile and make it active. This would then allow you to do what you wanted provided you call set profile first.

[gbraad]

I do not believe set should also deal with creating a profile. This feels like an unexpected side-effect that might have typos or just a lucky-guesses ("I think it was demo2") to create a new profile. Using a dedicated create feels more appropriate as the user has an 'expectation' with this, as is, therefore, more cautious and precise in his approach.

[hferentschik]

minishift profile set foo could report to the user that a new (empty) profile got created. I don't see a contradiction here. If you introduce profile create you proliferate commands, also you how do you deal then with cases like minsihft --profile foo config set vm-driver virtualbox? If you have the create command, would you enforce it? Or would you commands like the previous or the start command still create the profile implicitly then? The most consistent behaviour imo is to stick what we have plus changing the way minishift profile set bahaves. This relates to a certain level to #179 where we discussed a split between create and start for a single VM, but I think we said that this ship has sailed.

[gbraad]

What about the situation:

# no profile, global
$ ./minishift config set disk-size 40g
$ ./minishift start --profile demo
# intend to set global settings, reset the defaults (outside of the profile?)
$ ./minishift config set disk-size 20g

or:

# no profile, global
$ ./minishift config set disk-size 40g
$ ./minishift start --profile demo
$ ./minishift profle set demo
# intend to set global settings, reset the defaults (outside of the profile?)
$ ./minishift config set disk-size 20g

I can understand how this can be confusing, as --profile as an option indicates an action that can only happen on the instance (just like hostfolders, see note). While actually, the actions happen in a context. Maybe when a profile is active, we should print the profile name:

$ minishift config set ...
Command will be performed against active profile: 'demo'
Config set

And what if I want to set --iso-url for all instances? /me also confused just reasoning about this.

Note

For adding hostfolder, we added an explicitm hostfolder add ... --instance-only to avoid any confusion, while m hostfolder add ... will always add the hostfolder globally. Does this still work as intended?

[LalatenduMohanty]

@gbraad In a default setup (which does not have any created profile), we always have minishift as a default active profile. This is done to create backward compatibility with previous Minishift releases. May be we can communicate to user which profile is used when he runs config set commands and also improve the documentation explaining minishift is our default profile.

[gbraad]

The default might exist, but in this case I want something to be picked up globally, for all instances. We have all instances config for this particular reason. But how to enable this for use?

[hferentschik]

We have all instances config for this particular reason. But how to enable this for use?

ATM you cannot. We would need an additional flag for the config command, e.g. --global. However, that would only solve some the issues around the config command. I propose a solution without adding another level to the configuration hierarchy. Instead I'd suggest to introduce a profile clone|copy command.

[gbraad]

Instead I'd suggest to introduce a profile clone|copy command.

To me this sounds like the least favourable solution, as this means you will end up having stale profiles, and even disk files just for copying/cloning config from. In this case, a config import and export sound like a better approach as these are distributable and can even be used as a means to preconfigure a certain 'profile' for use.

…

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

[hferentschik]

To me this sounds like the least favourable solution, as this means you
will end up having stale profiles,

Why do you have stale profiles? I guess you mean because you might end up with some "base" profile to clone from? If so, sure. I don't think I would consider them as "stale" though. Also in the most lightweight option we talk about the persistent config and add-ons.

and even disk files just for copying/cloning config from.

Initially we would indeed copy everything except the machine specific files. Moving forward the plan is to share common data - ISO, oc and image cache.

In this case, a config import and export sound like a better approach as these are distributable and can even be used as a
means to preconfigure a certain 'profile' for use.

Provided you include the add-ons into this, I don't see a big difference except the command name. IMO though is "profile" the term which encompasses everything which characterises a given instance. This is more than what the config command deals with. Hence my suggestion to add a new command to profiles. Semantically there is not a big difference here, especially once caching is fully worked out.

[jorgemoralespou]

You already know my preference here. I agree with @gbraad that a global configuration store should exist and a local(profile) configuration store, and avoid clone/copy as an additional command. What would you copy/clone?

I've opened a new Issue as RFE to discuss there how this should work, as this issue is a question that should not deviate to a different topic. #1517

[LalatenduMohanty]

We can close this after #1605 is merged.

[LalatenduMohanty]

Also here are two work flows how persistent configurations can be set.

#To create a new profile foo with specific configurations, run:

$ minishift profile set foo
$ minishift config set memory 4GB
$ minishift config set cpus 2
$ minishift addon enable anyuid
$ minishift start

Alternate method to create the profile foo:

$ minishift --profile foo config set memory 4GB
$ minishift --profile foo config set cpus 2
$ minishift --profile foo addon enable anyuid
$ minishift --profile foo minishift start