Re: Deprecate route-sync from CFCR to CFAR

Shannon Coen
 

That issue could be addressed by having CFCR use a different router group, which is part of the solution we have proposed here: https://docs.google.com/document/d/1RXu-o44zxwrU5gKqsghT86hXKwgPrPpSk6-TWSTlrBs/edit

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


On Fri, Jul 13, 2018 at 11:47 AM Gabriel Rosenhouse <grosenhouse@...> wrote:
Also: I suspect that the CFCR route-sync feature has a dangerous interaction with CFAR Cloud Controller, if both CFCR and CFAR are sharing a TCP Routing API.  CFAR Cloud Controller creates and uses a TCP Router Group for itself, and expects to completely own that router group.  My reading of the CFCR code is that route-sync will happily discover and use that Router Group as-is.  The CFAR Routing API has no mechanism to prevent this collision, or to prevent the two clients from reserving the same TCP port for different backends.  I think that the result will be that ingress to that TCP Router Port will get load balanced to both the CFAR App and the CFCR Service.  This is likely not what the user intends.

On Fri, Jul 13, 2018 at 4:14 AM, arghya sadhu <arghya88@...> wrote:
Hi Oleksandr,

What alternative do we have if we want to use kubectl with tls

Thanks,
Arghya

On Fri, Jul 13, 2018, 3:01 PM <oslynko@...> wrote:
Hi, cf-dev

Almost one year ago CFCR has added the ability to expose applications using CFAR gorouter. This was an experiment.
We haven't added any changes to this feature for one year and plan to remove it in next release. It will greatly reduce the burden on the team.

If someone uses it, please contact us via email or Slack (#cfcr).

Thanks,
Oleksandr


Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.