[cf-dev] Deprecate route-sync from CFCR to CFAR

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Deprecate route-sync from CFCR to CFAR

oslynko
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
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8141) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Deprecate route-sync from CFCR to CFAR

arghya sadhu
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 <[hidden email]> 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

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8142) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Deprecate route-sync from CFCR to CFAR

Gabriel Rosenhouse
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 <[hidden email]> 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 <[hidden email]> 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


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8143) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8144) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Deprecate route-sync from CFCR to CFAR

oslynko
In reply to this post by oslynko
Hi Arghya,

You have mentioned in Github that you were able to overcome this issue.

For everyone else, here is the context and a bit more information.

History
In very early CFCR days, we did not support cloud provider and basically could not give access to the applications and API outside of the cluster. We had HA Proxies to give access to workloads and API.  At that point, several early adopters told us that they would like to try exposing routes in more dynamic way a-la CFAR and possibly reuse existing routing layer. The main point was that we would like to provision multiple clusters with ease and without changed to Cloud Config.
As result we created a route-sync. 

What is does
It solves two problems:
- have stable and known URL for the API, so we can use to sign the certificate
- have a way to expose applications

How we solve it now
For API, we suggest people to wire their load balancers directly and then add the URL to the manifest. For example, check how BBL does it https://github.com/cloudfoundry/bosh-bootloader/tree/master/plan-patches/cfcr-gcp

Are we diverging further from CFAR?
Yes, CFCR team is moving further to the "vanilla" Kubernetes. But we expect other team to provide solutions for both worlds. We don't have enough deep knowledge of CFAR components and getting this knowledge will slow us down in improving Kubernetes experience. 

We are ready to help anyone to understand Kubernetes more and provide better experience with both runtimes.

Sincerely,
Oleksandr
_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8150) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Deprecate route-sync from CFCR to CFAR

gberche
Hi Oleksandr and Shannon,

I wonder what's the current plan for routing to CFCR workloads from CFAR ? Is there a concensus towards the proposed usage of TCP router [1] with an associated CloudFoundryRouteController component, or rather leverage K8S cloud providers ?

Which team would be working on this as I could not yet find related stories in the routing/tcp-routing/kubo pivotal trackers [2][3][4]

Thanks in advance,

Guillaume.


On Mon, Jul 16, 2018 at 12:57 PM, Oleksandr Slynko <[hidden email]> wrote:
Hi Arghya,

You have mentioned in Github that you were able to overcome this issue.

For everyone else, here is the context and a bit more information.

History
In very early CFCR days, we did not support cloud provider and basically could not give access to the applications and API outside of the cluster. We had HA Proxies to give access to workloads and API.  At that point, several early adopters told us that they would like to try exposing routes in more dynamic way a-la CFAR and possibly reuse existing routing layer. The main point was that we would like to provision multiple clusters with ease and without changed to Cloud Config.
As result we created a route-sync. 

What is does
It solves two problems:
- have stable and known URL for the API, so we can use to sign the certificate
- have a way to expose applications

How we solve it now
For API, we suggest people to wire their load balancers directly and then add the URL to the manifest. For example, check how BBL does it https://github.com/cloudfoundry/bosh-bootloader/tree/master/plan-patches/cfcr-gcp

Are we diverging further from CFAR?
Yes, CFCR team is moving further to the "vanilla" Kubernetes. But we expect other team to provide solutions for both worlds. We don't have enough deep knowledge of CFAR components and getting this knowledge will slow us down in improving Kubernetes experience. 

We are ready to help anyone to understand Kubernetes more and provide better experience with both runtimes.

Sincerely,
Oleksandr


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8192) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_