juju set is overloaded
Bug #1194945 reported by
David Britton
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| juju-core |
Fix Released
|
High
|
Frank Mueller | ||
Bug Description
When you run:
juju set option=
in juju-core you actually have the perhaps unintended side-effect of setting back to a default value, rather than setting an empty string, or even unsetting the option.
This behavior should really be made more explicit with something like
juju set --default <option> [ <option1> [...]]
Then, you can use
juju set option=
to probably inject an empty string into the value of an option.
Related branches
lp:~themue/juju-core/038-cmd-unset
- Juju Engineering: Pending requested
-
Diff: 592 lines (+365/-167)7 files modifiedcmd/juju/config_test.go (+0/-164)
cmd/juju/deploy_test.go (+2/-2)
cmd/juju/get_test.go (+90/-0)
cmd/juju/set.go (+7/-1)
cmd/juju/set_test.go (+101/-0)
cmd/juju/unset.go (+72/-0)
cmd/juju/unset_test.go (+93/-0)
lp:~themue/juju-core/039-empty-strings-in-charm-config
- Juju Engineering: Pending requested
-
Diff: 136 lines (+16/-29)4 files modifiedcharm/config.go (+0/-5)
charm/config_test.go (+13/-14)
state/service_test.go (+0/-4)
state/statecmd/config_test.go (+3/-6)
lp:~themue/juju-core/042-empty-values
- Juju Engineering: Pending requested
-
Diff: 351 lines (+130/-45)7 files modifiedcharm/config.go (+2/-8)
charm/config_test.go (+13/-14)
state/apiserver/client/client.go (+37/-2)
state/apiserver/client/client_test.go (+58/-7)
state/apiserver/client/export_test.go (+6/-0)
state/apiserver/client/get_test.go (+12/-13)
state/service_test.go (+2/-1)
| Changed in juju-core: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| Changed in juju-core: | |
| assignee: | nobody → Frank Mueller (themue) |
Revision history for this message
| Roger Peppe (rogpeppe) wrote | #1 |
| Changed in juju-core: | |
| status: | Triaged → In Progress |
| Changed in juju-core: | |
| milestone: | none → 1.15.0 |
| Changed in juju-core: | |
| status: | In Progress → Fix Committed |
| Changed in juju-core: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
+1 to the suggestion for a way to get juju set to reset to values.
I think I like "juju set --default" too - another alternative might be "--reset".
There was a suggestion that this might not be sufficient, because
we might want to set values to default in the same transaction
that we set values to explicit values. I can't see a compelling case
for that. If we really want to do that, we can use juju set followed
by juju set --default.
For example, if a charm has two config values, "user" and "password"
where password has a default value of "letmein" and the user
wants to reset the password to its default value while also changing
the user name, she could do:
juju set user=anonymous password=letmein
juju set --default password
The charm should see the user name and password change
once, in a single transaction, but if the charm is upgraded
and the default password happens to change, the password
value will change as appropriate.