Update cli parameters for consistency/clarity

[cdrage]

So I'm implementing the api conversion of k8s and I notice that providing api credentials could be simpler.

Can we deprecate the naming of these:

provider = openshift
providerapi = https://127.0.0.1:8443
accesstoken = sadfasdfasfasfdasfasfasdfsafasfd
namespace = mynamespace
providertlsverify = False

to:

provider = openshift
api = https://127.0.0.1:8443
token = sadfasdfasfasfdasfasfasdfsafasfd
namespace = mynamespace
tls = False

Please :)

Seems wayyyyyy simpler and it'll be easier to implement these changes now before GA / 1.0

Thus when I implement k8s and any other provider, the names aren't wacky, ex:

provider = kubernetes
api = https://10.10.10.10:8080
token = sadfasdfasfasfdasfasfasdfsafasfd
namespace = mynamespace
tls = True

[cdrage]

Hi all,

@kadel @dustymabe @rtnpro @surajssd @containscafeine

Any thoughts on this?

This is a blocker for me for the k8s api implementation as I'm adding in the token parameters, ca file, etc.

Everything is implemented (for the most part) except this.

[dustymabe]

I don't really see a reason to change them. I'm also a fan of being more explicit so the longer names don't bother me.

[kadel]

I like sorter names more. But in this case I'm not sure if it is good idea. :-(

My concern is about making it clear what each option represents.
All those parameters are in [general] section so it is not clear what they are setting.
For example If we would have only tls or api than it is not clear for what connections it is.

Longer names are little bit uglier, but from its names it is clear what they are doing.

We also have providerconfig and providercafile, if we decide to make options shorter we should change it to config so at least we have same naming convention
(providerconfig, providerapi, providertlsverify,providercafile) || (config, api, tls, cafile)

[cdrage]

Okay, could we have it more consistent then if we're using the "provider" name?

ex. providertoken, providernamespace

Or dashes?
ex. provider-token, provider-namespace

[dustymabe]

I'd be interested in @jberkus' opinion on this subject.

[jberkus]

So, first, I agree that the existing names are confusing; their length does not add to clarity.

I'm going to go with longer names for the simple reason that Answers is a flat namespace, and we need to accommodate user-supplied variables. Having a built-in Answer, which is optional, but has as short and common a name as "api" or "token" seems liable to lead to user-unexpected conflicts.

I'll also go with dashes, if they're supportable, it's just more readable.

[surajssd]

+1 for dashes.

[cdrage]

+1 for dashes too.

@dustymabe @rtnpro Opinions?

This will need to change before we release for GA.

[cdrage]

(hence blocker)

[dustymabe]

@cdrage, from your email on list you are suggesting we move to:

provider = openshift
provider-api = https://127.0.0.1:8443
provider-token = sadfasdfasfasfdasfasfasdfsafasfd
namespace = mynamespace
provider-tls-verify = False

May I suggest that we change provider-token to provider-auth so that we can support client certificate authentication in the future: see #533.

Also I don't really like having two dashes.. would prefer provider-tlsverify.

[cdrage]

@dustymabe @kadel

provider-auth

makes is more ambiguous so that's good, I agree on that.

Yeah, let's put tlsverify as one word.

[kadel]

I agree with changing it to provider-auth it is going to make it easier to use it with different auth method.

👍 for provider-tlsverify also