CF v205 / Pushing an app


Dieu Cao <dcao@...>
 

I'll look into getting that page updated.

One known issue is that CC doesn't have a concept of a default shared
domain when pushing apps.
The CLI assumes it's the first shared domain that comes back in the list.
Depending how you're splitting your domain, you may need to create a new
shared domain, delete any other shared domains until your desired shared
domain for apps is first in the `cf domains` list and create/map routes
with your new shared app domain to existing apps.

-Dieu

On Tue, Oct 13, 2015 at 8:03 AM, Sylvain Gibier <sylvain(a)munichconsulting.de
wrote:
Hi,

Thanks for the clarification - it should be worth to update the
documentation (
http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html) - as I
followed this one, and this setting is not even mentioned anywhere.

Any known issues should I be aware before trying to split an existing CF
deployment ? Does it mean that both application and system domain go
through the same ELB (cfrouter) ? Quid of existing application deployed ?

Sylvain


Sylvain Gibier
 

Hi,

Thanks for the clarification - it should be worth to update the documentation (http://docs.cloudfoundry.org/deploying/ec2/bootstrap-aws-vpc.html) - as I followed this one, and this setting is not even mentioned anywhere.

Any known issues should I be aware before trying to split an existing CF deployment ? Does it mean that both application and system domain go through the same ELB (cfrouter) ? Quid of existing application deployed ?

Sylvain


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


Jim Park
 

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


Sylvain Gibier
 

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