Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"pulumi config set" allow invalid config key #2171

Closed
ncsibra opened this issue Nov 7, 2018 · 0 comments
Closed

"pulumi config set" allow invalid config key #2171

ncsibra opened this issue Nov 7, 2018 · 0 comments
Assignees
@ellismg
Milestone
0.19

Comments

@ncsibra
Copy link

ncsibra commented Nov 7, 2018

I played a little with pulumi config and found, that there's some backward compatible logic when fetching config values(removing of the ":config" part from the key).
I was able to set an invalid key, without any error, which caused an error during get.

  ➜ ✗ pulumi config set a:b:c 3                                
error: invalid configuration key: a:b:c is not in config module
  ➜ ✗ pulumi config set a:config:b:c 3                         
  ➜ ✗ pulumi config                                            
error: could not unmarshal map: a:b:c is not in config module

Pulumi version: v0.16.2.
@lukehoban lukehoban added this to the 0.19 milestone Nov 7, 2018
ellismg added a commit that referenced this issue Nov 19, 2018
@ellismg
Don't fail on configuration keys like a:config:b:c
dbf823d 
Configuration keys are simple namespace/name pairs, delimited by
":". For compatability, we also allow
"<namespace>:config:<name>", but we always record the "nice" name in
`Pulumi.<stack-name>.yaml`.

While `pulumi config` and friends would block setting a key like
`a:b:c` (where the "name" has a colon in it), it would allow
`a:config:b:c`. However, this would be recorded as `a:b:c` in
`Pulumi.<stack-name>.yaml`, which meant we'd error when parsing the
configuration file later.

To work around this, disallow ":" in the "name" part of a
configuration key.  With this change the following all work:

```
keyName
my-project:keyName
my-project:config:keyName
```

However, both

`my-project:keyName:subKey`
`my-project:config:keyName:subKey`

are now disallowed.

I considered allowing colons in subkeys, but I think it adds more
confusion (due to the interaction with how we allow you elide the
project name in the default case) than is worthwile at this point.

Fixes #2171
ellismg added a commit that referenced this issue Nov 19, 2018
@ellismg
Don't fail on configuration keys like a:config:b:c
9e45adc 
Configuration keys are simple namespace/name pairs, delimited by
":". For compatability, we also allow
"<namespace>:config:<name>", but we always record the "nice" name in
`Pulumi.<stack-name>.yaml`.

While `pulumi config` and friends would block setting a key like
`a:b:c` (where the "name" has a colon in it), it would allow
`a:config:b:c`. However, this would be recorded as `a:b:c` in
`Pulumi.<stack-name>.yaml`, which meant we'd error when parsing the
configuration file later.

To work around this, disallow ":" in the "name" part of a
configuration key.  With this change the following all work:

```
keyName
my-project:keyName
my-project:config:keyName
```

However, both

`my-project:keyName:subKey`
`my-project:config:keyName:subKey`

are now disallowed.

I considered allowing colons in subkeys, but I think it adds more
confusion (due to the interaction with how we allow you elide the
project name in the default case) than is worthwile at this point.

Fixes #2171
ellismg added a commit that referenced this issue Nov 19, 2018
@ellismg
Don't fail on configuration keys like a:config:b:c
a1cfb57 
Configuration keys are simple namespace/name pairs, delimited by
":". For compatability, we also allow
"<namespace>:config:<name>", but we always record the "nice" name in
`Pulumi.<stack-name>.yaml`.

While `pulumi config` and friends would block setting a key like
`a:b:c` (where the "name" has a colon in it), it would allow
`a:config:b:c`. However, this would be recorded as `a:b:c` in
`Pulumi.<stack-name>.yaml`, which meant we'd error when parsing the
configuration file later.

To work around this, disallow ":" in the "name" part of a
configuration key.  With this change the following all work:

```
keyName
my-project:keyName
my-project:config:keyName
```

However, both

`my-project:keyName:subKey`
`my-project:config:keyName:subKey`

are now disallowed.

I considered allowing colons in subkeys, but I think it adds more
confusion (due to the interaction with how we allow you elide the
project name in the default case) than is worthwhile at this point.

Fixes #2171
@ellismg ellismg mentioned this issue Nov 19, 2018
Merged
ellismg added a commit that referenced this issue Nov 20, 2018
@ellismg
Don't fail on configuration keys like a:config:b:c
fb58060 
Configuration keys are simple namespace/name pairs, delimited by
":". For compatability, we also allow
"<namespace>:config:<name>", but we always record the "nice" name in
`Pulumi.<stack-name>.yaml`.

While `pulumi config` and friends would block setting a key like
`a:b:c` (where the "name" has a colon in it), it would allow
`a:config:b:c`. However, this would be recorded as `a:b:c` in
`Pulumi.<stack-name>.yaml`, which meant we'd error when parsing the
configuration file later.

To work around this, disallow ":" in the "name" part of a
configuration key.  With this change the following all work:

```
keyName
my-project:keyName
my-project:config:keyName
```

However, both

`my-project:keyName:subKey`
`my-project:config:keyName:subKey`

are now disallowed.

I considered allowing colons in subkeys, but I think it adds more
confusion (due to the interaction with how we allow you elide the
project name in the default case) than is worthwhile at this point.

Fixes #2171
ellismg added a commit that referenced this issue Nov 20, 2018
@ellismg
Don't fail on configuration keys like a:config:b:c
d0e4864 
Configuration keys are simple namespace/name pairs, delimited by
":". For compatability, we also allow
"<namespace>:config:<name>", but we always record the "nice" name in
`Pulumi.<stack-name>.yaml`.

While `pulumi config` and friends would block setting a key like
`a:b:c` (where the "name" has a colon in it), it would allow
`a:config:b:c`. However, this would be recorded as `a:b:c` in
`Pulumi.<stack-name>.yaml`, which meant we'd error when parsing the
configuration file later.

To work around this, disallow ":" in the "name" part of a
configuration key.  With this change the following all work:

```
keyName
my-project:keyName
my-project:config:keyName
```

However, both

`my-project:keyName:subKey`
`my-project:config:keyName:subKey`

are now disallowed.

I considered allowing colons in subkeys, but I think it adds more
confusion (due to the interaction with how we allow you elide the
project name in the default case) than is worthwhile at this point.

Fixes #2171
ellismg added a commit that referenced this issue Nov 20, 2018
@ellismg
Don't fail on configuration keys like a:config:b:c
72d52c6 
Configuration keys are simple namespace/name pairs, delimited by
":". For compatability, we also allow
"<namespace>:config:<name>", but we always record the "nice" name in
`Pulumi.<stack-name>.yaml`.

While `pulumi config` and friends would block setting a key like
`a:b:c` (where the "name" has a colon in it), it would allow
`a:config:b:c`. However, this would be recorded as `a:b:c` in
`Pulumi.<stack-name>.yaml`, which meant we'd error when parsing the
configuration file later.

To work around this, disallow ":" in the "name" part of a
configuration key.  With this change the following all work:

```
keyName
my-project:keyName
my-project:config:keyName
```

However, both

`my-project:keyName:subKey`
`my-project:config:keyName:subKey`

are now disallowed.

I considered allowing colons in subkeys, but I think it adds more
confusion (due to the interaction with how we allow you elide the
project name in the default case) than is worthwhile at this point.

Fixes #2171
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ellismg ellismg

Labels
None yet
Projects
None yet
Milestone
0.19
Development

No branches or pull requests
3 participants
@lukehoban @ncsibra @ellismg