actions.yaml schema does not support "float"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Low
|
Unassigned |
Bug Description
when authoring a charm action, received error on testing:
$ juju upgrade-charm swift-proxy --path `pwd`/charm-
ERROR invalid params schema for action schema update-replicas: float is not a valid type
actions.yaml entry for update-replicas action is below.
update-replicas:
description: |
Update object, account, and container server replica count
Useful when needing to slowly weight up or down between replica settings
Implements 'Make ring's replica count adjustable' blueprint in charm
https:/
This action will trigger a rebalance and synchronization of the builder
and ring files
params:
replicas:
type: float
description: |
Number of replicas (floating point replicas can be used to gradually
reweight replica changes to reduce replication i/o overhead)
Example - 3.0
server:
type: string
description: |
One of "account", "container", or "object". "all" can be specified
to make the change to all 3 builder/ring settings
required:
- replicas
- server
Changed type: to "string" in actions.yaml and get the following error trying to input a floating point number:
$ juju run-action swift-proxy/1 update-replicas server=object replicas=2.9
ERROR validation failed: (root).replicas : must be of type string, given 2.9
$ juju run-action swift-proxy/1 update-replicas server=object replicas="2.9"
ERROR validation failed: (root).replicas : must be of type string, given 2.9
I have been successful in using type: float in config.yaml for the same charm. This seems an inconsistent implementation of input schemas.
juju version 2.2.2 on xenial
It appears "number" is the proper type for a floating point value. My use of type: float in config.yaml worked in juju 1.25.6. Perhaps the types changed between versions. Will use "number" for this solution, but more useful expounding upon available types in the upgrade-charm check would be helpful.
Lastly, a number should be acceptable as a string, though I know it's not a strong type-cast, string should be allowed by juju run-action var=<number>.