Provide mechanism to configure OpenShift

[hferentschik]

At least for the CDK usecase we need a way to configure OpenShift with a given set of templates (and potentially run other oc administration commands).

The question is whether we build anything specific into minishift or whether we just include a couple of config (JSON) files as part of the release bundle and let the user run the oc create command. I could image a 'openshift-create' flag in minishift which when specified and pointing to a file/directory processes all found json files. This somehow automates the process a bit.

Also in some cases it might be necessary to change the config of OpenShift directly. How is this going to work? Is minishift providing any means beyond minishift ssh?

Me preferred setup of minishift is the one where the OpenShift setup is mapped out onto the host. This way OpenShift settings persist even across VM re-creation and it allows to make any OpenShift config changes directly by editing the config file on the host. Problem with that is, that host mounts are not stable across OSes and virtualization frameworks.

Thoughts?

[praveenkumar]

The question is whether we build anything specific into minishift or whether we just include a couple of config (JSON) files as part of the release bundle and let the user run the oc create command.

I think till now minishift had some of the example templates. if we add as part of minishift then we also make sure it's get updated when upstream template get update.

Is minishift providing any means beyond minishift ssh?

There is config flag in earlier minishift version, it have some capability like set, get, unset and view but I didn't try it, might be worth to take a look.

Problem with that is, that host mounts are not stable across OSes and virtualization frameworks.

That is valid point and it not going to work with different providers.

[LalatenduMohanty]

The question is whether we build anything specific into minishift or whether we just include a couple of config (JSON) files as part of the release bundle and let the user run the oc create command. I could image a 'openshift-create' flag in minishift which when specified and pointing to a file/directory processes all found json files. This somehow automates the process a bit.

I would suggest to make it part of default experience.

For templates oc cluster up i.e #167 provides some templates out of the box. Are we talking about some more templates?

[hferentschik]

For templates oc cluster up provides some templates out of the box.

Sure, but how does one change these. Replace them with others or add additional configuration, not necessarily only app templates. How are we solving this for CDK?

Are we talking about some more templates?

We are talking about a generic way of applying configuration and whether minishift is involved at all or whether we basically say, once the initial OpenShift instance is up, it us up to the user to configure OpenShift in whatever ways by using for example the oc command.

[jorgemoralespou]

For templates oc cluster up provides some templates out of the box.

Sure, but how does one change these. Replace them with others or add additional configuration, not necessarily only app templates. How are we solving this for CDK?

Should be as easy as --skip-configuration. This should also be supported by "oc cluster up" but that change can be requested to them.

Are we talking about some more templates?

We are talking about a generic way of applying configuration and whether minishift is involved at all or whether we basically say, once the initial OpenShift instance is up, it us up to the user to configure OpenShift in whatever ways by using for example the oc command.

Once the instance is up, a user will probably want to further configure their cluster, so I would think that there needs to be something like:

• minishift start --config=my_config // This could apply the configuration at bootstrap (Could be cool if oc cluster supported this, but even if not, it's easy to do, like I do in the oc-cluster-wrapper)
• minishift start --skip-config // This will not load any of the "by default" bootstrapping
• minishift start // Out of the box cluster with default configuration/bootstraping

Also, if "oc cluster up" provided a way to configure it, it could be cool to extend that same mechanism to minishift, so that minishift just calls same mechanism, and people can use same "configuration" for minishift or "oc cluster up". Then allow to use this from addons, and support people creating their own addons, while providing maybe some by default.

[hferentschik]

@jorgemoralespou +1, I am basically thinking along the same lines. The details need to be discussed, but I think something in this form makes most sense.

[LalatenduMohanty]

+1 @jorgemoralespou.

One thing to keep in mind that the default configuration (e.g templates )of minishift start in CDK vs upstream Minishift might differ.

[hferentschik]

See also #59.

[hferentschik]

So here is my current thinking around this. Following up on issue #276, we will have a minishift openshift context. Under this context we add:

$ minishift openshift package [view|enable|disable|export|install]

A Package or maybe OpenShiftConfigPackage is an interface with two methods methods apply and isExportable. A default and probably most commonly used implementation of Package is OcPackage, which is basically a package containing of a list of oc command which need to be executed to enable a certain functionality.

We will have our own internal list of packages we always apply, eg exposure of the OpenShift registry (see #254), and we will (further down the road) also maintain several common add on packages which a user can use. A user can use minishift openshift package view to see which packages are available and which ones are enabled. He can also enable (and potentially disable them) via minishift openshift package [enable|disable] [name].

OcPackage instance can also be exported (minishift openshift package export [name]) to get a list of oc commands. The user can modify it and then use this new custom package. One can install a package by minishift openshift package install <file> which copies the package into the MINISHIFT_HOME directory from where it will be picked up.

Last but not least, we add a OpenShiftConfigurator to the bootstrapping process whose tasks it is to determine which implicit and explicit defined packages to apply.

This mechanism should allow us to maintain and offer well known packages for ease of use, but also give the user the ability to define its own custom configuration.

There are several details which still needs some thoughts, but it would be the basic approach. Thoughts?

[gbraad]

@hferentschik the idea is a good improvement, but package sounds a lot like a software package. Of course naming is always a difficult thing, but maybe ConfigurationBundle sounds clearer about the intention?

As in: a bundle of (configuration) commands which we run against OpenShift

Hope we can keep this as much as possible as a separate tool that we consume, as the use-case seems very generic. This way it is possible to have "which we" be substituted by any other invoker.

[hferentschik]

_Bundle _or better ConfigBundle sounds indeed better +1

Hope we can keep this as much as possible as a separate tool that we consume, as the use-case seems very generic. This way it is possible to have "which we" be substituted by any other invoker.

+1

[hferentschik]

See also #207 (comment)

[hferentschik]

@jorgemoralespou, out of your experience what type of commands does one need to do configuration of OpenShiff. Obviously oc, but do you also need to run arbitrary system commands on the VM for example (via ssh). I am trying to figure out whether for a user provided configuration bundle we get away with a list of oc commands which we just execute, or whether we need to handle different types of commands (ssh, oc, openshift) and hence maybe need to put some sort of DSL on top. WDYT?

[jorgemoralespou]

@hferentschik so far, in my experience all where "oc" and "oc adm" and "openshift" commands to deploy stuff and change configuration.
Also I have some util functions to check things like:

• Is it connected to internet (for when the plugin will pull down things from the internet, not to execute if there's no connectivity) example
• Provide some self values like:
  • default domain (in case templates need to provide the domain suffix) example
  • default ip of the master example
• ability to provide some templates to be processed example
• ability to patch config example

Adding some more people to chime in. @GrahamDumpleton @siamaksade @marekjelen @thesteve0

[hferentschik]

@jorgemoralespou awesome, thanks a lot. That helps a lot.

[hferentschik]

@jorgemoralespou regarding self referencing values, would you think that we can define a reasonable subset of variables (ip, route suffix, etc) which is useful. I don't think it is realistic to be able to "interpolate" any sort of variable used w/i OpenShift. WDYT?

[hferentschik]

Merged via pull request #625