First set-env for a var always results in a WARNING

[Andreas Hasenack]

The first juju set-env you do for a variable always results in a WARNING. This can be very confusing, as people think juju is checking the variable against a list of valid keys and that they made a typo:

andreas@nsn7:~$ juju unset-env http-proxy
andreas@nsn7:~$
andreas@nsn7:~$ juju unset-env http-proxy
WARNING key "http-proxy" is not defined in the current environment configuration: possible misspelling
andreas@nsn7:~$
andreas@nsn7:~$ juju set-env http-proxy=http://squid.internal:3128/
WARNING key "http-proxy" is not defined in the current environment configuration: possible misspelling
andreas@nsn7:~$
andreas@nsn7:~$ juju get-env http-proxy
http://squid.internal:3128/
andreas@nsn7:~$

That warning is even weirder when you consider that set-env accepts any type of garbage:

andreas@nsn7:~$ juju set-env any-type=of-garbage
WARNING key "any-type" is not defined in the current environment configuration: possible misspelling
andreas@nsn7:~$ juju get-env any-type
of-garbage
andreas@nsn7:~$

[Curtis Hovey (sinzui)]

This issue is specifically about a warning shown when the option doesn't already exist in the env. The env only contains a subset of all legitimate options. You can set-env for any options shown by juju get-env. setting an option for one not listed is not listed and asks if it is a mis-spelling. It make the user recheck their spelling

Juju should know which options are valid and not warn.

[Andreas Hasenack (ahasenack)]

Also affects juju2 beta5.

[Nate Finch (natefinch)]

The warning is bad for several reasons...

1.) It makes it look like you screwed up when you didn't.
2.) It doesn't give *any* useful information - who cares if the value was previously unset?
3.) This code is actually *in place of* code that would actually check that you're setting a valid configuration value.