Are dynamic networks supported in the cf releases?

Ben

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 Integration
Pivotal

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 recent
cf releases.

Best,

Jim

On Mon, Apr 11, 2016 at 3:06 PM, Release Integration <cfruntime(a)gmail.com>
wrote:

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 Integration
Pivotal

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 onwards, I am running into
this metron agent template filling issues.


Ben R

On Mon, Apr 11, 2016 at 3:06 PM, Release Integration <cfruntime(a)gmail.com>
wrote:

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 Integration
Pivotal

As Amit wrote in the other, related thread - https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/RYMBWNUMMWSDPIE3DZ5JUVN2VNYXDWU6/

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 runtime, requiring system calls to determine IP. metron_agent is one such job, and it tends to be colocated with each other job (it is what allows all system component logs to be aggregated through the loggregator system), so this would require all Cloud Foundry VMs to be on a manual network. You don't need to manually pick the IPs, you just need to tell BOSH which IPs in the network not to use and specify these in the "reserved" range.

Since so many different components depend on being able to determine their IP via BOSH data, there's no quick workaround if you want to stick to using dynamic networks, but we're aware of this current limitation.

Thanks,
Rob & Alvaro
CF Release Integration
Pivotal

That other thread Rob and Alvaro just mentioned currently leaves open the
question of why metron_agent worked when deployed from Micro BOSH on
stemcell 3160 but started giving this error message on 3163. For sanity, I
wlll continue the discussion on that other thread.

Best,
Amit

On Tue, Apr 12, 2016 at 9:40 AM, Release Integration <cfruntime(a)gmail.com>
wrote:

As Amit wrote in the other, related thread -
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/RYMBWNUMMWSDPIE3DZ5JUVN2VNYXDWU6/

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 runtime, requiring system
calls to determine IP. metron_agent is one such job, and it tends to be
colocated with each other job (it is what allows all system component logs
to be aggregated through the loggregator system), so this would require all
Cloud Foundry VMs to be on a manual network. You don't need to manually
pick the IPs, you just need to tell BOSH which IPs in the network not to
use and specify these in the "reserved" range.

Since so many different components depend on being able to determine

their IP via BOSH data, there's no quick workaround if you want to stick to
using dynamic networks, but we're aware of this current limitation.

Thanks,
Rob & Alvaro
CF Release Integration
Pivotal