Openshift provider: Overwriting options from provider-config using commandline arguments

[kadel]

Currently, when you are using OpenShift provider argument in provider-config and arguments specified using commandline arguments must be consistent. It is not possible to overwrite them from command line :-(

Example: If your OpenShift config file (provider-config) has active project set to proj1 and you want deploy something to project proj2 It is not possible to overwrite that value by simply adding --namespace=proj2 to atomicapp. You have to change project in OpenShift config file first (using oc project proj2 or by editing config file manually), and than you have to run atomicapp again with --namespace=proj2 (you have to switch project in two places) Same is true for other parameters like provider-cafile.

Proposal: Command-line argument should have higher priority and they should overwrite whatever is in provider-config. For example if you set --namespace from command-line, project setting from provider-config should be ignored.

[surajssd]

I would like to pick it.

[dustymabe]

@kadel - I think the original idea was that you use either provider-config OR "a combination of the other options" to talk to openshift/kube. I agree with you that command line overrides are nice, but right now I don't think we have any way to know if we are providing a value from the command line or if it got picked up from the answers.conf file.

I think if we had an easy way to tell where a value came from then we could easily pull this off. This should be done as part of the work for https://github.com/projectatomic/atomicapp/issues/524

[kadel]

It is not possible to know if value is from answers.conf or from command line that I agree. But inside openshift.py it is possible to know if value is from parsed provider-config or from answers/command-line, this should be enough to pull this off, at least for openshift provider where this is the biggest pain, as far as I see it.

[surajssd]

yes, openshift.py does not require any hacks to do this because all the information is available already.

[dustymabe]

Here is the problem:

1 - namespace=default in answers.conf 2 - user provides --namespace=project1 on command line 3 - .kube/config contains namespace=project2

In this case you want the namespace to be "project1" because it was set from the command line. But what about this scenario:

1 - namespace=default in answers.conf 2 - nothing provided on command line 3 - .kube/config contains namespace=project2

Now in this case your namespace would be "default" because there is no way to know if the value provided came from the cli or from answers.conf. That is why we have enforced that the values from provider-config and answers match if there are values in both places for the same variable up until this point.

[kadel]

1 - namespace=default in answers.conf 2 - nothing provided on command line 3 - .kube/config contains namespace=project2

Now in this case your namespace would be "default" because there is no way to know if the value provided came from the cli or from answers.conf.

Yes and I don't see problem in using "default" project in this case. As first time user I would actually expect this behavior. Yes we ignore project settings from .kube/config, but I don't see that being problem. I think that this is same behavior as in Kubernetes provider (but not sure, haven't check that). Anything that you set in Atomic App should have priority from .kube/config.

To me honest, because of this, it is really painful to work with Atomic App and OpenShift.

[dustymabe]

I think if namespace wasn't a default value in the answers.conf then you would be right. The user doesn't have to set it manually though, as there is a default. By giving us a provider-config the user has told us to "find" the answers over here instead.. At least this is the way I interpret it.

I agree that if the user added --namespace to the command line then we should use that and not require the value in the .kube/config file to be the same, but as I've pointed out there is no way to make the distinction right now inside of Atomic App of where the "answers" value came from (either the answers file or from the command line). I think we should wait until we can make that distinction before doing this.

[kadel]

Me and @dustymabe discussed this little bit more and decided that this is going to be part of #524

One workaround specifying namespace is to delete namespace setting from answers.conf and not use --namespace argument, than namespace can by changed just in .kube/config using oc project.

[surajssd]

so this means --provider-config becomes compulsory?

[dustymabe]

so this means --provider-config becomes compulsory?

No. You don't have to specify provider-config at all if you want to specify all values in the answers.conf file.

However, if you are providing --provider-config every time on the command line, you can alternatively just set it in the answers file so you wouldn't have to do that every time. There is some talk of whether we should add logic to automatically pick up the config file from the user's home directory or not.