Support native CF rolling app deployments in cf-resource #78
Conversation
See: https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html [#165368744](https://www.pivotaltracker.com/story/show/165368744) Co-authored-by: Mona Mohebbi <mmohebbi@pivotal.io> Co-authored-by: Eric Promislow <eric.promislow@suse.com> Co-authored-by: Tim Downey <tdowney@pivotal.io> Co-authored-by: Connor Braa <cbraa@pivotal.io> Signed-off-by: Connor Braa <cbraa@pivotal.io>
ericpromislow
force-pushed
the
capi-native-rolling-app-deployments-165368744-pr
branch
from
d24b974 to
fd7720c
Compare
Setting use_rolling_app_deployment to true won't have any effect until PR cloudfoundry-community/cf-resource#78 is accepted. [finishes #165368744] Authored-by: Eric Promislow <eric.promislow@suse.com>
|
👀 I see lots of pivotal.io emails there - is this PR coming from a CF team by any chance? We've been trying to find new ownership of this resource as Concourse team really doesn't have the bandwidth or expertise to support this as one of our "core resources". The BOSH deployment resource, for example, is now maintained by CF at https://github.com/cloudfoundry/bosh-deployment-resource It'd be nice if a new fork could be created that leverages this behavior by default, and we could deprecate our |
|
@vito is the bosh-deployment-resource actually maintained by CF (as in a team is responsible for it) or is it maintained by @drich10 as a side-project and he happens to be involved with CF? You're correct that this came from the CF CAPI team, but we don't actually have much involvement with this resource apart from we discovered it existed and wanted to get our cool new feature in. 🙂
This could be interesting, but something we'd have to think about as a team. Cause we too are lacking in bandwith and although we have CF expertise we lack Concourse expertise! |
We'll need to have a team discussion about_if_ this is something we both want to and have the bandwidth to take on. In general, though, there's some bureaucracy involved around getting a repo made and what org (eg @cloudfoundry vs @cloudfoundry-incubator) it would belong in. This will all take some time to figure out, so I don't think we need to do anything immediately. @vito are you opposed to working with us on getting this merged to the current resource? |
|
@tcdowney Fair, I'm not really sure if there's an official CF entity that keeps it going. Maybe we could transfer this to cloudfoundry-community? 🤔 They seem to have a pattern for this sort of thing already, e.g. the Having it live in that org would make it more obvious that it's not necessarily a fully-supported/maintained project and is more reliant on the overall community for upkeep and decision-making. I'm not sure if we'd still need to find a de-facto owner/maintainer, though. No idea how push access is moderated there. I'd like to hold off on merging this until we figure that out, if it's OK with you. 🙂 |
|
@vito does concourse do CI/CD for this resource atm? |
|
After we hypothetically fork it to cf-community, if we could steal a concourse team member for part of a day to help move the CI into CAPI's concourse instance that'd be 👌and would save everybody a ton of now-and-future effort. That pipeline structure looks pretty different from ours and the PR resource is also unfamiliar to us. |
| cf.cf("version").Run() | ||
|
|
||
| if manifest != "" { | ||
| cf.ApplyManifest(currentAppName, manifest) |
There was a problem hiding this comment.
Does this order of operations require the app to already exist at least once before a rolling update can be performed? Since it appears in order to do v3-apply-manifest <app-name> you have to already have the application in place?
E.g., if the app doesn't exist yet, should this do cf v3-zdt-push with --no-start, then v3-apply-manifest, and then start application?
There was a problem hiding this comment.
I think this PR has sat long enough that a version of this resource could be built using the v7 cf cli. It has a better UX than the alpha v3- prefixed commands in the v6 CLI and is tolerant to the app not yet existing.
These docs demonstrate that workflow:
https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html
|
Hey all, what's the progress with moving this to cloudfoundry-community? We're on a gig where this feature would be useful, to avoid routes-that-were-added-after-the-first-deploy from disappearing. |
|
@cwlbraa @DanielJonesEB Sorry, dropped the ball on this. If there's still interest in moving it over just let me know where to transfer it to! We'd be happy to pair to make the hand-off go smoothly. 👍 |
|
Cheers @vito - I'll email the CFF folks and find out how we make that happen. |
|
The repo is moved! 🎊 @cwlbraa @tcdowney I've added you both as owners in a new |
7 participants
Note that when the
use_rolling_app_deploymentparameter is specified,pathmust be specified as well (this is documented in the README).This feature is now part of the cloud controller and is accessible through version 6.44 of the CLI. At some point it should be feasible to remove the
zdtpackage from this resource.See:
https://docs.cloudfoundry.org/devguide/deploy-apps/rolling-deploy.html
#165368744
Co-authored-by: Mona Mohebbi mmohebbi@pivotal.io
Co-authored-by: Eric Promislow eric.promislow@suse.com
Co-authored-by: Tim Downey tdowney@pivotal.io
Co-authored-by: Connor Braa cbraa@pivotal.io