Whitespace in VCAP_SERVICES causing problems with some legacy dependencies

[youngm]

Hi, our users are working on migrating from DEA to Diego. One of the areas of most pain have come from white space differences of VCAP_SERVICES between DEA and Diego.

The white space differences between the 2 have exposed several bugs.

• Some specific examples are a home grown JSON parser some of our applications use. These were easy enough to fix but it makes the migration to Diego slightly more complex for our customers cause now they need to upgrade the library before they can switch to Diego.

• Another more complex situation we ran into was with a bug in the thirdpary Java iText library that does some stupid stuff (https://github.com/itext/itextpdf/blob/2.1.7/itext/src/rtf/com/lowagie/text/rtf/parser/destinations/RtfDestinationFontTable.java#L585). This library is old, thirdparty, and a free version is no longer maintained making it more difficult to fix.

We can certainly fix this and encourage all our users of this library to also upgrade. However, before doing that I thought I would propose the idea of simply making VCAP_SERVICES white space format more compatible with what DEA produces....or at the very least consider stripping all white space from VCAP_SERVICES and make that the gold standard format going forward. Zero white space VCAP_SERVICES is something you can test for and help ensure minor VCAP_SERVICES format changes in the future don't cause upgrade issues for applications with weird bugs like this.

It would be much simpler for our users if nobody needed to upgrade anything because of VCAP_SERVICES formatting differences between Diego and DEA. Thoughts?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/134111467

The labels on this github issue will be updated when the story is started.

[youngm]

Sorry I wasn't sure which component this should be logged to. I can re-issue it to the right component if necessary.

[emalm]

Thanks for pointing out this issue, @youngm. I think the difference might arise from how Cloud Controller renders the value it puts into VCAP_SERVICES. Nothing in the CC-Bridge (in this case, nsync) looks to me like it touches that value, and then from that point forward it's just another environment variable as far as Diego or Garden are concerned. @SocalNick or @utako, any thoughts on this?

Thanks,
Eric

[youngm]

@ematpl Ah, Diego just taking what capi gives is good info. Perhaps even DEA is processing it to cause the difference between the 2 runtimes. I'll do some more investigation and file another issue somewhere else. But it sounds like Diego isn't at fault here.