`cf delete app -r` deletes shared routes

[glyn]

The -r option deletes routes even if other applications are using them.

Steps to reproduce

First issue:

cf push myapp ...
cf push myapp2 ...
cf map-route myapp cfapps.io --hostname myhost
cf map-route myapp2 cfapps.io --hostname myhost

At this point cf routes shows:

space              host                                   domain      path        apps
development   myapp                               cfapps.io                  myapp
development   myapp2                             cfapps.io                  myapp2
development   myhost                              cfapps.io                  myapp,myapp2

Now issue cf delete:

cf delete myapp2 -f -r

cf routes then shows:

space              host                                 domain      path        apps
development   myapp                             cfapps.io                  myapp

The route myhost.cfapps.io has been removed from myapp, which violates the principle of least surprise.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/112901699.

[krishicks]

Hi @glyn,

I think this is something @shalako and @dkoper should look at. CLI just hits the endpoint; if a shared route should not be deleted we should be getting an error from the API.

[shalako]

@dieucao I believe the convention in CC is that recursively deleting an app deletes the relationship with other resources, but not those other resources. The service binding is deleted, but not the service instance. Similarly, I would expect the mapping to the route to be deleted, but not the route (even if the app being deleted is the only one mapped to the route). To delete both the app and the route (or the service instance), you'd have to recursively delete the parent object (the space).

This could be a regression introduced by the new mapping resource /v2/route_mappings (I don't recall routes being deleted before). Let me know if you'd like the Routing team to take a look or if CAPI will take this.

[glyn]

@krishicks thanks for directing this bug to the correct parties. I raised it against the CLI because it was presumably a CLI design decision to support -r.

[krishicks]

@glyn No worries; you did the right thing.

[glyn]

This behaviour also resulted in a bug in Spring Cloud Services. A "worker" application (part of the SCS service broker implementation) is upgraded by renaming the application, pushing the upgraded worker application, and then deleting the renamed application using cf delete ... -f -r. Unfortunately this destroys the route to the upgraded application.

A workaround is to omit the -r, but this example shows the ease with which this issue can cause problems.

[XenoPhex]

Hi @glyn thanks for raising this issue. Since the issue you've described is CC-related, and not CLI-related, we are closing this issue. Feel free to reach out to the CAPI team if you believe the recursive behavior should change.

[zrob]

i'm not following how this is a CC issue. the cli explicitly calls DELETE on the route resource.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/159407934

The labels on this github issue will be updated when the story is started.

[shalako]

@zrob The use case was deleting the app with recursive option. I would expect any relationships with other resources to be deleted (e.g. /v2/apps/:guid/routes/:guid), but would you expect the route to be deleted also? That seems surprising, considering that other apps may be using the route.