1. posterid:472663
  2. CF v205 / Pushing an app

Re: CF v205 / Pushing an app

Dieu Cao <dcao@...>
 

We generally recommend to use a separate system domain from the shared apps
domain.
That could look like
Our test environment for example uses
a1.cf-app.com as the system domain and a1-app.cf-app.com as the default
shared apps domain.
This is because system components bypass cloud controller when registering
routes with the gorouter.
If you wish to use the same domain for system components and apps, a work
around is to create a space that squats on routes that would be used by
system components.

-Dieu
CF CAPI PM

On Thu, Oct 8, 2015 at 10:10 AM, Jim Park <spark(a)pivotal.io> wrote:

The cf-release templates allow for a "system_domain" (
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L616),
this allows for a separate namespace for non-app hostnames("app_domain").
Hope this helps

Thanks,


Jim

On Thu, Oct 8, 2015 at 2:49 AM Sylvain Gibier <sylvain(a)munichconsulting.de>
wrote:

Hi,

Bug ?

Pushing an application using a manifest.yml file with an host entry set
to 'api', you are able to override the default route api.<<mycf.domain>>
with the application - preventing further cf commands to work correctly, as
it redirects traffic to new application.
I would have expect an error indicating the api.<<mycf.domain>> is
already used to prevent anyone to override api, uaa and login endpoint with
a custom app. Or am I missing something?

Is it a way - to make application/host like api, uaa, login ... not been
able to be overrided by custom application binding?

Sylvain

?
attachment.html

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