bundle deployment does not accept "1.0" as valid float

[Nobuto Murata]

deploying a bundle with juju command fails when "1.0" is specified for an option which requires float.

How to reproduce:

$ juju version
2.0-beta15-xenial-amd64

$ cat minimal-bundle.yaml
series: xenial
services:
  nova-cloud-controller:
    charm: cs:xenial/nova-cloud-controller
    num_units: 1
    options:
      worker-multiplier: 1.0

$ juju --debug deploy minimal-bundle.yaml
...
2016-08-16 18:25:43 INFO juju.api apiclient.go:537 dialing "wss://10.0.8.102:17070/model/aebacf81-78de-4fc1-8025-4a4c14d5e897/api"
2016-08-16 18:25:43 INFO juju.api apiclient.go:313 connection established to "wss://10.0.8.102:17070/model/aebacf81-78de-4fc1-8025-4a4c14d5e897/api"
2016-08-16 18:25:43 DEBUG juju.juju api.go:248 API hostnames unchanged - not resolving
2016-08-16 18:25:43 DEBUG httpbakery client.go:244 client do GET https://api.jujucharms.com/charmstore/v5/xenial/nova-cloud-controller/meta/any?include=id&include=supported-series&include=published {
2016-08-16 18:25:44 DEBUG httpbakery client.go:246 } -> error <nil>
2016-08-16 18:25:44 INFO cmd cmd.go:129 added charm cs:xenial/nova-cloud-controller-4
2016-08-16 18:25:44 INFO juju.juju api.go:74 connecting to API addresses: [10.0.8.102:17070]
2016-08-16 18:25:44 INFO juju.api apiclient.go:537 dialing "wss://10.0.8.102:17070/model/aebacf81-78de-4fc1-8025-4a4c14d5e897/api"
2016-08-16 18:25:44 INFO juju.api apiclient.go:313 connection established to "wss://10.0.8.102:17070/model/aebacf81-78de-4fc1-8025-4a4c14d5e897/api"
2016-08-16 18:25:44 DEBUG juju.juju api.go:248 API hostnames unchanged - not resolving
2016-08-16 18:25:44 DEBUG juju.api apiclient.go:588 health ping failed: connection is shut down
2016-08-16 18:25:44 DEBUG juju.api apiclient.go:588 health ping failed: connection is shut down
2016-08-16 18:25:44 DEBUG juju.api apiclient.go:588 health ping failed: connection is shut down
2016-08-16 18:25:44 ERROR cmd supercommand.go:458 cannot deploy bundle: cannot deploy application "nova-cloud-controller": option "worker-multiplier" expected float, got 1
2016-08-16 18:25:44 DEBUG cmd supercommand.go:459 (error details: [{github.com/juju/juju/cmd/juju/application/deploy.go:429: } {github.com/juju/juju/cmd/juju/application/bundle.go:192: cannot deploy bundle} {github.com/juju/juju/cmd/juju/application/bundle.go:416: cannot deploy application "nova-cloud-controller"} {option "worker-multiplier" expected float, got 1}])

[Drew Freiberger (afreiberger)]

I've run into this in a few situations. juju action.yaml also has the same issue. I have a variable that is type: number (actions.yaml equivalent to float) that doesn't accept a default value of X.0. I feel like this is a yaml pre-processing issue within juju that is truncating the floating point .0 from the values in the parsed yaml before it makes it to the schema gate checks.

I wonder if having a check that a number is an int is valid for a float value as well in the gate check, as I wouldn't expect many applications to require a decimal place (such as 1.0) in their config and not honor a floatkey = <some_int>.

If this is an issue, perhaps we should be handling float in a more string-like fashion with schema checks ensuring that the values are equivalent when typing the string as a float.

[Drew Freiberger (afreiberger)]

That is to say, this is not just limited to bundles, but also to charm definitions in config.yaml and actions.yaml as well. The CLI juju config key=1.0 will accept the input, so I think it's yaml file pre-processing which is squashing the floating point .0 out of the input.

[Tim Penhey (thumper)]

No, I don' think this is on the way in to the settings, I think it is on the way out. This could easily be checked by asking for the charm config to see if it still has the '.0', although given how things are pushed over the API, I can't be certain what you'll see.

I'd say this is more of a bug in the nova-cloud-controller charm, as "1" is a valid float value.

[Drew Freiberger (afreiberger)]

@Tim

This issue happens on any charm with a "type: float" variable and an integer or a float with a .0 is specified. In any case, an integer should be considered a float just as you say 1 is a valid zero decimal place float.

See also neutron-gateway with a worker-multiplier of 1.0

Happening on juju snap stable branch

drew@ewah:~$ juju version
2.3.1-xenial-amd64

drew@ewah:~$ grep -A9 'neutron-gateway:$' bundle-mitaka.yaml
  neutron-gateway:
    annotations:
      gui-x: '0'
      gui-y: '0'
    charm: cs:xenial/neutron-gateway
    num_units: 1
    options:
      bridge-mappings: physnet1:br-ex
      data-port: br-ex:eth1
      worker-multiplier: 1.0
drew@ewah:~$ juju deploy bundle-mitaka.yaml
[...]
- deploy application neutron-gateway on xenial using cs:neutron-gateway-244
ERROR cannot deploy bundle: cannot deploy application "neutron-gateway": option "worker-multiplier" expected float, got 1

It's not just one charm, it's

[Drew Freiberger (afreiberger)]

This does appear to be in the juju deploy bundle.yaml code.

Steps to reproduce:

1. charm create -t reactive-python foo
2. cat > foo/config.yaml
options:
  myflt:
    type: float
    default: 1.0
^D
3. cat > foo/metadata.yaml
name: foo
summary: <Fill in summary here>
maintainer: ubuntu <email address hidden>
description: |
  <Multi-line description here>
tags:
  # Replace "misc" with one or more whitelisted tags from this list:
  # https://jujucharms.com/docs/stable/authors-charm-metadata
  - misc
subordinate: false
^D
4. charm build foo
5. cat > bundle.yaml
series: trusty
services:
  foo:
    charm: ./foo/trusty/foo
    num_units: 1
    options:
      myflt: 1.0
^D
6. juju add-model test
7. juju switch test
8. juju deploy bundle.yaml

drew@ewah:~$ juju deploy bundle.yaml
Executing changes:
- upload charm ./foo/trusty/foo for series trusty
- deploy application foo on trusty using ./foo/trusty/foo
ERROR cannot deploy bundle: cannot deploy application "foo": option "myflt" expected float, got 1

9. change bundle.yaml to myflt: 1.1 remove options: section all together, both work fine. when repeating step 8.

[Drew Freiberger (afreiberger)]

FYI, just ran across another workaround:

https://github.com/openstack-charmers/openstack-on-lxd/issues/18

notes that defining a float as a string such as myflt: "1.0" works vs myflt: 1.0

[Michał Ajduk (majduk)]

This issue is still valid in 2.5-rc1-xenial-amd64

[Michał Ajduk (majduk)]

Issue is in project github.com/juju/schema

The checker accepts only float input. However every integer can be converted to float.

Hence I've proposed fix:
https://github.com/majduk/schema/tree/1613839