Add cnb_app_lifecycle

[c0d1ngm0nk3y]

• Read the Contributing document.

Summary

This adds another app lifecycle called cnbapplifecycle to the diego-release to allow apps to build and start with cloud native buildpacks.

• cnbapplifecycle - https://github.com/cloudfoundry/cnbapplifecycle
• cloudfoundry RFC - https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0028-cnb-lifecycle.md
• Related PR: cloud_controller_ng
• Related PR: cf-deployment

Backward Compatibility

Breaking Change? No

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: c0d1ngm0nk3y / name: Ralf Pannemans (a8076f0)

[klapkov]

Looks good!

[PlamenDoychev]

Looks good to me.
This PR is basically adding a new lifecycle in diego release. The communication around the new 'cnb' lifecycle is documented in the RFC 28.

[winkingturtle-vmw]

Thanks for doing this work. I am a bit newbie when it comes to CNB, so I ask you to please help me get educated along the way. I looked through the linked issues and was not sure if there is an overall acceptance-criteria for this feature. Something in the following format would be good to start with

Scenario: describe scenario
Given I have some sort of configuration
When I do X
And do Y
Then I see the desired behavior

[ameowlia]

👋 Hi @c0d1ngm0nk3y,

There is a little bit of awkwardness about this integration that I want to call out. One group is developing this repo, but a different group of people maintain diego release.
❓ Are you going to handle bumping go/dependancies/etc?
❓ Or should we handle that in the diego-release pipeline like we do with other submodules?
❓ How do you think we should handle the maintenance long term between these two groups?

[loewenstein-sap]

There is a little bit of awkwardness about this integration that I want to call out. One group is developing this repo, but a different group of people maintain diego release. ❓ Are you going to handle bumping go/dependancies/etc? ❓ Or should we handle that in the diego-release pipeline like we do with other submodules? ❓ How do you think we should handle the maintenance long term between these two groups?

Hi @ameowlia, we planned to bump the dependencies in the cnbapplifecycle repo directly, likely with dependabot or renovate. Unless of course we should not because the general practice in the WG is to manage Go dependencies in the Bosh release. We might want to discuss challenging the status quo then though ;) because we like to be able to build the Go binary without the context of the Diego release.

Not sure what the long-term maintenance implications will be. We need to add CI to the repo (GitHub actions, if that's acceptable) and when we release, it of course needs to be bumped in the Diego release - we'll likely open PRs for this automatically. Also, we'll happily welcome contributors and/or maintainers to the new lifecycle repo.

[loewenstein-sap]

Thanks for doing this work. I am a bit newbie when it comes to CNB, so I ask you to please help me get educated along the way. I looked through the linked issues and was not sure if there is an overall acceptance-criteria for this feature. Something in the following format would be good to start with

I'd probably go with
Scenario: Deploying applications to Cloud Foundry and using Cloud Native Buildpacks for the staging process
Given I have a Java application
When I do cf push --lifecycle cnb -b paketobuildpacks/java
Then I will see the output of Paketo Buildpacks and the CNB lifecycle in my application staging log and will end up with my application running on CF.

Does that help @winkingturtle-vmw?

More context can be found in buildpacks.io and paketo.io.

[ameowlia]

Here are the four things that are top of mind for me and how they happen right now for other diego-release submodules.

1️⃣ Where will test be run
All tests for all current submodules are run in the diego-release pipeline in concourse. We have it set up so that all tests are run with the same go version that is set at the bosh release level.

2️⃣ Bumping submodules in diego release
All submodules are bumped daily in the diego-relase pipeline in concourse. This will happen automatically (I think) if this PR is merged.

3️⃣ Go Updates
Go is bumped at the diego release level. This is done in the diego release pipeline in concourse.

4️⃣ Dependency Bumps
Each repo uses dependabot and they are either automatically or manually merged.

I think we should work to keep to this pattern as much as possible. We have our working group meeting in 5 minutes :) I'm sure we'll talk more about it there.

[geofffranks]

If cnb-app-lifecycle doesn't need to import any of the go package from diego-release/src/code.cloudfoundry.org submodules, there's possibly another option that would allow cnb-app-lifecycle to be much more independent from diego-release:

• Instead of adding cnb-app-lifecycle as a submodule, we add the it as an import to the diego-release/src/code.cloudfoundry.org/tools package (or something similar)
• the diego-release package definition would then pull in source from src/code.cloudfoundry.org/vendor/...cnb-app-lifecycle
• the cnb app lifecycle team can maintain their own internal testing, go.mod, branches, and release process however they want, rather than conforming to diego-release's workflow
• diego-release CI will bump the cnb-app-lifecycle go package when it detects newly released versions of cnb-app-lifecycle

We do this pattern already in at least nats-release. Would this be any easier for all of you and seem like a reasonable alternative?

[winkingturtle-vmw]

Has this been tested on Windows? I see that RFC have no mentions of OS level, so that's a good sign, but I am not yet educated enough to understand how this works on Windows?

[modulo11]

No we have not. We removed the Windows build for now. If there's interest for Windows within the community, we can bring this up again.

[winkingturtle-vmw]

I see that cnbapplifecycle is not vendoring it's dependencies. I believe this would fail when running in an internet-less env. We attempt to provide the compilations VMs everything it needs without the need to reach to the outside.

[modulo11]

Should be fixed now.

[loewenstein]

Here are all the PRs for the implementation of the RFC for reference:

• Initial version of cnbapplifecycle cnbapplifecycle#1
• Add cnb_app_lifecycle #929
• Fix rotate database key spec cloud_controller_ng#3831
• [RFC0028] Implement Cloud Native Buildpacks lifecycle cloud_controller_ng#3778
• [RFC0028] Support for Cloud Native Buildpacks lifecycle cli#2871
• Add cnbapplifecycle to cf-deployment cf-deployment#1178
• Add acceptance tests for cnb lifecycle cf-acceptance-tests#1136

[c0d1ngm0nk3y]

If cnb-app-lifecycle doesn't need to import any of the go package from diego-release/src/code.cloudfoundry.org submodules, there's possibly another option that would allow cnb-app-lifecycle to be much more independent from diego-release:

Sounds good. We will try this.

• Instead of adding cnb-app-lifecycle as a submodule, we add the it as an import to the diego-release/src/code.cloudfoundry.org/tools package (or something similar)

Understood.

• the diego-release package definition would then pull in source from src/code.cloudfoundry.org/vendor/...cnb-app-lifecycle

But how to maintain the list of vendored folders in the spec file, like here.

• diego-release CI will bump the cnb-app-lifecycle go package when it detects newly released versions of cnb-app-lifecycle

But how to synch on the dependencies? There could be conflicts, right?

We do this pattern already in at least nats-release. Would this be any easier for all of you and seem like a reasonable alternative?

We had a look, could you please check above question.

[winkingturtle-vmw]

But how to maintain the list of vendored folders in the spec file, like here.

This would be accomplished by running the linter. We update those depdendencies by running this daily job.

[c0d1ngm0nk3y]

@winkingturtle-vmw, @geofffranks , @ameowlia We tried to use ad cnbapplifecycle as a go dependency here. Would this be an option?

• Within cnbapplifecycle, we would maintain a go.mod file and update it via dependabot
• We would regularly (once a week) release
• The dependabot of diego-release should pick up the new release

Open question: Will the automation take care of the vendoring and the spec file for copying the dependencies or do we need to do something?

[winkingturtle-vmw]

@c0d1ngm0nk3y If you add

_  "code.cloudfoundry.org/cnbapplifecycle/cmd/builder"
_  "code.cloudfoundry.org/cnbapplifecycle/cmd/launcher"

to modules.go and then from src/code.cloudfoundry.org directory you run:

go mod tidy
go mod vendor

It will bring all of the required dependencies. You then have to add cnbapplifecyle to the list of packages to use gosub replacement. After that when you run the linter (linked above), it should populate the spec file with all of the required files to be used at bosh compile time. I hope that helps.

[modulo11]

We removed the Windows build and adjusted the PR according to the instructions. @winkingturtle-vmw could you please verify that we did not miss anything?

[winkingturtle-vmw]

I think this version got bumped because cnbapplifecycle is using 1.22. We always try to stay at least one minor version behind the tip. As of today, this would be go1.21. This is because we want to make sure all components have a chance to upgrade within the 6 month window for supporting the older version.

This might be okay for now, since go1.22 has been out for a while now, but in future, we wouldn't be able to consume latest version of this module if this version is bumped at every minor bump to be the latest. In other words, when go1.23 is out, we expect this to remain the same until go1.24 is out. As that point, it could be changed to go1.23 or remain unchanged (which is also the case for many of our modules)

[winkingturtle-vmw]

I think the bump for these submodules are not related to the cnbapplifecycle work. Can you go back for these submodules to be what is at develop branch?

• routing-api
• routing-info
• garden
• guardian
• grootfs

[winkingturtle-vmw]

code.cloudfoundry.org/cnbapplifecylce is missing a LICENSE. This would get flagged during the OSL process, can we make sure that there is a LICENSE for this repo?

[pbusko]

added in cloudfoundry/cnbapplifecycle#15

[modulo11]

@winkingturtle-vmw we added the license and cut a new release.

[winkingturtle-vmw]

@modulo11 this looks good now. We now need someone to deploy this release and verify it's functionality. We have a story for this PR.

[loewenstein]

@winkingturtle-vmw what is the status of this - and what's the plan? I.e. what kind of test do you plan to do - just whether this cleanly installs with Bosh I guess?
Not sure if it helps, but we do have it running in a bbl up based installation and did not run into any issues.

[winkingturtle-vmw]

@loewenstein There is a story in our backlog to deploy this PR and verify it's functionality. We are also going to turn on CATs tests in our pipeline for this feature. Additionally, I don't see any information around what CNBs are supported in the first iteration of this feature and plans around supporting other CNBs in the future. It would be helpful for the community to know the roadmap for this feature (maybe as a markdown in cnbapplifecycle repo or a series of issues) since it's getting added for every deploy of CF. We don't have anyone assigned to the story yet, but it's in our backlog and we will get to it.

[loewenstein-sap]

Thanks @winkingturtle-vmw for the response.

I'd argue that this PRs functionality is pretty limited as it only adds another lifecycle binary to the file server.
The end to end functionality, I.e. the support for Cloud Native Buildpacks, is not available until the cf-deployment PR is merged and it is turned off by default via Cloud Controller feature gate. Wondering if the Diego-release PR is the right place for e2e checks.

Regarding the community questions: all Cloud Native Buildpacks that can tolerate cflinuxfs4 as rootfs are going to be supported.
There is a follow up rfc already merged to support cloud native Buildpacks as system Buildpacks and there should likely be a follow up to decide if there should be batteries included and which ones - I'd assume the answer will be "Yes" and "Paketo" but that is still open in terms of rfc and work distribution - probably something for the ARI WG and Buildpacks maintainers.

Once the functionality is actually available, i.e. all remaining PRs merged, it's probably time to add cloud native buildpack support to CF Docs.

TL;DR the near term roadmap for Buildpacks is documented in the RFCs, user facing documentation blocked on the open PRs and I would hope to get this PR merged soon and hopefully disentangled from an e2e test run that includes ~10 PRs with more than half of them actually already merged anyway.