[bosh] Plans to release route-registrar?

[Cyrille Le Clerc]

Dear community,

Context: CloudBees uses route-registrar in the bosh release to deploy Jenkins Enterprise by CloudBees on CloudFoundry (Pivotal CF) to assign an "external hostname" to the deployed Jenkins Master.

Question: is there a plan to release a "stable" version of route-registrar? I feel it would help engineers who are not experts on Cloud Foundry and who maintain bosh releases to integrate route-registrar in their packaging. 

For my job of maintaining a bosh release, it would help to pick a version of route-registrar recommended by a Cloud Foundry expert and to just add the binaries file in my blob store instead of integrating a git submodule with a version identifier (commit hash) which is meaningless to me (should i upgrade to "Jan 20, 2015 - Use go v1.4.1"?).

Cyrille

[Shannon Coen]

Hello Cyrille,

Though several of the Pivotal-maintained releases use route-registrar as it provided a cheap convenience early on, we believe it sets a bad example and we intend to move away from it as soon as possible.

Route-registrar requires credentials for NATS, which has stability issues and transmits unfiltered sensitive data. In general, I don't believe components external to cf-release should have admin-level access to cf-release, and this includes listening to NATS. Where service authors have use cases for which there is no alternative, I am motivated to provide platform solutions we can recommend. Specifically, I recognize it is handy to use gorouter in cf-release for balancing http traffic across instances of a service component.

For this use case our recommended solution will be the Routing API, which is a proposal from Dieu Cao and the Runtime team. The feature will effectively offer routing-as-a-service. Stories for this epic can be found in the Runtime backlog. The design for this API will support authentication via OAuth tokens from UAA, which should support components external to cf-release.

I am thrilled that CloudBees has released the Jenkins Enterprise service for Cloud Foundry, appreciate your feedback, and look forward to your continued input to help us build a platform that enables such compelling use cases as yours.

Best,

Shannon

[Cyrille Le Clerc]

Thanks Shannon,

I fully support your opinion that bosh releases should not use any privileged credentials during the deployment phase. 

We currently use 2 types of privileged credentials during our deployments that we would be happy to no longer deal with:

• CF admin credentials for route registrar --> could it be possible, in the bosh release manifest, in the "networks" section of a job, to ask for a hostname that would be transformed into a DNS domain name by during the deployment (this attribute could seat next to the "static_ips" attribute)
• UAA admin credential to create a UAA/SSO Client ID to register our application and integrate it with UAA (done with a UAAC errand) --> could we also declare in the bosh release manifest that our application needs a UAA Client ID?

Cyrille