Feature Request: add add-network-policy to manifest

[dustpuppyNGTI]

It is possible to set network policies using the command line:

cf add-network-policy SOURCE_APP --destination-app DESTINATION_APP --protocol (tcp | udp) --port RANGE

However it is not possible to set these values using the manifest. This makes it hard to perform deploys from automated systems.

[cf-gitbot]

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

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

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

[abbyachau]

cc @zrob

[zrob]

This is a really interesting request.

I don't know how we'll be able to accommodate it in the server side manifest world. The network policy API is a totally separate entity from the CC.

/cc @rosenhouse @ameowlia @pvaramballypivot

[rosenhouse]

@zrob what is this server-side-manifest-world that you speak of? got a link?

[zrob]

The cli will no longer parse app manifests and translate them to API requests. Instead they will send the yaml to CC and we'll apply it.

Epic: https://www.pivotaltracker.com/epic/show/3867153
API docs: http://v3-apidocs.cloudfoundry.org/version/3.55.0/index.html#app-manifest

[making]

@zrob this feature is pretty important, for example in case of the following situation:

When zero-downtime-updating App B, the following sequences are required:

1. cf rename app-b app-b-venerable
2. cf push app-b
3. cf add-network-policy app-a --destination-app app-b --port 8080
4. cf add-network-policy app-b --destination-app app-c --port 8080
5. cf unmap-route app-b-venerable apps.internal -n app-b
6. cf delete -r -f app-b-venerable

Without a support from cf cli, autopilot plugin is unavailable and it is truoublesome for deploying cf apps in concourse

It would be awesome if we could write something like:

applications:
- name: app-b
  network_policies:
  - source: app-a 
    port: 8080
    protocotl: tcp
  - destination: app-b
    port: 8080
    protocol: tcp

[rosenhouse]

I really like the model of decorating the destination (server) app with the list of allowed source (client) apps. +1 to this UX.

[zrob]

I see how that would be valuable. We'd have to teach CC how to talk to policy server. It has interesting implications for the create-manifest workflow as well.

I also wonder if there's some even simpler workflows if we went deep on CC/policy server integration

For example imagine something like

1. cf create-network networkName
2. cf add-app-to-network appName networkName
3. cf remove-app-from-network appName networkName

manifest something like this instead of using the add/remove commands

applications:
- name: app-b
  networks:
  - networkName
  - otherNetworkName

Would mean you don't have to keep a full list of apps all the time, although maybe the full list is desirable?

[ameowlia]

@zrob, it sounds like rolling deploys would fix @making's use case?

[making]

@zrob +1 for your idea.
My proposal will not work in case that App C is not deployed yet such as first deployment.
Adding the app to a logical group sounds pretty good

[kzbt]

Will this be considered in the near future?

[ameowlia]

cc/ Networking PM @adobley

[adobley]

@kzbt this is not currently planned, but we have been collecting evidence to help us scope, plan, and prioritize this feature. It is in the pipeline, but I can't give an estimate as to when. If you have a case that isn't captured above, I'd love to hear about it.

[kzbt]

@adobley Our usecase is the same/similar. We have a gateway app that controls all ingress and all internal traffic is using pcf internal routes. This makes add-network-policy a necessity for deployments. It is easy enough to automate it and we have done that in our ci pipelines, but problem arises when doing quick manual deploys to dev environments for testing etc.. because often this step is forgotten or devs don't realize it is required. Making it a declarative option in the manifest would be best as that would describe ideal state of the app in pcf once deployed.

[abbyachau]

Hi all, thanks for everyone's feedback. I'm moving this issue to the CC API's github repo since they are responsible for server side manifests for V3.