search

cloudfoundry / cli

The official command line client for Cloud Foundry
https://docs.cloudfoundry.org/cf-cli
Apache License 2.0
1.75k stars 927 forks source link

Clone application #1212

Closed CAFxX closed 1 month ago

CAFxX commented 7 years ago

Command

cf clone APP OLD_APP [--no-start] [--no-routes] [--no-services] [-o/--org OLD_ORG] [-s/--space OLD_SPACE]

What occurred

currently not supported

What you expected to occur

A new APP is created with the same bits and configuration of OLD_APP (optionally from OLD_SPACE/OLD_ORG, assuming the user has access to them). If --no-start is specified, the application is only cloned but not staged/started. If --no-routes is specified, the routes of OLD_APP are not mapped to APP. If --no-services is specified, the services of OLD_APP are not bound to APP.

If cloning across spaces/orgs and a route/service is not available in the destination space/org the command should fail with a tip to run it with --no-services/--no-routes.

Use cases

The goal is to not require users to do a cf push in the following scenarios (assume the application is in production):

This will become more and more important with the fine-grained auth effort that is currently underway. Many of our users have big teams and they don't want anyone to be able to push bits (but would be fine with making a copy of an existing app).

There may be other use cases, I will update the ticket in that case.

Potential directions

The request above is about the ability to clone an application bits, not its droplet.

Some of the use-cases above may further benefit from the ability to clone the droplet, i.e. to skip the staging process. Unfortunately the CC currently does not expose the required APIs to implement cloning the droplet (it may be possible to hack together something that downloads the droplet and then re-uploads it, but it would be dirty). When and if the CC grows the required API to implement such functionality the clone command could add a --no-restage or --droplet flag to instruct the CLI to request a droplet copy instead of a bits copy.

CLI Version

cf version 6.29.2+c66d0f3.2017-08-25

CC API Endpoint Version

2.74.0

Any other relevant information

Command naming can be bikeshedded as much as required (cf clone, cf copy, cf clone-app, ...)

This would likely be useful to improve cf bg-restage, a feature that our users frequently use. (cc @ArthurHlt)

Also it would improve the user experience of restaging applications with newer buildpack versions.

cf-gitbot commented 7 years ago

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

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

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

dkoper commented 7 years ago

Hi @CAFxX

Would the user's expectation be that this command uses the same app bits, or the same droplet (which ensures same buildpack version, stack, etc.) is used?

CAFxX commented 7 years ago

For the primary use case I had in mind it would be same bits, to improve the restage process with new buildpack versions.

I can also see some use cases for cloning the droplet, maybe I can open a separate ticket for that?

dkoper commented 7 years ago

For the droplet, rather than the CLI having to download a droplet from one space and uploading it to another, it may make more sense for CC to support an operation for that.

dkoper commented 7 years ago

Btw, you're asking for a solution (a clone command). Can you explain more about the problem it is designed to solve?

CAFxX commented 7 years ago

Can you explain more about the problem it is designed to solve?

Sure! The goal is to not require users to do a cf push in the following scenarios (assume the application is in production):

This will become more and more important with the fine-grained auth effort that is currently underway. Many of our users have big teams and they don't want anyone to be able to push bits (but would be fine with making a copy of an existing app).

There may be other use cases, I will update the ticket in that case.

For the droplet, rather than the CLI having to download a droplet from one space and uploading it to another, it may make more sense for CC to support an operation for that.

Yup, that was one of the reasons this ticket is about cloning the bits and not the droplet. I know copying the bits from app to app is supported by CC, but AFAIK copying a droplet from app to app is not.

CAFxX commented 7 years ago

@dkoper I updated the first post with the use cases

mohanbabubb commented 5 years ago

Anyone seeing this! I have the usecase for my operation to move/clone the app for testing with new buildpacks without disturbing the existing one.!

abbyachau commented 5 years ago

Hi @CAFxX thanks for this and for folks who have commented. I've spoken to you before about a new rolling deployments feature that the CC API are currently implementing. Please see this feature narrative. It sounds like rolling deployments would resolve some of the use cases you've mentioned above. Is that statement accurate? What would rolling deployments not solve for your use cases?

cc @tcdowney @charleshansen @zrob

CAFxX commented 5 years ago

@abbyachau yes, zero-downtime push would solve some of the same problems; AFAICT it doesn't address:

Note that all of the things above can be done today with the current APIs, so this is merely a CLI issue.

abbyachau commented 5 years ago

cc @charleshansen @tcdowney

jenspinney commented 5 years ago

These seem like important use cases. I know you're asking for a new command for this, but as a workaround, the steps @tjvman mentioned here might help: https://github.com/cloudfoundry/cli/issues/1498#issuecomment-444211657. These steps don't address the use case of wanting to experiment with a new/different buildpack, but it may help with some of the scenarios you mentioned. Not exactly what you're looking for, but maybe it'll help some who stumble upon this GitHub issue.

CAFxX commented 5 years ago

@jenspinney thanks for pointing that out. As a matter of fact that's what we already do, so much so that we have actually partially implemented that as bg-restart in the bg-restage plugin: https://github.com/orange-cloudfoundry/cf-plugin-bg-restage/commit/0b52023b864dc0e22af8f6147ed106ce1455cc9b (that's how I know it's doable with the current API :D)

mamachanko commented 5 years ago

pardon that I haven't read the whole thread in detail yet, but could cf copy-source help?

gururajsh commented 1 month ago

Hi @CAFxX ,

At this time, we will not be able to pursue this. If this issue is still relevant, please open a new GH Issue.