Openstack + bosh dynamic networks For instance, cf-231/cf-233 + dynamic networks work on bosh releases up to 240 (or stemcell versions up to 3160) The moment I upgrade the stemcell to 3163 and

This will not work with dynamic networks. Many jobs in cf-release rely on data from BOSH to determine their IP so that configuration files can be rendered up-front by the director rather than at

I believe he is referring to bosh's dynamic networks: https://bosh.io/docs/networks.html#dynamic. Per another thread there seems to be an issue with metron_agent templates and dynamic networks in

Ah, I think that helps a lot. So to restate this would be a feature of the buildpacks themselves and the current buildpack contract (perhaps triggering off of detect or something) not a generic

Is it a bug of CF or Bosh ? -- Regards, Yitao

The Cloud Foundry Buildpacks project does not contain an "oracle-library" buildpack. For as list of Cloud Foundry buildpacks please see the "System Buildpacks" section of the official Cloud Foundry

Although, correct me if I'm wrong, this feature could be used as a solution for some of those cases. For example, if my application depends upon an oracle-service my node application will require the

Can you clarify the question further? What do you mean by dynamic networks? Can you describe what network topology you would like to see Cloud Foundry deployed to? Thanks, Rob & Dennis CF Release

Mike, this is so buildpacks can be composed together. For example, if a user want to use NodeJS to compile Javascript assets for a Java app (yes, there always Maven support, but some have different

Orchestrating a raft cluster in a way that requires no manual intervention is incredibly difficult. We write the PID file late for a specific

Thanks! This was happening in JBP v3.3.1, I just tested with JBPv 3.6 and it's working.

Finally got around to testing this. Preliminary testing show that "\u2028" doesn't function as a new line character in bash and causes eclipse console to wig out. I don't think "\u2028" is a viable

Hi all, The buildpacks team would like to propose a change to the nodejs buildpack. It was recently brought to our attention in this

An interesting proposal. Any thoughts about this proposal in relation to multi-buildpacks [0]? How many of the use cases for this feature go away in lue of multi-buildpack support? I think it would

This seems to be yet another way to extend buildpacks with out forking to go along with [0] and [1]. My only hope is that all these newly proposed extension mechanisms come together in a simple,

Actually, doing some further tests, I realize a mere 'join' is definitely not enough. Instead, you need to restore the raft/peers.json on each one of the 3 consul server nodes: monit stop

Very neat! Thanks a lot Eric.

Hi cf devs, I’m running a CF deployment with redundancy, and I just experienced my consul servers not being able to elect any leader. That’s a VERY frustrating situation that keeps the whole CF

Hi, Benjamin, Yes, the BOSH-Lite boxes with kernel 3.19.0-40 through 3.19.0-50 are all susceptible to the AUFS bug. Kernel versions 3.19.0-51 and later will be fine, and I believe the earliest

Hi, Sorry for the late up, but would this hit bosh-lite too? Because after it has run for a while, I’m experiencing severe similar issues with the 53 garden containers I use in Bosh-Lite. Config