Disallow booleans in environment #2000

mnowster · 2015-09-07T15:48:21Z

This change will force people to put boolean values in quotes, thus ensuring
that the value gets passed through as intended.

Fixes #1788

mnowster · 2015-09-07T16:19:55Z

:person_frowning: the test failures are not to do with the changes, as far as I can tell.

aanand · 2015-09-08T19:07:56Z

This will likely break a lot of existing files. Although the fix is simple, I think my vote would go to auto-converting boolean values to "true" and "false". @dnephin, @shin- - thoughts?

shin- · 2015-09-08T19:28:02Z

Yeah, on top of that, forcing explicit quotes is really unwieldy. I'd rather we convert boolean env variables to strings instead.

The small downside is that yes and no will be transformed if they're not quoted, but that's the case right now anyway.

dnephin · 2015-09-08T19:28:27Z

compose/config/fields_schema.json

+            {
+              "type": "object",
+              "patternProperties": {
+                "^[a-zA-Z0-9_]+$": {


I think we should actually relax this to be any character (or maybe anything but dash). While bash may not support everything, swarm at least needs colons (http://docs.docker.com/swarm/scheduler/filter/#affinity-filter), so it might be easier to just allow most characters for now.

aanand · 2015-09-08T19:33:12Z

The small downside is that yes and no will be transformed if they're not quoted, but that's the case right now anyway.

Oh, yuck. That's a pretty strong downside in my opinion (and reminds me - we've had the same problem with other options, e.g. command: yes becomes "Command": ["True"]).

dnephin · 2015-09-08T19:34:46Z

compose/config/fields_schema.json

@@ -37,7 +37,15 @@

        "environment": {


should this use the list_or_dict schema? maybe there are differences between them?

I didn't use list_or_dict for this one as we define some extra constraints in the patternProperties for the allowed key names. I was being restrictive cos I was worried about character compatibility for different systems.

I think these constraints here are the same ones we'd want for labels, and most likely for extra_hosts as well (where are the two places that list_or_dict is used).

What do you think about moving this to be the new definition of list_or_dict ?

If we do that, I think we'd want to change the format to something like non_bool_scalar

I honestly can't remember now why I thought they had separate requirements and I can't find it in my notes. If you can't think of any issues with doing that, I think that's a good suggestion, I will amend. Thanks.

Oh, hmm, so I guess dashes are valid in label and hostnames, so that is one issue. We could just relax this to "any character" which would make it usable for all three.

I think that would be better in a separate PR as it effects other fields. I'll look at doing that after this one has gone in.

cool, that sounds fair

dnephin · 2015-09-08T19:40:37Z

I really don't like converting types to other types. I prefer the strict option (as it's implemented) of failing, and documenting it in the reference. If someone wants a string, they should use a string!

If we suspect this is a common enough case, maybe we could allow for bools, but add a warning that it will be deprecated in the future. Give them a chance to upgrade and fix their config to use strings, and then remove it in the next release?

aanand · 2015-09-08T19:58:18Z

If we suspect this is a common enough case, maybe we could allow for bools, but add a warning that it will be deprecated in the future. Give them a chance to upgrade and fix their config to use strings, and then remove it in the next release?

+1. I do suspect it's common - there must be lots out there like this:

environment:
  DEBUG: true

shin- · 2015-09-08T21:02:05Z

If someone wants a string, they should use a string!

But in most cases a literal value (without explicit quotes) will translate to a string in YAML, which is... fine in most situations.

dnephin · 2015-09-10T17:29:02Z

compose/config/validation.py

@@ -44,6 +48,20 @@ def format_ports(instance):
    return True


+@FormatChecker.cls_checks(
+    format="environment")


minor: this could be a single line

I had been trying to do something clever previously with calling the log.warn instead of an exception but it didn't pan out. So yep, I'll make it one line.

When users were putting true/false/yes/no in the environment key, the YML parser was converting them into True/False, rather than leaving them as a string. This change will force people to put them in quotes, thus ensuring that the value gets passed through as intended. Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>

We're going to warn people that allowing a boolean in the environment is being deprecated, so in a future release we can disallow it. This is to ensure boolean variables are quoted in strings to ensure they don't get mis-parsed by YML. Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>

One of the use cases is swarm requires at least : character, so going from conservative to relaxed. Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>

aanand · 2015-09-15T15:24:56Z

LGTM

…onment Disallow booleans in environment

- general_log does not work with /dev/stdout - docker/compose#2000 true needs to be in quotes Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>

GordonTheTurtle added the status/0-triage label Sep 7, 2015

dnephin mentioned this pull request Sep 8, 2015

Improve validation schema for list_or_dict fields #2008

Closed

dnephin reviewed Sep 8, 2015
View reviewed changes

dnephin added kind/bug area/config labels Sep 8, 2015

dnephin reviewed Sep 8, 2015
View reviewed changes

dnephin reviewed Sep 10, 2015
View reviewed changes

mnowster force-pushed the do-not-allow-booleans-in-environment branch 3 times, most recently from 979cb3e to 03c2e34 Compare September 15, 2015 14:09

mnowster added 3 commits September 15, 2015 15:33

Relax constraints on key naming for environment

4b2fd76

One of the use cases is swarm requires at least : character, so going from conservative to relaxed. Signed-off-by: Mazz Mosley <mazz@houseofmnowster.com>

mnowster force-pushed the do-not-allow-booleans-in-environment branch from 03c2e34 to 4b2fd76 Compare September 15, 2015 14:40

aanand added a commit that referenced this pull request Sep 15, 2015

Merge pull request #2000 from mnowster/do-not-allow-booleans-in-envir…

041a1ff

…onment Disallow booleans in environment

aanand merged commit 041a1ff into docker:master Sep 15, 2015

naumvd95 mentioned this pull request Apr 6, 2018

Kqueen ldap Mirantis/kqueen-ui#52

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disallow booleans in environment #2000

Disallow booleans in environment #2000

mnowster commented Sep 7, 2015

mnowster commented Sep 7, 2015

aanand commented Sep 8, 2015

shin- commented Sep 8, 2015

dnephin Sep 8, 2015

aanand commented Sep 8, 2015

dnephin Sep 8, 2015

mnowster Sep 10, 2015

dnephin Sep 10, 2015

mnowster Sep 10, 2015

dnephin Sep 10, 2015

mnowster Sep 14, 2015

dnephin Sep 14, 2015

dnephin commented Sep 8, 2015

aanand commented Sep 8, 2015

shin- commented Sep 8, 2015

dnephin Sep 10, 2015

mnowster Sep 10, 2015

aanand commented Sep 15, 2015

Disallow booleans in environment #2000

Disallow booleans in environment #2000

Conversation

mnowster commented Sep 7, 2015

mnowster commented Sep 7, 2015

aanand commented Sep 8, 2015

shin- commented Sep 8, 2015

Choose a reason for hiding this comment

aanand commented Sep 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dnephin commented Sep 8, 2015

aanand commented Sep 8, 2015

shin- commented Sep 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aanand commented Sep 15, 2015