behavior difference with old ruby cli when deploying cf-release about bosh-cli HOT 5 CLOSED

What does the exact property snippet from your manifest look like? Is this on the app security groups, or which specific cloud_controller_click property is seeing this?

from bosh-cli.

Here's a trimmed, sanitized example that is very similar to the actual data in my manifest:

# configure the singleton vm
- name: singleton
  - name: cloud_controller_clock
    properties:
      cc:
        security_group_definitions:
        - name: google
          rules:
          - protocol: tcp
            destination: 216.58.195.78
            ports: "80,443"

referenced in the jobs/cloud_controller_clock/templates/cloud_controller_clock.yml.erb:

security_group_definitions: <%= p("cc.security_group_definitions").to_json %>

when prepared under the direction of the new bosh cli produces

security_group_definitions: [{"name": "google","rules":[{"protocol":"tcp","destination":"216.58.195.78","ports":80443}]}]

but under the ruby bosh cli produces the intended

security_group_definitions: [{"name": "google","rules":[{"protocol":"tcp","destination":"216.58.195.78","ports":"80,443"}]}]

from bosh-cli.

I just noticed that "80,443" looks like the (English-localized?) number 80443 with "," for thousands separator. But I don't understand why that interpretation is the default under one bosh cli and not the other. If I need to rewrite my config, could someone please suggest a workable alternative? (I'm currently trying "443,80" on the chance that avoids triggering numeric interpretation).

[edited to add] Followup: that has no effect. Now, it outputs a numeric 44380 into the JSON/YML

[edited to add] Found a workaround: adding a whitespace after the comma causes the to_json to preserve the stringiness of the value.

from bosh-cli.

I was able to reproduce this issue.

Story: https://www.pivotaltracker.com/story/show/131930999

from bosh-cli.

@w7tek looks like we wont be able to easily fix this. it appears that this is a mismatch between how golang and ruby/python/etc. handle yaml decoding. golang is correct according to yaml spec. ruby and python do opportunistic decoding as a number which is not correct according to spec (only _ should be used as a separator). it's unlikely that yaml library we use will accept the change (which i would agree with) so we are not planning to reconcile this behavior. you can avoid this parsing problem by adding a space i believe but ultimately it would be better for cloud controller configuration to take array of ports instead of a comma separated string.

from bosh-cli.